写点什么

让 KAS 给 GitOps 插上腾飞的翅膀

用户头像
极狐GitLab
关注
发布于: 11 小时前
让 KAS 给 GitOps 插上腾飞的翅膀

温习 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 的设计架构中还是值得借鉴的。


引用链接

  1. https://gitlab.com/groups/gitlab-org/-/epics/3329

  2. https://gitlab.com/gitlab-org/gitlab/-/issues/220912

  3. https://docs.gitlab.com/ee/api/graphql/getting_started.html

  4. https://gitlab.cn/-/graphql-explorer

  5. https://docs.gitlab.com/ee/user/clusters/agent/repository.html

发布于: 11 小时前阅读数: 6
用户头像

极狐GitLab

关注

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

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

评论

发布
暂无评论
让 KAS 给 GitOps 插上腾飞的翅膀