系列文章目录

本文章分为2个部分：

        Part 1主要涉及Gitlab、Gitlab-Runner、Git-Ci、Sonar-qube-CI阶段

        Part 2主要涉及ArgoCD阶段

Gitops-万字保姆级教程-小白也可以轻松学会! (Part 1)-CSDN博客

Gitops-万字保姆级教程-小白也可以轻松学会! (Part 2)

---

---

前言

        在Part 1中我们安装了Gitlab、配置了Gitlab-Runner、并且测试了最基本的Ci流水线。

        接着结合Sonar_qube对代码进行静态扫描并集成在Gitlab_Ci中。

        我们初步的完成了Ci阶段。

        这篇Part 2 主要涉及到CD阶段，通过Argo结合Gitops部署到我们的环境中。

        在Part 1 篇中我们使用的Python代码只用于演示Ci阶段，本次演示代码使用DevOps Journey博主的Github开源仓库。

开源万岁！

---

一、Argo-CD是什么？

        1.1 Argo-CD官网

Home | Argo

        1.2 一句话说明Argo-CD以及Argo-CD的软件架构

        Argo CD是Kubernetes的声明式、GitOps持续交付工具。

        那么Argo CD的组件有哪些？干什么用？

                1.2.1 Api Server

        Argo_CD的Api Server 对外提供两种接口，一种是Grpc,一种是REST，其中Grpc用于Argo-CD的Cli工具交互，REST 而为UI服务。他的最重要作用：1、处理客户端(Ui/Cli)请求 2、处理自身以及第三方CI/CD工具集成请求。

                1.2.2 Repository Server

存储库服务器（Repository Server）的概念可以通过以下几个方面来理解：

1. 内部服务：存储库服务器是一个在后台运行的服务，通常是云原生环境或持续集成/持续部署（CI/CD）流程中的一部分。它不直接面向最终用户，而是为其他服务或系统组件提供支持。

2. 维护Git存储库的本地缓存：存储库服务器有一个重要的功能是维护Git存储库的本地缓存。这意味着它会将远程Git存储库的内容复制到本地系统中，以便快速访问和处理。这个本地缓存可以提高性能，减少对远程存储库的直接访问，从而提高效率和响应速度。

3. 包含应用程序清单：存储库中包含的是应用程序清单，这些清单是描述应用程序部署和配置所需的文件。在Kubernetes环境中，这通常包括各种YAML文件，如部署、服务、配置映射等。

4. 生成和返回Kubernetes清单：当存储库服务器接收到特定的输入（如存储库URL、修订（提交、标签、分支）、应用路径以及模板特定设置（参数，Helm values.yaml等））时，它会基于这些输入生成相应的Kubernetes清单。这些清单是根据存储库中的应用程序清单和提供的参数动态生成的，用于在Kubernetes集群中部署和管理应用程序。

5. 输入参数的作用：

   • 存储库URL：指定Git存储库的位置，存储库服务器将从此URL克隆或更新本地缓存。
   • 修订（提交、标签、分支）：指定Git存储库中特定的修订版本，以便存储库服务器可以检出正确的代码或配置状态。
   • 应用路径：指定存储库中包含应用程序清单的路径，这有助于存储库服务器找到并处理正确的文件。
   • 模板特定设置：如参数和Helm的values.yaml文件，这些设置允许用户自定义生成的Kubernetes清单，以满足特定的部署需求或配置要求。

        1.3 安装RKE2

        请参考我的另一篇博客部署安装Rke2集群搭建一个kubernetes集群，如果一台主机则即当server节点也当worker、etcd节点、部署安装3分钟不到。

Rancher-RKE2-安装流程_rke2 安装-CSDN博客

        1.4 部署Argo-CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

验证：有一些状态问题是我集群的问题，可以不管哈。

                1.4.1 部署的Pod的用途解释

1. argocd-application-controller-0: 这是Argo CD的应用程序控制器Pod，状态为Running，表示它正在正常运行。它没有重启过，运行时间为4天11小时。应用程序控制器负责监控和维护Argo CD管理的应用程序状态。

2. argocd-applicationset-controller-65bb5ff89-wszqs: 这是Argo CD ApplicationSet控制器的Pod，也处于Running状态，表示正常运行。ApplicationSet控制器用于管理ApplicationSet资源，这是一种可以同时管理多个Argo CD应用程序的资源。

3. argocd-dex-server-6f898cbd9-zz4dg: 这是另一个Argo CD的Dex服务器Pod，状态为Running，表示正常运行。Dex是一个身份服务，用于提供OAuth2和OpenID Connect（OIDC）功能。

4. argocd-notifications-controller-64bc7c9f7-mml5d: 这是Argo CD通知控制器的Pod，状态为Running。Argo CD通知控制器用于发送通知（如Slack、Email等）。

5. argocd-redis-5df55f45b7-ggrsn: 这是Argo CD使用的Redis服务器Pod，状态为Running。Redis用于缓存和其他数据存储需求。

6. argocd-repo-server-74d5f58dc5-gz8zz 是Argo CD的仓库服务器Pod。仓库服务器负责与版本控制系统（如Git）交云，获取应用程序配置。

7. argocd-server-5b86767ddb-n5qqj: 这是Argo CD的主服务器Pod，状态为Running。Argo CD服务器提供API服务和用户界面。

        1.5 Ingress方式访问Argo-CD

                1.5.1 ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-http-ingress
  namespace: argocd
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              name: http
    host: argocd.example.com
  tls:
  - hosts:
    - argocd.example.com
    secretName: argocd-secret

kubectl apply -f ingress.yaml 

                1.5.2 修改Configmap文件,添加insecure为true，我们证书在入口的控制器终结。

kubectl edit cm/argocd-cmd-params-cm -n argued

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"argocd-cmd-params-cm","app.kubernetes.io/part-of":"argocd"},"name":"argocd-cmd-params-cm","namespace":"argocd"}}
  creationTimestamp: "2024-07-11T03:13:33Z"
  labels:
    app.kubernetes.io/name: argocd-cmd-params-cm
    app.kubernetes.io/part-of: argocd
  name: argocd-cmd-params-cm
  namespace: argocd
  resourceVersion: "205867846"
  uid: dac39b0f-a273-4cf6-bf31-6d7e3fad096b
data:
  server.insecure: "true"

                1.5.3 修改你的本机host文件

echo "xxxxx  argocd.example.com" >> /etc/hosts

                1.5.4 访问Argo-CD

  

                1.5.5 获取初始admin密码

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath='{.data.password}' | base64 --decode; echo

                1.5.6 进入到Argo- CD UI

1.6 Helm方式部署示例应用以及测试ArgoCD

        1.6.1 创建New App

        *Application name 为你应用的名称

        *Preject name 为你项目的名称-选择default

        *SYNC Policy 同步规则：手动和自动

                手动：即Argocd检测到你Gitrepo仓库存在更改需要你手动在ArgoCD中进行同步才会部署到你的Kubernetes集群中。

                自动：即ArgoCD探测到Gitrepo代码变化则自动部署到Kubernetes集群中。

        下面这些选项，后面实际用到的时候再做解释。

        目前先选择一个自动创建NameSpace.即如果你的App的部署文件中有不存在的NameSpace则会自动创建。

        下面配置Repo源，下面的源为Youtu博主DevOps Journey提供示例：

        *提供了两种不同方式的部署：helm以及kustom。 

        *这个项目会部署1个deployment,1个Configmap,1个NodePort类型的service

                复制下面项目的URL即可。

GitHub - devopsjourney1/argo-examples

        

HEAD：在 Git 中，HEAD 是一个引用，指向当前分支的最新提交。因此，当 Argo CD 的 TARGET REVISION 设置为 HEAD，它会持续追踪并同步 Git 仓库中相应分支的最新更改 。

        配置目的部署到目的Kubernetes:

        最下面的Helm-参数配置文件选择：

        valus-dev.yaml.

        点击左上角的Create-创建。

        **你可以看到应用程序已经部署，但状态为OutOfSync,没有进行同步，因为我们选择了手动同步。

        1.6.2 ArgoCD 手动同步 

        *点击SYNC

        *点击同步后效果         

        *进入到我们的RKE2集群进行验证。

kubectl get po -n dev

        *进行访问测试验证 

kubectl get svc -n dev

        1.6.3  ArgoCD 自动同步 

        *修改指定helm文件values-dev.yaml中的replicas来测试自动同步。       

        ***在Github中你需要导入博主的Github-repo就可以自己提交修改。

*在Argo-CD中刷新App的状态

        *可以看到副本变为2个，我们进入本地集群查看

kubectl get po -n dev

        1.6.4 模拟错误并回退

        上面我们演示了从初始化的5个Pods到我们修改副本数为2个，那么这次假设我们做了一次App的Update，并且我们这次Update有问题，需要进行回退到之前的5个Pods.

        *你当然可以直接在Github上进行修改为5个，ArgoCD依然会自动同步，但前提是你需要知道你到底修改了什么内容。这是一个手工且不能验证的操作，存在风险。

        *ArgoCD则提供了一种自动化的方式来解决回退问题。

        点击History and rollback,

        *你可以看到我们对目标App的修订历史版本号。

        *App页面上是我们的当前修订版本号。 

        *找到我们上次操作的修订版本号，右边的按钮，点击Rollback.

        *他会提示你需要关闭自动同步来进行这次操作，这个很好理解，因为如果存在自动同步则ArgoCD又会同步到最新的版本。

        *在App页面你可以看到回退到了我们第一个历史修订版本号。

        *并且App的Repset为5个Pods. 

        **那么修订的版本号是怎么来的呢？

我们点击修订的版本号

 

他会跳转Github的网站,那么可以看到ArgoCD的历史修订版本号其实就是Github上的历史修订版本号。

 

1.7 Kustom方式部署示例应用

        部分同学可能没使用过Kustom，可以看一下我另外一篇博客～

5分钟了解，kustom是什么工具？-CSDN博客

        1.7.1 创建App

        1.7.2 配置如下

 

        **这里选择的是自动同步Git-repo

 

        **还是之前的Git-repo,这里截图是我Import的项目地址。你需要替换为你的import的Github项目地址。 

 

        **部署的Kubernetes集群还是本地，Namespace是dev.

        **可以看到下面匹配的就是Kustomize.

        **这里需要注意，因为Kustomize的语法更新了，在/dev/kustomization.yaml需要修改patches的语法。

bases:
- ../../base

patches:
- path: replicas.yaml

configMapGenerator:
- name: mykustom-map
  env: config.properties

        **我们点击Create。查看App部署情况。

        **可以看到部署成功了，并且应用的是我们dev环境下的Patch配置环境来部署的App. 

        **同时查看部署的资源，Deploy以及Pod的名称。就可以理解上面没有讲到的

namePrefix:
  kustom-

nameSuffix:
  -v1

        **其实就是在基础模版Deployment的name字段的值的基础上加前缀和后缀。

        **基础模版中定义的App的Deployment资源的名称为mywebapp. 

1.8 Helm与Kustom迭代应用

        **通过Github的edit也同样可以完成。

        1.8.1 修改Helmapp的values-dev.yaml配置文件

        1.8.2 修改Kustomzi的yaml配置文件

        1.8.3 推送到仓库、查看App现象

        1.8.4 Kustom-App现象 

        **可以看到Kustom-App的状态为进程中，因为他在重启Pod.

        **可以看到上面为新的Pod存活时间为2分，下面为38分之前老的Pod.

        **并且可以看到Configmap有两份配置文件。但其实在我们Github-repo中只有一份配置文件，也是导致我们无法同步的原因。

        **进行修建操作。 

 

        **只有一份则正常。

1.8.5 Helm现象

        **Helm则是同步了，只有一份ConfigMap.

但他的Pod并没有应用这个Configmap.

 

        **我们对Deploy执行restart即可。

 1.8.6 迭代总结

        总结，这种行为差异主要是由于 Kustomize 和 Helm 更新配置资源时的机制不同。Kustomize 通过改变资源名称来强制更新，自然触发了 Pod 的重启。而 Helm 则依赖于模板和值的变化，不一定会改变资源的名称，因此不会自动触发 Pod 重启，除非采取了额外的措施。

1.9 升级迭代最佳实践

正确的迭代更新应用程序，无论是使用 Kustomize、Helm 还是其他工具，在 Kubernetes 环境中的最佳实践通常包括以下几个方面：

1. **版本控制**:
   - 将所有配置文件和模板存储在版本控制系统中，如 Git。这样可以追踪每次更改的历史，方便回滚和审计。

2. **持续集成/持续部署 (CI/CD)**:
   - 使用 CI/CD 管道自动化部署过程。当代码或配置更改被推送到版本控制系统时，自动触发部署流程。ArgoCD 是 Kubernetes 环境中的一个流行选择，它可以监控 Git 仓库并自动同步更改。

3. **环境隔离**:
   - 为开发、测试和生产等不同环境使用不同的命名空间或集群。通过 Kustomize 或 Helm 的值文件来管理每个环境的特定配置。

4. **配置管理**:
   - 使用 ConfigMap 和 Secrets 管理应用配置和敏感信息。确保敏感信息（如密码和密钥）不被直接存储在配置文件中，而是使用 Kubernetes Secrets。

5. **资源更新策略**:
   - 明确定义如何处理资源更新，特别是对于需要重启的资源（如 Deployment）。对于 Helm，考虑使用如 `helm upgrade --recreate-pods` 的命令或在 ConfigMap 和 Secrets 名称中包含内容哈希来触发重启。
   - 对于 Kustomize，利用其生成资源名称后缀的能力（如哈希值）来自动触发依赖资源的更新。

6. **监控和日志**:
   - 配置适当的监控和日志收集工具，以便于实时监控应用状态和性能，以及快速定位问题。

7. **灰度发布和回滚策略**:
   - 实施灰度发布（如使用 Kubernetes 的 Deployment 策略）和自动回滚机制，以减少新版本可能引入的风险。

8. **文档和培训**:
   - 维护详细的文档，记录部署流程、配置指南和故障排除步骤。确保团队成员了解操作流程和最佳实践。

通过遵循这些最佳实践，团队可以确保应用的迭代更新过程既高效又可靠，同时最大限度地减少出错的可能性。

-----------------------------------------------------------------------------------------------

2.0 总结

        本篇文章重点讲述了如何安装、使用Argocd，以及如何升级、迭代应用，并且阐述了Helm、Kustomize迭代应用的区别。最后也分享了最佳迭代应用的实践步骤。

        下一篇紧跟最佳实践：Gitops-万字保姆级教程-小白也可以轻松学会! Part3, 将重点关注监控、日志。