26、OpenShift中的CI/CD管道与高可用架构

OpenShift中的CI/CD管道与高可用架构

1. OpenShift中的CI/CD管道

在OpenShift中，CI/CD管道是实现应用程序自动化交付的关键。Jenkins是构建和管理这些管道的常用工具，它使用Apache Groovy编程语言。下面我们将详细介绍如何在OpenShift中创建、编辑和管理CI/CD管道。

1.1 编辑Jenkinsfile

Jenkins管道的配置文件是Jenkinsfile。要编辑它，我们可以在其中添加一个新的阶段，例如“approval”阶段，该阶段将在构建和部署阶段之间添加一个手动审批步骤。以下是示例代码：

node('nodejs') {
    stage('build') {
        openshiftBuild(buildConfig: 'nodejs-mongodb-example', showBuildLogs: 'true')
    }
    stage('approval') {
        input "Approve moving to deploy stage?"
    }
    stage('deploy') {
        openshiftDeploy(deploymentConfig: 'nodejs-mongodb-example')
    }
}

编辑完成后，点击保存并启动管道。

1.2 管理管道执行

添加“approval”阶段后，第二次构建将启动，并且你将看到新的审批阶段，显示“Input Required”。点击“Input Required”将打开一个新标签页，重定向到Jenkins审批阶段，询问是否批准进入部署阶段。根据你的回答，结果将有所不同。如果点击“Proceed”按钮，将重定向到Jenkins控制台输出，但你可以关闭它并返回OpenShift管道标签页。此时，CI/CD管道将完成部署阶段，并且你将在“Overview”菜单中看到一个新的“nodejs-mongodb-example, #2”Pod正在运行。

1.3 相关问题解答

以下是一些关于CI/CD管道的常见问题及答案：
1. 哪种CI/CD方法允许在没有任何人工干预的情况下自动化应用程序交付过程？
- 答案：Continuous deployment
2. OpenShift使用哪三个CI/CD管道组件？
- 答案：OpenShift Domain Specific Language、Jenkins Pipeline Build Strategy、Jenkinsfile
3. 是否需要手动配置OpenShift管道与Jenkins的OpenShift认证？
- 答案：False
4. Jenkinsfile中哪个命令允许实现手动审批程序？
- 答案：Input
5. OpenShift GUI中的哪个菜单可以带你到OpenShift管道页面？
- 答案：Build | Pipelines
6. Jenkinsfile中的CI/CD管道阶段是预定义的，不能更改吗？
- 答案：False

2. 高可用性概述

高可用性（HA）是确保系统长时间运行的重要概念。在实际业务中，任何业务都不希望出现系统故障，因为这可能导致人员失业和公司破产。为了提供高可用性，系统的每个组件都需要具备容错能力，并且所有的底层和上层组件及协议都必须高度可用。例如，如果OpenShift以HA模式设计和实现，但网络存在单点故障，应用程序仍将停止工作。因此，正确规划和设计HA架构至关重要。

3. OpenShift中的高可用性

在OpenShift中，高可用性的实现涉及多个方面，包括网络、节点、存储等。以下是OpenShift经典架构和HA架构的对比：
| 架构类型 | 描述 |
| ---- | ---- |
| OpenShift经典架构 | 包含节点、主节点、存储和由基础设施节点组成的路由层 |
| OpenShift HA架构 | 与经典架构类似，但在路由层使用负载均衡器，使整个解决方案始终可访问，其他组件本质上是冗余的 |

3.1 虚拟IP（VIP）

在OpenShift HA架构中，使用企业负载均衡器和两个虚拟IP（VIP）。一个VIP用于主节点的流量，另一个VIP用于OpenShift节点上运行的实际应用程序的流量。使用VIP的原因是DNS负载均衡存在局限性，如果使用DNS负载均衡，当某个主节点或节点出现故障时部分流量仍会流向故障节点。而负载均衡器可以实现健康检查，并停止向故障端点路由流量。

以下是一个示例表格，展示了节点的物理IP地址、虚拟IP地址和DNS映射：
| 节点名称 | 物理IP地址 | 虚拟IP地址 | DNS |
| ---- | ---- | ---- | ---- |
| Infra1 | 10.0.0.1/24 | 10.0.0.11 | .apps.osp.com |
| Infra2 | 10.0.0.2/24 | 10.0.0.11 | .apps.osp.com |
| Infra3 | 10.0.0.3/24 | 10.0.0.11 | *.apps.osp.com |
| Master1 | 10.0.1.4/24 | 10.0.0.14 | console.osp.com |
| Master2 | 10.0.1.5/24 | 10.0.0.14 | console.osp.com |
| Master3 | 10.0.1.6/24 | 10.0.0.14 | console.osp.com |

使用外部负载均衡器是构建OpenShift HA的理想选择，但它也有一些缺点，例如需要额外的配置和维护，并且商业负载均衡器设备可能非常昂贵。

3.2 IP故障转移

另一种确保OpenShift应用程序始终可从外部访问的方法是实现IP故障转移机制。这种方法适用于没有外部负载均衡器的情况。OpenShift IP故障转移设计主要依赖于两种技术：
- Keepalived ：提供OpenShift基础设施节点上VIP的高可用性。
- DNS ：管理外部流量负载均衡。

以下是一个使用Keepalived和DNS的示例表格：
| 节点名称 | 物理IP地址 | 虚拟IP地址 | DNS |
| ---- | ---- | ---- | ---- |
| Infra1 | 10.0.0.1/24 | 10.0.0.11 | .apps.osp.com |
| Infra2 | 10.0.0.2/24 | 10.0.0.12 | .apps.osp.com |
| Infra3 | 10.0.0.3/24 | 10.0.0.13 | *.apps.osp.com |
| Master1 | 20.0.0.1/24 | 20.0.0.11 | console.osp.com |
| Master2 | 20.0.0.2/24 | 20.0.0.12 | console.osp.com |
| Master3 | 20.0.0.3/24 | 20.0.0.13 | console.osp.com |

这种方法的缺点是，如果某个节点出现故障，可能会导致其他节点负载过重。因此，在使用这种方法时，需要仔细考虑各种可能的情况。

3.3 OpenShift基础设施节点

OpenShift基础设施节点默认标记为“infra”，它们运行两个主要的OpenShift组件：OpenShift内部注册表和OpenShift路由器。为了确保高可用性，建议至少安装三个基础设施节点，并为注册表和路由器启用Pod反亲和性特性。这样可以防止在同一节点上运行多个注册表或路由器，避免端口冲突。

3.4 OpenShift主节点

OpenShift主节点是控制平面节点，是OpenShift解决方案的核心控制点。在早期版本中，需要使用Pacemaker来安装OpenShift主节点以提供故障转移，但在最近的版本中，这由Keepalived和外部存储来处理。如果某个主节点完全失败，可以使用“oc delete node”命令删除该节点，然后从“openshift-ansible”项目中运行“scaleup.yml”文件来重新安装。如果所有主节点都丢失，虽然不会影响最终用户和应用程序之间的流量，但将无法对OpenShift集群进行任何新的更改，此时只能从最后一次备份中恢复主节点。

3.5 OpenShift etcd

OpenShift etcd键值存储是OpenShift中最关键和敏感的组件，因为所有OpenShift主节点的持久数据都保存在etcd集群中。etcd本身以主动/主动配置运行，并在初始安装时进行安装。建议在专用节点上安装和配置etcd集群，数量为三个、五个或七个成员。同时，定期备份etcd数据非常重要，因为在某些情况下可能需要恢复它。

3.6 OpenShift节点

OpenShift节点在高可用性方面相对容易管理。由于OpenShift Pod本质上是无状态的，我们只需要确保应用程序Pod在不同的OpenShift节点上运行，这样如果某个节点出现故障，最终用户不会有停机时间，并且复制控制器将启动新的应用程序Pod。如果某个节点完全失败，可以使用“oc delete node”命令删除该节点，然后从“openshift-ansible”项目中运行“scaleup.yml”文件来重新安装。

3.7 外部存储

对于OpenShift的持久数据，外部存储的配置和设计也非常重要。虽然本书未详细介绍，但一般建议确保外部存储具有冗余性和可扩展性，以便在一个或多个组件出现故障时不影响整体存储性能，并且始终可由OpenShift访问。同时，需要单独处理定期的外部存储备份和恢复程序，并确保有经过测试和验证的程序来处理持久存储数据丢失的情况。

4. OpenShift备份和恢复

无论如何，OpenShift集群可能会出现问题，导致部分或全部数据丢失。因此，了解何时以及如何进行OpenShift备份以及如何将OpenShift恢复到可操作状态非常重要。

4.1 需要备份的组件

OpenShift安装过程中需要备份的组件包括：
- Etcd键值存储数据
- 主节点配置数据
- Ansible主机安装剧本
- Pod数据
- 注册表数据
- 项目配置数据
- 额外安装的软件

4.2 etcd键值存储备份和恢复

etcd备份过程可以在任何etcd节点上执行，步骤如下：
1. 停止etcd服务： systemctl stop etcd
2. 创建etcd备份： etcdctl backup --data-dir /var/lib/etcd --backup-dir ~/etcd.back
3. 复制etcd数据库文件： cp /var/lib/etcd/member/snap/db ~/etcd/member/snap/db
4. 启动etcd服务： systemctl start etcd

etcd键值存储恢复过程也在etcd节点上执行，步骤如下：
1. 创建单节点集群
2. 在etcd停止运行时，从备份中恢复数据到 /var/lib/etcd/
3. 从备份中恢复 /etc/etcd/etcd.conf

通过以上步骤，可以确保在出现问题时能够及时备份和恢复OpenShift集群的数据，保证系统的高可用性和数据的安全性。

OpenShift中的CI/CD管道与高可用架构

5. 高可用架构总结与对比

为了更清晰地理解OpenShift不同组件在高可用架构中的特点和差异，我们将之前介绍的内容进行总结和对比，以下是一个综合表格：
| 组件 | 高可用实现方式 | 优点 | 缺点 |
| ---- | ---- | ---- | ---- |
| 网络（负载均衡） | 企业负载均衡器 + 两个VIP | 确保集群始终可从外部访问，可进行健康检查和流量分配 | 需要额外配置和维护，商业负载均衡器昂贵 |
| 网络（IP故障转移） | Keepalived + DNS | 无需外部负载均衡器也可保证外部访问 | 可能导致节点负载过重 |
| 基础设施节点 | 至少三个节点 + Pod反亲和性 | 避免端口冲突，提高可用性 | 增加节点数量和配置复杂度 |
| 主节点 | Keepalived + 外部存储 | 提供故障转移功能 | 若全部丢失需从备份恢复 |
| etcd | 主动/主动配置，专用节点 | 存储关键持久数据 | 需要定期备份和合理设计集群 |
| 普通节点 | 多节点运行Pod | 无状态Pod可自动恢复 | 无明显缺点，但需确保节点资源充足 |

通过这个表格，我们可以更直观地看到不同组件在高可用架构中的优劣，从而根据实际需求进行合理选择和配置。

6. 高可用架构流程图

下面是一个mermaid格式的流程图，展示了OpenShift高可用架构中，当某个节点出现故障时的处理流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([节点故障发生]):::startend --> B{故障节点类型?}:::decision
    B -->|基础设施节点| C(Keepalived检测故障):::process
    B -->|主节点| D(Keepalived和外部存储处理):::process
    B -->|普通节点| E(复制控制器启动新Pod):::process
    C --> F{是否使用负载均衡?}:::decision
    F -->|是| G(负载均衡器移除故障节点):::process
    F -->|否| H(IP故障转移，VIP迁移):::process
    G --> I(流量重新分配):::process
    H --> J(可能导致其他节点负载增加):::process
    D --> K(可删除故障节点并重新安装):::process
    E --> L(确保应用无停机时间):::process
    I --> M([系统恢复正常]):::startend
    J --> N{是否超出节点负载?}:::decision
    N -->|是| O(需考虑扩容或调整配置):::process
    N -->|否| M
    K --> M
    L --> M

这个流程图清晰地展示了不同类型节点出现故障时的处理步骤，以及可能出现的情况和后续操作。

7. 高可用架构的实际应用建议

在实际应用中，为了确保OpenShift集群的高可用性，我们可以遵循以下建议：
1. 规划阶段
- 对网络架构进行全面评估，确定是否使用外部负载均衡器或IP故障转移机制。如果预算充足且对系统可用性要求极高，建议使用外部负载均衡器；如果预算有限，可以考虑IP故障转移。
- 合理规划节点数量和分布，至少确保有三个基础设施节点和三个主节点，以提高容错能力。
- 为etcd集群选择专用节点，并根据实际需求确定节点数量（三个、五个或七个）。
2. 配置阶段
- 为基础设施节点的注册表和路由器启用Pod反亲和性特性，避免端口冲突。
- 定期备份etcd数据和其他重要组件的数据，制定详细的备份计划。
- 调整Ansible库存文件，确保在需要时可以方便地添加新节点。
3. 监控和维护阶段
- 建立完善的监控系统，实时监控节点的运行状态、负载情况和网络流量。
- 定期进行故障模拟测试，验证高可用架构的有效性和恢复能力。
- 及时更新OpenShift版本和相关组件，以获取最新的安全补丁和功能改进。

8. 总结

OpenShift的CI/CD管道和高可用架构是确保应用程序高效交付和系统稳定运行的关键。通过合理配置CI/CD管道，可以实现应用程序的自动化交付，提高开发和部署效率。而高可用架构则从网络、节点、存储等多个方面入手，确保系统在面对各种故障时能够快速恢复，保证业务的连续性。

在实际应用中，我们需要根据具体的业务需求和预算情况，选择合适的高可用架构方案，并严格按照操作步骤进行配置和维护。同时，定期备份数据和进行故障模拟测试也是必不可少的，以确保系统的安全性和可靠性。希望本文能够为你在OpenShift的使用和管理中提供有价值的参考。