天天看點

k8s筆記20--基于 K8S 的 cicd 概述

k8s筆記20--基于 K8S 的 cicd 概述

  • ​​1 介紹​​
  • ​​2 方案實施​​
  • ​​2.1 Jenkins + kubectl + k8s​​
  • ​​2.2 Jenkins + helm + k8s​​
  • ​​2.3 Zadig + helm + k8s​​
  • ​​3 注意事項​​
  • ​​4 說明​​

1 介紹

近年來雲服務|原生發展迅猛,企業上雲已經成為家常便飯。當企業大量服務上雲後,如何在雲上快速部署、更新服務就是一個必須面對的問題。本文結合當下經典方案,分享以下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實戰教程,并将連結更新補充在此處,歡迎有需要的小夥伴關注!

2 方案實施

上述已經介紹了3種主流 k8s cicd 方案的優缺點,此處繼續通過案例進一步詳細說明。

2.1 Jenkins + kubectl + k8s

本方案主要使用 build_docker 來建構鏡像,然後通過 deploy_kubectl 将鏡像釋出到叢集,以下為相關參數和 jenkins script腳本說明。

build_docker job 如下

1)圖1 主要參數

k8s筆記20--基于 K8S 的 cicd 概述

build 流程中,我們一般提供給使用者 git repo名稱、分支、鏡像repo-name 等幾個核心參數即可,也可按需添加附加參數。

2)圖2 執行結果

k8s筆記20--基于 K8S 的 cicd 概述

執行過程中我們可以動态生成鏡像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 = "[email protected]:${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主要參數

k8s筆記20--基于 K8S 的 cicd 概述

deploy 流程中,我們一般提供使用者命名空間選項、deployment_name選項、docker repo 、docker image tag、container名稱等選項即可

2)圖2執行結果

k8s筆記20--基于 K8S 的 cicd 概述

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}
            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 系列文章​​

2.2 Jenkins + helm + k8s

本方案主要使用 build_docker 來建構鏡像,然後通過 deploy_helm 将鏡像釋出到叢集,以下為相關參數和 jenkins script腳本說明。

build_docker job 直接複用上面的流程,此處就不再單獨介紹了。

deploy_helm job 如下:

1)圖1主要參數

k8s筆記20--基于 K8S 的 cicd 概述

deploy_helm 流程中,我們一般提供使用者 app name選項、命名空間選項、鏡像版本選項、服務環境選項(用于區分不同的 {deploy_env}-values.yaml)2)圖2執行結果

k8s筆記20--基于 K8S 的 cicd 概述

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 = "[email protected]: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​​

2.3 Zadig + helm + k8s

本方案使用helm chart 的方式将服務部署在叢集中,然後使用 zadig 的 ci 和 cd 功能實作服務的建構和部署。

zadig 中提供給使用者使用的是工作流,類似于jenkins 中的 job|pipeline,一般隻需要給項目提供一個通用的建構部署工作流 和 一個通用的傳遞物部署工作流即可, 如下圖所示。

k8s筆記20--基于 K8S 的 cicd 概述

1)建構部署=服務鏡像+釋出服務

k8s筆記20--基于 K8S 的 cicd 概述
k8s筆記20--基于 K8S 的 cicd 概述

2)傳遞物部署=已有鏡像釋出服務

k8s筆記20--基于 K8S 的 cicd 概述
k8s筆記20--基于 K8S 的 cicd 概述

3 注意事項

  1. 筆者kubectl 部署服務的時候需要輸入多個參數,包括 deployment 名稱 和 container 名稱,實際上很多使用者不一定會關注容器名稱,是以我們也可以通過 kubectl apply -f app-deploy.yaml 的方式來更新服務,更新過程中通過 shell 将 ymal 中的image tag替換即可。
  2. zadig 既可部署 k8s yaml 項目,也可以 helm chart 項目; 但是部署 yaml 項目的時候通常需要删除後重新部署,部署 helm chart 的時候可以在已有 app 存在的情況下部署,是以實際項目中建議有限使用 helm chart 部署項目。

4 說明