如何在Kubernetes上安裝和使用Jenkins？

如何在Kubernetes上安裝Jenkins

首先，我們需要安裝Helm，它是Kubernetes的軟件包管理器：

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh -v v2.15.0

 
同樣，我們還需要安裝Tiller，以讓Helm正常運行：
 

$ kubectl -n kube-system create serviceaccount tiller
serviceaccount/tiller created

~/.kube
$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller created

~/.kube
$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/itspare/.helm.

 
完成這些步驟之后，我們需要運行檢查命令，以查看deployment的配置值：
 

$ helm inspect values stable/jenkins > values.yml

 
仔細檢查配置值并在需要的時候進行更改。然后安裝Chart：
 

$ helm install stable/jenkins --tls \
--name jenkins \
--namespace jenkins

 
安裝過程中會有一些關于下一步操作的說明：

注意：

1.  運行以下命令獲取”admin“用戶的密碼：
    

   printf $(kubectl get secret --namespace default my-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

    

2. 在相同的shell中獲取Jenkins URL以訪問這些命令：
    

   export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/component=jenkins-master" -l "app.kubernetes.io/instance=my-jenkins" -o jsonpath="{.items[0].metadata.name}")
   echo http://127.0.0.1:8080
   kubectl --namespace default port-forward $POD_NAME 8080:8080

    
   遵循這些步驟，它們將在http://127.0.0.1:8080 啟動代理服務器。
    

到那里輸入你的用戶名和密碼。你將會擁有自己的Jenkins 服務器：
 

 
不過，請記住，還有許多配置選項尚未修改
  

在默認情況下，服務器會安裝好最基本的插件，如Git和Kubernetes-Jenkins，我們可以根據自己的需要安裝其他插件。

總而言之，使用Helm安裝Jenkins十分輕松。
 

使用K8S擴展CI/CD Jenkins流水線

既然我們已經大致了解CI/CD如何在Kubernetes上運行的，那么我們來看一個在Kubernetes中部署高度可擴展的Jenkins部署的示例用例。人們通常用它（進行了少量修改）來處理基礎結構的CI/CD，開始吧！

使用Jenkins固定發行版

雖然官方Jenkins鏡像很適合入門，但它需要的配置超出了我們的期望。許多用戶會選擇一個固定的發行版，如my-bloody-jenkins（https://github.com/odavid/my-bloody-jenkins ），它提供了一個較為完整的預安裝插件以及配置選項。在可用的插件中，我們使用saml插件、SonarQubeRunner、Maven和Gradle。

它能夠使用以下命令通過Helm Chart安裝：
 

$ helm repo add odavid https://odavid.github.io/k8s-helm-charts
$ helm install odavid/my-bloody-jenkins

 
我們選擇使用以下Dockerfile部署自定義鏡像：
 

FROM odavid/my-bloody-jenkins:2.190.2-161

USER jenkins

COPY plugins.txt /usr/share/jenkins/ref/
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt

USER root

 
其中plugins.txt文件是我們要預安裝到鏡像中的其他插件列表：
 

build-monitor-plugin
xcode-plugin
rich-text-publisher-plugin
jacoco
scoverage
dependency-check-jenkins-plugin
greenballs
shiningpanda
pyenv-pipeline
s3
pipeline-aws
appcenter
multiple-scms
Testng-plugin

 
然后，只要dockerfile發生更改，我們就使用此通用Jenkinsfile來構建master：
 

#!/usr/bin/env groovy

node('generic') {
try {

def dockerTag, jenkins_master

stage('Checkout') {
checkout([
$class: 'GitSCM',
branches: scm.branches,
doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
extensions: [[$class: 'CloneOption', noTags: false, shallow: false, depth: 0, reference: '']],
userRemoteConfigs: scm.userRemoteConfigs,
])

def version = sh(returnStdout: true, script: "git describe --tags `git rev-list --tags --max-count=1`").trim()
def tag = sh(returnStdout: true, script: "git rev-parse --short HEAD").trim()
dockerTag = version + "-" + tag
println("Tag: " + tag + " Version: " + version)
}

stage('Build Master') {
jenkins_master = docker.build("jenkins-master", "--network=host .")
}

stage('Push images') {
docker.withRegistry("https://$env.DOCKER_REGISTRY", 'ecr:eu-west-2:jenkins-aws-credentials') {
jenkins_master.push("${dockerTag}")
}
}

if(env.BRANCH_NAME == 'master') {

stage('Push Latest images') {
docker.withRegistry("https://$env.DOCKER_REGISTRY", 'ecr:eu-west-2:jenkins-aws-credentials') {
jenkins_master.push("latest")
}
}

stage('Deploy to K8s cluster') {
withKubeConfig([credentialsId: 'dev-tools-eks-jenkins-secret',
serverUrl: env.TOOLS_EKS_URL]) {
sh "kubectl set image statefulset jenkins jenkins=$env.DOCKER_REGISTRY/jenkins-master:${dockerTag}"
}
}
}
currentBuild.result = 'SUCCESS'
} catch(e) {
currentBuild.result = 'FAILURE'
throw e
}
}

 
我們所使用的專用集群由AWS中的一些大中型實例組成，用于Jenkins jobs。接下來，我們進入下一個部分。
 

使用專用的Jenkins Slaves和標簽（label）

為了擴展我們的一些Jenkins slaves，我們使用Pod模板并將標簽分配給特定的agent。因此在我們的Jenkinsfiles中，我們可以為jobs引用它們。例如，我們有一些需要構建安卓應用程序的agent。因此，我們引用以下標簽：
 

pipeline {
agent { label "android" }
…

 
并且將使用特定于安卓的pod模板。我們使用這一Dockerfile，例如：
 

FROM dkr.ecr.eu-west-2.amazonaws.com/jenkins-jnlp-slave:latest

RUN apt-get update && apt-get install -y -f --no-install-recommends xmlstarlet

ARG GULP_VERSION=4.0.0
ARG CORDOVA_VERSION=8.0.0

# SDK version and build-tools version should be different
ENV SDK_VERSION 25.2.3
ENV BUILD_TOOLS_VERSION 26.0.2
ENV SDK_CHECKSUM 1b35bcb94e9a686dff6460c8bca903aa0281c6696001067f34ec00093145b560
ENV ANDROID_HOME /opt/android-sdk
ENV SDK_UPDATE tools,platform-tools,build-tools-25.0.2,android-25,android-24,android-23,android-22,android-21,sys-img-armeabi-v7a-android-26,sys-img-x86-android-23
ENV LD_LIBRARY_PATH ${ANDROID_HOME}/tools/lib64/qt:${ANDROID_HOME}/tools/lib/libQt5:$LD_LIBRARY_PATH/
ENV PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/platform-tools

RUN curl -SLO "https://dl.google.com/android/repository/tools_r${SDK_VERSION}-linux.zip" \
&& echo "${SDK_CHECKSUM} tools_r${SDK_VERSION}-linux.zip" | sha256sum -c - \
&& mkdir -p "${ANDROID_HOME}" \
&& unzip -qq "tools_r${SDK_VERSION}-linux.zip" -d "${ANDROID_HOME}" \
&& rm -Rf "tools_r${SDK_VERSION}-linux.zip" \
&& echo y | ${ANDROID_HOME}/tools/android update sdk --filter ${SDK_UPDATE} --all --no-ui --force \
&& mkdir -p ${ANDROID_HOME}/tools/keymaps \
&& touch ${ANDROID_HOME}/tools/keymaps/en-us \
&& yes | ${ANDROID_HOME}/tools/bin/sdkmanager --update

RUN chmod -R 777 ${ANDROID_HOME} && chown -R jenkins:jenkins ${ANDROID_HOME}

 
我們還使用了Jenkinsfile，該文件與上一個文件類似，用于構建master。每當我們對Dockerfile進行更改時，agent都會重建鏡像。這為我們的CI/CD基礎架構提供了極大的靈活性。
 

使用自動伸縮

盡管我們為deployment分配了特定數量的節點，但我們還可以通過啟用cluster autoscaling，來完成更多的事情。這意味著在工作負載增加和峰值的情況下，我們可以增加額外的節點來處理job。目前，如果我們有固定數量的節點，那么我們只能處理固定數量的job。基于以下事實，我們可以進行粗略地估計：每個slave通常分配500ms CPU和256MB內存，并且設置一個很高的并發。這根本不現實。

舉個例子，當你的版本被大幅削減并且需要部署大量微服務時，可能會發生上述情況。然后，大量的job堆積在流水線，造成嚴重的延誤。

在這種情況下，我們可以增加該階段的節點數。例如，我們可以添加額外的VM實例，然后在過程結束時將其刪除。

我們可以在命令行中使用自動伸縮選項來配置“Vertical”或“集群”自動伸縮選項。但是，此方法需要仔細計劃和配置，因為有時會發生以下情況：

1. 越來越多的job達到平穩階段

2. Autoscaler增加新的節點，但是需要10分鐘來進行部署和分配

3. 舊的job已經完成任務，新的job將填補空白，進而減少了對新節點的需求

4. 新節點可用，但需要X分鐘保持穩定且未利用，X由–scale-down-unneeded-time標志定義

5. 同樣的事情每天發生很多次

    

在這種情況下，最好是根據我們的特定需求進行配置，或者只是增加當天的節點數，并在流程結束后將其還原。所有這些都與尋找最佳方法來利用所有資源并使成本最小化有關。

在任何情況下，我們都應該有一個可伸縮且易于使用的Jenkins集群。對于每個job，都會創建一個pod來運行特定的流水線，并在完成后將其銷毀