当前位置：首页 > news >正文

基于 GitHub Actions 的 Kubernetes 集群节点变更操作自动化

news 2025/9/17 6:50:27

引言

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

客户背景

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

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

核心思路

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

解决方案细节

CMDB 集成

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

GitHub Actions 工作流设计

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

多云适配

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

自定义脚本

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

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

为什么选择 GitHub Actions？

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

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

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

客户收益

统一管理：通过 CMDB 实现对多云环境的统一管理，提高运维效率。
自动化更新：节省了大量的人工操作时间，降低了人为错误风险。
增强一致性：统一的更新流程保证了不同云平台上节点更新的一致性。
提高可靠性：定期更新节点可以修复漏洞、提升系统性能，增强系统可靠性。
促进持续交付：将节点更新纳入到 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-lateststeps:- uses: actions/checkout@v3- name: Configure kubectluses: actions/setup-kubectl@v2- name: Update imagesrun:# Retrieve Launch Template ID and Versionlaunch_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 IDlatest_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 Versionnew_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 resultwhile true; doUPDATE_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;;esacdone