[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工具。

Argo CD Architecture

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

2. 如上,使用上面的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。

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