网站专题设计模板,做百度竞价什么网站好,asp.net 网站图标,seo指什么背景Kubesphere 3.3.0 集成了 ArgoCD#xff0c;但与笔者目前使用的 K8S 版本不兼容。再者#xff0c;目前 Kubesphere 中持续集成和流水线打通还是不太友好#xff0c;也缺少文档说明#xff08;可能是笔者没有找到#xff09;。目前遇到最主要的问题就是流水线制作完成的… 背景Kubesphere 3.3.0 集成了 ArgoCD但与笔者目前使用的 K8S 版本不兼容。再者目前 Kubesphere 中持续集成和流水线打通还是不太友好也缺少文档说明可能是笔者没有找到。目前遇到最主要的问题就是流水线制作完成的镜像如何更新到 Git 仓库然后触发 Application 的同步。基于上述问题目前有两种方法ArgoCD 官方的argocd-image-updater[1]根据镜像仓库的镜像 Tag 变化完成服务镜像更新Kubesphere 提供了一个 ks app update 工具[2]支持 Kubesphere v3.3.0 中 Application不支持原生 ArgoCD Application为此笔者基于 Kubesphere v3.1.1 的流水线根据笔者的场景实现了 GitOps 的服务发布流程作此记录暂且称之为最佳实践。目标基于 Kubesphere 的流水线自动创建服务部署清单自动创建服务 pipeline提交到服务部署清单仓库流水线风格统一通过服务流水线发布版本之后在一段时间内可以回滚实现 GitOps 方式管理服务部署清单和流水线清单做到版本控制设计GitLab 项目规划服务源代码和部署清单仓库分离方便做权限管理模板仓库 argocd-gitops-templates 是单独的 GitLab 仓库每个 DevOps 项目对应一个 GitLab 仓库。仓库名称为 argocd-gitops-{devops 项目名}所有 GitLab 仓库都放在同一个 GitLab Group 下每个仓库中包含了服务不同环境的清单如uat 和 prod一个服务包含一个 pipeline Application 和服务部署清单 Application。服务部署清单通过 Application CR 管理服务 pipeline 清单通过 pipeline Application CR 管理。模板仓库目录结构argocd-gitops-templates项目存储了生成服务流水线和部署清单、argocd Application 的模板。.
|-- app-manifests-templates
| |-- go
| | |-- base
| | | |-- deployment.yaml
| | | |-- kustomization.yaml
| | | -- service.yaml
| | |-- canary
| | | |-- deployment_overlay.yaml
| | | |-- kustomization.yaml
| | | -- service_overlay.yaml
| | |-- ga
| | | -- kustomization.yaml
| | |-- kustomization.yaml
| |
|-- application-templates
| |-- README.md
| |-- application-pipeline.yaml
| -- application.yaml
|-- pipeline-templates
| -- pipeline
| -- ks-pipeline-jenkinsfile.yaml
|-- top-pipeline
| |-- README.md
| |-- dev
| | |-- application.yaml
| | |-- only-test-deploy-by-argo-top-pipeline.jenkinsfile
| | -- pipeline
| | -- deploy-by-argo-top-pipeline.yaml
| |-- prod
| | |-- application.yaml
| | |-- only-test-deploy-by-argo-top-pipeline.jenkinsfile
| | -- pipeline
| | -- deploy-by-argo-top-pipeline.yamlapp-manifests-templates包含 go、java、nodejs 的服务部署清单模板使用 overlay 的方式 和 base 文件夹中的配置进行合并利用 kustomize 工具实现生成最终的部署清单。application-templates包含服务 argocd Application服务 pipeline argocd Application 清单模板。top-pipeline包含 dev、prod K8S 集群中的 top pipeline 清单和管理它的 argocd Application。pipeline-templates包含了服务 pipeline 模板整体用 Groovy 语法实现注意app-manifests-templates、pipeline-templates、application-templates在发布 GitOps 服务时执行 Top pipeline 生成服务 pipeline会自动拷贝并根据运行 Top pipeline 时输入的参数生成清单到服务对应的 GitLab 仓库中。服务部署清单仓库目录结构例如devops1 项目的 GitLab 部署清单仓库目录结构如下.
|-- README.md
-- appsmanifests|-- kubeinfo-svc1| |-- prod| | |-- application-pipeline.yaml| | |-- application.yaml| | -- manifests| | |-- base| | | |-- deployment.yaml| | | |-- kustomization.yaml| | | -- service.yaml| | |-- canary| | | |-- deployment_overlay.yaml| | | |-- kustomization.yaml| | | -- service_overlay.yaml| | |-- ga| | | |-- deployment_overlay.yaml| | | -- kustomization.yaml| | |-- kustomization.yaml| | |-- pipeline| | | -- ks-pipeline-jenkinsfile.yaml| -- uat| |-- application-pipeline.yaml| |-- application.yaml| -- manifests| |-- base| | |-- deployment.yaml| | |-- kustomization.yaml| | -- service.yaml| |-- canary| | |-- deployment_overlay.yaml| | |-- kustomization.yaml| | -- service_overlay.yaml| |-- ga| | |-- deployment_overlay.yaml| | -- kustomization.yaml| |-- kustomization.yaml| |-- pipeline| | -- ks-pipeline-jenkinsfile.yaml服务清单在 appsmanifests/{服务名}文件夹下。每个服务根据环境用 top pipeline 创建服务流水线的时候需要选择又划分为不同的文件夹。每个环境文件夹下有两个 Application 清单分别去管理 manifests 中的部署清单和 pipeline 清单。canary、ga 文件夹根据 STAGE_LEVEL用 top pipeline 创建服务流水线的时候需要选择的值会自动在 kustomization.yaml 中进行管理。注意目前只提供最基本的部署清单如果需要 Configmaps、Secrets、Ingress、增加环境变量、label 等需要手动增加或修改。具体可以参考下面的实践说明文档Top Pipeline 流程Top Pipeline 用来自动化创建 GitOps 仓库生成服务部署清单、pipeline CR 清单、Application CR 清单将清单提交到 GitLab 仓库并将 Application 创建到 K8S 集群中。整体用 Groovy 语法实现。流程黄色部分为需要人为干预的绿色为自动执行的。每个服务的发布流水线都隶属于一个 DevOps 项目下如果这个 DevOps 项目不存在则需要手动新建。如果存在则需要手动点击运行 top pipeline。输入服务配置参数点击确定运行。持久化参数信息流水线运行时会将所填参数更新到 Pipeline CR 的 parameters 中避免流水线执行失败后重新运行时需要重填参数流水线会自动获取需要选择的动态参数需要人为选择。检查 GitLab 中是否存在该 DevOps 项目的仓库不存在会自动新建仓库自动克隆 模板仓库生成服务部署清单、pipeline CR 清单、两个 Application CR 清单提交到 GitLab自动执行kubectl apply -f {两个 application yaml}创建 argocd Application CR服务 Pipeline 发布版本流程细节解析Application 怎么创建通过 kubectl 命令行直接创建到 ArgoCD 所在 K8S 集群。每个服务对应几个 Application一个服务对应 2 个 Application一个管理 pipeline CR另一个管理 deployment 等部署清单。流水线上编译的镜像 Tag 如何提交到 Git用 Git 命令行实现。一个 DevOps 项目下的多个 Pipeline 同时运行一定程度可能会提交失败。比如B 克隆代码到本地此时 A 提交一次B 提交时就失败需要重新 pull 后再提交。所以需要加重试机制失败重新 pull。容易提交冲突所以需要先 pull 再 push并增加失败之后重试CI 更新镜像 Tag 到 GitLab 后如何触发 CD 同步开启自动同步后默认是 3~4 分钟 sync时间较长。如何及时触发 CD 同步集成 argocd 命令行工具到 Agent 镜像中新建一个 gitops 账号并通过 RBAC 控制该账号的权限。执行 argocd sync 命令也可能失败需要加失败之后重试具体请参看ArgoCD 用户管理、RBAC 控制、命令行登录、App 同步[3]Agent 镜像制作kubesphere/builder-base:v3.2.2 镜像中包含了 kustomize 和 Git更新镜像 Tag 时用 base-3.2.2 作为 Pipeline Agent。并将 argocd 命令行集成到上面镜像中生成新的镜像harbor.kubeinfo.cn/library/kubesphere/builder-base:v3.2.2-argocd如何回滚审核阶段如果点击“终止”将回滚上一个阶段的镜像版本。正式环境发布之后即流水线最后一步可以点击“终止”回滚到上一个镜像版本一般在新版本测试不通过的情况下点击“终止”如果 30 分钟内没有点击或者点了继续本次发布流程将结束。回滚的时候通过 git revert 命令回退某一次提交。跨集群发布服务没有启用 DevOps 系统的 K8S 集群中不存在 pipeline CRD。所以 pipeline 用单独的 Application 管理其中的 destination cluster 只能为 ArgoCD 所在的集群。只要加入到了 argocd 中的 k8s 集群即使没有被 Kubesphere 纳管都可以走这一套 GitOps 流程将服务部署到这个 k8s 集群中。清单管理目前采用 Kustomizekustomize 利用 overlay 机制覆盖某些配置虽然在可定制化方面不如 helm如不支持模板语法和变量但 helm 对于笔者来说太重。目前的场景采用 Kustomize基本可以满足需求。kustomize 命令行用于更新 kustomization.yaml 中镜像 Tag以及校验语法是否正确避免语法不正确提交。kustomize edit set image kubeinfo-svcharbor-kubeinfo.cn/argocd/kubeinfo-svc:${DOCKER_TAG}kustomize 已经在上面的 Agent 镜像中包含。实例数如何适配 HPA 自动伸缩注释掉 deployment 中的spec.replicasargocd 将不管理 deployment 的实例数。在 Kubesphere 中修改了清单argocd 会还原吗argocd Application 中有个 selfHeal 配置表示指定当仅在目标 Kubernetes 集群中更改资源且未检测到 git 更改时(默认为 false) 是否应执行部分应用程序同步。所以当 K8S 资源对象被修改时Git 中清单没变化的情况下不需要自愈修复argocd 不会做还原但下一次流水线发布版本时Git 上的清单会发生变化此时 K8S 资源会被还原。凭证统一用 top pipeline 生成的流水线有统一的格式所以凭证必须统一。DevOps 项目有很多维护凭证成本很高。如何统一、自动化创建管理如harbor、argocd 的 gitops 账户、GitLab 的账号凭证。通过 kubed kyverno 实现在 kubesphere-devops-system 下创建的源 secret将会自动同步到所有 devops project 下。参考如何跨命名空间共享 Secret 和 ConfigMapKubesphere 凭证如何同步[4]展望引入了 GitOps发现要做的东西更多了但也确实带来很多好处。本文旨在记录分享笔者的 GitOps 落地经验有些方案细节可能只适用于笔者当前的场景笔者也处于摸索阶段。欢迎大佬们拍砖。同时也期待 Kubesphere 服务的发布可以和流水线一条龙创建将 GitOps 做的更易用而不用在项目和DevOps项目之间切换同时将灰度发布集成到流水线、可以回滚。参考资料[1]argocd-image-updater: https://argocd-image-updater.readthedocs.io/en/stable/[2]ks app update 工具: https://github.com/kubesphere-sigs/ks/blob/master/docs/app.md[3]ArgoCD 用户管理、RBAC 控制、命令行登录、App 同步: https://blog.csdn.net/ll837448792/article/details/125899955[4]如何跨命名空间共享 Secret 和 ConfigMapKubesphere 凭证如何同步: https://liabio.blog.csdn.net/article/details/124973387 点个在看集群永保稳定
