[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-helm

helm 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: loki
  namespace: argocd
spec:
  syncPolicy:
    syncOptions:
    - ServerSideApply=true
  project: default
  source:
    chart: loki
    repoURL: https://grafana.github.io/helm-charts
    targetRevision: 5.9.2
    helm:
      releaseName: loki
      values: |
        loki:
          auth_enabled: false
          commonConfig:
            replication_factor: 1
          storage:
            type: 'filesystem'
        singleBinary:
          replicas: 1
  destination:
    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状态图例

Grafana Loki

让ArgoCD管理自己

最后，我要介绍一下如何让ArgoCD管理它自己。我们前面使用Helm安装了ArgoCD，因此当前集群中ArgoCD服务是由Helm来管理的，这意味着集群服务现在有着两种不同的管理模式。

1. 我们需要在Git仓库中创建一个Application表示当前ArgoCD服务：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argo-cd
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  project: default
  source:
    chart: argo-cd
    repoURL: https://argoproj.github.io/argo-helm
    targetRevision: 5.43.3
    helm:
      values: |
        server:
          extraArgs:
          - --application-namespaces="*"
          - --insecure
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

1. 如上，使用上面的Application yaml，在ArgoCD中为它自己创建一个App。

2. 等待app状态自己变为Synced，我们可以看到ArgoCD相关的pod将被重新创建出来，之后ArgoCD将管理它自己的状态。

1. 移除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。

总之，我们应尽可能采取科学的，优雅的技术来不断优化软件工程。