ArgoCD简介

官网：https://argo-cd.readthedocs.io/en/stable/

ArgoCD安装

$ kubectl create namespace argocd$ kubectl apply -n argocd -f https://ghproxy.com/https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml~# kubectl wait --for=condition=Ready pods --all -n argocd --timeout 300s
pod/argocd-application-controller-0 condition met
pod/argocd-applicationset-controller-6dd887f766-gv2gk condition met
pod/argocd-dex-server-89774cfc6-v2dhc condition met
pod/argocd-notifications-controller-79c985586c-xkt7q condition met
pod/argocd-redis-74f98b85f-dvhjc condition met
pod/argocd-repo-server-9cb997c7b-vjzrn condition met
pod/argocd-server-749879d78d-hcc6v condition met

访问ArgoCD

可以通过ingress或者nodeport方式暴露进行访问！
user：admin
passwd：$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

GitOps 工作流总览

我们可以把这个完整的 GitOps 工作流分成三个部分来看。
第一部分：开发者推送代码到 GitHub 仓库，然后触发 GitHub Action 自动构建。
第二部分：GitHub Action 自动构建，它包括下面三个步骤：

1. 构建示例应用的镜像。
2. 将示例应用的镜像推送到 Docker Registry 镜像仓库。
3. 更新代码仓库中 Helm Chart values.yaml 文件的镜像版本。

第三部分：核心是 ArgoCD，它包括下面两个步骤:

4. 通过定期 Poll 的方式持续拉取 Git 仓库，并判断是否有新的 commit。
5. 从 Git 仓库获取 Kubernetes 对象，与集群对象进行实时比较，自动更新集群内有差异的资源。

前边的环境已经准备好，现在准备创建 GitOps 工作流中的第三部分，也就是创建 ArgoCD 应用，实现 Kubernetes 资源的自动同步。

创建 ArgoCD 应用

以示例应用为例子来创建 ArgoCD 应用，这里主要分成两个步骤。

1. 配置仓库访问权限。
2. 创建 ArgoCD 应用。

其中，如果你的示例应用仓库是公开的，可以跳过第一步。
配置 ArgoCD 仓库访问权限（可选）

$ argocd login 127.0.0.1:8080 --insecure    #更换地址
Username: admin
Password:
'admin:login' logged in successfully

添加示例应用仓库:

~# argocd repo add https://github.com/Hugh-yw/kubernetes-example.git --username $USERNAME  --password $PASSWORD

将 $USERNAME 替换为 GitHub 账户 ID，将 $PASSWORD 替换为 GitHub Personal Token，Token创建链接：https://github.com/settings/tokens/new

创建 ArgoCD 应用
ArgoCD 同时支持使用 Helm Chart、Kustomize 和 Manifest 来创建应用，本次实践以示例应用的 Helm Chart 为例。
通过argocd app create命令来创建应用:

$ argocd app create example --sync-policy automated --repo https://github.com/Hugh-yw/kubernetes-example.git --revision main --path helm --dest-namespace gitops-example --dest-server https://kubernetes.default.svc --sync-option CreateNamespace=true
application 'example' created

–sync-policy 参数代表设置自动同步策略。automated 的含义是自动同步，也就是说当集群内的资源和 Git 仓库 Helm Chart 定义的资源有差异时，ArgoCD 会自动执行同步操作，实时确保集群资源和 Helm Chart 的一致性。
–repo 参数表示 Helm Chart 的仓库地址。这里的值是示例应用的仓库地址，注意需要替换成你实际的 Git 仓库地址。
–revision 参数表示需要跟踪的分支或者 Tag，这里我们让 ArgoCD 跟踪 main 分支的改动。
–path 参数表示 Helm Chart 的路径。在示例应用中，存放 Helm Chart 的目录是 helm 目录。
–dest-namespace 参数表示命名空间。这里指定了 gitops-example 命名空间，注意，这是一个不存在的命名空间，所以我们额外通过--sync-option参数来让 ArgoCD 自动创建这个命名空间。
最后，–dest-server 参数表示要部署的集群， https://kubernetes.default.svc 表示 ArgoCD 所在的集群。

检查 ArgoCD 同步状态

在应用详情页面，需要重点关注三个状态。

1. APP HEALTH： 应用整体的健康状态，它包含下面三个值。
   1. Progressing：处理中
   2. Healthy：健康状态
   3. Degraded：宕机
2. CURRENT SYNC STATUS： 应用定义和集群对象的差异状态，也包含下面三个值。
   1. Synced：完全同步
   2. OutOfSync：存在差异
   3. Unknown：未知
3. LAST SYNC RESULT： 最后一次同步到 Git 仓库的信息，包括 Commit ID 和提交者信息。

访问应用

当应用健康状态变为 Healthy 之后，我们就可以访问应用了。

~# kubectl get ingressroute -n gitops-example 
NAME               AGE
frontend-service   70m

访问应用链接：http://frontend.demo.com

连接 GitOps 工作流

在完成 ArgoCD 的应用配置之后，我们就已经将示例应用的 Helm Chart 定义和集群资源关联起来了，但整个 GitOps 工作流还缺少非常重要的一部分，就是上面提到的自动更新 Helm Chart values.yaml 文件镜像版本的部分，在下面这张示意图中用“❌”把这个环节标记了出来。

在这部分工作流没有打通之前，提交的新代码虽然会构建出新的镜像，但是 Helm Chart 定义的镜像版本并不会产生变化， 这会导致 ArgoCD 不能自动更新集群内工作负载的镜像版本。
要解决这个问题，我们还需要在 GitHub Action 中添加自动修改 Helm Chart 并重新推送到仓库操作。
接下来，我们修改示例应用的.github/workflows/build.yaml文件，在“Build frontend and push”阶段后面添加一个新的阶段，代码如下：

- name: Update helm values.yamluses: fjogeleit/yaml-update-action@mainwith:valueFile: 'helm/values.yaml'commitChange: truebranch: mainmessage: 'Update Image Version to ${{ steps.vars.outputs.sha_short }}'changes: |{"backend.tag": "${{ steps.vars.outputs.sha_short }}","frontend.tag": "${{ steps.vars.outputs.sha_short }}"}

使用了 GitHub Action 中yaml-update-action插件来修改 values.yaml 文件并把它推送到仓库。如果你是使用 GitLab 或者 Tekton 构建镜像，可以调用 jq 命令行工具来修改 YAML 文件，再使用 git 命令行将变更推送到仓库。
到这里， 一个完整的 GitOps 工作流就建立好了。

体验 GitOps 工作流

尝试修改 frontend/src/App.js 文件，例如修改文件第 49 行的“Hi! I am a geekbang”。修改完成后， 将代码推送到 GitHub 仓库 main 分支，此时，GitHub Action 会自动构建镜像，并且还会更新代码仓库中 Helm values.yaml 文件的镜像版本。

这里遇到一点小插曲，在GitHub Action自动构建镜像时报异常：

HttpError: Resource not accessible by integration

参考解决资料：https://www.drixn.com/3074.html

ArgoCD 默认每 3 分钟会拉取仓库检查是否有新的提交，你也可以在 ArgoCD 控制台手动点击 Sync 按钮来触发同步。

ArgoCD 同步完成后，我们可以在“LAST SYNC RESULT”一栏中看到 GitHub Action 修改 values.yaml 的提交记录，当应用状态为 Healthy 时，我们就可以访问新的应用版本了。

生产建议

1）修改默认密码

注：
修改密码前，先使用 argocd login 登录到 ArgoCD 服务端。
$ argocd account update-password
*** Enter password of currently logged in user (admin):
*** Enter new password for user admin:

2）配置 Ingress 和 TLS

前提：
需要安装 Cert-manager！！！
> ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: argocd-server-ingressnamespace: argocdannotations:cert-manager.io/cluster-issuer: letsencrypt-prodkubernetes.io/ingress.class: nginxkubernetes.io/tls-acme: "true"nginx.ingress.kubernetes.io/ssl-passthrough: "true"nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:rules:- host: argocd.example.comhttp:paths:- path: /pathType: Prefixbackend:service:name: argocd-serverport:name: httpstls:- hosts:- argocd.example.comsecretName: argocd-secret # do not change, this is provided by Argo CD

3）使用 Webhook 触发 ArgoCD

我们在创建应用的时候提供了参数 --sync-policy=automated。这时候，ArgoCD 会默认以 3 分钟一次的频率来自动拉取仓库的更改，在生产环境下，这个同步频率可能并不能满足快速发布的要求。
如果 ArgoCD 可以在公网进行访问，建议使用 ArgoCD 提供的 Webhook 触发方式来解决这个问题了，如下图所示：

和主动 Poll 模型不同的是，源码仓库在收到开发者推送代码的事件后，将实时通过 HTTP 请求来通知 ArgoCD，也就是图中红色字体的部分。
要使用 Webhook 通知的方式，首先你需要在源码仓库进行配置。以 GitHub 为例，首先进入仓库的“Settings”页面，点击左侧的“Webhook”菜单进入配置页面，如下图:

在 Payload URL 中输入你的 ArgoCD Server 外网访问域名，/api/webhook ArgoCD 专门用于接收外部 Webhook 消息的固定路径。
Content type 选择 application/json，并在 Secret 中输入你要配置的 Webhook 的密钥，这个密钥需要提供给 ArgoCD 来校验 Webhook 来源是否合法？
接下来，你还需要为 ArgoCD 提供 GitHub Webhook 密钥，使用下面的命令来编辑 argocd-secret 对象。

$ kubectl edit secret argocd-secret -n argocd
apiVersion: v1
kind: Secret
metadata:name: argocd-secretnamespace: argocd
type: Opaque
data:
...
stringData:# 加入这一项webhook.github.secret: my-secret

注意，stringData 可以直接输入 Webhook Secret 内容而不需要进行 Base64 编码。
如果你使用的是其他的代码托管平台，例如 GitLab，可以参考 https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/进行配置。

4）将源码仓库和应用定义仓库分离

本次实践将示例应用的源码和 Helm Chart 存储在了同一个 Git 仓库，实际上， 这并不是一个好的实践。
这种方案有两个比较大的问题。首先，当我们手动修改 Helm Chart 并推送到 Git 仓库之后，在业务代码不变的情况下也会触发应用镜像构建，这个过程是没有必要的。
其次，在有一定规模的团队中，开发和发布过程是分开的，应用定义仓库一般只有基础架构部门或者 SRE 部门具有修改权限，将源码和应用定义放在同一个 Git 仓库不利于权限控制，开发者也很容易误操作。
所以，基于上面这两个问题，强烈建议将业务代码和应用定义分开存储管理。

5）加密 GitOps 中存储的秘钥

本次实践使用的是 DockerHub 公开仓库，所以 Kubernetes 集群不需要镜像拉取凭据就可以拉取到镜像。
在实际生产环境下，一般我们会使用内部自建例如 Harbor 私有仓库。所以在大部分情况下，我们会在 Helm Chart 里增加一个包含镜像拉取凭据的 Secret 对象。

apiVersion: v1
kind: Secret
metadata:name: regcred
type: kubernetes.io/dockerconfigjson
data:.dockerconfigjson: >-eyJhdXRocyI6eyJodHRwczovL2luZGV4LmRvY2tlcxxxxS8iOnsidXNlcm5hbWUiOiJseXpoYW5nMTk5OSIsInBhc3N3b3JkIjoibXktdG9rZW4iLCJhdXRoIjoiYkhsNmFHRnVaekU1T1RrNmJYa3RkRzlyWlc0PSJ9fX0=

当 ArgoCD 部署应用时，会一并将拉取凭据部署到集群中，这就解决了镜像拉取权限的问题。
但是，Secret 对象并没有加密功能， 这可能会导致凭据泄露。 所以，我们需要对这些敏感信息进行加密处理。关于如何加密秘钥，是一个遗留项！