CD的Gitops通常 Argo 基于Gitlab CI 你学会了吗
名目简介
名目说明
本名目构建了一个基于GitOps理念的完整CI/CD管道，旨在成功软件开发与运维的高度智能化和分歧性。经过GitLab、GitLab Runner（部署于Kubernetes）、Maven、Java、SonarQube、Harbor以及Argo CD等工具的严密单干，实现代码提交后智能启动编译打包、单元测试、代码扫描、构建镜像、更新资源清单以及滚动更新、蓝绿部署、金丝雀颁布、多集群颁布性能。
CI/CD管道流程
Gitlab CD劣势
GitOps长处
更多gitops引见可参考文档：GitOps-崔亮的博客 (cuiliangblog.cn)
Kustomize对比Helm
Kustomize强调申明式治理，性能即代码。它准许用户经过档次化的笼罩和变卦来定制Kubernetes资源，而不须要经常使用模板。
Helm是一个包治理工具，相似于Linux的apt或yum，旨在简化Kubernetes运行的部署和治理。Helm经常使用Charts（模板）来定义Kubernetes资源。 以下是两者的差异对比
|
特色 |
||
|
模板支持 |
||
|
笼罩支持 |
||
|
打包支持 |
||
|
验证hooks |
||
|
回滚支持 |
||
|
原生 K8s 集成 |
||
|
申明性 |
||
|
可见性和透明度 |
弱 |
强 |
相较而言Kustomize经常使用起来更便捷，只管不支持打包与回滚，但咱们可以依赖ArgoCD成功这局部性能，更符合GitOps 版本化控制思维。
更多Kustomize资料可参考文档：kustomize多环境治理-崔亮的博客 (cuiliangblog.cn)
名目流程图
预备上班
服务部署
须要部署Gitlab、SonarQube、Harbor、buildkitd、Gitlab Runner服务，详细可参考文档：gitlab+k8s名目实战-崔亮的博客 (cuiliangblog.cn)
部署成功后依据实践状况对Runner启动优化，详细可参考文档：kubernetes类型runner优化-崔亮的博客 (cuiliangblog.cn)
部署ArgoCD服务，详细可参考文档：ArgoCD部署-崔亮的博客 (cuiliangblog.cn)
部署ArgoCD Rollouts服务（可选，假设须要蓝绿部署或金丝雀颁布时须要部署），详细可参考文档：ArgoCD Rollouts-崔亮的博客 (cuiliangblog.cn)
Runner镜像构建
在Gitlab CI流程中，Runner重要的上班包含打包镜像、经常使用kustomize修正images消息，因此须要构建一个名为gitlab-runner-agent的镜像，dockerfile内容如下：
FROM alpine:latestUSER rootRUN apk update && \apk add --no-cache git && \rm -rf /var/cache/apk/*COPY kustomize /usr/bin/kustomizeCOPY nerdctl /usr/bin/nerdctlCOPY buildctl /usr/bin/buildctl[root@tiaoban ~]# docker build -t harbor.local.com/cicd/gitlab-agent:v1.1 .流水线镜像构建
须要构建maven、sonar-scanner、jmeter镜像，详细可参考文档：gitlab+docker名目实战-崔亮的博客 (cuiliangblog.cn)
名目代码仓库地址
gitee：
github：
gitlab名目权限性能
详细参考文档：Jenkins+docker名目实战-崔亮的博客 (cuiliangblog.cn)
性能邮件发送
详细可参考文档：Gitlab与Email集成-崔亮的博客 (cuiliangblog.cn)
创立ci用户并参与至devops组
创立一个名为gitlabci的用户，用于提交kustomize更新后的资源清单文件。将gitlabci用户角色指定为保养者。
Argo CD创立project与Repo
创立project，详细可参考文档：ArgoCD project-崔亮的博客 (cuiliangblog.cn)，project性能如下：
创立repo，详细可参考文档：ArgoCD极速体验-崔亮的博客 (cuiliangblog.cn)，repo性能如下：
Gitlab CI流程
性能密钥变量
进入名目——>设置——>CI/CD——>变量 新建SONAR_QUBE_TOEKN、HARBOR_PASSWORD、CI_PASSWORD三个变量，敞开包全变量，并勾选暗藏变量。 变量性能消息内容如下：
模板库资源更新
模板库详细引见可参考文档：gitlab+linux名目实战-崔亮的博客 (cuiliangblog.cn)，本文是在gitlab+k8s名目基础上补充模板库内容。 完整模板库链接：
该job的重要内容是经过kustomize工具，依据不同的分支提交事情，生成不同环境的资源清单，并将镜像交流为最新的镜像地址，并将资源清单文件提交至Gitlab仓库。
# 更新kustomizevariables: # 全局变量KUSTOMIZE_OVERLAY: '' # kustomize环境目录.update-kustomize:stage: update-kustomizetags:- buildonly:- master- testbefore_script:- git remote set-url origin http:// ${CI_USER}:${CI_PASSWORD}@gitlab.local.com/devops/spring_boot_demo.git- git config --global user.email "${CI_EMAIL}"- git config --global user.name "${CI_USER}"- if [ "$CI_COMMIT_BRANCH" == "master" ]; then KUSTOMIZE_OVERLAY="prod"; fi- if [ "$CI_COMMIT_BRANCH" == "test" ]; then KUSTOMIZE_OVERLAY="test"; fiscript:- git checkout -B ${CI_COMMIT_BRANCH}- cd cicd/kustomize/overlays/${KUSTOMIZE_OVERLAY}- kustomize edit set image $CONTAINER_NAME=$IMAGE_FULL_NAME- kustomize build .- git commit -am '[gitlab ci] kustomize update'- git push origin ${CI_COMMIT_BRANCH}流水线性能
在名目根目录下创立.gitlab-ci.yml文件，流水线内容如下：
include: # 引入模板库公共文件- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/build.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/test.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/sonarqube.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/harbor.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/kustomize.yml'variables: # 全局变量SONAR_QUBE_PATH: "$CI_PROJECT_DIR/cicd/sonar-project.properties" # sonarqube性能文件地址# 镜像上行HARBOR_REPO: devops # harbor仓库名HARBOR_USER: admin # harbor用户名DOCKERFILE_PATH: cicd/Dockerfile # Dockerfile文件门路IMAGE_NAME: "$CI_PROJECT_NAME:$CI_COMMIT_BRANCH-$CI_COMMIT_SHORT_SHA" # 镜像称号# 更新yamlCI_USER: gitlabci # gitlab ci用户名CI_EMAIL: gitlabci@qq.com # gitlab ci用户邮箱CONTAINER_NAME: demo # k8s控制器container称号default:cache: # 全局缓存性能paths:- target/workflow: # Gitlabci更新不触发流水线rules:- if: '$GITLAB_USER_LOGIN == "gitlabci"'when: never- when: alwaysstages:- build- code_scan- product- update_yamlmvn: # 编译打包stage: buildextends: .mvn_buildimage: harbor.local.com/cicd/maven:v3.9.3 # 构建阶段经常使用指定的maven镜像before_script:- ls -lh /home/gitlab-runner/cache/tags:- k8sunit_test: # 单元测试stage: buildextends: .mvn_unit_testimage: harbor.local.com/cicd/maven:v3.9.3 # 构建阶段经常使用指定的maven镜像before_script:- ls -lh /home/gitlab-runner/cache/tags:- k8scode_scan: # SonarQube代码扫描stage: code_scanextends: .sonarqubeimage: harbor.local.com/cicd/sonar-scanner-cli:10 # 代码扫描阶段经常使用sonar-scanner-cli镜像before_script:- ls target/tags:- k8sproduct: # 打包上行镜像到harbor仓库stage: productimage: harbor.local.com/cicd/gitlab-agent:v1.1extends: .container_upload_harbortags:- k8supdate_yaml: # 更新资源清单stage: update_yamlimage: harbor.local.com/cicd/gitlab-agent:v1.1extends: .update_kustomizetags:- k8sGitlab CI结果验证
检查update_yaml阶段kustomize生成的资源清单文件，已成功image和namespace的更新。
检查kustomization.yaml文件，已交流并提交最新的镜像地址。
雷同的操作，对test分支性能ci流水线，检查test分支kustomization.yaml文件消息。
至此 CI流程性能成功，CI流程只要要将集成后的文件提交至Gitlab仓库即可，后续CD流程会依据Gitlab资源清单智能成功服务部署与形态同步。
Argo CD流程(滚动更新)
创立APP
Argo CD支持经过web UI、CLI命令行工具、yaml文件创立APP，详细可参考文档Directory APP创立与性能-崔亮的博客 (cuiliangblog.cn)。
此处以yaml文件创立Kustomize类型APP为例，详细可参考文档：Kustomize App创立-崔亮的博客 (cuiliangblog.cn)，yaml文件内容如下：
apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: demo-prodnamespace: argocdspec:destination:namespace: 'prod'server: 'https://kubernetes.default.svc'source:path: cicd/kustomize/overlays/prodrepoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'targetRevision: 'master'sources: []project: devopssyncPolicy:automated:prune: trueselfHeal: true---apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: demo-testnamespace: argocdspec:destination:namespace: 'test'server: 'https://kubernetes.default.svc'source:path: cicd/kustomize/overlays/testrepoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'targetRevision: 'test'sources: []project: devopssyncPolicy:automated:prune: trueselfHeal: true此时检查Argo CD页面，已依据master和test分支区分部署了两套demo服务。
结果验证
检查pod消息
[root@tiaoban ~]# kubectl get pod -n prodNAMEREADYSTATUSRESTARTSAGEdemo-7dd977b57-5qdcx1/1Running04m41s[root@tiaoban ~]# kubectl get pod -n testNAMEREADYSTATUSRESTARTSAGEdemo-6b67766cb5-c9fq91/1Running04m32s修正host解析，区分访问测试和消费域名验证。
[root@tiaoban ~]# curl demo.prod.com<h1>Hello SpringBoot</h1><p>Version:v1 Env:prod</p>[root@tiaoban ~]# curl demo.test.com<h1>Hello SpringBoot</h1><p>Version:v1 Env:test</p>修正springboot名目源码，将version内容从v1更新为v2，期待gitlab CI和Argo CD口头成功。此时检查消费环境pod并访问服务，曾经经过deployment滚动更新到v2版本。
[root@tiaoban ~]# kubectl get pod -n prodNAMEREADYSTATUSRESTARTSAGEdemo-65b44b4d8-58f671/1Running021sdemo-7dd977b57-5qdcx1/1Terminating010m[root@tiaoban ~]# curl demo.prod.com<h1>Hello SpringBoot</h1><p>Version:v2 Env:prod</p>Argo CD流程(蓝绿部署)
Argo CD蓝绿部署和金丝雀颁布重要依赖Rollouts组件成功，详细内容可参考文档：ArgoCD Rollouts-崔亮的博客 (cuiliangblog.cn)。
蓝绿部署详细内容可参考文档：蓝绿部署-崔亮的博客 (cuiliangblog.cn)。
模板库资源性能
该job的重要内容是将镜像交流为最新的镜像地址，并将资源清单文件提交至Gitlab仓库。
# 更新rollout资源镜像.update_rollout:stage: update_rollouttags:- buildonly:- masterbefore_script:- git remote set-url origin http:// ${CI_USER}:${CI_PASSWORD}@gitlab.local.com/devops/spring_boot_demo.git- git config --global user.email "${CI_EMAIL}"- git config --global user.name "${CI_USER}"script:- git checkout -B master- sed -i "s|\(image:\s*\).*|\1${IMAGE_FULL_NAME}|" ${ROLLOUT_PATH}- git commit -am '[gitlab ci] rollout update'- git push origin ${CI_COMMIT_BRANCH}after_script:- cat ${ROLLOUT_PATH}流水线性能
在流水线update_yaml阶段经常使用下面定义的更新rollout资源job。
include: # 引入模板库公共文件- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/build.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/test.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/sonarqube.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/harbor.yml'- project: 'devops/gitlabci-template'ref: masterfile: 'jobs/rollout.yml'variables: # 全局变量SONAR_QUBE_PATH: "$CI_PROJECT_DIR/cicd/sonar-project.properties" # sonarqube性能文件地址# 镜像上行HARBOR_REPO: devops # harbor仓库名HARBOR_USER: admin # harbor用户名DOCKERFILE_PATH: cicd/Dockerfile # Dockerfile文件门路IMAGE_NAME: "$CI_PROJECT_NAME:$CI_COMMIT_BRANCH-$CI_COMMIT_SHORT_SHA" # 镜像称号# 更新yamlCI_USER: gitlabci # gitlab ci用户名CI_EMAIL: gitlabci@qq.com # gitlab ci用户邮箱ROLLOUT_PATH: cicd/argo-cd/bluegreen/rollout.yaml # rollout文件门路workflow: # Gitlabci更新不触发流水线rules:- if: '$GITLAB_USER_LOGIN == "gitlabci"'when: never- when: alwaysdefault:cache: # 全局缓存性能paths:- target/stages:- build- code_scan- product- update_yamlmvn: # 编译打包stage: buildextends: .mvn_buildimage: harbor.local.com/cicd/maven:v3.9.3 # 构建阶段经常使用指定的maven镜像tags:- k8sunit_test: # 单元测试stage: buildextends: .mvn_unit_testimage: harbor.local.com/cicd/maven:v3.9.3 # 构建阶段经常使用指定的maven镜像tags:- k8scode_scan: # SonarQube代码扫描stage: code_scanextends: .sonarqubeimage: harbor.local.com/cicd/sonar-scanner-cli:10 # 代码扫描阶段经常使用sonar-scanner-cli镜像before_script:- ls target/tags:- k8sproduct: # 打包上行镜像到harbor仓库stage: productimage: harbor.local.com/cicd/gitlab-agent:v1.1extends: .container_upload_harbortags:- k8supdate_yaml: # 更新资源清单stage: update_yamlimage: harbor.local.com/cicd/gitlab-agent:v1.1extends: .update_rollouttags:- k8sGitlab CI结果验证
检查update_yaml义务消息，已交流为最近的镜像地址。检查仓库rollout.yaml文件，曾经交流为最新的镜像地址。
Argo CD创立APP
接上去创立ArgoCD APP，资源清单内容如下：
apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: blue-greennamespace: argocdspec:destination:namespace: defaultserver: 'https://kubernetes.default.svc'source:path: cicd/argo-cd/bluegreenrepoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'targetRevision: mastersources: []project: devopssyncPolicy:automated:prune: trueselfHeal: true此时检查Argo CD页面，曾经成功部署了名为blue-green的运行。
蓝绿部署验证
参与hosts域名解析后访问，由于刚颁布第一个版本，因此正式环境和测试环境都是v1版本的镜像。
[root@tiaoban ~]# kubectl get podNAMEREADYSTATUSRESTARTSAGEbluegreen-rollout-7679f8576-bj9lw1/1Running04sbluegreen-rollout-7679f8576-lrt5r1/1Running04s[root@tiaoban ~]# curl demo.prod.com<h1>Hello SpringBoot</h1><p>Version:v2 Env:prod</p>[root@tiaoban ~]# curl demo.test.com<h1>Hello SpringBoot</h1><p>Version:v1 Env:prod</p>修正springboot名目源码，将version内容从v2更新为v3，期待gitlab CI和Argo CD口头成功。
此时访问运行消费和测试域名，区分前往不同的版本消息。
[root@tiaoban ~]# kubectl get podNAMEREADYSTATUSRESTARTSAGEbluegreen-rollout-6f76ccc55c-gbgsc1/1Running07sbluegreen-rollout-7679f8576-bj9lw1/1Running03m49sbluegreen-rollout-7679f8576-lrt5r1/1Running03m49s[root@tiaoban ~]# curl demo.prod.com<h1>Hello SpringBoot</h1><p>Version:v2 Env:prod</p>[root@tiaoban ~]# curl demo.test.com<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>颁布新版本后，此时就须要测试人员访问测试域名验证系统性能能否反常，验证无误后，将服务切换至消费域名。
[root@tiaoban ~]# kubectl argo rollouts promote bluegreen-rolloutrollout 'bluegreen-rollout' promoted此时访问web页面，消费和测试环境均前往v3版本消息。
[root@tiaoban ~]# kubectl get podNAMEREADYSTATUSRESTARTSAGEbluegreen-rollout-6f76ccc55c-gbgsc1/1Running083sbluegreen-rollout-6f76ccc55c-hcflg1/1Running019sbluegreen-rollout-7679f8576-bj9lw1/1Running05m5sbluegreen-rollout-7679f8576-lrt5r1/1Running05m5s[root@tiaoban ~]# curl demo.prod.com<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>[root@tiaoban ~]# curl demo.test.com<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>至此整个蓝绿颁布流程成功。
Argo CD流程(金丝雀颁布)
金丝雀颁布详细内容可参考文档：金丝雀颁布-崔亮的博客 (cuiliangblog.cn)，此处不再赘述。
模板库与流水线性能
模板库与流水线性能与下面的蓝绿部署分歧，区别在于流水线中ROLLOUT_PATH指定为金丝雀资源门路
variables: # 全局变量ROLLOUT_PATH: cicd/argo-cd/canary/rollout.yaml # rollout文件门路Gitlab CI结果验证
检查流水线update_yaml阶段日志，曾经交流为最新的镜像地址。
Argo CD创立APP
接上去创立ArgoCD APP，资源清单内容如下：
apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: canarynamespace: argocdspec:destination:namespace: defaultserver: 'https://kubernetes.default.svc'source:path: cicd/argo-cd/canaryrepoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'targetRevision: mastersources: []project: devopssyncPolicy:automated:prune: trueselfHeal: true此时检查Argo CD页面，曾经成功部署了名为canary的运行。
金丝雀颁布验证
参与hosts域名解析后访问，由于刚颁布第一个版本，因此一切流量都调度到v3版本的服务。
[root@tiaoban ~]# kubectl get podNAMEREADYSTATUSRESTARTSAGEcanary-rollout-7d77478fd7-4vdzn1/1Running0115scanary-rollout-7d77478fd7-5rbmp1/1Running0115scanary-rollout-7d77478fd7-6pm621/1Running0115scanary-rollout-7d77478fd7-98xmk1/1Running0115scanary-rollout-7d77478fd7-jv6zk1/1Running0115scanary-rollout-7d77478fd7-l22zh1/1Running0115scanary-rollout-7d77478fd7-lhxm81/1Running0115scanary-rollout-7d77478fd7-tkfrb1/1Running0115scanary-rollout-7d77478fd7-zcgwq1/1Running0115scanary-rollout-7d77478fd7-zw4w21/1Running0115s[root@tiaoban ~]# for i in {1..10}; do curl canary.demo.com; done<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>修正springboot名目源码，将version内容从v3更新为v4，期待gitlab CI和Argo CD口头成功。检查Rollouts形态，新增了canary-rollout-6c764844bd，运转v4版本的镜像。
[root@tiaoban ~]#kubectl argo rollouts get rollout canary-rolloutName:canary-rolloutNamespace:defaultStatus:॥ PausedMessage:CanaryPauseStepStrategy:CanaryStep:1/7SetWeight:10ActualWeight:10Images:harbor.local.com/devops/spring_boot_demo:master-3bccf809 (canary)harbor.local.com/devops/spring_boot_demo:master-e58822da (stable)Replicas:Desired:10Current:11Updated:1Ready:11Available:11NAMEKINDSTATUSAGEINFO⟳ canary-rolloutRollout॥ Paused12m├──# revision:2│└──⧉ canary-rollout-6c764844bdReplicaSet✔ Healthy24scanary│└──□ canary-rollout-6c764844bd-dzc4tPod✔ Running24sready:1/1└──# revision:1└──⧉ canary-rollout-7d77478fd7ReplicaSet✔ Healthy12mstable├──□ canary-rollout-7d77478fd7-4vdznPod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-5rbmpPod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-6pm62Pod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-98xmkPod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-jv6zkPod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-l22zhPod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-lhxm8Pod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-tkfrbPod✔ Running12mready:1/1├──□ canary-rollout-7d77478fd7-zcgwqPod✔ Running12mready:1/1└──□ canary-rollout-7d77478fd7-zw4w2Pod✔ Running12mready:1/1[root@tiaoban ~]# kubectl get podNAMEREADYSTATUSRESTARTSAGEcanary-rollout-6c764844bd-dzc4t1/1Running028scanary-rollout-7d77478fd7-4vdzn1/1Running012mcanary-rollout-7d77478fd7-5rbmp1/1Running012mcanary-rollout-7d77478fd7-6pm621/1Running012mcanary-rollout-7d77478fd7-98xmk1/1Running012mcanary-rollout-7d77478fd7-jv6zk1/1Running012mcanary-rollout-7d77478fd7-l22zh1/1Running012mcanary-rollout-7d77478fd7-lhxm81/1Running012mcanary-rollout-7d77478fd7-tkfrb1/1Running012mcanary-rollout-7d77478fd7-zcgwq1/1Running012mcanary-rollout-7d77478fd7-zw4w21/1Running012mrockylinux1/1Running21 (140m ago)52d循环恳求访问验证,可以看到，在前5分钟只要10%的流量恳求到了v4版本的服务中。
[root@tiaoban ~]# for i in {1..10}; do curl canary.demo.com; done<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v4 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p><h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>继续观察流量v4的占比会逐渐参与直到最后到达100%。
Argo CD流程(多集群颁布)
咱们在实践上班中会存在多个消费、测试集群，通常会将test分支代码颁布至测试环境，master分支代码颁布至消费环境，Argo雷同支持这种多集群形式颁布，且性能起来更为便捷。
多集群颁布性能详细可参考文档：多集群运行部署-崔亮的博客 (cuiliangblog.cn)
假定如今有两套集群，曾经在k8s-ha集群部署了gitlab和Argocd，如今须要参与k8s-test集群。 在参与集群前，先性能config高低文，详细内容可参考文档：kubectl多集群治理-崔亮的博客 (cuiliangblog.cn)
[root@tiaoban .kube]# kubectl config get-contextsCURRENTNAMECLUSTERAUTHINFONAMESPACE*ha-admin@k8s-hak8s-haha-admintest-admin@k8s-testk8s-testtest-admin[root@tiaoban .kube]# kubectl get nodeNAMESTATUSROLESAGEVERSIONmaster1Readycontrol-plane285dv1.27.6master2Readycontrol-plane285dv1.27.6master3Readycontrol-plane285dv1.27.6work1Ready<none>285dv1.27.6work2Ready<none>285dv1.27.6work3Ready<none>285dv1.27.6[root@tiaoban .kube]# kubectl config use-context test-admin@k8s-testSwitched to context "test-admin@k8s-test".[root@tiaoban .kube]# kubectl get nodeNAMESTATUSROLESAGEVERSIONk8s-masterReadycontrol-plane,master21hv1.23.17k8s-work1Ready<none>20hv1.23.17k8s-work2Ready<none>20hv1.23.17ArgoCD参与集群。
[root@tiaoban ~]# argocd login argocd.local.comWARNING: server certificate had error: tls: failed to verify certificate: x509: certificate is valid for de4d64dda4cc17aa063ca24baa2abc22.6d1744aa3a6f00c3129e20bc6d196dd0.traefik.default, not argocd.local.com. Proceed insecurely (y/n)? yWARN[0002] Failed to invoke grpc call. Use flag --grpc-web in grpc calls. To avoid this warning message, use flag --grpc-web.Username: adminPassword:'admin:login' logged in successfullyContext 'argocd.local.com' updated[root@tiaoban ~]# argocd cluster add test-admin@k8s-test --kubecnotallow=/root/.kube/configWARNING: This will create a service account `argocd-manager` on the cluster referenced by context `test-admin@k8s-test` with full cluster level privileges. Do you want to continue [y/N]? yINFO[0003] ServiceAccount "argocd-manager" created in namespace "kube-system"INFO[0003] ClusterRole "argocd-manager-role" createdINFO[0003] ClusterRoleBinding "argocd-manager-role-binding" createdWARN[0004] Failed to invoke grpc call. Use flag --grpc-web in grpc calls. To avoid this warning message, use flag --grpc-web.Cluster 'https://192.168.10.10:6443' added检查集群形态消息如下：
更新devops名目权限性能，准许对k8s-test集群启动操作。
创立Argo CD app，依照不同的分支同时颁布至不同的k8s集群中。
# master分支代码颁布至消费环境apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: demo-prodnamespace: argocdspec:destination:namespace: 'prod'server: 'https://kubernetes.default.svc'source:path: cicd/kustomize/overlays/prodrepoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'targetRevision: 'master'sources: []project: devopssyncPolicy:automated:prune: trueselfHeal: true---# test分支代码颁布至测试环境apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: demo-testnamespace: argocdspec:destination:namespace: 'test'server: 'https://192.168.10.10:6443'source:path: cicd/kustomize/overlays/testrepoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'targetRevision: 'test'sources: []project: devopssyncPolicy:automated:prune: trueselfHeal: trueArgoCD会智能启动颁布，检查颁布消息如下：
此时访问test集群检查资源，曾经成功创立myapp2资源。
[root@tiaoban ~]# kubectl config use-context test-admin@k8s-testSwitched to context "test-admin@k8s-test".[root@tiaoban ~]# kubectl get pod -n testNAMEREADYSTATUSRESTARTSAGEdemo-6c86b77bd6-dpf4m1/1Running03m3s[root@tiaoban ~]# kubectl config use-context ha-admin@k8s-haSwitched to context "ha-admin@k8s-ha".[root@tiaoban ~]# kubectl get pod -n prodNAMEREADYSTATUSRESTARTSAGEdemo-77b7f4576b-vlwtc1/1Running03m
