[GitOps]微服务版本控制：使用ArgoCD 部署Grafana Loki
背景介绍
请回答：你们是如何保证线上部署的服务，从服务版本到参数配置，都是和测试通过的版本是一致的呢？
本文将介绍GitOps的基本原理以及ArgoCD的使用：ArgoCD部署Grafana Loki 到k8s集群。
本文项目地址：郭麻花的Azure Devops argo-cd - Repos (azure.com)
什么是GitOps
GitOps通常作为k8s集群中的一项基础设施。它将Git仓库中的服务清单作为唯一版本来源，并且提供自动部署机制。
GitOps提供了高度自动化和审计朔源能力来管理集群服务，大大提高团队交付效率与安全一致性。
ArgoCD
ArgoCD是一个用于Kubernetes集群的开源且强大的GitOps工具。
ArgoCD可以做什么
- ArgoCD可以管理各种Kubernetes原生资源，如Deployment、Service、ConfigMap、Secret等；
- ArgoCD还可以管理Helm Chart，Kubernetes CRD等;
- ArgoCD还可以管理有状态服务，如PersistentVolumeClaim等。
总之，你可以将ArgoCD看作是集群的管家，它可以严格按照Git仓库中的清单文件，时刻监视清单与集群资源的差异，并提供自动/手动 同步机制。
ArgoCD Application
Application是由ArgoCD创建的一种Kubernetes CRD。一个k8s服务通常包含多种资源，例如：deployment, secret, configmap 或者CRD等等，而ArgoCD 可以将这些资源视为一个Application进行管理。
假如你们的服务已经被打包成了Helm Chart，更容易通过ArgoCD Application来进行管理。
注意：ArgoCD在部署Helm Chart时会将Chart重新拆解为各项资源文件进行部署，因此你无法通过Helm来管理ArgoCD部署的Helm Chart。
另外：Application可以包含其它Application。你可以在ArgoCD中对集群中的服务进行逻辑划分，将多个Application聚合到一个Application下进行管理。
使用Helm安装ArgoCD
使用helm安装ArgoCD非常简单，但是需要注意：
即使在具有充分的Cluster Role的情况下，ArgoCD 默认也只允许资源部署到它所在的命名空间。我们可以通过指定server参数 --application-namespaces="*"，让ArgoCD允许资源部署到其他命名空间。
helm repo add argo https://argoproj.github.io/argo-helmhelm install my-release argo/argo-cd
我们可以通过port-forward argocd-server 8080端口，并使用init-secret中的admin密码访问Argocd。
创建Git清单仓库
Grafana Loki是一个开源的高性能的集群日志聚合服务，它的原理与Promthus相似，与Grafana结合使用，可以获得与EFK解决方案相同的集群日志聚合可视化能力。
我将使用ArgoCD来部署Grafana Loki到集群中，请参考： argo-cd - sample (azure.com)
例如，下面是包含了 Loki helm chart的ArgocCD Application：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:name: lokinamespace: argocd
spec:syncPolicy:syncOptions:- ServerSideApply=trueproject: defaultsource:chart: lokirepoURL: https://grafana.github.io/helm-chartstargetRevision: 5.9.2helm:releaseName: lokivalues: |loki:auth_enabled: falsecommonConfig:replication_factor: 1storage:type: 'filesystem'singleBinary:replicas: 1destination:server: "https://kubernetes.default.svc"namespace: loki添加Repositories和certificates
现在，我们需要将Helm Chart仓库和Apps Git仓库以及它们的访问凭证添加到ArgoCD当中。
我所用到的是公开的Helm Chart仓库和Git仓库，假如你使用的是私有仓库，你需要为它指定连接所必须的凭证。对于Azure Git来说，只需要一个PAT(personal access token)
创建Grafana Loki App
我们用上面创建好的Git Repo地址，创建一个名为grafana-loki的App.
该Application包含了三个Application：Promtail, Loki, Grafana。
此时，这三个App的状态是Missing，意味着在集群中不存在；如果是集群版本与Git版本不一致，状态应该是OutSync；集群服务与Git仓库一致，则是Synced。
Application状态图例
让ArgoCD管理自己
最后，我要介绍一下如何让ArgoCD管理它自己。我们前面使用Helm安装了ArgoCD，因此当前集群中ArgoCD服务是由Helm来管理的，这意味着集群服务现在有着两种不同的管理模式。
1. 我们需要在Git仓库中创建一个Application表示当前ArgoCD服务：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:name: argo-cdnamespace: argocdfinalizers:- resources-finalizer.argocd.argoproj.io
spec:destination:server: https://kubernetes.default.svcnamespace: argocdproject: defaultsource:chart: argo-cdrepoURL: https://argoproj.github.io/argo-helmtargetRevision: 5.43.3helm:values: |server:extraArgs:- --application-namespaces="*"- --insecuresyncPolicy:automated:prune: trueselfHeal: true2. 如上，使用上面的Application yaml，在ArgoCD中为它自己创建一个App。
3. 等待app状态自己变为Synced，我们可以看到ArgoCD相关的pod将被重新创建出来，之后ArgoCD将管理它自己的状态。
4. 移除ArgoCD的Helm标记，之后我们将无法再通过Helm管理集群中的ArgoCD服务，而是由ArgoCD自己来管理自己。
kubectl delete secret -l owner=helm,name=argo-cd -n argocd总结
当然，能够实现GitOps的技术还有很多，GitOps的价值也不仅仅是自动化，可溯源。
例如：我们还可以使用ArgoCD的ApplicationSet为不同环境下的app定制不同的参数；我们也可以利用Git仓库的分支和pr策略，在CI阶段进行smoke test，或者其它更有价值的Actions。
总之，我们应尽可能采取科学的，优雅的技术来不断优化软件工程。