关于云计算:使用-KubeSphere-和极狐GitLab-打造云原生持续交付系统

Kubernetes 是一个非常复杂的容器编排平台，学习老本十分高，KubeSphere 所做的事件就是高度产品化和形象了底层 Kubernetes，是一个面向云原生的操作系统。讲得再艰深一点，Kubernetes 屏蔽了底层容器运行时的差别，而 KubeSphere 则屏蔽了底层 Kubernetes 集群的差别，它解决了 K8s 应用门槛高和云原生生态工具庞杂的痛点。你能够在可视化界面上点几下鼠标即可将 Pod 调度到集群的不同节点中，无需编写 YAML。

下面是 KubeSphere 的性能架构，能够看到 KubeSphere 蕴含了十分多的利用场景，比方微服务、DevOps、利用治理、可观测性和平安等，每一个场景生态上面都蕴含了很多对研发和运维人员比拟敌对的组件，而且所有的组件都是可插拔的，用户能够依据本人的志愿自由选择启用哪个组件。

从 v4.0 开始，KubeSphere 会提供前后端可插拔的架构和框架，任何第三方单干伙办和 ISV 都能够基于 KubeSphere 4.0 凋谢框架，开发扩大本人想要的性能插件，这些性能插件与 KubeSphere 有完全一致的 UI 体验，造成更弱小的利用生态。这就好比 Mac OS 和 App Store 之间的关系一样，任何企业或团队都能够公布本人开发的插件到利用商店，灵便满足各类用户的需要，在社区与 KubeSphere 单干互利共赢。

极狐 GitLab 是一个一体化的 DevOps 平台，能够简略了解为 GitLab 在国内的“发行版”。是由极狐 (GitLab) 公司推出的产品（极狐 (GitLab) 公司是以“中外合资 3.0”模式成立的公司，在国内独立经营，为国内用户提供适宜本土化的 DevOps 平台以及反对服务）。

极狐 GitLab 是开源的，任何人都能够参加开源共建，代码托管在极狐 GitLab SaaS 上：https://jihulab.com/gitlab-cn…。其提供的一体化 DevOps 能力笼罩软件开发全生命周期（从打算到运维），同时内置了平安性能，可能利用开箱即用的平安能力构建 DevSecOps 体系。

更重要的一点是，极狐 GitLab 反对自建（公有部署）和 SaaS 两种服务。在公有部署的时候，反对多种装置形式，其中就包含云原生的装置形式，因而，联合 KubeSphere 和极狐 GitLab，能够打造出一个适应云原生时代的继续交付零碎。

目前在 KubeSphere 上部署极狐 GitLab 十分便当，只须要利用 KubeSphere 的 利用商店 即可一键部署。

利用商店与利用全生命周期治理是 KubeSphere 独有的特色，KubeSphere 为用户提供了一个基于 Helm 的利用商店，用于利用生命周期治理。而且从 3.2.0 版本开始，KubeSphere 新增了 “动静加载利用商店” 的性能，合作伙伴可申请将利用的 Helm Chart 集成到 KubeSphere 利用商店，相干的 Pull Request 被合并后，KubeSphere 利用商店即可动静加载利用，不再受到 KubeSphere 版本的限度。目前极狐 Gitlab 就是通过动静加载的形式将其 Helm Chart 上架到了 KubeSphere 的利用商店。

间接抉择下图红色方框中的 jh-gitlab 即可开始部署。

下一步须要批改一些参数，即 Helm Chart 中的 values。

大家须要依据本人的理论状况批改，我的公有环境不须要 Ingress，能够通过 Cluster IP 直连，所以才将域名全副设置成了 Service Name。除此之外，还须要勾销装置 Runner，后续再独自装置。其余参数能够本人酌情批改，比方我勾销了 Certmanager 和 Ingress-Nginx。

查看创立好的工作负载：

部署实现后，就能够通过设置好的域名拜访极狐 GitLab。

默认用户名是 root，初始密码能够通过以下命令获取：

$ kubectl -n jh-gitlab get secret jh-gitlab-gitlab-initial-root-password -o go-template --template='{{.data.password}}' | base64 -D

登录之后能够先创立一个我的项目，上面装置 Runner 和演示 Demo 的章节都会用到。

极狐 GitLab Runner 只是极狐 GitLab 的其中一个组件，所以不能再通过利用商店来装置。KubeSphere 除了过利用商店之外，还能够通过利用仓库和利用模板来装置利用。所谓利用仓库，就是一个宽松版的利用商店，利用商店是所有用户共用的，利用仓库只是个人版的利用商店，不须要审批，只会存在于你本人的集群中。只需将相干利用 Helm Chart 的 URL 导入，即可变成利用仓库中的一个利用。这里咱们抉择导入极狐 GitLab 的 Helm Chart。

而后在『利用』中点击『创立』。

而后抉择『从利用模板』，在弹出面板的下拉框中抉择 GitLab。

抉择 gitlab-runner，而后设置利用名称，持续点击下一步，开始批改部署参数。

其中，gitlabUrl 的值为极狐 GitLab 的可视化界面地址，runnerRegistrationToken 的值能够设置为想要应用该 Runner 的我的项目的 CI/CD Specific runners 的 registration token，例如：

同时还须要开启 RBAC：

rbac:
  create: true
  rules: []
  clusterWideAccess: false
  podSecurityPolicy:
    enabled: false
    resourceNames:
      - gitlab-runner

其余参数可依据理论状况酌情批改，批改实现后点击下一步开始装置。装置实现后，能够进入 Pod 查看注册状况：

$ kubectl -n jh-gitlab get pod -l release=gitlab-runner
NAME                                          READY   STATUS        RESTARTS   AGE
gitlab-runner-gitlab-runner-c7c999dfc-wgg56   1/1     Running       0          61s

$ kubectl -n jh-gitlab exec -it gitlab-runner-gitlab-runner-c7c999dfc-wgg56 -- bash
Defaulted container "gitlab-runner-gitlab-runner" out of: gitlab-runner-gitlab-runner, configure (init)
bash-5.0$ gitlab-runner list
Runtime platform                                    arch=amd64 os=linux pid=106 revision=f761588f version=14.10.1
Listing configured runners                          ConfigFile=/home/gitlab-runner/.gitlab-runner/config.toml
gitlab-runner-gitlab-runner-c7c999dfc-wgg56         Executor=kubernetes Token=dSz6WoJzpD5bjkDhP5xN URL=https://jihulab.com/
bash-5.0$

能够看到 Pod 外面曾经内置了 gitlab-runner 命令，且有注册胜利的 Runner 实例 gitlab-runner-gitlab-runner-c7c999dfc-wgg56，而这就是刚刚用利用模板装置的 Runner。在极狐 GitLab 的 Web 页面也能够看到注册胜利的 Runner。

接下来咱们通过一个简略的流水线示例来演示极狐 GitLab 的 CI/CD 流水线工作原理。演示流水线之前，先来理解几个基本概念。

极狐 GitLab 流水线蕴含两个外围组件：

Job : 形容须要执行的工作；
Stage : 定义 Job 执行的程序。

而流水线（Pipeline）则是一组运行在各个 Stage 中的 Job 汇合，能够蕴含多个流程：编译、测试、部署等等，任何提交或 Merge Request 都能触发流水线。

负责执行 Job 的就是 Runner，Runner 的本体，是运行在某台机器上的守护过程，相似于 Jenkins agent。在 Runner 本人看来，没有类型的区别，它只是依据 Token 和 URL，注册到指定的极狐 GitLab 而已。

讲完了根底概念，间接来看示例仓库。

这个示例利用是用 Go 写的 HTTP Server，代码很简略，我就不解释了。

package main

import (
    "fmt"
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {fmt.Fprintf(w, "Hello this is kubesphere")
}

func main() {http.HandleFunc("/ks", handler)
    log.Fatal(http.ListenAndServe(":9999", nil))
}

流水线编排文件是 .gitlab-ci.yml，内容如下：

stages:
  - build
  - deploy

build:
  image: 
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: build
  tags: 
    - kubernetes
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - >-
      /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:1.0.0"

deploy:
  image: bitnami/kubectl:latest
  stage: deploy
  tags: 
    - kubernetes
  variables:
    KUBERNETES_SERVICE_ACCOUNT_OVERWRITE: jh-gitlab
  only:
    - main
  script:
    - kubectl -n jh-gitlab apply -f deployment.yaml

因为最新版的 Kubernetes 无情地摈弃了 Docker，举荐应用 Containerd 作为运行时，所以就没法应用 Docker 来构建镜像啦，咱们能够抉择应用 Kaniko。Kaniko 是谷歌开源的一款用来构建容器镜像的工具。与 Docker 不同，Kaniko 并不依赖于 Docker Daemon 过程，齐全是在用户空间依据 Dockerfile 的内容逐行执行命令来构建镜像，这就使得在一些无奈获取 Docker Daemon 过程的环境下也可能构建镜像，比方在规范的 Kubernetes 集群上。

这个流水线总共蕴含两个阶段：构建和部署。部署阶段须要留神的是，默认状况下 Kubernetes 中的 Pod 是没有权限创立工作负载的，所以咱们须要创立一个新的 ServiceAccount，将其绑定到具备权限的 ClusterRole 下面。

# rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jh-gitlab
  namespace: jh-gitlab
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: jh-gitlab
    namespace: jh-gitlab

$ kubectl apply -f rbac.yaml

最初再让 Runner 应用这个新的 ServiceAccount，即：

  variables:
    KUBERNETES_SERVICE_ACCOUNT_OVERWRITE: jh-gitlab

然而这样还不行，默认状况下流水线没有权限批改 Runner 的 ServiceAccount，须要批改 Runner 的部署清单，赋予其批改权限。

留神图中右侧的高亮局部，示意容许 jh-gitlab 这个 namespace 上面的 Pod 更改其 ServiceAccount。批改结束后点击更新即可。

这是我的残缺配置，供大家参考：

imagePullPolicy: IfNotPresent
gitlabUrl: 'https://jihulab.com/'
runnerRegistrationToken: GR1348941fycCAhY3_LnRFPqy3DL4
terminationGracePeriodSeconds: 3600
concurrent: 10
checkInterval: 30
sessionServer:
  enabled: false
rbac:
  create: true
  rules: []
  clusterWideAccess: false
  podSecurityPolicy:
    enabled: false
    resourceNames:
      - gitlab-runner
metrics:
  enabled: false
  portName: metrics
  port: 9252
  serviceMonitor:
    enabled: false
service:
  enabled: false
  type: ClusterIP
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:16.04"
  privileged: true
  tags: "kubernetes"
  cache: {}
  builds: {}
  services: {}
  helpers: {}
securityContext:
  runAsUser: 100
  fsGroup: 65533
resources: {}
affinity: {}
nodeSelector: {}
tolerations: []
envVars:
  - name: KUBERNETES_SERVICE_ACCOUNT_OVERWRITE_ALLOWED
    value: jh-gitlab
hostAliases: []
podAnnotations: {}
podLabels: {}
secrets: []
configMaps: {}

当初轻易批改仓库中的文件（比方 README）来触发流水线。

能够看到流水线被胜利触发并执行胜利。最初咱们来看看构建好的镜像有没有被胜利部署。

从 KubeSphere 可视化界面里能够看到利用被胜利部署了。最初能够测试一下这个 HTTP Server 是否失常工作：

$ kubectl -n jh-gitlab get pod -l app=cicd-demo -owide
NAME                         READY   STATUS    RESTARTS   AGE     IP             NODE           NOMINATED NODE   READINESS GATES
cicd-demo-86d7fb797c-428xs   1/1     Running   0          4m40s   10.233.65.81   k3s-worker02   <none>           <none>

$ curl http://10.233.65.81:9999/ks
Hello this is kubesphere

本文给大家介绍了 KubeSphere 和极狐 GitLab 以及各自的劣势，并探讨了如何联合 KubeSphere 和极狐 GitLab 来打造一个云原生时代的继续交付零碎，最初通过一个流水线示例来展现极狐 GiLab 流水线的工作原理。

从最初的示例能够看出，CD（即部署阶段）的过程还是比拟麻烦的，比方须要装置配置额定工具（kubectl），还须要 Kubernetes 对其进行受权，如果 Kubernetes 部署在云平台中，还须要云平台对其受权。最重要的是，它无奈感知部署的状态，部署完了之后无奈获知该工作负载是否失常提供服务。

那么这个问题有没有解决办法呢？我将在下一篇文章中给大家介绍如何通过 GitOps 来解决这个问题。

本文由博客一文多发平台 OpenWrite 公布！

关于云计算:使用-KubeSphere-和极狐GitLab-打造云原生持续交付系统

KubeSphere 简介

极狐 GitLab 简介

在 KubeSphere 上装置极狐 GitLab 和 Runner

装置极狐 GitLab

装置极狐 GitLab Runner

CI/CD Demo 演示

总结