使用GitLab CI/CD部署应用到Kubernetes集群的方案 |
您所在的位置：网站首页 › gitlab集群方案 › 使用GitLab CI/CD部署应用到Kubernetes集群的方案 |
使用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-deploykubectl是一个客户端，你可以在本地安装一个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从下图可以看到，答案符合预期。 在本地验证了使用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 不能错。 编写完提交。 下面就是见证奇迹的时刻了。
答案诚如我所预期，打印出了集群中所有的命名空间下的pod数据。你永远可以相信GitLab CI/CD，你永远可以相信我的探索能力。中国人不骗中国人。 如何部署到K8s集群那？核心命令行就是下面这行。 kubectl apply -f workload.yaml运行此命令会删除旧的部署，重新部署，即使你二次使用的docker镜像版本一致，内容不一致也能部署成功。apply 大法好。 workload.yaml 这个文件可以直接放在项目根目录，可以使用一些变量来定义镜像地址，镜像版本，部署端口。并在流水线中替换他们。这些都是常规操作。此外还可以加一下部署后的验证。打印一下调试日志。增加部署成功，部署失败的钉钉通知，邮件通知。这些都是附加项，之前也有介绍过。 本文到此就结束了，有关kubectl镜像的使用问题，以及在GitLab CI/CD中使用kubectl镜像的问题让我花了不少时间查阅资料。如果文章对你有帮助。请别忘记点赞。前端P6切图仔，擅长增删改查，略懂GitLab CI/CD。需要你的支持。谢谢。 最后感谢严奇同学提供的集群支持，能让我顺利完成k8s的CD实践，非常感谢。 |
配置完后，修改作业测试。
【本文地址】
今日新闻 |
推荐新闻 |