和许多人一样，我使用kubernetes CLI(又名kubectl)管理我的第一个集群。通过直接应用yaml文件部署了一些“对象”，如Deployment、secret、configmaps和services，例如:kubectl config use-context cluster1kubectl apply -f deployment1.yaml -n namespacekubectl apply -f secret1.yaml -n namespace
经过多次试验和调整，我终于完善了本地应用的yaml文件，每次执行这些命令都可以实现应用程序的部署。然后，我又添加了两个其他的集群分别是预发和生产环境，这样要执行的命令就变成原来的三倍。然后，我又添加了另一个应用程序，文件和命令的数量再次翻倍。当需要升级应用程序时，每次升级我都必须修改所有文件，重新执行所有命令。当然，人工操作就会犯错。其中许多问题导致应用和/或某些功能和/或用户崩溃。所以，为了排除坏的应用程序，我需要学习和执行一大堆其他的kubectl命令，例如:kubectl config use-context clusterkubectl apply -f deployment1.yaml -n mynamespacekubectl apply -f service1.yaml -n mynamespace
我在想肯定有更好的办法。如何实现自动化，并消除人为错误和开销？作为一名工程师，我过去写过一些定位脚本，我认真地考虑编写一组脚本来自动化这些过程，这样我(以及未来的团队)就不会再犯一些可以避免的错误。毕竟，脚本把大量命令行参数推送给kubeclt执行会很容易。我也考虑过helm和Kustomize，但这并不能解决问题，因为它仍然需要推送很多更新chart的工作。有一天，我读到一篇关于ArgoCD的文章，重点是“推”和“拉”配置之间的区别，这让我大吃一惊。我不应该“推送”命令、脚本或chart去更新应用。这些方法总是需要在每个集群、每个应用、所有监控和每次升级中进行人工操作。相反，我应该从单一的代码或配置仓库中“拉”部署文件到k8集群。换句话说，在集群中创建一个代理，该代理监听配置修改(应用程序的期望状态)，并自动地执行更新命令。机器人比人类更擅长下达命令。使用pull方法，我的所有应用程序和所有集群的行为都将完全符合我的预期，不会再有人为错误。当每天或每周升级时，我只需要在一个地方升级所需的状态，所有集群中的相关应用程序就会自动更新。这就是我一直在寻找的自动化工具。随着我的阅读，并最终成为ArgoCD的用户，我意识到ArgoCD是K8s应用程序的完美机器人。ArgoCD将这种方法更进一步，将应用部署文件放在源代码管理工具上，所以有一个“撤消”按钮，可以审计应用程序和集群的完整更改历史。与使用kubectl的人工执行方式相比，GitOps是一个更加健壮、高效和可扩展的模型。所以，如果你使用CLI将文件、命令或chart“推送”到Kubernetes，那么你可能搞错了。从kubectl命令开始是可以的，但是关键任务的应用程序应该用GitOps来管理。ArgoCD作为一个应用持续发布工具非常好用，该工具现在就可以为你所用。所以，加入GitOps革命吧。更多阅读
[argo-cd]https://github.com/argoproj/argo-cd[Argo CD]https://argo-cd.readthedocs.io/en/stable/