Argo CD 从入门教程来看其架构

本文的目标是能对 Argo CD 基本操作有一定的了解,同时可以对 Argo CD 的架构、组成有一定的认识。准备kubectlkubernetes 集群安装kubectl create namespace argocdkubectl apply -n argocd -f https://raw.g

本文的目标是能对 Argo CD 基本操作有一定的了解,同时可以对 Argo CD 的架构、组成有一定的认识。

准备

  • kubectl
  • kubernetes 集群

安装

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

执行完上述命令后,会创建一个 argocd 命名空间,并将所有的 argo cd 服务都安装在该命名空间下。

部分资源状态

使用

先获取用户名和登陆密码

用户名:admin

登陆密码(可通过如下方式获得)

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

再将本地 8080 端口转发到 Argo CD 的 argocd-server 服务

kubectl port-forward svc/argocd-server -n argocd 8080:443

接下来可以通过两种方式来操作运行在 kubernetes 集群中的 Argo CD 服务,分别为:

  • Web UI 方式

打开浏览器,输入 localhost:8080/,选择相信证书,输入用户名、密码即可登陆。

  • Command CLI 方式

安装 argocd 命令行:

brew install argocd

通过命令行登陆:

argocd login localhost:8080

按提示输入即可。

更进一步

apply yaml 时的输出如下:

customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
serviceaccount/argocd-application-controller created
serviceaccount/argocd-dex-server created
serviceaccount/argocd-redis created
serviceaccount/argocd-server created
role.rbac.authorization.k8s.io/argocd-application-controller created
role.rbac.authorization.k8s.io/argocd-dex-server created
role.rbac.authorization.k8s.io/argocd-redis created
role.rbac.authorization.k8s.io/argocd-server created
clusterrole.rbac.authorization.k8s.io/argocd-application-controller created
clusterrole.rbac.authorization.k8s.io/argocd-server created
rolebinding.rbac.authorization.k8s.io/argocd-application-controller created
rolebinding.rbac.authorization.k8s.io/argocd-dex-server created
rolebinding.rbac.authorization.k8s.io/argocd-redis created
rolebinding.rbac.authorization.k8s.io/argocd-server created
clusterrolebinding.rbac.authorization.k8s.io/argocd-application-controller created
clusterrolebinding.rbac.authorization.k8s.io/argocd-server created
configmap/argocd-cm created
configmap/argocd-gpg-keys-cm created
configmap/argocd-rbac-cm created
configmap/argocd-ssh-known-hosts-cm created
configmap/argocd-tls-certs-cm created
secret/argocd-secret created
service/argocd-dex-server created
service/argocd-metrics created
service/argocd-redis created
service/argocd-repo-server created
service/argocd-server created
service/argocd-server-metrics created
deployment.apps/argocd-dex-server created
deployment.apps/argocd-redis created
deployment.apps/argocd-repo-server created
deployment.apps/argocd-server created
statefulset.apps/argocd-application-controller created
networkpolicy.networking.k8s.io/argocd-application-controller-network-policy created
networkpolicy.networking.k8s.io/argocd-dex-server-network-policy created
networkpolicy.networking.k8s.io/argocd-redis-network-policy created
networkpolicy.networking.k8s.io/argocd-repo-server-network-policy created
networkpolicy.networking.k8s.io/argocd-server-network-policy created

这个 yaml 文件 中所包含的资源如下:

资源导图

可以从中看出,其主要功能的是 5 个组件,分别为:

  • argocd-server

与外界进行交互,所有流量的入口。包括 Web UI 流量入口、Command CLI 流量入口以及相应 Git 仓库的 Webhook事件等。可通过上述使用过程中的 port-forward 来理解,我们只需要将该模块的 443 端口映射处理便可以使用这个 Argo CD 的功能。

  • argocd-dex-server

Argo CD 内部所使用到的工具

  • argocd-repo-server

在本地维护 Git 仓库缓存,并生成 yaml

  • argocd-application-controller

kubernetes controller,持续监听 application crd 并比较当前状态(集群中的状态)与所期望状态(Git 仓库中所定义的状态)。

  • argocd-redis

Argo CD 内部所使用到的缓存数据库

因此可以看出,argocd-server + argocd-dex-server 就组成了下面架构图中的 API 部分:

Argo CD 架构图

还有一个有意思的地方:Argo CD 相关的 3 个 Deployment 及 1 个 StatefulSet 所使用的镜像是一样的。这里需要涉及到它的打包方式,可以从源码中看出:Argo CD 服务所使用的二进制是相同的,但他们的启动命令不同;不同的启动命令对应不同的功能组(可通过 源文件 查看)。

const binaryNameEnv = "ARGOCD_BINARY_NAME"

func main() {
	var command *cobra.Command

	binaryName := filepath.Base(os.Args[0])
	if val := os.Getenv(binaryNameEnv); val != "" {
		binaryName = val
	}
	switch binaryName {
	case "argocd", "argocd-linux-amd64", "argocd-darwin-amd64", "argocd-windows-amd64.exe":
		command = cli.NewCommand()
	case "argocd-util", "argocd-util-linux-amd64", "argocd-util-darwin-amd64", "argocd-util-windows-amd64.exe":
		command = util.NewCommand()
	case "argocd-server":
		command = apiserver.NewCommand()
	case "argocd-application-controller":
		command = appcontroller.NewCommand()
	case "argocd-repo-server":
		command = reposerver.NewCommand()
	case "argocd-dex":
		command = dex.NewCommand()
	default:
    // ...
	}

	if err := command.Execute(); err != nil {
		fmt.Println(err)
		os.Exit(1)
	}
}

新建一个 Application 之后,可以在 Web UI 里面看到新建的应用及其状态如下:

应用状态

其中所展示的状态均来自对应的 CRD,如下:

Application CRD

详情如下:

spec:
  destination:
    namespace: nginx-ns
    server: 'https://kubernetes.default.svc'
  project: default
  source:
    path: nginx
    repoURL: 'https://xxxxxxxx/argocd-yamls.git'
    targetRevision: HEAD
status:
  health:
    status: Missing
  reconciledAt: '2021-06-17T07:30:33Z'
  resources:
    - group: apps
      health:
        status: Missing
      kind: Deployment
      name: nginx-deployment
      namespace: nginx-ns
      status: OutOfSync
      version: v1
  sourceType: Directory
  summary: {}
  sync:
    comparedTo:
      destination:
        namespace: nginx-ns
        server: 'https://kubernetes.default.svc'
      source:
        path: nginx
        repoURL: 'https://xxxxxxxx/argocd-yamls.git'
        targetRevision: HEAD
    revision: 5acebc82a613b73b46a09be1b023a1720ea3f7e9
    status: OutOfSync

Reference

Read more

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd