近年来云服务|原生发展迅猛，企业上云已经成为家常便饭。当企业大量服务上云后，如何在云上快速部署、更新服务就是一个必须面对的问题。本文结合当下经典方案，分享以下3种常见基于 K8S的CICD方案，并加以案例介绍。
| 方案 | 概述 | 评价 |
|---|---|---|
| jenkins + kubectl + k8s | jenkins job实现镜像构建和服务更新, 服务更新的时候直接通过kubeclt命令实现 | jenkins 比较经典，简单易用，适合新入门的用户，UI和附加功能较少 |
| jenkins + helm + k8s | jenkins job实现镜像构建和服务更新, 服务部署时候使用helm chart模式，服务更新的时候直接通过helm 命令实现 | 使用helm chart管理服务，可快速通过多个values.yaml部署不同环境的服务，同时具备jenkins的简单医用特性，UI和附加功能较少 |
| zadig + helm + k8s | 直接使用zadig实现镜像构建和服务更新，服务部署的时候使用helm chart模式 | 既有helm chart优秀功能，又具备良好的UI，且具备多个优秀的附加功能 |
注意:
此处第3种方案中Zadig 是 KodeRover 公司基于 Kubernetes 自主设计、研发的开源分布式持续交付 (Continuous Delivery) 产品，其可以被很多大公司内部的服务部署&发布系统代替。
本文受限于篇幅和时间，只出略讲了3种方案，很多实施细节暂未来得及补充，后续笔者会基于本文出一系列 基于K8S的CICD实战教程，并将链接更新补充在此处，欢迎有需要的小伙伴关注！
上述已经介绍了3种主流 k8s cicd 方案的优缺点，此处继续通过案例进一步详细说明。
本方案主要使用 build_docker 来构建镜像，然后通过 deploy_kubectl 将镜像发布到集群，以下为相关参数和 jenkins script脚本说明。
build_docker job 如下
1）图1 主要参数
build 流程中，我们一般提供给用户 git repo名称、分支、镜像repo-name 等几个核心参数即可，也可按需添加附加参数。
2）图2 执行结果
执行过程中我们可以动态生成镜像tag，并把它输出在 description栏目，方便用户获取镜像 tag。
3）pipeline script
gitlab_repo = "${params.gitlab_repo}"
def split = gitlab_repo.split("/")
def repo_name = split[1]
build_node = 'knode-pc'
branch_name = "${params.branch_name}"
dockerhub_repo = "${params.dockerhub_repo}"
repo_url = "git@xx.xx.xx.xx:${gitlab_repo}.git"
import java.text.SimpleDateFormat;
def createVersion() {
def dateUnix = ((new Date().time + 8*3600*1000) / 1000).intValue()
Date dateObj = new Date( ((long)dateUnix) * 1000 )
String ymd = new SimpleDateFormat("yyyy.MM.dd-HHmm").format(dateObj)
return "${ymd}"
}
image_version = createVersion()
work_dir = "${repo_name}-${image_version}"
build_user=""
node{
wrap([$class: 'BuildUser']) {
build_user = env.BUILD_USER
}
}
println("build_user=${build_user}")
default_description = "${build_user} ${gitlab_repo}/${branch_name}:${image_version}"
currentBuild.description = "${default_description}"
pipeline {
agent {
node {
label "${build_node}"
}
}
environment {
repo_name1 = "${repo_name}"
}
stages {
stage('Clean workspace') {
agent {
node {
label "${build_node}"
}
}
steps {
sh """
rm -rf ${work_dir}
"""
}
}
stage("Clone Repo"){
agent {
node {
label "${build_node}"
}
}
steps {
dir("${work_dir}"){
deleteDir()
git(
url: "${repo_url}",
credentialsId: '73d34b09-yourCredentialsId-142643489274',
branch: "${branch_name}"
)
sh """
pwd && ls -la
"""
}
}
}
stage('Build docker images') {
agent {
node {
label "${build_node}"
}
}
steps {
dir("${work_dir}"){
sh """
if [ ! -f Dockerfile ]
then
echo "No available Dockerfile in workspace"
exit 0
fi
pwd
ls
docker build -f Dockerfile -t ${dockerhub_repo}:${image_version} .
docker push ${dockerhub_repo}:${image_version}
docker rmi ${dockerhub_repo}:${image_version}
"""
}
}
}
stage('Set tag') {
agent {
node {
label "${build_node}"
}
}
steps {
dir("${work_dir}"){
sh """
git tag ${branch_name}_${image_version}
git push origin ${branch_name}_${image_version}
"""
}
sh """
rm -fr ${work_dir}
"""
}
}
}
post {
always {
echo 'I have finished'
}
success {
sh """
echo "@${build_user} build_docker notify: ${gitlab_repo}/${branch_name}:${image_version}, succeed!"
"""
}
failure {
sh """
echo "@${build_user} build_docker notify: ${gitlab_repo}/${branch_name}:${image_version}, failed!"
"""
}
}
}
deploy_kubectl job 如下：
1）图1主要参数
deploy 流程中，我们一般提供用户命名空间选项、deployment_name选项、docker repo 、docker image tag、container名称等选项即可
2）图2执行结果
3）pipeline script
namespace = "${params.namespace}"
deployment_name = "${params.deployment_name}"
dockerhub_repo = "${params.dockerhub_repo}"
image_version = "${params.image_version}"
container_name = "${params.container_name}"
build_node = 'knode-pc'
default_description = "${namespace}/${deployment_name} ${image_version}"
currentBuild.description = "${default_description}"
pipeline {
agent {
node {
label "$build_node"
}
}
stages {
stage('check-deploy') {
agent {
node {
label "$build_node"
}
}
steps {
echo "Hello, check deployment ${namespace}/${deployment_name} exists"
sh "/usr/bin/kubectl --kubeconfig /home/xg/.kube/config -n ${namespace} get deploy ${deployment_name}"
}
}
stage('deploy') {
agent {
node {
label "$build_node"
}
}
steps {
echo 'Hello, deploy to k8s'
sh """
/usr/bin/kubectl --kubeconfig /home/xg/.kube/config -n ${namespace} set image deployment/${deployment_name} ${container_name}=ccr.ccs.tencentyun.com/${dockerhub_repo}:${image_version}
"""
}
}
}
post {
always {
echo 'I have finished'
}
success {
sh """
echo "curl deploy_kubectl: ${namespace}/${deployment_name} ${image_version}, succeed!"
"""
}
failure {
echo "${namespace}/${deployment_name} ${image_version}, failed!"
sh """
echo "curl deploy_kubectl notify: ${namespace}/${deployment_name} ${image_version}, failed!"
"""
}
}
}
此处为了使文档相对简洁，暂未详细介绍 jenkins 相关内容，若有需要可参考笔者 jenkins 相关博文：
docker笔记3–配置jenkins
Devops - cicd 01-08 系列文章
本方案主要使用 build_docker 来构建镜像，然后通过 deploy_helm 将镜像发布到集群，以下为相关参数和 jenkins script脚本说明。
build_docker job 直接复用上面的流程，此处就不再单独介绍了。
deploy_helm job 如下：
1）图1主要参数
deploy_helm 流程中，我们一般提供用户 app name选项、命名空间选项、镜像版本选项、服务环境选项(用于区分不同的 {deploy_env}-values.yaml)
2）图2执行结果
3）pipeline script
helm_app_name = "${params.helm_app_name}"
namespace = "${params.namespace}"
deployment_name = "${params.helm_app_name}"
version = "${params.version}"
deploy_env = "${params.deploy_env}"
build_node = 'knode-pc'
repo_url = "git@xx.xx.xx.xx:root/sre-helm.git"
import java.text.SimpleDateFormat;
def createVersion() {
def dateUnix = ((new Date().time + 0) / 1000).intValue()
Date dateObj = new Date( ((long)dateUnix) * 1000 )
String ymd = new SimpleDateFormat("yyyy.MM.dd-HHmm").format(dateObj)
return "${ymd}"
}
ymd = createVersion()
image_version = createVersion()
work_dir = "deploy-helm-${image_version}"
build_user=""
node{
wrap([$class: 'BuildUser']) {
build_user = env.BUILD_USER
}
}
println("build_user=${build_user}")
default_description = "${build_user} ${namespace}/${deployment_name} ${version}"
currentBuild.description = "${default_description}"
pipeline {
agent {
node {
label "${build_node}"
}
}
stages {
stage('check-deploy') {
agent {
node {
label "${build_node}"
}
}
steps {
echo 'Hello, check deployment exists'
sh """
helm --kubeconfig /home/xg/.kube/config -n ${namespace} status ${deployment_name}
"""
}
}
stage("Clone Repo"){
agent {
node {
label "${build_node}"
}
}
steps {
dir("${work_dir}"){
deleteDir()
git(
url: "${repo_url}",
credentialsId: '73d34b09-yourCredentialsId-142643489274',
branch: "helm"
)
sh """
pwd && ls -la
"""
}
}
}
stage('deploy') {
agent {
node {
label "${build_node}"
}
}
steps {
echo 'Hello, deploy to k8s'
dir("${work_dir}"){
sh """
helm --kubeconfig /home/xg/.kube/config upgrade ${deployment_name} ./${deployment_name} -n ${namespace} -f ./${deployment_name}/${deploy_env}-values.yaml --set image.tag=${version}
"""
}
}
}
}
post {
always {
echo 'I have finished'
echo "rm -fr ./${work_dir}"
}
success {
echo "${namespace}/${deployment_name} ${version}, succeed!"
sh """
echo "curl succeed message here"
"""
}
failure {
echo "${namespace}/${deployment_name} ${version}, failed!"
sh """
echo "curl failed message here"
"""
}
}
}
此处为了使文档相对简洁，暂未详细介绍 helm 相关内容，若有需要可参考笔者 helm 相关博文：
k8s笔记7.1–快速入门helm
k8s笔记7.2–搭建私有helm仓库
k8s笔记7.3–基于gitlab、jenkins、helm、k8s的CI/CD
k8s笔记7.4–helm构建无端口类型chart
本方案使用helm chart 的方式将服务部署在集群中，然后使用 zadig 的 ci 和 cd 功能实现服务的构建和部署。
zadig 中提供给用户使用的是工作流，类似于jenkins 中的 job|pipeline，一般只需要给项目提供一个通用的构建部署工作流 和 一个通用的交付物部署工作流即可， 如下图所示。
1）构建部署=服务镜像+发布服务
2）交付物部署=已有镜像发布服务
此处为了使文档相对简洁，暂未详细介绍 zadig 相关内容，若有需要可参考笔者 zadig 相关博文或官方文档：
k8s笔记14–初次体验 开源云原生软件交付平台zadig
核心软件环境：
ubuntu server 18.04
k8s 1.23.6
Jenkins 2.354
zadig 1.12.0 (k8s 1.19.3)
helm v3.6.1
主要参考文档：
jenkins 官方文档
helm 官方文档
zadig官方文档