Kubernetes声明性GitOps持续交付工具-Argo CD

GitOps持续交付工具-Argo CD 1.Argo CD简介 Argo目前已被CNCF基金会收录，成为毕业项目。Argo站点地址：https://argoproj.github.io/,其中Argo CD是Argo项目中的一个分支。

argo CD文档帮助：https://argo-cd.readthedocs.io/en/stable/

Argo CD是用于Kubernetes的声明性GitOps持续交付工具，遵循GitOps模式，该模式使用Git仓库作为定义所需应用程序状态的真实来源。 Argo CD可在指定的目标环境中自动部署所需的应用程序状态，应用程序部署可以在Git提交时跟踪对分支，标签的更新，或固定到清单的特定版本。 ArgoCD支持的Kubernetes 配置清单包括helm charts、kustomize或纯YAML/json文件等。 2.Argo CD架构 Argo CD被实现为kubernetes控制器，该控制器持续监视正在运行的应用程序，并将当前的活动状态与所需的目标状态（在Git存储库中指定）进行比较。当已部署应用程序的运行状态偏离目标状态时将被argoCD视为OutOfSync。Argo CD报告并可视化差异，同时提供自动或手动方式将实时状态同步回所需目标状态的功能。在Git存储库中对所需目标状态所做的任何修改都可以自动应用并同步到指定的目标环境中。 3.为什么选择 Argo CD 应用程序定义、配置和环境应该是声明性的和版本控制的。应用程序部署和生命周期管理应该是自动化的、可审计的和易于理解的。

4.Argo CD特性一览

将应用程序自动部署到指定的目标环境 支持多种配置管理/模板工具（Kustomize，Helm，Ksonnet，Jsonnet，plain-YAML） 能够管理和部署到多个集群 SSO集成（OIDC，OAuth2，LDAP，SAML 2.0，GitHub，GitLab，Microsoft，LinkedIn） 多租户和RBAC授权策略 在任何地方回滚/滚动到Git存储库中提交的任何应用程序配置 应用程序资源的健康状况分析 自动配置漂移检测和可视化 自动或手动将应用程序同步到所需状态 Web UI，提供应用程序活动的实时视图 用于自动化和CI集成的CLI Webhook集成（GitHub，BitBucket，GitLab） 访问令牌以实现自动化 PreSync，Sync，PostSync钩子可支持复杂的应用程序部署（例如，蓝/绿发布和金丝雀升级） 应用程序事件和API调用的审核跟踪 普罗米修斯指标 在Git中覆盖ksonnet / helm参数

5.Argo CD安装 为了演示多集群管理，准备了两个集群环境。

5.1集群资源安装 参考github地址https://github.com/argoproj/argo-cd，这里以v2.4.0为例。 安装有两种方式 Non-HA: kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.0/manifests/install.yaml

HA: kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.0/manifests/ha/install.yaml 这里演示环境安装Non-HA模式，两个集群分别安装argocd。 Argo CD安装完成后如下所示

修改serivce类型为nodeport，通过节点IP+端口访问Argo CD API Server界面 kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}' 查看service kubectl -n argocd get svc 5.2客户端工具安装 Github地址下载二进制使用 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 查看版本信息：

登录argo，地址为argocd地址，用户名为admin，密码获取如下： kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Argo ui界面是通过https登陆的。 argocd login 192.168.10.71:31309 --username admin --password TZ3tvHAK1ZNIlciX 修改默认密码 argocd account update-password
--current-password TZ3tvHAK1ZNIlciX
--new-password Aa123456

如果执行argocd相关命令提示token失效，可以执行argocd relogin 重新更新认证token。 访问argo ui界面

5.3管理多集群 多集群管理是通过argo对连接不同的k8s集群，然后实现对各个集群上服务的部署和管理。 获取到目标集群的config配置信息，根据config配置信息，获取到目标集群的上下文信息。

关键信息 name，添加集群时需要用到。 客户端添加集群，--name 可以设置自定义名字。 argocd add xxx(集群上下文名称) --kubeconfig config配置文件 --name xxx 添加第一个集群信息： 添加第二个集群信息：

查看集群信息argocd cluster list

其中node01节点自身也是集群的一个节点 查看argo 平台

6.Argo CD使用 6.1Git仓库准备 这里演示环境使用gitlab作为git仓库，也可以使用github等 在argo平台添加git仓库

确认git仓库连接状态是正常的

6.2UI界面创建应用 Application Name: 自定义的应用名。 Project: 使用默认创建好的 default 项目。 SYNC POLICY： 同步方式，可以选择自动或者手动，这里我们选择手动同步。 Repository URL: 项目的 Git 地址。 Revision: 分支名。 Path: yaml 资源文件所在的相对路径。

创建应用后应用状态为OutOfSync(当已部署应用程序的运行状态偏离目标状态时将被argoCD视为OutOfSync),需要手动同步，也可以在创建应用时勾选自动同步选项。

可以看到状态为OutSync，然后可以点击sync进行同步

点开应用查看详情

访问tomcat： 查看应用总览：

6.3客户端CLI 创建应用 argocd app create kube-state-metrics
--repo http://192.168.137.31:8090/tuwei/argo.git
--path argocd01/kube-state-metrics --dest-server
https://kubernetes.default.svc
--dest-namespace kube-system

同步应用 argocd app sync kube-state-metrics

查看UI界面应用详情：

6.4一个命名空间创建多个应用 可以在git仓库同一个目录下创建多个目录，通过应用分区开，如下所示：

在argo cd平台创建应用：创建后查看

6.5Application资源部署应用 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: nginx-001 namespace: argocd spec: destination: namespace: default # 部署应用的命名空间 server: https://192.168.137.20:6443 # API Server 地址 project: default # 项目名 source: path: argocd01/nginx # 资源文件路径 directory: recurse: true #由于nginx目录下还有两个目录，这里配置目录递归 repoURL: http://192.168.137.31:8090/tuwei/argo.git # Git 仓库地址 targetRevision: main # 分支名

6.6跨集群部署应用

ApplicationSet控制器是一个Kubernetes控制器，它增加了对ApplicationSet CustomResourceDefinition (CRD)的支持。这个控制器/CRD可以实现跨大量集群和单节点管理Argo CD应用程序的自动化和更大的灵活性。从Argo CD v2.3开始，Argo CD集成了ApplicationSet控制器。 ApplicationSet控制器提供: 通过Argo CD使用单个Kubernetes清单来针对多个Kubernetes集群的能力;通过Argo CD使用单个Kubernetes清单从一个或多个Git存储库部署多个应用程序的能力。 yaml示例如下： apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-test spec: generators:

• list: elements:
  • cluster: k8s-test url: https://192.168.10.70:6443
  • cluster: k8s-prod url: https://192.168.10.20:6443

template: metadata: name: '{{cluster}}' spec: project: default source: repoURL: http://192.168.10.30:8090/k8s/argocd.git targetRevision: main path: '{{cluster}}' destination: server: '{{url}}' namespace: default

该crd实现的结果就是从同一个git仓库中获取配置清单并部署到k8s-test、k8s-prod这两个集群，path和server中采用变量方式，分别获取list中对应的值。

跨集群部署业务,通过argocd appset list查看应用时提示没有权限，

查看安装文件，可以看到名为argocd-server对应的集群角色没有applicationsets权限，添加一下。

部署应用 argocd appset create app.yaml 查看应用argocd app list

查看argo cd web界面部署情况，然后就可以进行同步操作了。

6.7kustomize进行业务发布 Argo CD 进行业务部署时支持k8s原生yaml格式，同时也支持kustomize进行部署。 根据官网的描述：kustomize 是 kubernetes 原生的配置管理，以无模板方式来定制应用的配置。kustomize 使用 k8s 原生概念帮助创建并复用资源配置(YAML)，允许用户以一个应用描述文件 （YAML 文件）为基础（Base YAML），然后通过 Overlay 的方式生成最终部署应用所需的描述文件。 在 Kubernetes v1.14 版本的发布说明中，kustomize 成为了 kubectl 内置的子命令，并说明了 kustomize 使用 Kubernetes 原生概念帮助用户创作并复用声明式配置。github地址：https://github.com/kubernetes-sigs/kustomize 下面演示kustomize方式来管理配置清单。其中git仓库目录结构如下：

argocd平台已添加git仓库：

argocd平台应用部署： 下拉选择kustomize方式，纯k8s yaml文件时则选择Directory。 命名空间设置为pro，不设置名称前后缀信息。同步应用： 查看应用：

7.Argo CD用户管理 7.1概述 安装后，Argo CD 具有一个对系统具有完全访问权限的内置admin用户。建议admin仅使用用户进行初始配置，然后切换到本地用户或配置 SSO 集成。 本地用户/帐户功能服务于两个主要用例： Argo CD 管理自动化的身份验证令牌。可以配置具有有限权限的 API 帐户并生成身份验证令牌。此类令牌可用于自动创建应用程序、项目等。 一个非常小的团队的其他用户，使用 SSO 集成可能被认为是过度杀伤力。本地用户不提供组、登录历史等高级功能。因此，如果您需要此类功能，强烈建议使用 SSO。 当您创建本地用户时，这些用户中的每一个都需要设置额外的RBAC 规则，否则他们将回退到ConfigMappolicy.default字段指定的默认策略。在argocd-rbac-cm中进行配置，argo cd支持很多第三方认证方式，这里演示采用本地用户及github为例。 7.2创建本地用户及授权 创建本地用户并禁用admin用户 新用户应该在argocd-cmConfigMap 中定义 apiVersion: v1 kind: ConfigMap metadata: name: argocd-cm namespace: argocd labels: app.kubernetes.io/name: argocd-cm app.kubernetes.io/part-of: argocd data: accounts.tuwei: apiKey, login admin.enabled: "false" 每个用户可能有两种能力： apiKey - 允许为 API 访问生成身份验证令牌 login - 允许使用 UI 登录 这里演示添加一个本地用户tuwei，并设置允许UI登录。 设置用户密码：argocd account update-password
--account tuwei
--current-password Aa123456
--new-password Aa123456 使用新用户登录UI：

再次使用admin登录发现账号已被禁用：

新创建的用户没有相关操作权限，接下来结合RBAC进行授权。 基本内置角色： Argo CD 有两个预定义的角色，但 RBAC 配置允许定义角色和组。 role:readonly- 对所有资源的只读访问 role:admin- 不受限制地访问所有资源 RBAC 权限结构 分解权限定义在应用程序和 Argo CD 中的所有其他资源类型之间略有不同。 除应用程序权限外的所有资源： p, <role/user/group>, <resource>, <action>, <object>

应用程序（属于 AppProject）： p, <role/user/group>, <resource>, <action>, <appproject>/<object> RBAC 资源和行动 资源：clusters, projects, applications, repositories, certificates, accounts,gpgkeys 动作：get, create, update, delete, sync, override,action 可以在argocd-rbac-cmConfigMap 中配置其他角色和组，对角色或者用户赋予相关权限，比如对应用或者仓库的读写权限等等。 apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd data: policy.default: role:readonly policy.csv: | p, tuwei, applications, *, /, allow p, tuwei, clusters, get, *, allow p, tuwei, repositories, get, *, allow p, tuwei, repositories, create, *, allow p, tuwei, repositories, update, *, allow p, tuwei, repositories, delete, *, allow

查看UI：

7.3对接github认证及授权 配置SSO集成，并立即添加团队中的每个人，而不是手动为你的团队成员注册帐户。Argo CD使用OpenID Connect（OIDC），一个基于OAuth 2.0的现代认证协议。如果你的组织正在使用OIDC，那么你已经准备好了。如果你用别的东西也没有问题——我们仍然为你提供服务。默认的Argo CD安装包括了Dex[1]。Dex是一个联邦OpenID Connect提供者，作为一个代理，并允许连接Argo CD到其他身份提供者，如LDAP、SAML、GitHub、谷歌和许多其他。 为了简单起见，让我们使用Github作为身份提供程序。请浏览https://github.com/settings/applications/new，并创建Github OAuth应用程序：在 GitHub 中，注册一个新应用程序。回调地址应该是您的 Argo CD URL 的端点+/api/dex/callback（例如https://argocd.example.com/api/dex/callback）

获取Github应用程序客户端id和secret 这里获取的id为 56909d41aee8292da76a secret为4a5f5fd005b739d683885d5a2adea18bb0aa9b09

修改argocd-cm ConfigMap，并将Github配置为身份提供程序 样式如下： kubectl apply -n argocd -f - << EOF apiVersion: v1 kind: ConfigMap metadata: name: argocd-cm labels: app.kubernetes.io/part-of: argocd data: url: https://139.159.184.210:31198/ dex.config: | connectors: - type: github id: github name: GitHub config: clientID: 56909d41aee8292da76a clientSecret: 4a5f5fd005b739d683885d5a2adea18bb0aa9b09 loadAllGroups: true EOF

上面的Dex配置允我们的Argo CD任何Github帐户，但零权限。所以你不能做任何配置更改，不会看到任何Argo CD应用程序。要解决这个问题，我们需要更改RBAC配置，并向我们的帐户授予管理权限。RBAC配置在argocd-rbac-cm ConfigMap中定义。为了完成本练习，让我们基于Github账户email配置admin访问。执行如下命令应用配置： export ADMIN_EMAIL='[email protected]' kubectl apply -n argocd -f - << EOF apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd labels: app.kubernetes.io/name: argocd-rbac-cm app.kubernetes.io/part-of: argocd data: policy.csv: | g, $ADMIN_EMAIL, role:admin scopes: '[groups, email]' EOF 再次登录ui界面

可以看到用户名为上面配置email访问的邮箱地址

8.Argo CD webhook配置 Argo CD每三分钟轮询一次Git存储库，以检测对清单的更改。为了消除轮询的延迟，可以将API服务器配置为接收webhook事件。Argo CD支持GitHub、GitLab、Bitbucket、Bitbucket Server和Gogs的webhook通知，下面以gitlab配置为例进行说明。 8.1GitLab仓库配置webhook Webhook 的地址填写 Argo CD 的 API 接口地址 https://192.168.10.22:32182/api/webhook，由于是自签证书，需要取消ssl认证

8.2Secret token 添加到Argo CD的Secret 配置中 修改secret资源（secret名为argocd-secret） data: ...... stringData:

gitlab webhook secret

webhook.gitlab.secret: xxxxx 添加webhook.gitlab.secret相关配置，后面就是gitlab中生成的token数据。 在gitlab界面测试push events

查看argo server日志：

可以看到已经接收到新的event消息。 9.Argo CD运维管理

9.1应用部署事件 点开具体的deployment或者pod信息，点到EVENTS界面查看应用部署的事件信息。

9.2应用回滚 多次更新应用后在历史及回滚页面可以看到每次更新的记录，可以回滚到历史的一个部署版本。如果应用是自动同步的不支持回滚操作。

9.3查看应用日志 部署业务后可以点开具体的pod信息，然后点到LOGS界面查看容器日志。

9.4容器web控制台 argo cd2.4版本提供web控制台，用户可以进入容器里执行操作，该特性默认是关闭的，需要配置开启。 1.argocd-cm configmap配置中开启exec能力

2、argocd-server对应的集群角色里添加exec相关权限

• apiGroups:
  • "" resources:
  • pods/exec verbs:
  • create 容器界面会多出一个terminal界面，则是容器控制台。

9.5应用程序指标监控 Argo CD 为每个服务器公开了不同的 Prometheus 指标集。如果使用 Prometheus Operator，可以使用 ServiceMonitor 进行配置。更改metadata.labels.release为您的 Prometheus 选择的标签名称，然后在grafana上展示应用相关。

部署后可以看到prometheus 配置已生效，但在prometheus target中看不到，通过查看prometheus日志发现权限不够，需要修改Prometheus的clusterrole，添加相关权限。

然后查询prometheus，可以看到argo-server等指标已经监控。

创建应用后可以在grafana上看到应用相关监控，比如同步状态，应用状态，仓库个数等。

10.Argo CD告警通知 10.1概述 Argo CD Notifications 持续监控 Argo CD 应用程序，并提供一种灵活的方式来通知用户应用程序状态的重要变化。使用 触发器和模板的灵活机制，您可以配置何时发送通知以及通知内容。Argo CD Notifications 包括有用的触发器和模板的目录。因此，您可以直接使用它们，而不是重新发明新的。 Argo CD 通知已经支持 Slack、电子邮件、Telegram、Netgenie、Grafana、定制 Webhooks，并且列表还在不断增长。你可以在Argo CD Notifications 文档中https://argocd-notifications.readthedocs.io/en/stable/找到关于每个服务的详细说明。 10.2集成钉钉通知 10.2.1钉钉机器人配置 们需要在钉钉群中创建一个机器人，现在的机器人安全认证有几种方式，这里我们就选择关键字的方式，配置包含 ArgoCD 关键字的机器人：

10.2.2argocd-notifications-cm 添加相关配置支持钉钉 添加通知模板及触发器 apiVersion: v1 kind: ConfigMap metadata:   name: argocd-notifications-cm data:   service.webhook.dingtalk: |     url: https://oapi.dingtalk.com/robot/send?access_token=25e013b4e7cf84bdbeb6e32f4dfcdddfc6b05444a8897667f4aa10833f4d187b     headers:       - name: Content-Type         value: application/json   context: |     argocdUrl: https://192.168.10.22:32182   template.app-sync-change: |     webhook:       dingtalk:         method: POST         body: |           {                 "msgtype": "markdown",                 "markdown": {                     "title":"ArgoCD同步状态",                     "text": "### ArgoCD同步状态\n> - app名称: {{.app.metadata.name}}\n> - app同步状态: {{ .app.status.operationState.phase}}\n> - app应用健康状态:{{.app.status.health.status}}\n> - 时间:{{.app.status.operationState.startedAt}}\n> - URL: 点击跳转ArgoCD \n"                 }             }   trigger.on-deployed: |     - description: Application is synced and healthy. Triggered once per commit.       oncePer: app.status.sync.revision       send: [app-sync-change]  # template names       # trigger condition       when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy'   trigger.on-health-degraded: |     - description: Application has degraded       send: [app-sync-change]       when: app.status.health.status == 'Degraded'   trigger.on-sync-failed: |     - description: Application syncing has failed       send: [app-sync-change]  # template names       when: app.status.operationState.phase in ['Error', 'Failed']   trigger.on-sync-running: |     - description: Application is being synced       send: [app-sync-change]  # template names       when: app.status.operationState.phase in ['Running']   trigger.on-sync-status-unknown: |     - description: Application status is 'Unknown'       send: [app-sync-change]  # template names       when: app.status.sync.status == 'Unknown'   trigger.on-sync-succeeded: |     - description: Application syncing has succeeded       send: [app-sync-change]  # template names       when: app.status.operationState.phase in ['Succeeded']   subscriptions: |     - recipients: [dingtalk]  # 可能有bug，正常应该是webhook:dingtalk       triggers: [on-sync-running, on-deployed, on-sync-failed, on-sync-succeeded]

创建应用查看测试效果