使用 Kubernetes Agent Server 实现 GitOps-Toy模板网

这篇具有很好参考价值的文章主要介绍了使用 Kubernetes Agent Server 实现 GitOps。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

温习 GitOps

极狐GitLab Kubernetes Agent

极狐GitLab GitOps workflow

极狐GitLab KAS 的配置

创建极狐GitLab agent

创建 agent token

Kubernetes 上安装 agent（agentk）

极狐GitLab GitOps workflow 实践

写在最后

温习 GitOps

GitOps 的核心不是 Git，而是以声明式系统为基座，以 Git 为单一可信源，通过将应用程序和基础设施代码化（一切皆代码），进行云原生应用程序和基础设施部署管理。更多关于 GitOps 的内容，可以查看公众号文章GitOps 系列｜云原生时代，你还不懂 GitOps？

极狐GitLab Kubernetes Agent 恰巧就是实现 GitOps workflow 的一个特性功能，在 13.x 版本中陆续引入。

本文将通过理论加实践的方式对极狐GitLab GitOps workflow 进行剖析，方便大家对其有个全方位的认知。

极狐GitLab Kubernetes Agent

极狐GitLab Kubernetes Agent 是一个位于 Kubernetes 集群侧的组件，能够以安全、云原生的方式来实现极狐GitLab 和 Kubernetes 的集成。主要实现的功能有：

将极狐GitLab 与防火墙或 NAT（网络地址转换）后的 Kubernetes 集群进行集成；
“pull” 模式的 GitOps workflow；
对应用在集群上的资源进行追踪；
对集群的 API 端点进行实时访问；
基于容器网络策略的报警生成；
CI/CD 隧道作用，以使用户能够从 GitLab CI/CD 中访问 Kubernetes 集群，即使 GitLab Runner 和集群之间没有网络连接。

更多的功能和特性还在开发过程中，感兴趣的可以查看 Roadmap。

接下来将重点分析如何使用极狐GitLab Kubernetes Agent 来实现 GitOps workflow。

极狐GitLab GitOps workflow

极狐GitLab GitOps workflow 的示意图如下

使用 Kubernetes Agent Server 实现 GitOps,算法,kubernetes,git,workflow,devops

上述列出了完成实践所需的组件

极狐GitLab 服务（如使用极狐Saas 则地址为 GitLab-10万企业使用的一站式DevOps平台_GitLab中文官网)；
一个运行正常且安装了极狐GitLab Kubernetes Agent 的 Kubernetes 集群（Agent 安装过程后续会讲）；
一个配置仓库，包含 config.yaml 文件，里面定义了 agent 需要去跟集群侧做同步的 Project 信息；
一个清单仓库，包含了往 Kubernetes 集群上部署资源的清单文件。

最终的目的就是：一旦部署清单仓库中的清单文件发生了变更，则此变更能够自动同步至集群侧。

可以将 config.yaml 文件和部署资源清单文件存放在同一个极狐GitLab Project 里面，这是 Project 可以是 Public 的，也可以是 Private的，而且这也是官方推荐方式。当然，也可以用不同的 Project 来分别存储config.yaml文件和部署清单文件，此时，需要注意的是，存放部署清单文件的 Project 必须是 Public 的，而存放config.yaml文件的 Project 则可以是 Public 或 Private 的，具体原因可以查看 issue。

从上述示意图中看到，要完成整个流程，需要两个重要组件的配合：agentk 和 kas。其中 agentk 代表极狐GitLab Kubernetes Agent，是位于 Kubernetes 集群侧的组件，主要用来和 kas 进行交互。kas 代表极狐GitLab Kubernetes Agent Server，是位于极狐GitLab 侧的组件，主要实现的功能有：

接受来自 agentk 侧的请求；
对 agentk 做权限验证（这一步是通过查询极狐 GitLab RoR 来完成)；
通过查询 Gitaly 来获取 agent 的配置信息；
将来自极狐GitLab RoR 的请求与正确的 agentk 的现有连接进行匹配，然后将请求转发给 agentk，且将响应转发回来；
通过和 Gitaly 通信来对存储部署清单的 Project 进行轮询，从而实现 GitOps。

整体的架构示意图如下：

使用 Kubernetes Agent Server 实现 GitOps,算法,kubernetes,git,workflow,devops

从架构图中可以看出，要想实现极狐GitLab GitOps workflow，需要对 agentk 和 kas 进行安装配置。

极狐GitLab KAS 的配置

首先，要在极狐GitLab 侧创建一个与存储 config.yaml 文件的配置仓库相关联的 agent 记录。这个过程分两步走：创建 agent 和生成 agent token（后面的步骤会用到）。

创建极狐GitLab agent

可以使用 GraphQL 来完成创建工作，关于 GraphQL 的更多内容可以查看极狐GitLab GraphQL API 使用方法。当然最快速的方法就是使用 GraphQL Explorer 来完成创建工作。

在 GraphQL Explorer 的页面中输入创建 agent 的语法，然后运行即可。如在左侧输入如下 GraphQL 语法：

mutation createAgent {
# agent-name should be the same as specified above in the config.yaml
createClusterAgent(input: { projectPath: "your-configuration-project-path", name: "agent-name-you-specified-in-config.yaml" }) {
    clusterAgent {
    id
    name
    }
    errors
}
}

点击运行按钮之后，在右侧会会出现返回结果，如：

{
  "data": {
    "createClusterAgent": {
      "clusterAgent": {
        "id": "gid://gitlab/Clusters::Agent/43",
        "name": "gitops"
      },
      "errors": []
    }
  }
}

整体效果如下：

使用 Kubernetes Agent Server 实现 GitOps,算法,kubernetes,git,workflow,devops

上述步骤创建了一个名为gitops，且与 your-configuration-project-path 这个 project 相关联的 agent，agent 的 ID 为 gid://gitlab/Clusters::Agent/43。接下来就需要为这个 agent 创建一个 agent token了。

创建 agent token

和创建 Agent 一样，利用 GraphQL Explorer 页面，在左侧输入 agent token 创建的 GraphQL 语法：

mutation createToken {
    clusterAgentTokenCreate(
      input: {
        clusterAgentId: "gid://gitlab/Clusters::Agent/43"
        description: "GitLab Kubernetes Agent Server Demo"
        name: "gitops"
      }
    ) {
      secret # This is the value you need to use on the next step
      token {
        createdAt
        id
      }
      errors
    }
  }

clusterAgentId为创建 agent 时候的返回值，如gid://gitlab/Clusters::Agent/43。name为指定的 agent 名称，本文为 gitops。

点击运行之后，在右侧会返回 agent token：

{
  "data": {
    "clusterAgentTokenCreate": {
      "secret": "generated-agent-token",
      "token": {
        "createdAt": "2021-08-17T13:22:31+08:00",
        "id": "gid://gitlab/Clusters::AgentToken/37"
      },
      "errors": []
    }
  }
}

结果中的 secret 即为 agent token。在后续会用到。

紧接着，就需要在 Kubernetes 集群侧安装 agent 了。

Kubernetes 上安装 agent（agentk）

在 Kubernetes 上安装 agent 时，有三个必要参数：

your-agent-token（上述步骤已经获取）；
Agent 所在的 namespace，这个自定义即可，本文用 gitlab-kubernetes-agent；
Kubernetes Agent Server（KAS）的地址。以极狐GitLab 用户为例，地址为 wss://kas.gitlab.cn。

接下来可以用如下命令进行一键式安装

$ docker run --pull=always --rm registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable generate --agent-token=your-agent-token --kas-address=wss://kas.gitlab.cn --agent-version stable --namespace gitlab-kubernetes-agent | kubectl apply -f -

将上述的--agent-token指定为前面步骤获取的值，同时用--namespace指定 agent 安装的 namespace，然后执行上述命令

$ docker run --pull=always --rm registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable generate --agent-token=your-agent-token  --kas-address=wss://kas.gitlab.cn --agent-version stable --namespace gitlab-kubernetes-agent | kubectl apply -f -
stable: Pulling from gitlab-org/cluster-integration/gitlab-agent/cli
Digest: sha256:a34079259440dcb627947e4df26fe5462829a3d6622d031ea0129e5953b70281
Status: Image is up to date for registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable
namespace/gitlab-kubernetes-agent created
serviceaccount/gitlab-agent created
clusterrole.rbac.authorization.k8s.io/cilium-alert-read created
clusterrole.rbac.authorization.k8s.io/gitlab-agent-gitops-read-all created
clusterrole.rbac.authorization.k8s.io/gitlab-agent-gitops-write-all created
clusterrolebinding.rbac.authorization.k8s.io/cilium-alert-read created
clusterrolebinding.rbac.authorization.k8s.io/gitlab-agent-gitops-read-all created
clusterrolebinding.rbac.authorization.k8s.io/gitlab-agent-gitops-write-all created
secret/gitlab-agent-token-8ccgb67gb2 created
deployment.apps/gitlab-agent created

安装完毕，可在gitlab-kubernetes-agent namespace 下查看 agent pod：

$ kubectl -n gitlab-kubernetes-agent get pods
NAME                            READY   STATUS    RESTARTS   AGE
gitlab-agent-866cc7fb95-5dgc2   1/1     Running   0          42s

查看 pods 的 log，如果成功的话会看到下面的内容：

{"level":"info","time":"2021-08-17T05:31:44.009Z","msg":"Cluster successfully synced","mod_name":"gitops","project_id":"your-configruation-project"}

说明 agent 在 Kubernetes 集群侧安装成功，且 agent 已和 config Project 同步成功。接下来就可以进行 GitOps workflow 实践了。

极狐GitLab GitOps workflow 实践

实践的前提条件

一个运行良好的极狐GitLab 实例（方便期间，推荐使用极狐GitLab Saas 产品，也即 GitLab-10万企业使用的一站式DevOps平台_GitLab中文官网）；
一个运行良好的 Kubernetes 集群(本文使用 Desktop 自带的 Kubernets 集群）。

根据上面的理论介绍，极狐GitLab GitOps workflow 需要有存放 config.yaml 文件和部署清单文件的 Project。两个可以用不同的 Project，也可以用同一个 Project，本次实践是将全部文件存放在同一个极狐GitLab Project 下面。目录结构如下：

├── .gitlab
│   └── agents
│       └── gitops
│           └── config.yaml
├── README.md
└── deployment
    └── deployment.yaml

其中 .gitlab/agents/gitops/ 是 config.yaml 文件存放的路径，gitops 是创建的 agent 名称，config.yaml 文件的内容如下：

gitops:
  manifest_projects:
  - id: "your-jihu-GitLab-project-which-you-want-to-be-listened-by-agent"
    paths:
    - glob: '/**/*.yaml'
observability:
  logging:
    level: debug

其中 id 表示存放部署清单文件的 Project 路径，glob 表示 agent 要监听的文件，可以监听所有的文件，也可以监听某个目录下的文件。具体的语法可以在这儿查看。而 deployment 目录下存放的则是需要部署的清单文件，本文以部署 nginx 来做示范，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: gitlab-kubernetes-agent 
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

上述内容会在 gitlab-kubernetes-agent namesace 下面部署一个名为 nginx-deployment 的 deployment，且 pod 副本数为 1。

$ kubectl -n gitlab-kubernetes-agent get deploy,pods
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/gitlab-agent       1/1     1            1           4h3m
deployment.apps/nginx-deployment   1/1     1            1           4h

NAME                                    READY   STATUS    RESTARTS   AGE
pod/gitlab-agent-866cc7fb95-5dgc2       1/1     Running   0          4h3m
pod/nginx-deployment-66b6c48dd5-mzwdb   1/1     Running   0          4h

接下来我们将 deployment.yaml 文件中的 replicas 修改为 2，来触发极狐GitLab GitOps workflow。观察 agent 的 log 可以看到如下内容：

$ kubectl -n gitlab-kubernetes-agent logs -f gitlab-agent-866cc7fb95-5dgc2
{"level":"info","time":"2021-08-17T09:34:58.406Z","msg":"Applying resource Deployment/nginx-deployment in cluster: https://10.96.0.1:443, namespace: gitlab-kubernetes-agent","mod_name":"gitops","project_id":"jihulab/marketing/technical-marketing/devops-demo"}
{"level":"info","time":"2021-08-17T09:34:58.502Z","msg":"Synced","mod_name":"gitops","project_id":"jihulab/marketing/technical-marketing/devops-demo","resource_key":"apps/Deployment/gitlab-kubernetes-agent/nginx-deployment","sync_result":"deployment.apps/nginx-deployment configured"}

同时查看 nginx-deployment 的 pod 数量变化：

$ kubectl -n gitlab-kubernetes-agent get pods -w
NAME                                READY   STATUS    RESTARTS   AGE
gitlab-agent-866cc7fb95-5dgc2       1/1     Running   0          4h5m
nginx-deployment-66b6c48dd5-mzwdb   1/1     Running   0          4h2m
nginx-deployment-66b6c48dd5-hpwqd   0/1     Pending   0          0s
nginx-deployment-66b6c48dd5-hpwqd   0/1     Pending   0          0s
nginx-deployment-66b6c48dd5-hpwqd   0/1     ContainerCreating   0          0s
nginx-deployment-66b6c48dd5-hpwqd   1/1     Running             0          2s

可以看到有新的 pod 被创建，当前 nginx-deployment 下的 pod 副本数是 2，这和部署清单文件里面描述的是一致的。也再次证明：当部署清单文件发生任何变更的时候，变更会被自动同步至 Kubernetes 集群侧。

写在最后

极狐GitLab 在设计 kas 和 agentk 的时候，倾向于把功能逻辑添加在 kas 中，而不是 agentk 中。尽量保持了 agentk 的精简，以便能够减少对于升级的需要，这也减少了维护人员的升级工作负担。因为在 gitlab.cn 中，kas 是由极狐GitLab 来管理的，所以功能的添加和版本的升级都是极狐侧来完成，而无需要求用户同步升级 agentk。这一点，其实在类似 agent/server 的设计架构中还是值得借鉴的。文章来源地址https://www.toymoban.com/news/detail-772017.html

到了这里，关于使用 Kubernetes Agent Server 实现 GitOps的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！