让 KAS 给 GitOps 插上腾飞的翅膀

关注

发布于: 11 小时前

温习 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^[1]。

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

极狐 GitLab GitOps workflow

极狐 GitLab GitOps workflow 的示意图如下

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

极狐 GitLab 服务（如使用极狐 Saas 则地址为 https://gitlab.cn)
一个运行正常且安装了极狐 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^[2]。

从上述示意图中看到，要完成整个流程，需要两个重要组件的配合：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

整体的架构示意图如下

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

极狐 GitLab KAS 的配置

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

创建极狐 GitLab agent

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

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

mutation createAgent {# agent-name should be the same as specified above in the config.yamlcreateClusterAgent(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": []    }  }

复制代码

整体效果如下：

上述步骤创建了一个名为 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/cliDigest: sha256:a34079259440dcb627947e4df26fe5462829a3d6622d031ea0129e5953b70281Status: Image is up to date for registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stablenamespace/gitlab-kubernetes-agent createdserviceaccount/gitlab-agent createdclusterrole.rbac.authorization.k8s.io/cilium-alert-read createdclusterrole.rbac.authorization.k8s.io/gitlab-agent-gitops-read-all createdclusterrole.rbac.authorization.k8s.io/gitlab-agent-gitops-write-all createdclusterrolebinding.rbac.authorization.k8s.io/cilium-alert-read createdclusterrolebinding.rbac.authorization.k8s.io/gitlab-agent-gitops-read-all createdclusterrolebinding.rbac.authorization.k8s.io/gitlab-agent-gitops-write-all createdsecret/gitlab-agent-token-8ccgb67gb2 createddeployment.apps/gitlab-agent created

复制代码

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

$ kubectl -n gitlab-kubernetes-agent get podsNAME                            READY   STATUS    RESTARTS   AGEgitlab-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 产品，也即 https://gitlab.cn）
一个运行良好的 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 要监听的文件，可以监听所有的文件，也可以监听某个目录下的文件。具体的语法可以在这儿^[5]查看。而 deployment 目录下存放的则是需要部署的清单文件，本文以部署 nginx 来做示范，内容如下：

apiVersion: apps/v1kind: Deploymentmetadata:  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,podsNAME                               READY   UP-TO-DATE   AVAILABLE   AGEdeployment.apps/gitlab-agent       1/1     1            1           4h3mdeployment.apps/nginx-deployment   1/1     1            1           4h
NAME                                    READY   STATUS    RESTARTS   AGEpod/gitlab-agent-866cc7fb95-5dgc2       1/1     Running   0          4h3mpod/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 -wNAME                                READY   STATUS    RESTARTS   AGEgitlab-agent-866cc7fb95-5dgc2       1/1     Running   0          4h5mnginx-deployment-66b6c48dd5-mzwdb   1/1     Running   0          4h2mnginx-deployment-66b6c48dd5-hpwqd   0/1     Pending   0          0snginx-deployment-66b6c48dd5-hpwqd   0/1     Pending   0          0snginx-deployment-66b6c48dd5-hpwqd   0/1     ContainerCreating   0          0snginx-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://gitlab.com/groups/gitlab-org/-/epics/3329
https://gitlab.com/gitlab-org/gitlab/-/issues/220912
https://docs.gitlab.com/ee/api/graphql/getting_started.html
https://gitlab.cn/-/graphql-explorer
https://docs.gitlab.com/ee/user/clusters/agent/repository.html

发布于: 11 小时前阅读数: 6

原文链接:【http://xie.infoq.cn/article/45bfd162146b3b5bf47ae0faf】。文章转载请联系作者。

极狐GitLab

关注

开源开放，人人贡献 2021.05.19 加入

开放式一体化DevOps平台，助力行业高速协同增长！

发布

暂无评论

创作场景

让 KAS 给 GitOps 插上腾飞的翅膀

温习 GitOps

极狐 GitLab Kubernetes Agent

极狐 GitLab GitOps workflow

极狐 GitLab KAS 的配置

创建极狐 GitLab agent

Kubernetes 上安装 agent（agentk）

极狐 GitLab GitOps workflow 实践

写在最后

极狐GitLab

评论