argocd部署与实践
时间:2025-08-27 19:34 来源:未知 作者:liangzh 点击:次
GitOps这个术语是由Weaveworks的Alexis Richardson在一篇名为《Operation by Pull Request》的博文中创造的。其基本思想是通过向Git提交变更并使用Pull Request（以下简称PR）进行审批来管理Kubernetes上的资源。
GitOps 是 Weaveworks 推出的天才的应用部署解决方案，它将 Git 作为整个应用部署的单一可信数据源(SSOT)，通过类似代码开发的 Pull Request 流程完成应用部署的 Review 和自动化实现，并且将部署配置信息纳入版本控制。
如果听起来有点模糊，那么我们来定义一下GitOps的四条规则，让它更接地气。
将所有Kubernetes资源配置存储在Git中。
只使用PR来修改该Git仓库上的资源。
一旦修改了Git，立即将更改应用到集群中，并且完全自动化。
如果实际状态与所需的状态有偏差，要么纠正它，要么提醒操作人员。
当我们把这些结合起来，我们就会得到一个系统，在这个系统中，所有对应用环境的更改都会被记录下来，我们可以应用我们基于Git的工具来管理历史记录。我们还可以通过使用PR来进行审批。
在架构上，GitOps将允许我们将应用的持续集成（CI）流程与部署流程分开，因为部署流程将根据环境仓库的变化而不是作为CI流程的一部分来启动。点击了解关于GitOps和CI/CD的更多信息。
GitOps 和持续部署工具现在已经有许多有效的部署工具，例如 ArgoCD、FluxCD 和 Terraform，每一种都有其独特的优势。
下面大致介绍一下每种工具是如何通过 GitOps 实践使项目尽可能高效的。
ArgoCD
ArgoCD 是一个持续部署工具，有助于快速地回滚整个基础架构，从而能够实现 GitOps 的最佳实践。
ArgoCD 与 Kubernetes 一起使用，通过自动化整个过程，不断检查“真实来源”是否与 Git 存储库的内容相匹配，最终加速部署。
遵循这些实践，DevOps 专业人员可以：实现版本跟踪 接收有关漂移检测的警报快速加载整个基础架构
回滚到 Git 存储库中记录的任何点此外，由于其直观的 UI、内置的 Web 界面和 API 服务器实时提供应用程序的统计信息，
ArgoCD 使监控系统变得更加容易。它还带有一个命令行界面 (CLI)，可帮助实施 CI（持续集成）管道。
ArgoCD是用于Kubernetes的声明性GitOps持续交付（CD）工具。该功能集虽然侧重于应用程序部署的管理，
但是却非常出色，涵盖了多个同步选项，用户访问控制，状态检查等。它自2018年以来由Intuit开发，并
根据Apache 2.0许可证在GithHub上开源。
在GitOps风格上，部署从ArgoCD跟踪的Git仓库中的应用程序清单更改开始，类似于Flux的工作方式。
但是，让它大放异彩的是其具有通过精细控制来管理多租户和多集群部署的功能。它可以将不同团队的多个应用程序同步到一个或多个Kubernetes集群。
此外，它具有漂亮的现代Web UI，用户可以在其中查看其应用程序部署的状态，管理员可以管理项目和用户访问权限。
安装与管理
ArgoCD完全以Kubernetes原生方式安装和管理。它在Kubernetes上在自己的命名空间中运行，所有的配置都存储在ConfigMaps、Secrets和Custom Resources中。
这使得我们可以使用GitOps工作流程来管理ArgoCD本身。
支持的清单格式
ArgoCD在GitOps仓库中提供了对不同格式的最广泛支持。根据文档，它可以处理：
Kustomize应用程序
Helm Charts
Ksonnet应用
YAML/JSON清单目录，包含Jsonnet
配置管理插件配置的任何自定义配置管理工具
多租户
一个ArgoCD实例可以处理不同团队的许多应用程序。它使用项目的概念进行此操作。项目可以容纳多个应用程序，并映射到一个团队。
团队成员将仅能看到分配给他们的项目，并且通过扩展仅看到那些项目中的应用程序。这种模式与Kubernetes中的命名空间中的资源非常相似。
多集群
ArgoCD可以在其运行的Kubernetes集群上同步应用程序，也可以管理外部集群。它也可以被配置为只访问一组受限的命名空间。
其他群集的API服务器的凭证会作为秘密存储在ArgoCD的命名空间中。只要你可以远程公开其他集群的API，这对于从一个地方
管理所有部署都是非常有用的功能。内置的RBAC机制提供了一些选项，以控制仅特定用户对不同环境中的部署的访问。
当集群的操作员在不经过GitOps工作流程（即提交到Git）的情况下更改资源时，Kubernetes资源可能会偏离存储在Git中的配置。
这在GitOps中是一个问题，因为很容易发生这些变化，使Git中的状态过期。ArgoCD可以检测到这些更改并将其还原，从而使状态恢复到Git中定义的状态。
垃圾回收
删除资源是GitOps的另一个问题。当从Git中删除诸如部署之类的资源时，kubectl apply将忽略它（除非使用实验性的--prune标志）。
这使得开发人员无法删除他们创建的资源，因为它们与Kubernetes的接口是Git仓库。
Helm确实解决了这个问题，但ArgoCD也是如此。它可以在自己的同步过程中删除过时的资源，所以你不必使用Helm来实现这个功能。
局限性
尽管我们喜欢ArgoCD可以一站式管理所有团队的部署这一事实，但我们并不喜欢你如何配置项目与团队的映射。
基本上，团队所属项目的整个配置都保存在存储ArgoCD配置的Git仓库中的单个文件中。这意味着，每次创建或修改新团队时，都必须更新此文件。
在大公司里，开发团队的组建和解散都是在不断地进行，这种管理方式可能会变得很繁琐，也限制了ArgoCD提供的多租户设置。
实测效果:
1、支持git多分支、tag，但是不支持分支名称模糊匹配。
2、可以手动或自动同步git版本配置，但是自动同步有一定的延迟时间(30s-300s)，尤其通过git版本回退发版时自动同步较慢。
3、支持char、yaml方式，也支持helm repo仓库。
4、支持多集群、多名称空间、多分支隔离部署，互不影响，但不能多用户管理。
5、界面可视化可以查看部署的结果、日志、历史版本回滚，类似rancher。
FluxCD
Flux被描述为Kubernetes的GitOps运维工具，它可以将Git仓库中的清单状态与集群中运行的内容同步。
在本次评测的三个工具中，它是最简单的一个。事实上，只需几步就可以设置好一个GitOps工作流，这一点让人惊叹不已。
这个工具运行在集群中，更新会被应用到集群中，它的主要功能是监视远程Git仓库来应用Kubernetes清单中的更改。它最初是由Weaveworks开发的，现在是在GitHub上使用Apache 2.0许可的CNCF项目。
FluxCD与 ArgoCD 有着类似的与目录相关的功能。FluxCD 和 ArgoCD 都可以连接到项目的 Git 并同步 Kubernetes 集群。但是，FluxCD 仅适用于每个 Flux 运算符实例的一个存储库。
值得庆幸的是，维护 FluxCD 的团队最近提出了版本 2，它现在允许使用多个存储库。Flux CD 对已经熟悉 Git 的 GitOps 开发人员很友好，因为它适用于拉取请求而不是集群。
使用它变得像检查项目 Git 历史记录中的更改、检查所做的更改以及通过拉取请求修复生产中引起的任何问题一样简单。
与 ArgoCD 相比，FluxCD 可能缺少 Web UI，但在部署和维护 helm 图表时它弥补了这一点。Flux helm operator 带有一个扩展，可以在使用 Flux 时加速和自动化 helm chart 发布。
这是通过让 Flux Agent (fluxd) 同步 Git 集群的内容来实现的。同时，Flux helm 操作符确保 helm 图表按指定发布。
该工具专注于软件交付周期中的部署部分，专门针对Git仓库和容器注册表与集群中的工作负载的版本和状态同步，因此该工具易于安装和维护。
它可以在每个安装中只监视一个远程仓库，而且它只能在其底层服务账户（serviceaccount）有权限更改的命名空间中应用更改。
虽然乍一看很有局限性，但更复杂的场景，如果有多个团队和自己的Git仓库和目标部署环境，则可以设置相应数量的Flux实例，每个实例都有自己特定的RBAC权限。
Flux安装跟在集群中部署任何其他典型Pod一样容易。它正式支持基于Helm Charts和Kustomize的安装。此外，还有一个fluxctl的命令行（CLI）工具，以二进制形式
发布，可帮助安装过程并与集群中正在运行的Flux守护程序进行交互以执行一些管理任务。
在集群中安装Flux的最简单的方法是应用少量清单文件，可以使用fluxctl install命令并添加适当的参数生成，包括将被监视的Git仓库的URL。
作为Flux的主要功能，它会定期拉取远程Git仓库，并以真正的GitOps方式将其清单文件（如果有新更改）应用于集群。
这可以用于部署应用程序，也可以维护Kubernetes清单形式的任何种类的集群配置。同步也可以通过fluxctl sync命令手动触发。
从群集管理员的角度来看，考虑到Flux实际上是在Pod中部署的单个二进制文件，安装后几乎不需要管理。可以通过将相同的清单重新应用新的值来更改配置或升级到较新的版本，或者仅在安装时使用Kustomize或Helm进行更改。
除了安装之外，fluxctl命令行工具还可以帮助完成其他一些任务，例如立即触发同步或列出集群中部署的相关配置和工作负载。
作为一个简单的组件，我们可以在同一个集群中使用不同的Flux实例，每一个实例都可以监视不同的远程Git仓库，并在不同的目标命名空间中同步它们的变化。
这种可能性可以让不同的团队拥有自己的Git仓库。
话虽如此，但要由团队来选择Git仓库的布局，以及如何在集群中用命名空间代表的应用程序和目标环境进行映射，这都是由团队来决定的。
为了提供团队之间的隔离，可以使用不同的Git仓库，因此可以使用不同的Flux实例来监视每一个Git仓库。
虽然在集群中运行多个Flux实例可能会增加一些管理开销，但它可以让团队管理自己的环境仓库，并拥有适当的权限来提交更改和批准PR。
此外它还可以在命名空间之间实现一定程度的隔离，为集群中不同的Flux实例使用的每个服务账户提供更具体的RBAC设置。
基于同样的原因（简单性），Flux可以用于多集群场景。不同的集群会有自己的Flux实例来监视远程仓库中的变化。
考虑到可以在一个仓库中指定一个要监视的目录，团队有同样的灵活性来选择多集群情况下的最佳版本库布局。
一个单一的版本库可以由两个或多个来自不同集群的Flux实例来监视，每一个都监视一个特定的目录，也可以使用单独的版本库。
自动部署新版本容器镜像
当新版本的容器镜像可用时，Flux可以选择更新集群中的工作负载。如果启用，运行fluxctl automate或者在工作负载的部署清单
中添加注释，它会轮询注册表中的镜像元数据，并且如果有指定镜像的新版本可用，它可以使用新的版本来更新部署。当这样做时，
Flux会写一个提交回原始Git仓库，以更新清单中使用的镜像版本，因此Git仍然是集群中运行的内容的真实来源。
重新应用偏移的资源
不管来自Git仓库的新更该如何，Flux都会在一定间隔内同步重新应用其清单的工作负载状态。这在GitOps工作流之外的应用程序和配置状态发生变化时非常有用。
垃圾回收
当资源从环境仓库中被删除时，Flux可以将其从集群中删除。这种潜在的危险操作需要跟踪GitOps工作流程已创建了哪些资源。
当启用此功能后，Flux将根据源（仓库URL、分支和安装过程中指定的路径组合），在同步循环期间给集群中部署的所有资源贴上特定的标签。
当涉及到垃圾回收循环时，Flux将查询APIServer，以检索所有标记为来自源的对象，并删除那些在上一阶段没有同步的对象。
局限性
Flux最大的局限，可能是设计上的，也是它最大的优势。它只支持一个单一的仓库。
这个特性使它成为一个相当简单的工具，易于理解和故障排除。
考虑到它运行在轻量级部署上，这个限制可以通过集群中的多个实例来克服，正如前面的“多租户”部分所描述的那样。
FluxCD版本 2，它现在允许使用多个存储库
根据设计，Flux仅专注于将清单部署到群集。因此，你仍然需要CI工具来构建和测试你的应用程序，并在最后将你的容器镜像推送到注册表。
另一方面，CI工具不需要访问群集，因为Flux会从内部周期性地拉取变化，最大限度地减少了群集的暴露。
Terraform
使用 Terraform 的 GitOps 基础设施即代码Terraform 允许快速可靠地定义基础架构，并在此过程中将整个基础架构保存在配置和代码中。
它还使合理有效地更改、跟踪和重建基础设施的任何部分变得容易。Terraform 具有与平台无关并支持许多服务和云提供商的优势。
尽管尚不支持一些较小的提供商，但涵盖了所有主要的提供商，例如 AWS、GCP 和 Azure。 由于其跨提供商的支持，Terraform 对于同时使用多个云服务提供商的公司和团队特别有用。
此功能使不同云提供商之间的通信变得快速而轻松。使用基础架构即代码 (IaC) 意味着 Terraform 可以自动化整个云基础架构，例如可以使用它快速定义的卷、IP、网络、应用程序和实例。
Jenkins X
Jenkins X是一个围绕GitOps构建的完整的CI/CD解决方案，其底层使用了Tekton。首先，从名称来看，我们希望看到大家都了解到的Jenkins的下一代，包含其任务和插件功能。
实际上，Jenkins X采取了不同的方向，与经典的Jenkins几乎没有共同点。
它抛开了Jenkins的master-worker节点架构，并以成为Kubernetes原生CI/CD引擎打造。它在GitHub上以Apache 2.0许可下开源，由Cloudbees开发，该公司还提供了商业发行版。
1. 自动化一切：自动化CI/CD流水线
选择项目类型自动生成Jenkinsfile定义流水线
自动生成Dockerfile并打包容器镜像
自动创建Helm Chart并运行在Kubernetes集群
自动关联代码库和流水线，作为代码变更自动触发（基于Webhook实现）
自动版本号自动归档
2. Review代码一键部署应用：基于GitOps的环境部署
所有的环境，应用列表，版本，配置信息统一放在代码库中进行版本控制
通过Pull Request实现研发和运维的协同，完成应用部署升级（Promotion）
可自动部署和手动部署，在必要的时候增加手工Review
当然这些都封装在jx命令中实现
3. 自动生成预览环境和信息同步反馈
预览环境用于代码Review环节中临时创建
同Pull Request工作流程集成并实现信息同步和有效通知
验证完毕后自动清理
提交和应用状态自动同步到Github注释
自动生成release notes信息供验证
Flux可作为多用户设置中的一个构件使用。
Jenkins X正在努力实现在单个实例中支持多个团队。
ArgoCD可以将更新发送到Slack以及其他工具但是不能通过这些工具控制它（而且实际上也并非必要）。
DevOps项目的目标是：
1、更快的上市时间
2、提高部署频率
3、更短的修复时间
4、降低发布失败率
5、更快的平均恢复时间
以下最佳实践被认为是成功运行DevOps方法的关键：
1、松耦合架构
2、自助服务配置
3、自动部署和管理资源
4、持续构建/集成和交付
5、自动发布管理
6、增量测试
7、基础结构配置为代码
8、全面的配置管理
9、基于主干的开发和功能标志
https://argo-cd.readthedocs.io/en/stable/getting_started/
https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/
server.insecure: "true"
Argo CD 基本上是无状态的。所有数据都作为 Kubernetes 对象持久化，而 Kubernetes 对象又存储在 Kubernetes 的 etcd 中。
Redis 仅用作一次性缓存，可能会丢失。丢失时，它将重建而不会丢失服务。
1.安装Argo CD
http://argocd.test.nip.io
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl apply -n argocd install.yaml
#3.1
Quick Start
Non-HA:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.1.0/manifests/install.yaml
HA:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.1.0/manifests/ha/install.yaml
2.下载Argo CD CLI¶
从https://github.com/argoproj/argo-cd/releases/latest下载最新的 Argo CD 版本。可以通过CLI 安装文档找到更详细的安装说明。
也可用于 Mac、Linux 和 WSL Homebrew：
brew install argocd
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x /usr/local/bin/argocd
3. 访问 Argo CD API 服务器¶
默认情况下，Argo CD API 服务器不使用外部 IP 公开。要访问 API 服务器，请选择以下技术之一来公开 Argo CD API 服务器：
入口¶
按照ingress 文档了解如何使用 ingress 配置 Argo CD。
https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/
关键参数设置：
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
nginx.ingress.kubernetes.io/force-ssl-redirect: 'true'
注意：以上2条参数要添加，而且http和https都要开启，否则会出现访问api后台页面跳转死循环
参考实例：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: argocd-server
annotations:
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
nginx.ingress.kubernetes.io/force-ssl-redirect: 'true'
spec:
ingressClassName: nginx
rules:
- host: argocd.test.nip.io
http:
paths:
- backend:
service:
name: argocd-server
port:
number: 80
path: /
pathType: Prefix
tls:
- hosts:
- argocd.test.nip.io
转发端口¶
Kubectl 端口转发也可用于连接到 API 服务器而不暴露服务。
kubectl port-forward svc/argocd-server -n argocd 8080:443
然后可以使用 localhost:8080 访问 API 服务器
这里采用nodeport
4. 使用 CLI 登录¶
该admin帐户的初始密码是自动生成的，并以明文形式存储 在您的 Argo CD 安装命名空间中命名password的密码字段中。
argocd-initial-admin-secret您可以使用以下方法简单地检索此密码kubectl：
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
[test@localhost ~]$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
6xTwY3itc1KWGhgz
注意：argocd-initial-admin-secret更改密码后，您应该从 Argo CD 命名空间中删除。
该秘密仅用于明文存储最初生成的密码并且可以随时安全地删除。如果必须重新生成新的管理员密码，它将由 Argo CD 按需重新创建。
使用admin上面的用户名和密码，登录 Argo CD 的 IP 或主机名：
注意:CLI 环境必须能够与 Argo CD 控制器通信。
argocd login argocd-helm.10-182-71-89.nip.io:443
[test@localhost ~]$ argocd login 192.168.88.131:30443
WARNING: server certificate had error: x509: cannot validate certificate for 192.168.88.131 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y
Username: admin
Password:
'admin:login' logged in successfully
Context '192.168.88.131:30443' updated
使用以下命令更改密码：
argocd account update-password
5.注册一个集群来部署应用程序（可选）
此步骤将集群的凭据注册到 Argo CD，并且仅在部署到外部集群时才需要。在内部部署时（到运行 Argo CD 的同一集群），应使用 https://kubernetes.default.svc 作为应用程序的 K8s API 服务器地址。
首先列出当前 kubeconfig 中的所有集群上下文：
[test@localhost ~]$ kubectl config get-contexts -o name
test
test-node1
test-node2
test-node3
从列表中选择一个上下文名称并将其提供给argocd cluster add CONTEXTNAME. 例如
[test@localhost ~]$ argocd cluster add test
WARNING: This will create a service account `argocd-manager` on the cluster referenced by context `test` with full cluster level admin privileges. Do you want to continue [y/N]? y
INFO[0008] ServiceAccount "argocd-manager" created in namespace "kube-system"
INFO[0008] ClusterRole "argocd-manager-role" created
INFO[0008] ClusterRoleBinding "argocd-manager-role-binding" created
FATA[0009] rpc error: code = Unauthenticated desc = the server has asked for the client to provide credentials
这里报错是因为test集群未rancher的api代理，其身份验证与下游的k8s集群有差异，导致argocd添加集群时身份验证异常。
可以通过直接添加k8s的集群地址解决：
[test@localhost ~]$ argocd cluster add test-node1
WARNING: This will create a service account `argocd-manager` on the cluster referenced by context `test-node1` with full cluster level admin privileges. Do you want to continue [y/N]? y
INFO[0001] ServiceAccount "argocd-manager" already exists in namespace "kube-system"
INFO[0002] ClusterRole "argocd-manager-role" updated
INFO[0002] ClusterRoleBinding "argocd-manager-role-binding" updated
Cluster 'https://192.168.88.131:6443' added
上述命令将 ServiceAccount ( argocd-manager) 安装到该 kubectl 上下文的 kube-system 命名空间中，并将服务帐户绑定到管理员级别的 ClusterRole。
Argo CD 使用此服务帐户令牌来执行其管理任务（即部署/监控）。
[test@localhost ~]$ argocd cluster list
SERVER NAME VERSION STATUS MESSAGE PROJECT
https://192.168.88.131:6443 test-node1 Unknown Cluster has no application and not being monitored.
https://kubernetes.default.svc in-cluster Unknown Cluster has no application and not being monitored.
argocd-manager-role可以修改角色的规则，使其仅对一组有限的命名空间、组、种类具有create、update、patch、权限。
delete但是get， Argo CD 需要集群范围list的watch权限才能运行。
6. 从 Git 存储库创建应用程序
存储库， 以演示 Argo CD 的工作原理。
通过 CLI 创建应用程序¶
使用以下命令创建示例留言簿应用程序：
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
argocd repo add https://github.com/argoproj/argocd-example-apps --username <username> --password <password>
argocd repo add https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git --username liangzonghua --password '0*dYUVsb8k4A4$B2'
argocd app create guestbook --repo https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
注意：要保证指定的目录guestbook在仓库中存在
7. 同步（部署）应用程序¶
通过 CLI 同步¶
创建留言簿应用程序后，您现在可以查看其状态：
[test@localhost argocd]$ argocd app get guestbook
Name: guestbook
Project: default
Server: https://kubernetes.default.svc
Namespace: default
URL: https://192.168.88.131:30443/applications/guestbook
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target:
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: <none>
Sync Status: OutOfSync from (d1dbc00)
Health Status: Missing
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service default guestbook-ui OutOfSync Missing
apps Deployment default guestbook-ui OutOfSync Missing
应用程序状态最初处于OutOfSync状态，因为应用程序尚未部署，并且尚未创建任何 Kubernetes 资源。要同步（部署）应用程序，请运行：
argocd app sync guestbook
[test@localhost argocd]$ argocd app sync guestbook
TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
2022-05-19T13:21:23+08:00 Service default guestbook-ui OutOfSync Missing
2022-05-19T13:21:23+08:00 apps Deployment default guestbook-ui OutOfSync Missing
2022-05-19T13:21:25+08:00 Service default guestbook-ui OutOfSync Missing service/guestbook-ui created
2022-05-19T13:21:25+08:00 apps Deployment default guestbook-ui OutOfSync Missing deployment.apps/guestbook-ui created
2022-05-19T13:21:25+08:00 Service default guestbook-ui Synced Healthy service/guestbook-ui created
2022-05-19T13:21:25+08:00 apps Deployment default guestbook-ui Synced Progressing deployment.apps/guestbook-ui created
Name: guestbook
Project: default
Server: https://kubernetes.default.svc
Namespace: default
URL: https://192.168.88.131:30443/applications/guestbook
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target:
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: <none>
Sync Status: Synced to (d1dbc00)
Health Status: Progressing
Operation: Sync
Sync Revision: d1dbc002eeb1ea348b17c579ba7a7a99c0d4c815
Phase: Succeeded
Start: 2022-05-19 13:21:23 +0800 CST
Finished: 2022-05-19 13:21:24 +0800 CST
Duration: 1s
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service default guestbook-ui Synced Healthy service/guestbook-ui created
apps Deployment default guestbook-ui Synced Progressing deployment.apps/guestbook-ui created
此命令从存储库中检索清单并执行kubectl apply清单中的一个。留言簿应用程序现在正在运行，您现在可以查看其资源组件、日志、事件和评估的健康状态。
[test@localhost ~]$ argocd app get guestbook
Name: guestbook
Project: default
Server: https://kubernetes.default.svc
Namespace: default
URL: https://192.168.88.131:30443/applications/guestbook
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target:
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: <none>
Sync Status: Synced to (d1dbc00)
Health Status: Degraded
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service default guestbook-ui Synced Healthy service/guestbook-ui created
apps Deployment default guestbook-ui Synced Degraded deployment.apps/guestbook-ui created
[test@localhost ~]$ argocd app get guestbook
Name: guestbook
Project: default
Server: https://kubernetes.default.svc
Namespace: default
URL: https://192.168.88.131:30443/applications/guestbook
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target:
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: <none>
Sync Status: Synced to (c3d2a8e)
Health Status: Progressing
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service default guestbook-ui Synced Healthy service/guestbook-ui unchanged
apps Deployment default guestbook-ui Synced Progressing deployment.apps/guestbook-ui configured
[root@localhost guestbook]# git add -u
[root@localhost guestbook]# git commit -m "update images"
[master c3d2a8e] update images
1 file changed, 1 insertion(+), 1 deletion(-)
[root@localhost guestbook]# git push
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 402 bytes | 0 bytes/s, done.
Total 4 (delta 2), reused 0 (delta 0)
To https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
d1dbc00..c3d2a8e master -> master
[root@localhost guestbook]# git log -3
commit c3d2a8ee3278ee7039885112a990a76c8706533c
Author: liangzonghua <liangzonghua@crb.cn>
Date: Thu May 19 13:32:18 2022 +0800
update images
commit d1dbc002eeb1ea348b17c579ba7a7a99c0d4c815
Author: liangzonghua <liangzonghua@crb.cn>
Date: Thu May 19 11:45:32 2022 +0800
add guestbook
版本回退(一般不推荐，因为只能回退，不能前退):
[root@localhost guestbook]# git reset --hard e51b69c
HEAD is now at e51b69c roll images v2
[root@localhost guestbook]# git push -f
Total 0 (delta 0), reused 0 (delta 0)
To https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
+ ed23109...e51b69c master -> master (forced update)
[root@localhost guestbook]# git log -3
commit e51b69cc1820b607c36242dfaf3df4e715521023
Author: liangzonghua <liangzonghua@crb.cn>
Date: Thu May 19 15:54:50 2022 +0800
roll images v2
[test@localhost ~]$ argocd app get guestbook --show-operation
Name: guestbook
Project: default
Server: https://kubernetes.default.svc
Namespace: default
URL: https://192.168.88.131:30443/applications/guestbook
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target:
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: Automated
Sync Status: Synced to (e51b69c)
Health Status: Healthy
Operation: Sync
Sync Revision: e51b69cc1820b607c36242dfaf3df4e715521023
Phase: Succeeded
Start: 2022-07-26 16:39:29 +0800 CST
Finished: 2022-07-26 16:39:31 +0800 CST
Duration: 2s
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service default guestbook-ui Synced Healthy service/guestbook-ui unchanged
apps Deployment default guestbook-ui Synced Healthy deployment.apps/guestbook-ui configured
新建分支部署环境：
argocd app create guestbook-uat --repo https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git --revision uat --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace uat
[test@localhost ~]$ argocd app get guestbook-uat --show-operation
Name: guestbook-uat
Project: default
Server: https://kubernetes.default.svc
Namespace: uat
URL: https://192.168.88.131:30443/applications/guestbook-uat
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target: uat
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: <none>
Sync Status: OutOfSync from uat (152d9c3)
Health Status: Missing
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service uat guestbook-ui OutOfSync Missing
apps Deployment uat guestbook-ui OutOfSync Missing
[test@localhost ~]$ kubectl create namespace uat
应用程序状态最初处于OutOfSync状态，因为应用程序尚未部署，并且尚未创建任何 Kubernetes 资源。要同步（部署）应用程序，请运行：
argocd app sync guestbook-uat
[test@localhost ~]$ argocd app sync guestbook-uat
TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
2022-07-29T16:52:56+08:00 Service uat guestbook-ui OutOfSync Missing
2022-07-29T16:52:56+08:00 apps Deployment uat guestbook-ui OutOfSync Missing
2022-07-29T16:52:57+08:00 Service uat guestbook-ui Synced Healthy
2022-07-29T16:52:57+08:00 apps Deployment uat guestbook-ui OutOfSync Missing deployment.apps/guestbook-ui created
2022-07-29T16:52:57+08:00 Service uat guestbook-ui Synced Healthy service/guestbook-ui created
2022-07-29T16:52:57+08:00 apps Deployment uat guestbook-ui Synced Progressing deployment.apps/guestbook-ui created
Name: guestbook-uat
Project: default
Server: https://kubernetes.default.svc
Namespace: uat
URL: https://192.168.88.131:30443/applications/guestbook-uat
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target: uat
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: <none>
Sync Status: Synced to uat (152d9c3)
Health Status: Progressing
Operation: Sync
Sync Revision: 152d9c3413cc11a5c1c0dcc5eb780cb42dfe7a9f
Phase: Succeeded
Start: 2022-07-29 16:52:56 +0800 CST
Finished: 2022-07-29 16:52:57 +0800 CST
Duration: 1s
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service uat guestbook-ui Synced Healthy service/guestbook-ui created
apps Deployment uat guestbook-ui Synced Progressing deployment.apps/guestbook-ui created
[test@localhost ~]$ kubectl get pod -n uat
NAME READY STATUS RESTARTS AGE
guestbook-ui-58d5c5744c-qptlz 1/1 Running 0 8s
分支编辑提交
[root@localhost test-demo]# git branch
70.2107.0
* master
uat
[root@localhost test-demo]# git checkout uat
Switched to branch 'uat'
[root@localhost test-demo]# git branch
70.2107.0
master
* uat
[root@localhost test-demo]# git log -2
commit 152d9c3413cc11a5c1c0dcc5eb780cb42dfe7a9f
Author: liangzonghua <liangzonghua@crb.cn>
Date: Tue Jul 26 17:36:17 2022 +0800
uat v2
commit 89fc1c6b36e26b7eaf06c753a33858e6169c5f10
Author: liangzonghua <liangzonghua@crb.cn>
Date: Tue Jul 26 17:01:53 2022 +0800
update uat v1
[root@localhost test-demo]# vim guestbook/guestbook-ui-
guestbook-ui-deployment.yaml guestbook-ui-svc.yaml
[root@localhost test-demo]# vim guestbook/guestbook-ui-deployment.yaml
[root@localhost test-demo]# git add -u
[root@localhost test-demo]# git commit -m "uat v3"
[uat 13f9c62] uat v3
1 file changed, 1 insertion(+), 1 deletion(-)
[root@localhost test-demo]# git push
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 376 bytes | 0 bytes/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote:
remote: To create a merge request for uat, visit:
remote: https://d4s.crb.cn/gitlab/liangzonghua/test-demo/-/merge_requests/new?merge_request%5Bsource_branch%5D=uat
remote:
To https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
152d9c3..13f9c62 uat -> uat
[test@localhost ~]$ argocd app get guestbook-uat --show-operation
Name: guestbook-uat
Project: default
Server: https://kubernetes.default.svc
Namespace: uat
URL: https://192.168.88.131:30443/applications/guestbook-uat
Repo: https://d4s.crb.cn/gitlab/liangzonghua/test-demo.git
Target: uat
Path: guestbook
SyncWindow: Sync Allowed
Sync Policy: Automated
Sync Status: Synced to uat (13f9c62)
Health Status: Healthy
Operation: Sync
Sync Revision: 13f9c6289ee48885343e940a2212f842ba18b926
Phase: Succeeded
Start: 2022-07-29 17:30:07 +0800 CST
Finished: 2022-07-29 17:30:08 +0800 CST
Duration: 1s
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service uat guestbook-ui Synced Healthy service/guestbook-ui unchanged
apps Deployment uat guestbook-ui Synced Healthy deployment.apps/guestbook-ui configured
[test@localhost ~]$ kubectl get pod -n uat
NAME READY STATUS RESTARTS AGE
guestbook-ui-69d78b9584-lb662 1/1 Running 0 77s
#另外的环境不受影响
[test@localhost ~]$ kubectl get pod
NAME READY STATUS RESTARTS AGE
guestbook-ui-58d5c5744c-qnfgz 1/1 Running 0 60m
Examples:
# Create a directory app
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --directory-recurse
# Create a Jsonnet app
argocd app create jsonnet-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path jsonnet-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --jsonnet-e
xt-str replicas=2
# Create a Helm app
argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --helm-set replic
aCount=2
# Create a Helm app from a Helm repo
argocd app create nginx-ingress --repo https://charts.helm.sh/stable --helm-chart nginx-ingress --revision 1.24.3 --dest-namespace default --dest-server https://kubernetes.default.svc
# Create a Kustomize app
argocd app create kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kusto
mize-image gcr.io/heptio-images/ks-guestbook-demo:0.1
# Create a app using a custom tool:
argocd app create ksane --repo https://github.com/argoproj/argocd-example-apps.git --path plugins/kasane --dest-namespace default --dest-server https://kubernetes.default.svc --config-management-plugin
kasane
扩展：
helm部署方案：
https://github.com/argoproj/argo-helm/
helm repo add argo https://argoproj.github.io/argo-helm
helm本地部署：
helm install argocd-helm ./argo-cd --set redis-ha.enabled=true --set global.domain=argocd-helm.10-182-71-89.nip.io -n argocd
添加helmfile插件：
参考文档：https://cloud.tencent.com/developer/article/2398649
value文件在repo服务下新增如下：
extraContainers:
- name: helmfile
image: pkg.test.com/docker/helmfile/helmfile:v0.160.0
# Entrypoint should be Argo CD lightweight CMP server i.e. argocd-cmp-server
command: ["/var/run/argocd/argocd-cmp-server"]
env:
- name: HELM_CACHE_HOME
value: /tmp/helm/cache
- name: HELM_CONFIG_HOME
value: /tmp/helm/config
- name: HELMFILE_CACHE_HOME
value: /tmp/helmfile/cache
- name: HELMFILE_TEMPDIR
value: /tmp/helmfile/tmp
securityContext:
runAsNonRoot: true
runAsUser: 999
volumeMounts:
- mountPath: /var/run/argocd
name: var-files
- mountPath: /home/argocd/cmp-server/plugins
name: plugins
# Register helmfile plugin into sidecar
- mountPath: /home/argocd/cmp-server/config/plugin.yaml
subPath: helmfile.yaml
name: argocd-cmp-cm
# Starting with v2.4, do NOT mount the same tmp volume as the repo-server container. The filesystem separation helps mitigate path traversal attacks.
- mountPath: /tmp
name: helmfile-tmp
volumes:
- name: argocd-cmp-cm
configMap:
name: argocd-cmp-cm
- name: helmfile-tmp
emptyDir: {}
configs:
cmp:
create: true
plugins:
helmfile:
allowConcurrency: true
discover:
fileName: helmfile.yaml
generate:
command:
- bash
- "-c"
- |
if [[ -v ENV_NAME ]]; then
helmfile -n "$ARGOCD_APP_NAMESPACE" -e $ENV_NAME template --include-crds -q
elif [[ -v ARGOCD_ENV_ENV_NAME ]]; then
helmfile -n "$ARGOCD_APP_NAMESPACE" -e "$ARGOCD_ENV_ENV_NAME" template --include-crds -q
else
helmfile -n "$ARGOCD_APP_NAMESPACE" template --include-crds -q
fi
lockRepo: false
同步策略：
https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/
https://www.cnblogs.com/wangguishe/p/17897322.html
PRUNE RESOURCES（自动修剪）
当集群中存在已部署但未在Git仓库中定义的资源时，ArgoCD会自动删除这些资源。例如，当Git仓库中删除了某个配置文件时，ArgoCD会检查集群中是否存在该配置的实例，若存在则将其删除。
SELF HEAL（自愈）
当集群中的资源状态与Git仓库的期望状态不一致时（如手动修改或外部干预），ArgoCD会尝试将实际状态同步回仓库的期望状态。例如，若集群中某个配置被手动修改，ArgoCD会触发同步操作以恢复仓库的原始配置。
自动同步间隔由 argocd-cm ConfigMap 中的 timeout.reconciliation 值决定，默认为 180 秒（3 分钟）。
Prune
资源修剪。可选值：true,false。推荐值：true。
Validation
是否执行资源规范格式的校验，相当于“kubectl apply --validate={true|false}”，默认为true。
ApplyOutOfSyncOnly
仅对那些处于OutOfSync状态的资源执行同步操作
SkipDryRunOnMissingResource
跳过测试新的自定义类型的资源。
PrunePropagationPolicy
资源修剪传播策略，默认使用foreground(前台执行)策略，另外可选的策略还有background(后台执行)和orphan(在新的管理接口执行)。
PruneLast
在同步操作的最后再执行修剪操作，即其它资源已经部署且转为健康状态后再进行Prune。
Replace
对资源的修改，以replace方式进行，而非默认的apply。
FailOnSharedResource
默认的同步操作不会考虑GitRepo中定义的资源是否已经被其它Application所使用。将该选项设置为true，意味着在发现资源已经被其它Application所使用时，则将同步状态设置为fail。
RespectIgnoreDifferences
在同步阶段忽略期望状态的字段。
CreateNamespace
创建缺失的名称空间。
ServerSideApply
资源太大，无法容纳允许的 262144 字节注释大小。在这种情况下，可以使用服务器端应用来避免此问题，因为在这种情况下不使用注释。
修补集群上未完全由 Argo CD 管理的现有资源。
使用更具声明性的方法，跟踪用户的字段管理，而不是用户上次应用的状态。
Delete
对于某些资源，即使您的应用程序被删除，您可能也希望保留它们，例如。Persistent Volume Claims。在这种情况下，您可以使用以下注释来阻止在应用程序删除期间清理这些资源：
(责任编辑：liangzh) |