引言

Kubernetes 集群的node节点版本更新是保证系统稳定性和高可用性的重要手段。传统的节点更新方式往往涉及运维手动操作，效率低且容易出错。本文将介绍如何利用 GitHub Actions 来实现 Kubernetes 集群node节点的自动化滚动更新，提高运维效率，降低人为错误风险，并深入探讨这种自动化方式带来的诸多益处。

客户背景

客户的 Kubernetes 集群分布在多个云服务平台上(ali、azure、aws)，每个平台的节点更新方式和管理工具都略有不同。同时，客户希望对这些集群进行统一管理，以便更好地了解集群状态、配置变更和资源利用情况。为了解决客户问题，我们提出了一种基于 GitHub Actions 和 CMDB 的协同处理来进行自动化操作的解决方案。通过将node节点更新流程自动化，并结合 CMDB 的统一管理功能，可以显著提高更新效率，降低人为错误风险，并实现对多云环境的集中管理。

解决方案：基于 GitHub Actions 和 CMDB 的自动化更新

核心思路

1. CMDB 统一管理：将所有集群的信息（如节点、应用、配置等）统一存储在 CMDB 中。
2. GitHub Actions 自动化：基于 GitHub Actions 工作流，实现节点更新的自动化触发和执行，结果回调至cmdb。
3. API 集成：通过调用 CMDB 的 API 获取集群信息，并调用各云平台的 API 执行更新操作。
4. 配置驱动：通过配置驱动的方式，实现不同集群的更新策略和参数的灵活配置。

解决方案细节

CMDB 集成

1. 数据同步：定期将集群信息同步到 CMDB 中，保持数据一致性。
2. API 调用：通过 CMDB 的 API 获取需要更新的节点信息、更新策略等。

GitHub Actions 工作流设计

1. 触发方式：支持多种触发方式，如定时触发、手动触发、事件触发等。
2. 节点选择：从 CMDB 获取需要更新的节点列表，并根据配置进行筛选。
3. 更新策略：支持滚动更新、蓝绿部署等多种更新策略。
4. 健康检查：集成 Kubernetes 的健康检查机制，确保更新后的节点正常运行。
5. 回滚机制：提供回滚机制，以便在更新失败时快速恢复。
6. 通知：通过 Slack、邮件或 CMDB 自身的通知机制通知更新结果。

多云适配

1. 云平台 API：针对不同的云平台（如 AWS、Azure、GCP），调用相应的 API 执行更新操作。
2. 配置管理：通过 CMDB 配置不同的云平台的认证信息和配置参数。

自定义脚本

支持编写自定义脚本，实现复杂的更新逻辑，例如：

• 更新节点上的特定软件包
• 配置节点防火墙
• 执行自定义的健康检查

为什么选择 GitHub Actions？

1. 自动化：将节点更新过程自动化，减少人工干预，降低人为错误的可能性。
2. 灵活配置：支持自定义工作流程，适应不同规模和复杂度的 Kubernetes 集群。
3. 与 Kubernetes 集成：可以轻松调用 Kubernetes API 进行节点操作，实现无缝集成。
4. 与其他工具集成：可以与其他 CI/CD 工具、监控工具等集成，构建完整的 DevOps 流水线。
5. 可追溯性：GitHub Actions 提供详细的运行日志和历史记录，方便问题排查和审计。

自动化节点滚动更新的价值

1. 提高效率：节省了大量的人工操作时间，提高了运维效率。
2. 降低风险：自动化流程减少了人为错误的可能性，降低了更新失败的风险。
3. 增强稳定性：通过滚动更新的方式，确保服务在更新过程中保持可用性。
4. 提高可靠性：定期更新节点可以修复漏洞、提升系统性能，增强系统可靠性。
5. 促进持续交付：将节点更新纳入到 CI/CD 流水线中，实现持续交付。

客户收益

1. 统一管理：通过 CMDB 实现对多云环境的统一管理，提高运维效率。
2. 自动化更新：节省了大量的人工操作时间，降低了人为错误风险。
3. 增强一致性：统一的更新流程保证了不同云平台上节点更新的一致性。
4. 提高可靠性：定期更新节点可以修复漏洞、提升系统性能，增强系统可靠性。
5. 促进持续交付：将节点更新纳入到 CI/CD 流水线中，实现持续交付。

实现步骤

1. 创建 GitHub 仓库

• 创建一个新的 GitHub 仓库，用于存放 Kubernetes 配置文件和 GitHub Actions 工作流文件。

2. 编写 Kubernetes 配置文件

• 创建一个 Deployment 或 StatefulSet 资源，定义要更新的应用。
• 创建一个 DaemonSet 资源，用于部署节点级别的守护进程（如监控、日志收集等）。

3. 编写 GitHub Actions 工作流文件

• 以aws 集群为例创建一个 .github/workflows/node-update.yml 文件，定义工作流（因考虑篇幅， 只展示核心逻辑）：

name: Node Update
on:workflow_dispathch:
jobs:
  update-nodes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Configure kubectl
        uses: actions/setup-kubectl@v2
      - name: Update images
        run:
          # Retrieve Launch Template ID and Version
        launch_template_id=$(aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name $NODEGROUP_NAME --query'nodegroup.launchTemplate.id' --output text)
        launch_template_version=$(aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name $NODEGROUP_NAME --query'nodegroup.launchTemplate.version' --output text)
        # Retrieve Latest EKS-optimized AMI ID
        latest_image_id=$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/$K8S_VERSION/amazon-linux-2/recommended/image_id --region $REGION --query "Parameter.Value" --output text)
        # Create New Launch Template Version
        new_version=$(aws ec2 create-launch-template-version --launch-template-id $launch_template_id --source-version $launch_template_version --launch-template-data "{\"ImageId\":\"$latest_image_id\"}" --query 'LaunchTemplateVersion.VersionNumber' --output text)
        
        UPDATE_RESPONSE=$(aws eks update-nodegroup-version --cluster-name $CLUSTER_NAME --nodegroup-name $NODEGROUP_NAME --launch-template"version=$new_version,id=$launch_template_id" --force)
        UPDATE_ID=$(echo $UPDATE_RESPONSE | jq -r '.update.id')
        
        # check upgrade result
        while true; do
            UPDATE_STATUS=$(aws eks describe-update --name $CLUSTER_NAME --nodegroup-name $NODEGROUP_NAME --update-id $UPDATE_ID  --query 'update.status'--output text)
            case $UPDATE_STATUS in
                "Failed")
                    echo "Cluster upgrade failed."
                    exit 1
                    ;;
                "Successful")
                    echo "Cluster upgrade completed successfully."
                    exit 0
                    ;;
                "InProgress")
                    echo "Cluster upgrade is still in progress..."
                    sleep 10
                    ;;
                *)
                    echo "Unknown status: $UPDATE_STATUS"
                    exit 1
                    ;;
            esac
        done

4. 配置触发条件

可以根据需求配置触发条件，比如：

• 定时触发
• 手动触发
• 代码提交触发
• AP 请求出发

5. 执行工作流

• 推送代码到 GitHub 仓库，触发工作流。
• cmdb 执行远程触发

6. 回调CMDB

• github actions执行执行情况告知cmdb，cmdb收到请求同步做出变更及行为记录

案例分析：AWS EKS 集群节点更新

上述示例展示了如何在 AWS EKS 集群上进行节点更新。通过更新 Launch Template，我们可以轻松地将新的 AMI 应用到节点上，实现节点的滚动更新。

优势：

• 利用 AWS EKS 的原生功能，实现高效的节点更新。
• 可以灵活配置 AMI、实例类型等参数。
• 集成了 AWS 的安全和访问控制机制。

注意事项：

• 确保 AWS 凭证配置正确。
• 注意更新过程中对集群的影响，可以考虑设置最小节点数。

总结

通过 GitHub Actions 实现 Kubernetes 集群节点的自动化滚动更新，可以显著提高运维效率，降低人为错误风险，并增强系统的稳定性和可靠性。本文提供了一个基本的实现方案，您可以根据实际需求进行定制和扩展。

扩展

1. 多集群支持：可以通过配置不同的 kubeconfig 文件来支持多个 Kubernetes 集群。
2. 自定义脚本：可以编写自定义脚本，实现更复杂的更新逻辑。
3. 与其他工具集成：可以与 Prometheus、Grafana 等工具集成，实现更全面的监控和告警。

建议

1. 结合具体场景：在实际应用中，可以根据不同的 Kubernetes 发行版（如 GKE、AKS、自建集群）、云厂商和应用场景，对上述方案进行适配。
2. 安全考虑：在进行节点更新时，务必注意安全，避免引入新的漏洞。
3. 持续优化：随着 Kubernetes 的不断发展，可以持续优化和改进自动化流程。

参考资源

• Kubernetes 官方文档
• GitHub Actions 官方文档
• 云厂商提供的 Kubernetes 解决方案文档

通过不断探索和实践，您可以构建一套高效、可靠的 Kubernetes 集群节点更新自动化方案。