- 最新动态
- 功能总览
-
服务公告
- 最新公告
- 产品变更公告
- 集群版本公告
-
漏洞公告
- 漏洞修复策略
- Kubernetes安全漏洞公告(CVE-2024-10220)
- Kubernetes安全漏洞公告(CVE-2024-9486,CVE-2024-9594)
- NVIDIA Container Toolkit容器逃逸漏洞公告(CVE-2024-0132)
- Linux CUPS服务RCE 漏洞公告(CVE-2024-47076、CVE-2024-47175、CVE-2024-47176、CVE-2024-47177)
- NGINX Ingress控制器验证绕过漏洞公告(CVE-2024-7646)
- Docker Engine授权插件AuthZ权限绕过漏洞公告(CVE-2024-41110)
- Linux内核权限提升漏洞公告(CVE-2024-1086)
- OpenSSH远程代码执行漏洞公告(CVE-2024-6387)
- Fluent Bit内存崩溃漏洞公告(CVE-2024-4323)
- runc systemd属性注入漏洞公告(CVE-2024-3154)
- runc漏洞(CVE-2024-21626)对CCE服务的影响说明
- Kubernetes安全漏洞公告(CVE-2022-3172)
- Linux Kernel openvswitch 模块权限提升漏洞预警(CVE-2022-2639)
- nginx-ingress插件安全漏洞预警公告(CVE-2021-25748)
- nginx-ingress插件安全漏洞预警公告(CVE-2021-25745,CVE-2021-25746)
- containerd容器进程权限提升漏洞公告(CVE-2022-24769)
- CRI-O容器运行时引擎任意代码执行漏洞(CVE-2022-0811)
- linux内核导致的容器逃逸漏洞公告(CVE-2022-0492)
- containerd镜像Volume非安全处理漏洞公告(CVE-2022-23648)
- Linux内核整数溢出漏洞(CVE-2022-0185)
- Linux Polkit 权限提升漏洞预警(CVE-2021-4034)
- Kubernetes subpath符号链接交换安全漏洞(CVE-2021- 25741)
- runc符号链接挂载与容器逃逸漏洞预警公告(CVE-2021-30465)
- Docker资源管理错误漏洞公告(CVE-2021-21285)
- NVIDIA GPU驱动漏洞公告(CVE-2021-1056)
- Sudo缓冲区错误漏洞公告(CVE-2021-3156)
- Kubernetes安全漏洞公告(CVE-2020-8554)
- Apache containerd安全漏洞公告(CVE-2020-15257)
- Docker Engine输入验证错误漏洞公告(CVE-2020-13401)
- Kubernetes kube-apiserver输入验证错误漏洞公告(CVE-2020-8559)
- Kubernetes kubelet资源管理错误漏洞公告(CVE-2020-8557)
- Kubernetes kubelet和kube-proxy授权问题漏洞公告(CVE-2020-8558)
- 修复Kubernetes HTTP/2漏洞公告
- 修复Linux内核SACK漏洞公告
- 修复Docker操作系统命令注入漏洞公告(CVE-2019-5736)
- 全面修复Kubernetes权限许可和访问控制漏洞公告(CVE-2018-1002105)
- 修复Kubernetes Dashboard安全漏洞公告(CVE-2018-18264)
-
产品发布记录
-
集群版本发布记录
- Kubernetes版本策略
-
Kubernetes版本发布记录
- Kubernetes 1.31版本说明
- Kubernetes 1.30版本说明
- Kubernetes 1.29版本说明
- Kubernetes 1.28版本说明
- Kubernetes 1.27版本说明
- Kubernetes 1.25版本说明
- Kubernetes 1.23版本说明
- (停止维护)Kubernetes 1.21版本说明
- (停止维护)Kubernetes 1.19版本说明
- (停止维护)Kubernetes 1.17版本说明
- (停止维护)Kubernetes 1.15版本说明
- (停止维护)Kubernetes 1.13版本说明
- (停止维护)Kubernetes 1.11版本说明
- (停止维护)Kubernetes 1.9及之前版本说明
- 补丁版本发布记录
- 操作系统镜像发布记录
-
插件版本发布记录
- CoreDNS域名解析插件版本发布记录
- CCE容器存储插件(Everest)版本发布记录
- CCE节点故障检测插件版本发布记录
- Kubernetes Dashboard插件版本发布记录
- CCE集群弹性引擎版本发布记录
- NGINX Ingress控制器插件版本发布记录
- Kubernetes Metrics Server插件版本发布记录
- CCE容器弹性引擎插件版本发布记录
- CCE突发弹性引擎(对接CCI)插件版本发布记录
- CCE AI套件(NVIDIA GPU)版本发布记录
- CCE AI套件(Ascend NPU)版本发布记录
- Volcano调度器版本发布记录
- CCE密钥管理(对接 DEW)插件版本发布记录
- CCE容器网络扩展指标插件版本发布记录
- 节点本地域名解析加速插件版本发布记录
- 云原生监控插件版本发布记录
- 云原生日志采集插件版本发布记录
- 容器镜像签名验证插件版本发布记录
- Grafana插件版本发布记录
- OpenKruise插件版本发布记录
- Gatekeeper插件版本发布记录
- 容器垂直弹性引擎版本发布记录
- CCE集群备份恢复插件版本发布记录(停止维护)
- Kubernetes Web终端版本发布记录(停止维护)
- Prometheus插件版本发布记录(停止维护)
-
集群版本发布记录
- 产品介绍
- 计费说明
- Kubernetes基础知识
- 快速入门
-
用户指南
- 高危操作一览
-
集群
- 集群概述
-
集群版本发布说明
-
Kubernetes版本发布记录
- Kubernetes 1.31版本说明
- Kubernetes 1.30版本说明
- Kubernetes 1.29版本说明
- Kubernetes 1.28版本说明
- Kubernetes 1.27版本说明
- Kubernetes 1.25版本说明
- Kubernetes 1.23版本说明
- (停止维护)Kubernetes 1.21版本说明
- (停止维护)Kubernetes 1.19版本说明
- (停止维护)Kubernetes 1.17版本说明
- (停止维护)Kubernetes 1.15版本说明
- (停止维护)Kubernetes 1.13版本说明
- (停止维护)Kubernetes 1.11版本说明
- (停止维护)Kubernetes 1.9及之前版本说明
- 补丁版本发布记录
-
Kubernetes版本发布记录
- 购买集群
- 连接集群
- 管理集群
-
升级集群
- 升级集群的流程和方法
- 升级前须知
- 升级后验证
- 集群跨版本业务迁移
-
升级前检查异常问题排查
- 升级前检查项
- 节点限制检查异常处理
- 升级管控检查异常处理
- 插件检查异常处理
- Helm模板检查异常处理
- Master节点SSH连通性检查异常处理
- 节点池检查异常处理
- 安全组检查异常处理
- 残留待迁移节点检查异常处理
- K8s废弃资源检查异常处理
- 兼容性风险检查异常处理
- 节点上CCE Agent版本检查异常处理
- 节点CPU使用率检查异常处理
- CRD检查异常处理
- 节点磁盘检查异常处理
- 节点DNS检查异常处理
- 节点关键目录文件权限检查异常处理
- 节点Kubelet检查异常处理
- 节点内存检查异常处理
- 节点时钟同步服务器检查异常处理
- 节点OS检查异常处理
- 节点CPU数量检查异常处理
- 节点Python命令检查异常处理
- ASM网格版本检查异常处理
- 节点Ready检查异常处理
- 节点journald检查异常处理
- 节点干扰ContainerdSock检查异常处理
- 内部错误异常处理
- 节点挂载点检查异常处理
- K8s节点污点检查异常处理
- everest插件版本限制检查异常处理
- cce-hpa-controller插件限制检查异常处理
- 增强型CPU管理策略检查异常处理
- 用户节点组件健康检查异常处理
- 控制节点组件健康检查异常处理
- K8s组件内存资源限制检查异常处理
- K8s废弃API检查异常处理
- 节点NetworkManager检查异常处理
- 节点ID文件检查异常处理
- 节点配置一致性检查异常处理
- 节点配置文件检查异常处理
- CoreDNS配置一致性检查异常处理
- 节点Sudo检查异常处理
- 节点关键命令检查异常处理
- 节点sock文件挂载检查异常处理
- HTTPS类型负载均衡证书一致性检查异常处理
- 节点挂载检查异常处理
- 节点paas用户登录权限检查异常处理
- ELB IPv4私网地址检查异常处理
- 检查历史升级记录是否满足升级条件
- 检查集群管理平面网段是否与主干配置一致
- GPU插件检查异常处理
- 节点系统参数检查异常处理
- 残留packageversion检查异常处理
- 节点命令行检查异常处理
- 节点交换区检查异常处理
- NGINX Ingress控制器插件升级检查异常处理
- 云原生监控插件升级检查异常处理
- Containerd Pod重启风险检查异常处理
- GPU插件关键参数检查异常处理
- GPU/NPU Pod重建风险检查异常处理
- ELB监听器访问控制配置项检查异常处理
- Master节点规格检查异常处理
- Master节点子网配额检查异常处理
- 节点运行时检查异常处理
- 节点池运行时检查异常处理
- 检查节点镜像数量异常处理
- OpenKruise插件兼容性检查异常处理
- Secret落盘加密特性兼容性检查异常处理
- Ubuntu内核与GPU驱动兼容性提醒
- 排水任务检查异常处理
- 节点镜像层数量异常检查
- 检查集群是否满足滚动升级条件
- 轮转证书文件数量检查
- Ingress与ELB配置一致性检查
- 集群网络组件的NetworkPolicy开关检查
- 集群与节点池配置管理检查
- Master节点时区检查
- 集群管理最佳实践
- 节点
- 节点池
- 工作负载
- 调度
-
网络
- 网络概述
- 容器网络
-
服务(Service)
- 服务概述
- 集群内访问(ClusterIP)
- 节点访问(NodePort)
-
负载均衡(LoadBalancer)
- 创建负载均衡类型的服务
- 使用Annotation配置负载均衡类型的服务
- 为负载均衡类型的Service配置HTTP/HTTPS协议
- 为负载均衡类型的Service配置服务器名称指示(SNI)
- 为负载均衡类型的Service配置跨集群的后端
- 为负载均衡类型的Service配置HTTP/2
- 为负载均衡类型的Service配置HTTP/HTTPS头字段
- 为负载均衡类型的Service配置超时时间
- 为负载均衡类型的Service配置TLS
- 为负载均衡类型的Service配置gzip数据压缩
- 为负载均衡类型的Service配置黑名单/白名单访问策略
- 为负载均衡类型的Service指定多个端口配置健康检查
- 为负载均衡类型的Service配置pass-through能力
- 为负载均衡类型的Service配置获取客户端IP
- 为负载均衡类型的Service配置自定义EIP
- 为负载均衡类型的Service配置区间端口监听
- 通过ELB健康检查设置Pod就绪状态
- 健康检查使用UDP协议的安全组规则说明
- DNAT网关(DNAT)
- Headless Service
-
路由(Ingress)
- 路由概述
- ELB Ingress和Nginx Ingress对比
-
ELB Ingress管理
- 通过控制台创建ELB Ingress
- 通过Kubectl命令行创建ELB Ingress
- 用于配置ELB Ingress的注解(Annotations)
-
ELB Ingress高级配置示例
- 为ELB Ingress配置HTTPS证书
- 更新ELB Ingress的HTTPS证书
- 为ELB Ingress配置服务器名称指示(SNI)
- 为ELB Ingress配置多个转发策略
- 为ELB Ingress配置HTTP/2
- 为ELB Ingress配置HTTPS协议的后端服务
- 为ELB Ingress配置GRPC协议的后端服务
- 为ELB Ingress配置超时时间
- 为ELB Ingress配置慢启动持续时间
- 为ELB Ingress配置灰度发布
- 为ELB Ingress配置黑名单/白名单访问策略
- 为ELB Ingress配置多个监听端口
- 为ELB Ingress配置HTTP/HTTPS头字段
- 为ELB Ingress配置gzip数据压缩
- 为ELB Ingress配置URL重定向
- 为ELB Ingress配置Rewrite重写
- 为ELB Ingress配置HTTP重定向到HTTPS
- 为ELB Ingress配置转发规则优先级
- 为ELB Ingress配置自定义Header转发策略
- 为ELB Ingress配置自定义EIP
- 为ELB Ingress配置跨域访问
- 为ELB Ingress配置高级转发规则
- 为ELB Ingress配置高级转发动作
- ELB Ingress转发策略优先级说明
- 多个Ingress使用同一个ELB对外端口的配置说明
- Nginx Ingress管理
- 自建Nginx Ingress迁移到ELB Ingress
- DNS
- 集群网络配置
- 容器如何访问VPC内部网络
- 从容器访问公网
- 网络管理最佳实践
- 存储
- 弹性伸缩
- 云原生观测
- 云原生成本治理
- 命名空间
- 配置项与密钥
- 插件
- 模板(Helm Chart)
- 权限
- 配置中心
- 存储管理-Flexvolume(已弃用)
-
最佳实践
- CCE最佳实践汇总
- 容器应用部署上云CheckList
- 容器化改造
- 集群备份恢复
- 迁移
- DevOps
- 容灾
- 安全
- 弹性伸缩
- 监控
- 集群
-
网络
- 集群网络地址段规划实践
- 集群网络模型选择及各模型区别
- CCE集群实现访问跨VPC网络通信
- 使用VPC和云专线实现容器与IDC之间的网络通信
- 自建IDC与CCE集群共享域名解析
- 通过负载均衡配置实现会话保持
- 不同场景下容器内获取客户端源IP
- 通过配置容器内核参数增大监听队列长度
- 为负载均衡类型的Service配置pass-through能力
- 从Pod访问集群外部网络
- 通过模板包部署Nginx Ingress Controller
- CoreDNS配置优化实践
- CCE Turbo配置容器网卡动态预热
- 集群通过企业路由器连接对端VPC
- 在VPC网络集群中访问集群外地址时使用Pod IP作为客户端源IP
- 存储
- 容器
- 权限
- 发布
- 批量计算
- API参考
- SDK参考
- 场景代码示例
-
常见问题
- 高频常见问题
- 计费类
- 集群
-
节点
- 节点异常问题排查
- 节点创建
-
节点运行
- 集群可用但节点状态为“不可用”如何解决?
- CCE集群中的节点无法远程登录,如何排查解决?
- 如何重置CCE集群中节点的密码?
- 如何收集CCE集群中节点的日志?
- 如何解决yum update升级操作系统导致的容器网络不可用问题?
- Node节点vdb盘受损,通过重置节点仍无法恢复节点?
- CCE集群节点中安装kubelet的端口主要有哪些?
- 如何配置Pod使用GPU节点的加速能力?
- 容器使用SCSI类型云硬盘偶现IO卡住如何解决?
- docker审计日志量过大影响磁盘IO如何解决?
- thinpool磁盘空间耗尽导致容器或节点异常时,如何解决?
- CCE节点上监听的端口列表
- GPU节点使用nvidia驱动启动容器排查思路
- CCE节点NTP时间不同步如何解决?
- Containerd节点业务容器标准输出日志写入过快导致节点数据盘使用率过高
- 为什么kubectl top命令查看节点内存使用超过100%?
- CCE节点事件中一直出现“镜像回收失败”告警如何解决?
- 规格配置变更
- 操作系统问题说明
- 节点池
- 工作负载
-
网络管理
-
网络异常问题排查
- 工作负载网络异常时,如何定位排查?
- 负载均衡类型Service异常问题排查
- 集群内部无法使用ELB地址访问负载
- 集群外部访问Ingress异常
- CCE集群中域名解析失败
- 为什么访问部署的应用时浏览器返回404错误码?
- 为什么容器无法连接互联网?
- VPC的子网无法删除,怎么办?
- 如何修复出现故障的容器网卡?
- 节点无法连接互联网(公网),如何排查定位?
- 如何解决VPC网段与容器网络冲突的问题?
- ELB四层健康检查导致java报错:Connection reset by peer
- Service事件:Have no node to bind,如何排查?
- 为什么登录虚拟机VNC界面会间歇性出现Dead loop on virtual device gw_11cbf51a, fix it urgently?
- 集群节点使用networkpolicy概率性出现panic问题
- 节点远程登录界面(VNC)打印较多source ip_type日志问题
- 使用IE浏览器访问nginx-ingress出现重定向308无法访问
- NGINX Ingress控制器插件升级导致集群内Nginx类型的Ingress路由访问异常
- 负载均衡型Service更新出现错误:Quota exceeded for resources: members_per_pool
- ELB Ingress出现告警:Invalid input for rules
- 为ELB Ingress配置了HTTPS证书后访问异常的原因有哪些?
- 网络规划
- 安全加固
- 网络指导
-
网络异常问题排查
-
存储管理
- 如何扩容容器的存储空间?
- CCE支持的存储在持久化和多节点挂载方面的有什么区别?
- 创建CCE节点时可以不添加数据盘吗?
- CCE集群中的EVS存储卷被删除或者过期后是否可以恢复?
- 公网访问CCE部署的服务并上传OBS,为何报错找不到host?
- Pod接口ExtendPathMode: PodUID如何与社区client-go兼容?
- 创建存储卷失败如何解决?
- CCE容器云存储PVC能否感知底层存储故障?
- 通用文件存储(SFS 3.0)在OS中的挂载点修改属组及权限报错
- 无法使用kubectl命令删除PV或PVC
- 删除挂载了云存储的Pod时提示target is busy
- 无法自动创建包周期的云硬盘存储卷
- 误卸载存储池的磁盘后如何恢复
- 删除动态创建的PVC之后,底层存储依旧残留
- 命名空间
-
模板插件
- 插件异常问题排查
- 集群安装nginx-ingress插件失败,一直处于创建中?
- NPD插件版本过低导致进程资源残留问题
- 模板格式不正确,无法删除模板实例?
- CCE是否支持nginx-ingress?
- 插件安装失败,提示The release name is already exist如何解决?
- 创建或升级实例失败,提示rendered manifests contain a resource that already exists
- kube-prometheus-stack插件实例调度失败如何解决?
- 上传模板失败如何解决?
- 如何根据集群规格调整插件配额?
- NGINX Ingress控制器插件处于Unknown状态时卸载残留
- NGINX Ingress控制器插件升级后无法使用TLS v1.0和v1.1
- API&kubectl
- 域名DNS
- 镜像仓库
- 权限
- 相关服务
- 配置参考
- 视频帮助
- 文档下载
- 通用参考
链接复制成功!
使用Argo CD实现持续交付
应用现状
ArgoCD是用于Kubernetes的声明型GitOps持续交付(CD)工具。ArgoCD以Git为核心,支持声明式定义各类对象,通过ArgoCD可以实现应用快速发布到Kubernetes中,并且能够根据版本标识快速跟踪和多集群部署功能,实现多个集群之间同一应用部署问题。

本文介绍在ArgoCD中对接CCE执行持续部署的过程,并通过一个具体的示例演示该过程。
准备工作
- 创建一个CCE集群,且需要给节点绑定一个EIP,用于安装Argo CD服务时下载镜像。
- 创建一台ECS服务器,且需要绑定一个EIP,下载并配置kubectl连接集群,具体操作步骤请参见通过kubectl连接集群。
- 在Git仓库中准备一个应用,本文使用https://gitlab.com/c8147/examples.git仓库下nginx示例应用。
安装Argo CD
- 在集群中安装Argo CD服务端。
# kubectl create namespace argocd # kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.0/manifests/install.yaml
查看安装是否成功,当argocd命名空间下Pod状态都为Running时表示安装成功。
# kubectl get pod -A NAMESPACE NAME READY STATUS RESTARTS AGE argocd argocd-application-controller-0 1/1 Running 0 8m32s argocd argocd-applicationset-controller-789457b498-6n6l5 1/1 Running 0 8m32s argocd argocd-dex-server-748bddb496-bxj2c 1/1 Running 0 8m32s argocd argocd-notifications-controller-8668ffdd75-q7wdb 1/1 Running 0 8m32s argocd argocd-redis-55d64cd8bf-g85np 1/1 Running 0 8m32s argocd argocd-repo-server-778d695657-skprm 1/1 Running 0 8m32s argocd argocd-server-59c9ccff4c-vd9ww 1/1 Running 0 8m32s
执行如下命令,将名为argocd-server的Service类型修改为NodePort。
# kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}' service/argocd-server patched
查看修改结果。
# kubectl -n argocd get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE argocd-applicationset-controller ClusterIP 10.247.237.53 <none> 7000/TCP,8080/TCP 18m argocd-dex-server ClusterIP 10.247.164.111 <none> 5556/TCP,5557/TCP,5558/TCP 18m argocd-metrics ClusterIP 10.247.138.98 <none> 8082/TCP 18m argocd-notifications-controller-metrics ClusterIP 10.247.239.85 <none> 9001/TCP 18m argocd-redis ClusterIP 10.247.220.90 <none> 6379/TCP 18m argocd-repo-server ClusterIP 10.247.1.142 <none> 8081/TCP,8084/TCP 18m argocd-server NodePort 10.247.57.16 <none> 80:30118/TCP,443:31221/TCP 18m argocd-server-metrics ClusterIP 10.247.206.190 <none> 8083/TCP 18m
通过argocd-server Service访问Argo CD,直接使用节点IP:端口号访问即可。例如本示例中,端口号为31221。
登录用户名为admin,密码可使用如下命令获取。
# kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d;echo
- 在ECS服务器上安装Argo CD客户端。
# wget https://github.com/argoproj/argo-cd/releases/download/v2.4.0/argocd-linux-amd64 # cp argocd-linux-amd64 /usr/local/bin/argocd # chmod +x /usr/local/bin/argocd
执行如下命令,如果显示如下则说明安装正确。
# argocd version argocd: v2.4.0+91aefab BuildDate: 2022-06-10T17:44:14Z GitCommit: 91aefabc5b213a258ddcfe04b8e69bb4a2dd2566 GitTreeState: clean GoVersion: go1.18.3 Compiler: gc Platform: linux/amd64 FATA[0000] Argo CD server address unspecified
使用Argo CD部署应用
- 在Argo CD中添加CCE集群。
- 登录ECS服务器。
- 查看kubectl上下文配置。
# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * internal internalCluster user
- 登录Argo服务端,用户名为admin,服务端地址及密码可从1中获取。如果ECS服务器与集群处于同一VPC下,此处节点IP可使用私网IP。
argocd login <节点IP:端口号> --username admin --password <password>
回显示例如下:
# argocd login 192.168.0.52:31221 --username admin --password ****** WARNING: server certificate had error: x509: cannot validate certificate for 192.168.0.52 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y 'admin:login' logged in successfully Context '192.168.0.52:31221' updated
- 添加CCE集群。
# argocd cluster add internal --kubeconfig /root/.kube/config --name argocd-01
上面命令中,internal是1.b中查出来的上下文名称,/root/.kube/config是kubectl配置文件所在路径,argocd-01是集群在Argo CD中定义的名称。
回显如下。
WARNING: This will create a service account `argocd-manager` on the cluster referenced by context `internal` with full cluster level privileges. Do you want to continue [y/N]? y INFO[0002] ServiceAccount "argocd-manager" already exists in namespace "kube-system" INFO[0002] ClusterRole "argocd-manager-role" updated INFO[0002] ClusterRoleBinding "argocd-manager-role-binding" updated Cluster "https://192.168.0.113:5443"" added
登录Argo CD界面,可以看到添加成功。
- 连接Git仓库。
# argocd repo add https://gitlab.com/c8147/examples.git --username <username> --password <password>
https://gitlab.com/c8147/examples.git 为仓库地址,<username>和<password>为仓库登录名和密码,请替换为实际取值。
回显如下。
Repository 'https://gitlab.com/c8147/cidemo.git' added
登录Argo CD界面,可以看到添加成功。
- 在Argo CD中添加应用。
# argocd app create nginx --repo https://gitlab.com/c8147/examples.git --path nginx --dest-server https://192.168.0.113:5443 --dest-namespace default
https://gitlab.com/c8147/examples.git 为仓库地址,nginx 为仓库路径,https://192.168.0.113:5443 为要部署集群的地址,default 为命名空间。
本例中,gitlab仓库下nginx目录下为nginx应用的YAML文件,包含一个Deployment和一个Service。
创建后可以查看应用。
# argocd app list NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGET nginx https://192.168.0.113:5443 default default OutOfSync Missing <none> <none> https://gitlab.com/c8147/examples.git nginx
登录Argo CD界面,可以看到添加成功。
- 同步应用。
同步应用及将应用部署到指定集群。执行如下命令。
# argocd app sync nginx TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE 2022-10-24T12:15:10+08:00 Service default nginx OutOfSync Missing 2022-10-24T12:15:10+08:00 apps Deployment default nginx OutOfSync Missing 2022-10-24T12:15:10+08:00 Service default nginx Synced Healthy 2022-10-24T12:15:10+08:00 Service default nginx Synced Healthy service/nginx created 2022-10-24T12:15:10+08:00 apps Deployment default nginx OutOfSync Missing deployment.apps/nginx created 2022-10-24T12:15:10+08:00 apps Deployment default nginx Synced Progressing deployment.apps/nginx created Name: nginx Project: default Server: https://192.168.0.113:5443 Namespace: default URL: https://192.168.0.178:32459/applications/nginx Repo: https://gitlab.com/c8147/examples.git Target: Path: nginx SyncWindow: Sync Allowed Sync Policy: <none> Sync Status: Synced to (dd15906) Health Status: Progressing Operation: Sync Sync Revision: dd1590679856bd9288036847bdc4a5556c169267 Phase: Succeeded Start: 2022-10-24 12:15:10 +0800 CST Finished: 2022-10-24 12:15:10 +0800 CST Duration: 0s Message: successfully synced (all tasks run) GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default nginx Synced Healthy service/nginx created apps Deployment default nginx Synced Progressing deployment.apps/nginx created
在CCE集群中可以查看到部署了一个nginx工作负载和一个service。
# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 2m47s # kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.247.0.1 <none> 443/TCP 5h12m nginx ClusterIP 10.247.177.24 <none> 80/TCP 2m52s
登录Argo CD界面,可以看到应用状态变为sync。
使用Argo Rollouts实现灰度发布
Argo Rollouts是一个Kubernetes控制器,可实现高级发布功能,例如蓝绿发布、灰度(金丝雀)发布、渐进式交付等功能。
- 在集群中安装argo-rollouts服务端。
# kubectl create namespace argo-rollouts # kubectl apply -f https://github.com/argoproj/argo-rollouts/releases/download/v1.2.2/install.yaml -n argo-rollouts
说明:
如果应用部署在多个集群,需要在每个目标集群都安装Argo Rollouts服务端。
- 在ECS服务器上安装argo-rollouts的kubectl插件。
# curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.2.2/kubectl-argo-rollouts-linux-amd64 # chmod +x ./kubectl-argo-rollouts-linux-amd64 # sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
执行以下命令来验证插件是否安装成功:
# kubectl argo rollouts version kubectl-argo-rollouts: v1.2.2+22aff27 BuildDate: 2022-07-26T17:24:43Z GitCommit: 22aff273bf95646e0cd02555fbe7d2da0f903316 GitTreeState: clean GoVersion: go1.17.6 Compiler: gc Platform: linux/amd64
- 准备两个示例nginx应用镜像,版本分别为v1和v2,欢迎页分别显示为“nginx:v1!”和“nginx:v2!”。
创建一个Dockerfile文件,其中v1版本的Dockerfile内容如下,v2版本将nginx:v1!替换为nginx:v2!即可。
FROM nginx:latest RUN echo '<h1>nginx:v1!</h1>' > /usr/share/nginx/html/index.html
制作v1版本镜像:
docker build -t nginx:v1 .
登录SWR,并将镜像上传至SWR镜像仓库,具体操作步骤请参见客户端上传镜像。其中container为SWR中的组织名,请根据实际填写。
docker login -u {region}@xxx -p xxx swr.{region}.myhuaweicloud.com docker tag nginx:v1 swr.cn-east-3.myhuaweicloud.com/container/nginx:v1 docker push swr.cn-east-3.myhuaweicloud.com/container/nginx:v1
使用相同的方法制作v2版本镜像并上传至镜像仓库。
- 部署一个Rollout,本文中的示例会先将20%的流量发送到新版本实例上,然后手动继续更新,最后在升级的剩余时间内逐渐自动增大流量。
创建一个rollout-canary.yaml文件,示例如下:
apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollout-canary # 自定义的Rollout名称 spec: replicas: 5 # 定义5个副本 strategy: # 定义升级策略 canary: # 灰度(金丝雀)发布 steps: # 发布的节奏(每个阶段可以设置持续时间) - setWeight: 20 #流量权重 - pause: {} # 不填写暂停时间会一直暂停 - setWeight: 40 - pause: {duration: 10} # 暂停时间,单位默认秒 - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10} revisionHistoryLimit: 2 selector: matchLabels: app: rollout-canary template: metadata: labels: app: rollout-canary spec: containers: - name: rollout-canary image: swr.cn-east-3.myhuaweicloud.com/container/nginx:v1 #SWR中提前上传的镜像,版本号为v1 ports: - name: http containerPort: 80 protocol: TCP resources: requests: memory: 32Mi cpu: 5m imagePullSecrets: - name: default-secret --- apiVersion: v1 kind: Service metadata: name: rollout-canary spec: type: NodePort ports: - port: 80 targetPort: 80 nodePort: 31270 #自定义节点端口号 selector: app: rollout-canary
创建上面的两个资源对象:
kubectl apply -f rollout-canary.yaml
说明:
Rollout在初始创建时不会触发版本升级,设置的发布策略不会生效,副本数会立即扩展到100%。
- Argo Rollouts提供了Rollout以及相关资源对象的可视化,并展示实时状态变化,可以通过插件的 get rollout --watch 命令观察部署过程,比如:
kubectl argo rollouts get rollout rollout-canary --watch
其中rollout-canary为自定义的Rollout名称。
- 创建完成后,可通过节点EIP:端口号访问nginx应用,其中端口号在rollout-canary.yaml文件中的Service资源中指定,本例中端口号为31270。
- 执行版本更新,使用v2版本的镜像更新上面的应用:
kubectl argo rollouts set image rollout-canary rollout-canary=swr.cn-east-3.myhuaweicloud.com/container/nginx:v2
在版本更新期间,控制器将通过更新策略中定义的步骤进行。本示例中在发布的第一步中设置了20%的流量权重,并一直暂停,直到用户取消或继续发布。可通过以下命令查看详细过程,该发布正处于暂停状态。
kubectl argo rollouts get rollout rollout-canary --watch
可查看5个副本中有1个运行新版本,其余4个仍然运行旧版本,即setWeight: 20中所定义的20%的权重。
如果执行以下命令进行多次访问,响应结果中大概20%为v2版本的响应。
for i in {1..10}; do curl <节点EIP:端口号>; done;
验证结果如下:
<h1>nginx:v2!</h1> <h1>nginx:v1!</h1> <h1>nginx:v1!</h1> <h1>nginx:v1!</h1> <h1>nginx:v1!</h1> <h1>nginx:v1!</h1> <h1>nginx:v1!</h1> <h1>nginx:v1!</h1> <h1>nginx:v2!</h1> <h1>nginx:v1!</h1>
- 手动继续执行版本更新。
kubectl argo rollouts promote rollout-canary
本示例中,剩余的步骤是完全自动化的,直到完全过渡到新版本。通过以下命令查看详细过程,该Rollout会逐渐完成全部流量切换。
kubectl argo rollouts get rollout rollout-canary --watch
- 如需使用更多Argo Rollouts功能,例如终止发布、回滚发布等,您可使用以下命令查询:
kubectl argo rollouts --help