大家好,我是张晋涛。
在上一篇『GitOps 应用实践系列 - 综述(一)』
2020 年 4 月 7 日,CNCF Technical Oversight Committee (TOC) 投票通过 Argo 项目进入 CNCF 孵化。
其实 Argo 是在 2017 年由 Applatix 公司创建的(这家公司的主要产品和服务目前主要与 AWS 进行深度融合,当然也包括一些多云的服务),2018 年初被 Intuit 收购。之后,BlackRock 为 Argo 项目贡献了 Argo Events 子项目。两家公司都积极参与项目和社区的开发和培育中。
Argo 及其子项目提供了一种简单的方法管理 Workflow,事件和应用程序。所有 Argo 工具都通过 CRD 的方式实现。他们可以使用或集成其他 CNCF 项目,如 gRPC、Prometheus、NATS、Helm 和 CloudEvents。
Argo 生态目前主要由四个子项目组成,包括:
Argo Workflows -- 第一个 Argo 项目,是 Kubernetes 的原生工作流引擎,支持 DAG 和 step-based 的工作流;
Argo Events -- Kubernetes 上的基于事件的依赖管理器,用于触发 Kubernetes 中的 Argo 工作流和其他操作。
Argo CD -- 是 Argo 社区和 Intuit 带来的开源项目,支持基于 GitOps 的声明性部署 Kubernetes 资源。
Argo Rollouts -- 支持声明式渐进式交付策略,例如 canary 、blue-green 和更多形式。
Argo CD 旨在提供一个声明式持续交付 (CD) 工具。Argo CD 支持多种配置管理工具,包括 ksonnet /jsonnet,kustomize 和 Helm 等。Argo CD 扩展了声明式和基于 Git 的配置管理的优势,以在不影响安全性和合规性的情况下加速应用程序的部署和生命周期管理。
应用程序及其部署环境的配置是声明性的,并且是版本可控的;
应用程序部署和生命周期管理简单、可自动和可审计(企业友好);
应用程序部署快速、可靠和幂等;
需要检测并纠正与版本控制配置的任何偏差;
回滚简单;
可搭配使用各种配置管理工具(如 ksonnet/jsonnet、Helm 和 kustomize)使应用程序与 Git 中定义的保持一致;
将应用程序自动部署到指定的目标环境;
持续监控已部署的应用程序;
基于 Web 和 CLI 的操作,以及应用程序可视化;
部署或回滚到 Git 仓库中提交的应用程序的任何状态(这也是使用 Git 进行版本管理的一大好处);
PreSync、Sync、PostSync hooks 以支持复杂的应用程序部署策略(例如:blue/green 、canary upgrades);
SSO 集成(OIDC、LDAP、SAML 2.0、GitLab、Microsoft、LinkedIn),这些是企业比较需要的功能;
Webhook 集成(GitHub、BitBucket、GitLab)。
可以独立使用,也可以作为现有 Pipeline 的一部分使用,例如与 Argo Workflow、Jenkins 以及 GitLab CI 等配合使用;
从整体上看,Argo CD 有三个主要的组成部分:API Server 、Repository Server 、Application Controller。
Argo CD 的 API Server 是一个 gRPC/REST server,它公开 Web UI、CLI 以及一些其他场景需要用到的 API。
它主要进行以下几个内容:
应用程序管理和状态报告;
调用应用程序操作(例如:同步、回滚、用户定义的操作);
repository 和集群 credential 管理(存 K8s secrets);
身份验证和授权委托给外部身份认证组件;
RBAC(Role-based access control 基于角色的访问控制);
Git webhook 事件的 listener/forwarder;
Repository Server 是一个内部服务,它负责保存应用程序 Git 仓库的本地缓存,并负责生成和返回可供 Kubernetes 使用的 manifests,它接受的输入信息主要有以下内容:
仓库地址(URL)
revision(commit, tag, branch)
应用程序路径
模板的特定设置:比如 helm values.yaml 等
Application Controller 是一个 Kubernetes controller,它持续监听正在运行的应用程序并将当前的实时状态与所需的目标状态(如 repo 中指定的)进行比较。它检测 OutOfSync 应用程序状态并有选择地采取纠正措施。它负责为生命周期事件(PreSync、Sync、PostSync)调用任何用户定义的 hooks。
自2019年3月17号发布了 v1.0.0 版本开始,到现在,Argo CD已经全面进入了 v2.x 时代,当前最新的版本是 v2.1.5。
在 2.0 中引入了Pods View功能、重写了日志可视化、新增了通知横幅功能、还有很多后台操作及自定义操作,并且致力于打造 Argo CD Core (轻量级 Argo CD 发行版,仅打包核心 GitOps 功能,依赖Kubernetes API/RBAC 为 UI 和 CLI 提供支持)。
Pods View :对于拥有数百个 Pod 的应用程序特别有用。它没有可视化应用程序的所有 Kubernetes 资源,而是仅显示 Kubernetes pod 和密切相关的资源。
新日志可视化:支持分页、过滤、禁用/启用日志流的能力,甚至为终端爱好者提供暗模式。支持查看多个部署 Pod 的聚合日志,Argo CD CLI 也支持日志流。
UI通知横幅功能:使用ConfigMap 中的ui.bannercontent和ui.bannerurl属性指定通知消息和可选 URL argocd-cm。
后台操作:资源的deletion/pruning、仅同步更改的资源、Prune Last、引入了对 Sealed-secrets、kubernetes-external-secrets 和 strimzi CRD 的健康检查。
Argo CD 有四种安装方式:多租户(multi-tenant)、 core 、自定义 、Helm。
多租户是 Argo CD 使用最多的部署方式。用户可以使用 Web UI 或 argocd CLI 通过 API Server访问 Argo CD 。
该 argocd CLI 必须先执行 argocd login
命令。
argocd login SERVER [flags]
# Login to Argo CD using a username and password
argocd login cd.argoproj.io
# Login to Argo CD using SSO
argocd login cd.argoproj.io --sso
# Configure direct access using Kubernetes API server
argocd login cd.argoproj.io --core
在项目的 GitHub 仓库中默认提供了两种部署方式(manifests):
这种类型的安装通常用于演示和测试。(不推荐用于生产)
install.yaml - 具有集群管理员权限的标准 Argo CD 安装。可使用 Argo CD 在其运行的同一集群中部署应用程序,当然也可以使用输入的 credentials 部署到外部集群。
namespace-install.yaml - 只需要命名空间级别的权限(不需要集群管理员权限)。但这种安装的话 Argo CD 不能在其所运行的同一集群中部署应用程序,并且将仅依赖于输入的外部集群 credentials 。
注意:Argo CD CRD 不包含在 namespace-install.yaml 中 必须单独安装。CRD manifests 位于manifests/crds目录中。使用以下命令安装它们:
kubectl apply -k https://github.com/argoproj/argo-cd/manifests/crds\?ref\=stable
强烈建议生产环境使用高可用方式安装。
bundle 包含相同的组件,但针对高可用性和弹性进行了调整。
ha/install.yaml - 与上文中提到的 install.yaml 相同,但配置了相关组件的多个副本;
ha/namespace-install.yaml - 与上文提到的 namespace-install.yaml 相同,但配置了相关组件的多个副本;
core 安装最适合独立使用 Argo CD 且不需要多租户功能的集群管理员。
此安装包括较少的组件,并且更易于设置。bundle 不包括 API Server或 UI,并只安装每个组件的轻量级(非 HA)版本。
用户需要 Kubernetes 访问权限来管理 Argo CD。该 argocd CLI 必须使用下面的命令进行配置:
kubectl config set-context --current --namespace=argocd
argocd login --core
Web UI 也可以使用,可以使用以下命令启动。
argocd admin dashboard
具体的 manifests 对应于仓库中的 core-install.yaml 。
Argo CD manifests 也可以使用自定义安装。建议将 manifests 作为远程资源包含在内,并使用 Kustomize 补丁应用其他自定义。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
resources:
- https://raw.githubusercontent.com/argoproj/argo-cd/v2.0.4/manifests/ha/install.yaml
Argo CD 可以使用Helm安装。Helm chart 目前由社区维护,访问 https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd 获取即可,此处不再添加示例。
Argo CD 没有明确限制 Secret 管理的方式。这里罗列些 GitOps 的管理 Secret 的方式,对其他场景也适用:
Hashicorp Vault 推荐,这是一种比较通用的方案,并且应用场景很广泛。(https://www.vaultproject.io/)
Bitnami Sealed Secrets 将 Secret 加密为可安全存储的 SealedSecret,甚至可以存储到公共库中;SealedSecret 只能由运行在目标集群中的控制器解密,其他人(甚至原作者)都无法从 SealedSecret 中获取原始 Secret。(https://github.com/bitnami-labs/sealed-secrets);
Banzai Cloud Bank-Vaults 为 Vault 提供各种工具,使 Hashicorp Vault 的使用和操作更容易。它是官方 Vault 客户端的封装,具有自动令牌更新和内置 Kubernetes 支持、基于Golang 的客户端的动态数据库凭据提供程序。它有一个 CLI 工具来自动初始化、解封和配置 Vault。它还提供了一个用于配置的 Kubernetes operator,以及一个用于注入机密的 mutating webhook。(https://github.com/banzaicloud/bank-vaults)
Helm Secrets 与Argo CD的集成是从 helm-secrets v3.9.0 开始可用;
argocd-vault-plugin 从各种 secrets 管理工具(HashiCorp Vault、IBM Cloud Secrets Manager、AWS Secrets Manager 等)中检索 secrets 并将它们注入到 Kubernetes 资源中(https://github.com/IBM/argocd-vault-plugin);
Kustomize secret generator plugins Kubernetes ConfigMaps和Secrets都是 key:value (KV) 映射。kustomize 有三种不同的方法来从本地文件生成 secrets,详细可查看链接 。(https://github.com/kubernetes-sigs/kustomize/blob/fd7a353df6cece4629b8e8ad56b71e30636f38fc/examples/kvSourceGoPlugin.md#secret-values-from-anywhere)
aws-secret-operator 一个 Kubernetes operator,可根据 AWS Secrets Manager 中存储的内容自动创建和更新 Kubernetes secrets。aws-secret-operator 自定义资源将 AWS secrets映射到 Kubernetes 。(https://github.com/mumoshu/aws-secret-operator)
secrets-store-csi-driver 是一个利用 CSI 接口,将密钥信息挂载进 Pod 的工具。支持多种密钥存储方式,比如 Vault,GCP,AWS,Azure 等;
Argo CD 为几种标准的 Kubernetes 资源提供了内置的健康评估,然后将这些评估作为一个整体呈现在整体应用程序健康状态中。
对以下几种类型的 Kubernetes 资源进行检查:
Deployment,ReplicaSet,StatefulSet,DaemonSet
Service
Ingress
PersistentVolumeClaim
Argocd App
也可以添加自定义的健康检查,Argo CD 支持用 Lua 编写自定义健康检查,支持两种配置方式:
1) 在argocd-cm 这个 ConfigMap 中定义自定义健康检查
可以在 argocd-cm
的 resource.customizations.health.
字段中定义自定义健康检查。
2) 捆绑到 Argo CD 中。自定义健康检查脚本位于 https://github.com/argoproj/argo-cd/tree/master/resource_customizations 目录中。
以上就是关于 Argo CD 的核心内容了,下一篇我们将进行 Argo CD 的实践。欢迎大家继续关注和反馈!
欢迎订阅我的文章公众号【MoeLove】