上节课我们将 Gitlab CI Runner 安装到了 Kubernetes 集群中，接下来看看如何结合 Kubernetes 和 Gitlab CI 进行持续集成和持续部署。
首先将本节所用到的代码库从 Github 上获得：cnych/gitlab-ci-k8s-demo，可以在 Gitlab 上新建一个项目导入该仓库，当然也可以新建一个空白的仓库，然后将 Github 上面的项目 Clone 到本地后，更改远程仓库地址即可：
当我们把仓库推送到 Gitlab 以后，应该可以看到 Gitlab CI 开始执行构建任务了:
此时 Runner Pod 所在的 namespace 下面也会出现两个新的 Pod：
这两个新的 Pod 就是用来执行具体的 Job 任务的，这里同时出现两个证明第一步是并行执行的两个任务，从上面的 Pipeline 中也可以看到是 test 和 test2 这两个 Job。我们可以看到在执行 image_build 任务的时候出现了错误：
我们可以点击查看这个 Job 失败详细信息：
出现上面的错误是因为我们并没有在 Gitlab 中开启 Container Registry，所以环境变量中并没有这些值，还记得前面章节中我们安装的 Harbor吗？我们这里使用 Harbor 来作为我们的镜像仓库，这里我们只需要把 Harbor 相关的配置以参数的形式配置到环境中就可以了。
定位到项目 -> 设置 -> CI/CD，展开 Environmentvariables栏目，配置镜像仓库相关的参数值：
配置上后，我们在上面失败的 Job 任务上点击“重试”，在重试过后依然可以看到会出现下面的错误信息：
从错误信息可以看出这是因为登录私有镜像仓库的时候证书验证错误，因为我们根本就没有提供任何证书，所以肯定会失败的，还记得我们之前在介绍 Harbor 的时候的解决方法吗？第一种是在 Docker 的启动参数中添加上 insecure-registries，另外一种是在目录 /etc/docker/certs.d/下面添加上私有仓库的 CA 证书，同样，我们只需要在 dind 中添加 insecure 的参数即可：
然后保存 .gitlab-ci.yml文件，重新提交到代码仓库，可以看到又触发了正常的流水线构建了，在最后的阶段 deploy_review仍然可以看到失败了，这是因为在最后的部署阶段我们使用 kubectl工具操作集群的时候并没有关联上任何集群。
我们在 Gitlab CI 中部署阶段使用到的镜像是 cnych/kubectl，该镜像的 Dockerfile文件可以在仓库 cnych/docker-kubectl 中获取：
我们知道 kubectl在使用的时候默认会读取当前用户目录下面的 ~/.kube/config文件来链接集群，当然我们可以把连接集群的信息直接内置到上面的这个镜像中去，这样就可以直接操作集群了，但是也有一个不好的地方就是不方便操作，假如要切换一个集群还得重新制作一个镜像。所以一般我们这里直接在 Gitlab 上配置集成 Kubernetes 集群。
在项目页面点击 AddKubernetesCluster -> Addexisting cluster：
1.Kubernetes cluster name 可以随便填
2.API URL 是你的集群的 apiserver的地址， 一般可以通过输入 kubectl cluster-info获取，Kubernetes master 地址就是需要的
3.CA证书、Token、项目命名空间
对于我们这个项目准备部署在一个名为 gitlab的 namespace 下面，所以首先我们需要到目标集群中创建一个 namespace:
由于我们在部署阶段需要去创建、删除一些资源对象，所以我们也需要对象的 RBAC 权限，这里为了简单，我们直接新建一个 ServiceAccount，绑定上一个 cluster-admin的权限：(gitlab-sa.yaml)
然后创建上面的 ServiceAccount 对象：
可以通过上面创建的 ServiceAccount 获取 CA 证书和 Token：
填写上面对应的值添加集群：
现在 Gitlab CI 的环境都准备好了，我们可以来看下用于描述 Gitlab CI 的 .gitlab-ci.yml文件。
一个 Job 在 .gitlab-ci.yml文件中一般如下定义：
上面这个 Job 会在 test 这个 Stage 阶段运行。
为了指定运行的 Stage 阶段，可以在 .gitlab-ci.yml文件中放置任意一个简单的列表：
你可以指定用于在全局或者每个作业上执行命令的镜像：
在我们当前的项目中定义了 4 个构建阶段：test、build、release、review、deploy，完整的 .gitlab-ci.yml文件如下：
上面的 .gitlab-ci.yml文件中还有一些特殊的属性，如限制运行的的 when和 only参数，例如 only:["tags"]表示只为创建的标签运行，更多的信息，我可以通过查看 Gitlab CI YAML 文件查看：https://docs.gitlab.com/ce/ci/yaml/README.html
由于我们在 .gitlab-ci.yml文件中将应用的镜像构建完成后推送到了我们的私有仓库，而 Kubernetes 资源清单文件中使用的私有镜像，所以我们需要配置一个 imagePullSecret，否则在 Kubernetes 集群中是无法拉取我们的私有镜像的：(替换下面相关信息为自己的)
在下面的 Deployment 的资源清单文件中会使用到创建的 myregistry。
接下来为应用创建 Kubernetes 资源清单文件，添加到代码仓库中。首先创建 Deployment 资源：（deployment.yaml）
这是一个基本的 Deployment 资源清单的描述，像 CI_ENVIRONMENT_SLUG和 VERSION这样的占位符用于区分不同的环境， CI_ENVIRONMENT_SLUG将由 dev 或 live（环境名称）和 VERSION替换为镜像标签。
为了能够连接到部署的 Pod，还需要 Service。对应的 Service 资源清单如下（service.yaml）：
我们的应用程序运行8000端口上，端口名为 http-metrics，如果你还记得前面我们监控的课程中应该还记得我们使用 prometheus-operator为 Prometheus 创建了 自动发现的配置，所以我们在 annotations里面配置上上面的这几个注释后，Prometheus 就可以自动获取我们应用的监控指标数据了。
现在 Service 创建成功了，但是外部用户还不能访问到我们的应用，当然我们可以把 Service 设置成 NodePort 类型，另外一个常见的方式当然就是使用 Ingress 了，我们可以通过 Ingress 来将应用暴露给外面用户使用，对应的资源清单文件如下：（ingress.yaml）
当然如果想配置 https 访问的话我们可以自己用 CA 证书创建一个 tls 密钥，也可以使用 cert-manager来自动为我们的应用程序添加 https。
当然要通过上面的域名进行访问，还需要进行 DNS 解析的， CI_ENVIRONMENT_SLUG-gitlab-k8s-demo.qikqiak.com其中 CI_ENVIRONMENT_SLUG值为 live 或 dev，所以需要创建 dev-gitlab-k8s-demo.qikqiak.com 和 live-gitlab-k8s-demo.qikqiak.com 两个域名的解析。
我们可以使用 DNS 解析服务商的 API 来自动创建域名解析，也可以使用 Kubernetes incubator 孵化的项目 external-dns operator 来进行操作。
所需要的资源清单和 .gitlab-ci.yml文件已经准备好了，我们可以小小的添加一个文件去触发下 Gitlab CI 构建：
现在回到 Gitlab 中可以看到我们的项目触发了一个新的 Pipeline 的构建：
可以查看最后一个阶段（stage）是否正确，如果通过了，证明我们已经成功将应用程序部署到 Kubernetes 集群中了，一个成功的 review阶段如下所示：
整个 Pipeline 构建成功后，我们可以在项目的环境菜单下面看到多了一个环境：
如果我们点击 终止，就会调用 .gitlab-ci.yml中定义的钩子 on_stop:stop_review，点击 Viewdeployment就可以看到这次我们的部署结果（前提是DNS解析已经完成）：
这就是关于 Gitlab CI 结合 Kubernetes 进行 CI/CD 的过程，具体详细的构建任务还需要结合我们自己的应用实际情况而定。下节课给大家介绍使用 Jenkins + Gitlab + Harbor + Helm + Kubernetes 来实现一个完整的 CI/CD 流水线作业。
参考链接：https://edenmal.moe/post/2017/Kubernetes-WYNTK-GitLab-CI-Kubernetes-Presentation/
扫描下面的二维码(或微信搜索 k8s技术圈)关注我们的微信公众帐号，在微信公众帐号中回复 加群 即可加入到我们的 kubernetes 讨论群里面共同学习