Argo CD 使用说明

一，背景概述

1.0，背景知识

docker虚拟化技术
Kubernetes容器编排技术

1.1，历史操作

以自身的使用经历来说明，之前在一个服务器上部署java程序的流程如下

本地java-maven打包成为成果物
将java程序的成果物上传到服务器上
使用命令kill具体服务的进程
使用命令启动java服务

上述的4个小步骤可以划分为2大步，其中1、2为集成阶段，3、4为部署阶段。

这样的做法有什么缺点呢？

麻烦、麻烦、麻烦（一个服务还好，如果是微服务架构一次将近50多个服务，让你一个人去维护怎么办？直接当场爆炸）
不安全（上述步骤的执行，需要暴露服务器的读写访问权限，如果权限控制没有做好，有人直接执行 rm -rf / 呢？！！也是直接当前爆炸）

如何解决上述的一些问题呢？这就涉及到后面出现的CI/CD（持续集成部署）

1.2，CI/CD

持续集成和持续部署（CI/CD）管道是为了交付新版本软件而必须执行的一系列步骤。

CI/CD 管道是一种实践，主要是通过自动化在整个软件开发生命周期改进软件交付。

在软件开发生命周期中的开发、测试、生产和监控阶段自动化 CI/CD，企业能够更快地开发更高质量的代码。尽管可以手动执行 CI/CD 管道的每个步骤，但 CI/CD 管道的真正价值在于自动化。

CI/CD Flow

优点：

节省运维成本（以前需要一个运维团队，在使用CI/CD方案后）
安全（物理服务器信息无需暴露给运维人员）

得益于docker虚拟化技术、k8s容器编排工具的大规模推广，当前已经有很多CI/CD实践方案，下图红框中其常用的工具。

这次要讲解的Argocd就是用于CD持续部署的一个k8s工具，同时Argo也有一个用于工作流（可以编写持续集成CI流水线）的工具argo-workflow。

1.3，Argo CD

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

一般认为应用程序的定义、配置和环境应该是声明式的，并受版本控制。应用程序部署和生命周期管理应该是自动化的、可审计的，并且易于理解。Argo CD正是为了实现上述目标而生。

Argo CD Architecture

Argo CD ui页面

Argo CD UI

二，安装部署

2.1，yaml安装

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

2.2，Kustomize安装

kustomization.yaml样例文件

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: argocd
resources:
- https://raw.githubusercontent.com/argoproj/argo-cd/v2.7.2/manifests/install.yaml

执行安装命令（上述文件的同路径下）：

kubectl apply -k

2.3，helm安装

helm repo add argo https://argoproj.github.io/argo-helm
helm install my-argo-cd argo/argo-cd --version 5.46.4

待全部的pod处于running状态（如下图所示），即可正常使用

三，系统准备

3.1，进入ui页面

想办法暴露argocd-server的对外访问能力，例如：NodePort、Loadbalance、Ingress等（此处略过）

进入UI页面如下

获取系统初始化密码，执行如下命令

kubectl get secret -n argocd argocd-initial-admin-secret -o yaml

将其中的password进行转换解析（此处的密码为样例）

echo cFN4SG5kR0tadFpjQ3Jaag== |base64 -d

添加账户密码后登录，正式进入页面

3.2，添加git仓库

进入setting页面

进入Repositories页面

添加git仓库（或者helm仓库）

添加完成后，CONNECTION STATUS状态如果为 Successful，表明argocd已经正常连接到，如下图所示

四，基础元素说明

4.1，核心概念

Application：由manifest定义的一组Kubernetes资源。这是自定义资源定义(CRD)。
Target state：应用程序的期望状态，由Git存储库中的文件表示。
Live state：该应用程序的活动状态。部署了哪些pod资源等。
Sync status：当前状态是否与目标状态匹配。部署的应用程序是否与Git要求的相同?
Sync：使应用程序移动到其目标状态的过程。例如，通过对Kubernetes集群应用更改。
Sync operation status：同步是否成功。
Refresh：将Git中的最新代码与实时状态进行比较。找出不同之处。
Health：应用程序的运行状况，是否正常运行?它能处理请求吗?

4.2，操作方式

可以通过WebUI、CLI命令行、第三方访问进行控制

4.3，支持方式

Kustomize applications
Helm charts
A directory of YAML/JSON/Jsonnet manifests, including Jsonnet.
Any custom config management tool configured as a config management plugin

4.4，声明式配置

Argo CD应用程序、项目和设置可以使用Kubernetes清单进行声明式定义。这些可以使用kubectl apply来更新，而不需要使用argocd命令行工具。
所有资源，包括Application和AppProject规范，都必须安装在Argo CD命名空间中(默认情况下是argocd)。

4.4.1， Application

Application CRD是Kubernetes资源对象，表示环境中已部署的应用程序实例。它由两个关键信息定义:

source：到Git中所需状态的源代码引用(存储库、修订、路径、环境)

destination：目标集群和名称空间的目标引用。对于集群，可以使用服务器或名称中的一个，但不能同时使用两者(这会导致错误)。当服务器丢失时，它将根据名称进行计算，并用于任何操作。

本质就是声明了将要部署哪些资源。这些资源来源于哪里、部署在哪里。

样例（部署git仓库某个目录下的资源）：

---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: dev-apps-index
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: argocd # 部署的目标namespace
    server: https://kubernetes.default.svc # 部署于哪一个集群中
  project: dev-apps-index # 部署在哪个项目下
  source: # 部署的材料来源
    path: cd/index/dev/microservice
    repoURL: https://gitee.com/activeclub/gitops-dev.git
    targetRevision: HEAD
    directory:
      recurse: true
  syncPolicy: # 同步策略
    automated: {}

样例（helm部署Cassandra）：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: database-cassandra
  namespace: argocd
spec:
  destination:
    namespace: database
    server: https://kubernetes.default.svc
  source:
    repoURL: 'https://charts.bitnami.com/bitnami'
    targetRevision: 10.5.3
    chart: cassandra
  sources: []
  project: dev-apps
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

下图为成功部署后的资源运行状态

4.4.2，AppProject

AppProject CRD是Kubernetes资源对象，表示应用程序的逻辑分组（项目）。它由以下关键信息定义:

sourceRepos：对存储库的引用，项目中的应用程序可以从中提取清单。

destinations：引用项目中的应用程序可以部署到的集群和名称空间(不要使用name字段，只匹配server字段)。

roles：列表中的实体定义了它们对项目内资源的访问权限。

AppProject限定了可以使用哪些资源仓库（git、helm等仓库）、可以部署到哪些命名空间、可以使用哪些集群资源、可以使用哪些命名空间下的资源。

样例：

---
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: dev-apps
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: Dev Applications
  sourceRepos: # 可用仓库地址
  - 'https://gitee.com/abcd/gitops-dev.git'
  destinations: # 可部署namespace
  - namespace: microservice
    server: https://kubernetes.default.svc
  - namespace: "*"
    server: https://kubernetes.default.svc
  clusterResourceWhitelist: # 集群资源白名单
  - group: '*'
    kind: '*'
  namespaceResourceWhitelist: # 集群命名空间下资源白名单
  - group: '*'
    kind: '*'

部署上述AppProject资源

可以在setting中看到相关信息

4.5，相关配置

可以直接在ui上进行配置也可以直接在注解中配置

PRUNE：

删除没有存在价值的对象

sync option no prune

DRY RUN：

干运行（试运行）。禁止ApplicationSet创建、修改或删除所有应用程序

https://github.com/argoproj/argo-cd/issues/12592

APPLY ONLY：

如果选择“Apply Only”，那么Argo CD将跳过前后同步挂钩，只运行kubectl申请应用程序资源。

FORCE：

强制执行。但是，需要注意的是，当补丁重试5次后遇到冲突时，强制操作会删除资源。

SKIP SCHEMA VALIDATION：

是否跳过模式验证

AUTO-CREATE NAMESPACE：

自动创建命名空间

PRUNE LAST：
此特性允许在部署其他资源并恢复正常之后，以及在所有其他波成功完成之后，将资源修剪作为同步操作的最后隐式波进行。

APPLY OUT OF SYNC ONLY：

目前，使用自动同步进行同步时，Argo CD会应用应用程序中的每个对象。对于包含数千个对象的应用程序，这需要相当长的时间，并且会给 api 服务器带来不适当的压力。启用选择性同步选项，该选项将仅同步不同步的资源。

RESPECT IGNORE DIFFERENCES：

此同步选项用于使 Argo CD 在同步阶段也考虑属性中进行的配置。

默认情况下，Argo CD 仅使用配置来计算实时状态和所需状态之间的差异，该状态定义了应用程序是否同步。但是，在同步阶段，所需状态将按原样应用。修补程序是使用实时状态、所需状态和注释之间的 3 向合并来计算的。这有时会导致不希望的结果。

SERVER-SIDE APPLY：

默认情况下，Argo CD 执行操作来应用 Git 中存储的配置。这是一个客户端操作，它依赖于注释来存储以前的资源状态。

资源太大，无法容纳 262144 字节允许的注释大小。在这种情况下服务器端应用可用于避免此问题，因为在这种情况下不使用注释。

REPLACE：

替换资源，而不是修改资源（更新）

在同步过程中，将使用“kubectl 替换/创建”命令同步资源。此同步选项可能具有破坏性，并可能导致必须重新创建资源，这可能会导致应用程序中断。

RETRY：

重试策略

    # The retry feature is available since v1.7
    retry:
      limit: 5 # number of failed sync attempt retries; unlimited number of attempts if less than 0
      backoff:
        duration: 5s # the amount to back off. Default unit is seconds, but could also be a duration (e.g. "2m", "1h")
        factor: 2 # a factor to multiply the base duration after each failed retry
        maxDuration: 3m # the maximum amount of time allowed for the backoff strategy

五，扩展使用

5.1，argocd-image-updater

一个自动更新由Argo CD管理的Kubernetes工作负载的容器映像的工具。

核心功能：检测docker镜像仓库中的版本变更情况，依照选定的策略进行自动化的服务版本更新

安装部署

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml

配置docker镜像仓库信息

kubectl create -n argocd secret docker-registry dockerhub-secret \
	--docker-username someuser \
	--docker-password s0m3p4ssw0rd \
	--docker-registry "https://registry-1.docker.io"

修改argocd-image-updater-config内容

---
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: argocd-image-updater-config
    app.kubernetes.io/part-of: argocd-image-updater
  name: argocd-image-updater-config
data:
  registries.conf: |
    registries:
    - name: AlibabaCloud Container Registry
      api_url: https://registry.cn-hangzhou.aliyuncs.com
      prefix: registry.cn-hangzhou.aliyuncs.com
      credentials: pullsecret:argocd/aliyun-docker-secret

调整application资源

添加《argocd-image-updater.argoproj.io》相关的注解

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: uid-server
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: uidserver=registry.cn-hangzhou.aliyuncs.com/abcd/uidserver
    argocd-image-updater.argoproj.io/trace-collector.update-strategy: latest
    argocd-image-updater.argoproj.io/write-back-method: git
    argocd-image-updater.argoproj.io/write-back-target: kustomization
    argocd-image-updater.argoproj.io/git-branch: master
spec:
  destination:
    namespace: microservice
    server: https://kubernetes.default.svc
  source:
    path: cd/apps/dev/project/uid-server
    repoURL: https://gitee.com/activeclub/gitops-dev.git
    targetRevision: HEAD
  sources: []
  project: dev-apps
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

调整Kustomization

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: blog-server
commonLabels:
  app: blog-server
resources:
- deployment.yaml
- ingress-http.yaml
images:
- name: registry.cn-hangzhou.aliyuncs.com/activeclub/blog-server
  newTag: 1.0.0-230912-141907-0694

六，拓展知识点

Devops

DevOps（Development和Operations的混成词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

Docker

Docker是一个开放源代码的开放平台软件，用于开发应用、交付（shipping）应用和运行应用。Docker允许用户将基础设施（Infrastructure）中的应用单独分割出来，形成更小的颗粒（容器），从而提高交付软件的速度。

Kubernetes

Kubernetes（常简称为K8s）是用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。[4]该系统由Google设计并捐赠给Cloud Native Computing Foundation（今属Linux基金会）来使用。

声明式vs命令式

声明式(declarative)是结果导向的，命令式(imperative)是过程导向的。它们都有自己适用的场景和局限，于是现实中的编程语言常常都有两者的身影。

参考文档：

posted on 2023-09-20 19:20 周健康阅读(1510) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

周健康的技术博客