使用GitLab CI/CD部署应用到Kubernetes集群的方案

最近业余时间调研了一下在GitLab CI/CD中部署应用到Kubernetes的方案。这是一个老生常谈的话题，很多粉丝和读者问我如何部署应用到K8s中。其实思路是很清晰的，只是其中又很多点大家可能无法串起来。那么本篇文章就带领大家实践一下如何做CD的方案。

本方案的好处就是，读者不需要了解太多关K8s相关知识也可以实现该方案。

Kubernets的命令行工具是kubectl。就像我们使用docker命令来管理docker的镜像，容器一样。
k8s中的所有资源都可以使用kubectl 来进行管理。例如一下几个命令

查看命名空间

kubectl get ns

查看所有命名空间下的pod

kubectl get pods --all-namespaces

查看当前命名空间下的deploment

kubectl get deployment

查看当前命名空间下的service

kubectl get services

部署一个应用

# workload.yaml定义了部署应用的所有参数
kubectl apply -f workload.yaml

一个应用模板

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: ci-test
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx-deploy        
    spec:
      containers:
        - name: nginx-deploy
          imagePullPolicy: Always
          image: nginx
          env:
          - name: TZ
            value: Asia/Shanghai
  selector:
    matchLabels:
      app: nginx-deploy
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy-ci-test
  namespace: ci-test
spec:
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 31594
  selector:
    app: nginx-deploy

kubectl是一个客户端，你可以在本地安装一个kubectl。配置好信息，就可以管理千里之外的k8s集群了。

在CI/CD中我们要部署应用到K8s集群中，也离不开它。
下面进入正题，
这个方案的架构是这样的。

GitLab Runner 是使用docker安装的，执行器为dokcer。（有很多同学不明白为什么在K8s里执行器还用docker啊。这是因为K8s执行器作者也不会啊🤣🤣，确切说，还没学到，实践到那一部分）。一般我都是"一个docker走天下" 能用dokcer装绝不要其他方式装。有条件的同学可以使用k8s作为执行器，动态伸缩还是很好用的。
在流水线中使用kubectl的容器来执行kubectl的命令
预设一个yaml模板来装载应用的部署信息
kubeconfig是存放在宿主机本地，通过挂载目录映射到kubectl的容器中

kubectl镜像的使用

kubectl 的容器我选用的是 bitnami/kubectl

使用方法是

# 获取kubectl的版本号
docker run --rm --name kubectl bitnami/kubectl:latest version

# 挂载目录配置kubectl
docker run --rm --name kubectl -v /path/to/your/kube/config:/.kube/config bitnami/kubectl:latest

特别注意，这个镜像其实是一个二进制文件，要执行命令必须在 docker run ... 的命令后，直接加命令。
注意不要有 kubectl。比如你要执行 kubectl version 只需要这样写

# 获取kubectl的版本号
docker run --rm --name kubectl bitnami/kubectl:latest version

这也是二进制镜像与其他镜像不一致的地方。想要了解更多里看看 Docker中有关 entrypoint的文档。

kubectl镜像的配置

在安装了kubectl的机器上输入以下命令可以查看kubectl的配置信息

# 获取kubectl的配置信息
kubectl config view

得到的内容大致是这样的。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://1.2.3.4:6443
  name: kubernetes
- cluster:
    certificate-authority: C:\Users\fizz\.minikube\ca.crt
    server: https://172.19.226.148:8443
  name: minikube
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: k8s
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: minikube
  user:
    client-certificate: C:\Users\fizz\.minikube\profiles\minikube\client.crt
    client-key: C:\Users\fizz\.minikube\profiles\minikube\client.key

一个yaml格式的内容。
最主要的是clusters contexts users

clusters 是用于配置集群信息的，可以配置多个，每个集群需要集群的证书，服务地址，以及名称。这个集群名称会在下面的contexts（上下文），users（用户）中用到。

contexts是用于kubectl的上下文，有几个上下文，每个上下文都有一个名称，可以使用kubectl来切换上下文，以此来达到管理多个集群的目的。 current-context 表明当前的上下文。

users 是用于配置操作集群的用户。每个用户也都需要配置证书和秘钥。

如果你不知道这个东西怎么生成（其实我也不太清楚），也没关系。只需要知道在哪里拿到就行了。
比如我本地的集群就在这个路径下存着C:\Users\fizz\.kube 在这里插入图片描述

如果是linux服务器上，那么可以在 ~/.kube/config中找到该文件。

有了这个东西，你就可以为所以为了。在集群想干嘛就干嘛。哈哈...

OK,现在有了配置文件，有了kubectl的镜像。那现在本地环境实验一把。
在本地运行kubectl的容器，挂载一个集群的配置文件，并打印出所有命名空间下的pod

docker run --rm --name kubectl -v /mnt/d/watch/config:/.kube/config bitnami/kubectl:latest get pods --all-namespaces

从下图可以看到，答案符合预期。
在这里插入图片描述

GitLab CI/CD中使用kubectl镜像

在本地验证了使用kubectl镜像管理集群的方案。下面就需要在GitLab CI/CD中来实践。
这里就有一个问题了。
由于kubectl是二进制镜像。在容器运行时必须要执行实质命令。否则会自动退出。那么在GitLab CI/CD该怎么操作那？
总不能在关键词script中执行 docker run bitnami/kubectl apply -f workload.yaml 吧。
其实这样应该是可以的，但是很不优雅。优雅的方式是使用关键词image 指定镜像为 bitnami/kubectl 再进行操作。
但这样做有一个问题，就是无法在运行该容器的时候执行kubectl的命令。

伟大的GitLab CI/CD开发人员已经想到了这个问题，并给出详细的文档。点击查看详情

在这里插入图片描述

用我二流的英语知识给大家解释一下这段英文的大致意思吧。

有些docker镜像已经定义好了入口，你在run的时候就会执行一些脚本。你要想运行你的命名就只能在run的命令后加。那么如果我只是想把这个镜像当做基础镜像，真正的脚本定义在script中。
这个时候就使用关键词下image下的 entrypoint 配置项，重置该镜像的入口。覆盖容器运行时的脚本，并将关键词，before_script, script, after_script三部分定义的脚本都合并起来当做容器运行时的脚本执行。

看懂了这段话，其实答案就呼之欲出了。
job就这样写就可以了

deploy_k8s:
  image:
    name: bitnami/kubectl
    entrypoint: [""]
  script:
    - kubectl version

这样应该就可以了。放到流水线里执行一下。

流水线日志如下，
在这里插入图片描述

答案与预期有些许差异。正确执行了kubectl version命令。但报了一个错。
The connection to the server localhost:8080 was refused - did you specify the right host or port?

聪明的读者一下就猜到了，这是因为kubectl没有配置文件导致的。
那么就给它配一个集群吧。

到这里就剩最后一步了。配置流水线中的kubectl镜像。
由于是流水线中的docker镜像，这里要使用挂载本地目录，将配置信息映射到容器中。我之前有写过一篇文章介绍这一配置。
[gitlab ci/cd如何在docker in docker 下将流水线的产物输出到宿主机上？
](https://fizzz.blog.csdn.net/article/details/120195224)

做法就是
找到GitLab Runner的配置文件 config.toml。
找到对应的runner。
vim /srv/gitlab-runner/config/config.toml

在volumes中增加一个目录挂载。
"/srv/gitlab-runner/config/kubeconfig:/build/kubeconfig:rw"
如下图
在这里插入图片描述

我们需要把kubectl 的配置文件放在宿主机的 /srv/gitlab-runner/config/kubeconfig 目录里。
像这样，文件名为config 不能错。
在这里插入图片描述
配置完后，修改作业测试。

deploy_k8s:
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  before_script:
    - cp -rf /build/kubeconfig/config /.kube/config
  script: 
    - echo "deploy to k8s cluster..."
    - kubectl version
    - kubectl get pods --all-namespaces

编写完提交。下面就是见证奇迹的时刻了。

在这里插入图片描述