在 kubernetes 集群上 CI/CD 流程梳理
在 kubernetes 集群上 CI/CD 流程梳理
持续集成/持续发布
持续集成（Continuous Integration）
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续发布（Continuous Deployment）
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
整体架构
规范开发者基于一个分支开发项目，而不是直接在master分支上开发项目。项目发布后合并到master。
Gogs 作为代码仓库。
Jenkins X
在jenkins任务中，首先会根据参数自动通过 模板代码 生成 Dockerfile 和 chart 文件， 传入的参数有
| 参数 | 说明 |
|---|---|
| REPLICA_COUNT | pod 数量 |
| GIT_REPO | git仓库地址 |
| APP_NAME | 项目名称 |
| BRANCH_NAME | 基于的分支 |
| PORT | 使用和暴露的端口 |
| JAVA_COMMAND | 启动镜像的java命令行 |
| MAVEN_COMMAND | 打包构建命令行 |
| KUBERNETES_CPU | cpu限制 |
| KUBERNETES_MENORY | 内存限制 |
其中 KUBERNETES_CPU 和 KUBERNETES_MENORY 是用于限制 pod 调用 CPU 和内存限制的。同时还用于kubernetes 集群的调度和分配，将参数作为参考调度到有剩余资源的 Node 上。
deployment.yaml
resources:
limits:
cpu:
memory:
requests:
cpu:
memory:
其中 limits 表示资源限额，既限制应用使用的资源限制； requests 表示 资源调度 ，即 kubernetes 集群根据这个参数将决定将这个应用分配到哪个有剩余资源 Node上 。requests 是按照 limits 以一个比例 （小于接近于1）写入的。
maven
打包构建，通过 maven plugins 在 target 文件夹中将生成
- jar包
- lib文件夹，放入依赖的 jar包
- config 文件夹 ，放入配置文件
然后将这些东西 docker COPY 到镜像当中
skafflod
skaffold 是谷歌开源的用于促进在 kubernets 集群里持续集成/持续发布的命令行工具。
简单来说就是通过 skaffold.yaml 将 Dockerfile 生成镜像，然后 push 到镜像仓库中。
Harbor
harbor是一个具有管理和监控功能的镜像仓库。
包含的组件
-
harbor core， harbor 核心，包含docker仓库和管理页面。
- harbor notary， 确保镜像来源真实的服务,是确保企业镜像安全必不可少的机制。
- harbor clair， 镜像仓库漏洞扫描
chartmuseum
一个放置 helm chart 的文件仓库，提供了一系列 Restful API 接口，包含上传和下载chart文件，提供查询接口。
charts文件结构
charts
.
|-- appname //项目名称
|-- templates
| |-- NOTES.txt
| |-- _helpers.tpl
| |-- deployment.yaml
| |-- ingress.yaml
| `-- service.yaml
|-- Chart.yaml //chart的基本信息，包含chart 名称，和项目名称相同
|-- values.yaml //大多数的配置都放在这个文件中
|-- Makefile
`-- .helmignore
Monocular
展示 chart 的文件仓库的前端项目
Helm
部署到 kubernetes 集群的工具
RANCHER
展示和管理 kubernets 集群的前端项目 ，包含资源状态和容器管理，可以通过浏览器执行命名行。
开发流程
步骤
-
开发者基于分支开发代码，并启动 pipeline 将代码发布到开发环境中。
-
将代码构建后生成镜像，并push到镜像仓库，镜像tag 根据当前时间生成时间戳。同时通过模板代码生成项目chart，将 chart 推送到 chart museum 中，以时间戳区分版本。
-
通过helm ，将chart 部署项目到开发环境中，用 ingress 暴露服务。
-
提交测试，在git上打上 *-TEST 形式的 tag，提交到测试流程。
-
测试环节，在docker仓库中提取镜像。在chart museum 提取开发的 chart ，修改chart 主要是 profile 、namespace、启动命令。提交新的 chart 。然后测试人员通过 SonarQube analysis 分析代码。
-
通过 helm ，将测试提交的 chart 部署项目到测试环境中，以 ingress 暴露服务。测试人员测试bug。
-
测试不通过，打回代码；测试通过，在git上修改成 *-RELEASE 形式的 tag ，同时 delpoy 到 maven 仓库 maven-releases ，固定版本。提交到生产流程。
-
发布生产环节，在docker仓库中提取镜像。在chart museum 提取开发的 chart ，修改chart 主要是启动个数， profile 、namespace、启动命令。提交新的 chart 作为备份。
-
滚动发布到生产环境。
滚动发布
kubernets Deployment 具有滚动更新机制
strategy:
rollingUpdate:
maxSurge: 15%
maxUnavailable: 15%
maxSurge: 滚动升级时会先启动15% pod，向上取整，默认为 25%。
maxUnavailable: 滚动升级时允许的最大Unavailable的pod个数，向上取整，默认为 25%。
滚动发布的流程是会先产生15% 的新版本 pod，当 running 状态后，删除 15% 的旧版本 pod ，直到所有旧版本的 pod 替换为 新版本 pod。
探针
kubernets Deployment 的状态检测机制
livenessProbe:
httpGet:
path:
port:
initialDelaySeconds:
periodSeconds:
successThreshold:
timeoutSeconds:
readinessProbe:
httpGet:
path:
port:
periodSeconds:
successThreshold:
timeoutSeconds:
livenessProbe: kubernetes认为该pod是存活的,不存活则需要重启
readinessProbe: kubernetes认为该pod是启动成功的
path: 探针URL 路径，使用的是 /health
port: 端口
periodSeconds: 每隔多少秒检测一次
successThreshold: 默认1
timeoutSeconds: 超时时间，超过时间就会自动重启
