共计 4672 个字符，预计需要花费 12 分钟才能阅读完成。
一 背景
在目前微服务大行其道的背景下，Gitlab CI 集成 kubernetes 曾经是不可或缺的基本操作，咱们前几节零碎的实战了前后端我的项目以及物理 /K8s 混合环境部署，这节课咱们来学习 Gitlab CI 如何将利用公布进 K8s，咱们都晓得在之前的将 gitlab-runner 部署在服务器下面是存在肯定的危险，如果运行 pipeline 的服务器宕机，公布工作就没方法持续了，更可怕的时候如果 common-runner 发送故障，多个公布工作就都有问题，在微服务架构中，不可变的基础设施，容器的自蕴含环境使得咱们公布变得更加简略快捷，不必在思考放心 runner 的环境如何依据不同的我的项目辨别，且动静的 Job 触发，咱们会随时拉起一个 Pod 来运行咱们的 Job，运行实现后又进行销毁，这样不仅能实现动静运行节俭资源，而且能够不必思考多我的项目多任务并发构建的问题，这节课就让咱们来纵情享受 K8s+Gitlab CI 为咱们带来畅快淋漓的公布体验。
二 架构解析
本文以构建一个 Java 软件我的项目并将其部署到阿里云容器服务 Kubernetes 集群中为例，阐明如何应用 GitLab CI 在阿里云 Kubernetes 服务上运行 GitLab Runner、配置 Kubernetes 类型的 executor，并执行 Pipeline。
2.1 Gitlab CI 流程图
2.2 流程详解
如上图为一个简略的 Gitlab CI 部署进 K8s 流程图，同之前咱们讲到的 CI 集成统一，只须要我的项目中存在.gitlab-ci.yml 文件即可，与之前的差别为在集成 kubernetes 的时候，咱们讲咱们的 gitlab-runner 运行在咱们 K8s 内，其为一个 POD 模式运行，其管制着后续的 pipeline 中各 stage 的执行，咱们能够看到，当一个 pipeline 有多个 stage，每个 stage 都是有一个独自的 Pod 去执行，这个 Pod 应用的镜像在咱们 CI 的.gitlab-ci.yml 的每个 stage 的 image 中定义，如所示为一个部署 Java 我的项目的流程
开发者或我的项目维护者 merge request 到特定分支，改分支存在 CI 文件，开始进行 CI
CI 工作由曾经注册在 gitlab-server 运行在 K8s 集群内的 giitlab-runner 进行下发
第一个为 package，对 java 我的项目利用 maven 镜像进行打包，生成 war 包制品到缓存目录中；
利用 docker 镜像对依据我的项目中的 Dockerfile 对缓存中的制品进行镜像构建，构建实现后登录镜像仓库进行镜像推送；
在此咱们利用将部署文件托管在我的项目内，也体现了 gitops 的思维，将之前构建推送胜利的镜像地址信息在 deployment.yaml 文件进行批改，之后 apply 进 k8s 中，java 我的项目构建的镜像就运行在 K8s 集群内了，实现整个的公布。
在流程中有一些注意事项：
咱们能够在 stage 中增加本人业务需要的内容，例如单元测试，代码扫描等。
在部署文件中，咱们能够将整个我的项目制作成 helm 的 chart，替换其中的镜像，利用 helm 来进行整个利用的部署。
利用在部署中单个 stage 利用的是不同的 image，在各个 stage 中传递曾经生成的制品例如 war/jar 包，须要应用到内部存储来缓存制品。
三 长处
通过下面的 Gitlab CI 流程咱们可能看到将 gitlab runner 运行在 K8s 集群中，每个 Job 启动独自的 POD 运行操作，此种形式齐全利用起了 K8s 的一些长处
高可用：当某个节点呈现故障时，Kubernetes 会主动创立一个新的 GitLab-Runner 容器，并挂载同样的 Runner 配置，使服务达到高可用。
弹性伸缩：触发式工作，正当应用资源，每次运行脚本工作时，Gitlab-Runner 会主动创立一个或多个新的长期 Runner 来运行 Job。
资源最大化利用：动态创建 Pod 运行 Job，资源主动开释，而且 Kubernetes 会依据每个节点资源的应用状况，动态分配长期 Runner 到闲暇的节点上创立，升高呈现因某节点资源利用率高，还排队期待在该节点的状况。
扩展性好：当 Kubernetes 集群的资源严重不足而导致长期 Runner 排队期待时，能够很容易的增加一个 Kubernetes Node 到集群中，从而实现横向扩大。
如果您的业务目前运行环境为 K8s，那么 Gitlab CI 齐全符合您的业务场景，您只须要自定义 gitlab-ci.yml 中的各个本人需要的 stage 即可，配合 gitops 将配置也托管在我的项目内，追随我的项目一块保护治理，实现端到端的 CI 工作流，使得运维工作也可通过 git 追溯，进步工作效力，麻利开发上线部署。
四 实战
咱们在下面理解来 Gitlab CI 与 Kubernetes 的集成及其长处，上面就让咱们通过实战来更具体的理解其流程。
4.1 环境筹备
须要有 Gitlab 服务器，能够是部署在物理服务器上，当然也能够部署在 K8s 集群外部。
我须要筹备好 K8s 集群，能够为私有云的容器编排引擎，例如阿里的 ACK，腾讯的 TKE，华为的 CCE 等都实用这些形式。
因为 gitlab-runner 装置较为简单，咱们在示例中应用 helm 来进行装置，helm 版本为 v2.14.3，如果有能力能够本人编写资源清单部署。
4.1.1 记录注册信息
登录 Gitlab 服务器记录 gitlab 的 url 和注册令牌，在咱们部署进 K8s 的 gitlab-runnner 的配置中须要填写该信息，运行在 K8s 中的 Pod 就利用此此信息在 gitlab 服务器进行注册。
4.1.2 获取 gitlab-runner
因为独自部署 gitlab-runner 进 K8s 中，本人去写资源清单文件难度较大，而且容易出错，咱们在此利用官网的 chart 镜像通过 helm 来进行部署，仅批改其中咱们关系的字段即可，首先在登录 K8s 集群进行 gitlab-runner 的 helm repo 的增加，之后将 chart 下载到本地，解压文件并批改其中的 values.yml 文件。
增加 repo 获取 charts
[root@master common-service]# helm repo add gitlab https://charts.gitlab.io
“gitlab” has been added to your repositories
[root@master common-service]# helm repo update
Hang tight while we grab the latest from your chart repositories…
…Skip local chart repository
…Successfully got an update from the “aliyun” chart repository
…Successfully got an update from the “apphub” chart repository
…Successfully got an update from the “gitlab” chart repository
…Successfully got an update from the “stable” chart repository
Update Complete.
[root@master common-service]# helm search gitlab-runner
NAME CHART VERSION APP VERSION DESCRIPTION
gitlab/gitlab-runner 0.14.0 12.8.0 GitLab Runner
我看曾经看到了 gitlab-runner 的 chart，其是 helm 中形容相干的一组 Kubernetes 资源的文件汇合，外面蕴含了一个 value.yaml 配置文件和一系列模板（deployment.yaml、svc.yaml 等）。当然如果咱们能力够，能够本人去编写这些资源清单文件。
在此有想去的搭档能够查看之前 K8s 学习笔记，心愿能对读者学习 K8s 有帮忙：awesome-kubernetes-notes
创立角色并绑定权限
gitlab-runner 在运行的时候须要拜访咱们 K8s 的 api，咱们在此为期创立 ServiceAccount 并为其进行 RBAC 受权，首先创立一个 gitlab-runners 的名称空间，并创立对用的 Role，将 ServiceAccount 于 Role 进行绑定。
[root@master gitlab-runner]# cat > rbac-runner-config.yaml <<EOF
apiVersion: v1
kind: ServiceAccount # 在 gitlab-runners 名称空间下创立名为 gitlab 的 serviceaccount
metadata:
name: gitlab
namespace: gitlab-runners
kind: Role # 创立 gitlab 角色，
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: gitlab-runners
name: gitlab
rules:
- apiGroups: [“”] #”” indicates the core API group
resources: [“*”]
verbs: [“*”] - apiGroups: [“apps”]
resources: [“deployments”]
verbs: [“*”] - apiGroups: [“extensions”]
resources: [“deployments”]
verbs: [“*”]
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitlab # 将 sa 与角色进行绑定
namespace: gitlab-runners
subjects:
- kind: ServiceAccount
name: gitlab # Name is case sensitive
apiGroup: “”
roleRef:
kind: Role #this must be Role or ClusterRole
name: gitlab # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
EOF
创立资源清单
[root@master gitlab-runner]# kubectl create -f rbac-runner-config.yaml
serviceaccount/gitlab created
role.rbac.authorization.k8s.io/gitlab created
rolebinding.rbac.authorization.k8s.io/gitlab created
获取 charts 文件，并进行配置
[root@master gitlab-runner]# helm fetch gitlab/gitlab-runner
[root@master gitlab-runner]# tar xf gitlab-runner-0.14.0.tgz
[root@master gitlab-runner]# vim gitlab-runner/values.yaml
helm 为咱们提供了一个配置文件能够在装置 runner 的时候为其注册一个默认的 runner。咱们能够去 gitlab-runner 的我的项目源码 中获取到 values.yaml 这个配置文件。