Jenkins基于"kubernetes plugin"与k8s集成,可以使Jenkins slave以pod的形式在k8s集群内部动态构建、运行、销毁等。
通过 jenkinsci/kubernetes-plugin 了解到,Jenkins master既可以运行在k8s集群内,也可运行在k8s集群外,但是Jenkins slave的整个生命周期都是在k8s集群内,并且通过JNLP与Jenkins master连接。
要想Jenkins master在k8s运行,我们必须提前创建StatefulSet、Service、Ingress、ServiceAccount等系列yaml文件进行部署;而实际Jenkins master在生产中先于k8s使用并已独立运行,如果再次在K8S内部部署,那么我们还需进行迁移,增加了工作量。既然"kubernetes plugin"支持Jenkins master在k8s集群外部,那么就不必要再在k8s中创建了
。
下面我们就来详细介绍下jenkins master位于k8s集群外,实现jenkins slave的动态构建,其中有很多细节问题牵扯到docker、k8s的使用问题,我们一一讲解。
IP | 角色 |
---|---|
192.168.3.217 | k8s master |
192.168.3.218 | k8s node |
192.168.3.219 | k8s node |
192.168.3.133 | jenkins master |
由于Jenkins slave运行在k8s集群内,为方便区分我们为其分配devops
的命名空间,日后运维相关的操作都可以在此命名空间中进行。
kubectl create ns devops
Jenkins通过kubernetes-plugin对k8s进行操作,需要在k8s内提前进行rbac授权。为方便管理,我们为其绑定cluster-admin
角色。当然也可以进一步缩小使用权限。
#创建serviceaccounts
kubectl create sa jenkins
#对jenkins做cluster-admin绑定
kubectl create clusterrolebinding jenkins --clusterrole cluster-admin --serviceaccount=devops:jenkins
kubernetes-plugin与k8s连接时,并不是直接使用serviceaccount,而是通过token。因此我们需要获取serviceaccount:jenkins对应的token,而此token是经过base64加密过的,必须解密后才能使用。
# 1.查看sa
# kubectl get sa -n devops
NAME SECRETS AGE
default 1 113m
jenkins 1 19m
# 2.查看secret
# kubectl get sa jenkins -n devops -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: "2020-07-28T08:27:55Z"
name: jenkins
namespace: devops
resourceVersion: "14403390"
selfLink: /api/v1/namespaces/devops/serviceaccounts/jenkins
uid: 43a98176-faa1-43f7-ad91-0352ca2dce2c
secrets:
- name: jenkins-token-44jkm
# 3.获取token,从yaml中得到token
# kubectl get secret jenkins-token-44jkm -n devops -o yaml
...省略...
token: ZXlKaGJHY2lPaUpTV...
...省略...
# 4.token解密
# 由于此token是经过base64加密的,我们需要通过base64解密获取token值
# echo "xxxxxxxx" |base64 -d
获取到的token解密值,需要在Jenkins master中添加为secret text类型的secret,才能被kubernetes-plugin使用。
通过构建时动态生成的Jenkins slave可以看出需要pvc会自动匹配pv,实现/home/jenkins/agent的存储挂载,因此我们需要提前创建pv,否则将会导致Jenkins slave无法成功创建。
注意:以下信息中的jenkins-pv就是我们已经提前传建好的pv。
# 查看pvc
# kubectl describe pvc pvc-jenkins-slave-m4ptp -n devops
Name: pvc-jenkins-slave-m4ptp
Namespace: devops
StorageClass:
Status: Bound
Volume: jenkins-pv
Labels: jenkins=slave
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 15Gi
Access Modes: RWO
VolumeMode: Filesystem
Mounted By: jenkins-slave-m4ptp
Events: <none>
我们在master创建nfs主目录,但是在主目录下通过子目录对k8s中的服务提供存储,这样可以通过子目录对所有服务的资源进行隔离。
注意:此时的accessModes为ReadWriteOnce
,需要和上面pvc的Access Modes: RWO
一致。下面我会演示不一致情况下出现的问题。
# 1.master上创建nfs主目录
mkdir -p /App/nfs
# 2. jenkins子目录作为jenkins slave的工作目录
mkdir -p /App/nfs/jenkins
# 3.nfs服务,还可创建其他子目录可以为其他服务提供目录挂载
# vim /etc/exports
/App/nfs *(rw,no_root_squash,no_all_squash,sync)
# 4.创建pv,这样k8s集群中的服务可自行匹配绑定pv
# vim jenkins-storage.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: jenkins-pv
spec:
persistentVolumeReclaimPolicy: Recycle
capacity:
storage: 15Gi
accessModes:
- ReadWriteOnce
nfs:
server: 192.168.3.217
path: /App/nfs/jenkins
至此我们已经提前将准备工作完成了,后续的操作需要配置Jenkins master了。
注意:
如果此时我们还没有Jenkins master的话,可以参考以下链接在k8s中部署Jenkins master。
https://github.com/jenkinsci/kubernetes-plugin/tree/master/src/main/kubernetes
其中:
由于Jenkins master先于k8s存在并已独立运行,为避免再次在K8S部署而产生的迁移问题,我们将直接使用Jenkins master。
# kubectl cluster-info
Kubernetes master is running at https://192.168.3.217:6443
KubeDNS is running at https://192.168.3.217:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://192.168.3.217:6443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
secret text
凭据,此时我们需要禁用HTTPS证书检查
。devops
,同时serviceaccount也在此空间内。tcp连接
,不要加上http
。通过以上配置,我们使用连接测试
即可测试kubernetes plugin与k8s是否能够正常连接。但是连接成功并不代表后续Jenkins slave就会如愿正常构建,请继续耐心往下看
。
k8s中最小单元为pod,在此我们定义Jenkins slave所在pod的信息。
其中:
devops
命名空间内。容器模板是我们在pod中运行的容器,此处我们可理解为在pod中创建Jenkins slave容器。
当然此处我们也可不配置,kubernetes plugin将会默认使用jenkins/jnlp-slave:alpine
镜像创建。但是kubernetes-plugin官方已停止维护
此镜像,而统一使用jenkins/inbound-agent
。因此我们需要进行重新设置。
其中:
jenkins/inbound-agent
,否则将会出现以下问题:jenkins/inbound-agent
和jenkins/jnlp-slave:alpine
两个镜像,第一个为重写后的实际使用镜像,第二个为默认镜像,导致jenkins-slave无法正常运行,不断重复构建。# kubectl describe pod jenkins-slave-3sgv0 -n devops
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 57s default-scheduler persistentvolumeclaim "pvc-jenkins-slave-3sgv0" not found
Warning FailedScheduling 25s (x5 over 57s) default-scheduler running "VolumeBinding" filter plugin for pod "jenkins-slave-3sgv0": pod has unbound immediate PersistentVolumeClaims
Normal Scheduled 14s default-scheduler Successfully assigned devops/jenkins-slave-3sgv0 to uvmsvr-3-218
Normal Pulled 13s kubelet, uvmsvr-3-218 Container image "jenkins/inbound-agent" already present on machine
Normal Created 12s kubelet, uvmsvr-3-218 Created container jenkins-slave
Normal Started 12s kubelet, uvmsvr-3-218 Started container jenkins-slave
Normal Pulled 12s kubelet, uvmsvr-3-218 Container image "jenkins/jnlp-slave:alpine" already present on machine
Normal Created 12s kubelet, uvmsvr-3-218 Created container jnlp
Normal Started 12s kubelet, uvmsvr-3-218 Started container jnlp
Normal Killing 8s kubelet, uvmsvr-3-218 Stopping container maven
Normal Killing 8s kubelet, uvmsvr-3-218 Stopping container jnlp
jenkins/inbound-agent
即为重写后的镜像,否则默认使用jenkins/jnlp-slave:alpine
。“万事俱备,只欠东风”,接下来我们在Jenkins master上创建普通的流水线来测试下是否能够动态构建Jenkins slave来进行CI/CD。
pipeline {
agent {
label 'jenkins-slave-k8s'
}
stages {
stage('test') {
script {
println "test"
}
}
}
}
通过此流水线来验证Jenkins slave是否动态构建成功。
如果有问题,我们还需进一步排查。下面我将介绍下我所遇到的一些问题。
问题信息的排查主要通过以下三种方式:
kubectl describe pod jenkins-slave-xxx -n devops
Manage Jenkins--System Log--All Logs
docker logs xxxxxx
docker inspect xxxxx
由于Jenkins slave动态构建,一旦构建不成功,则会不断重建。如果手速不够快,将无法捕获有效的错误信息。
现象:
查看pod状态,发现jenkins-slave不断重建
# kubectl get pod -n devops
NAME READY STATUS RESTARTS AGE
jenkins-slave-tsz20 0/2 Pending 0 54s
原因排查:
1.查看失败原因:找不到pvc
# kubectl describe pod jenkins-slave-tsz20 -n devops
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 74s default-scheduler persistentvolumeclaim "pvc-jenkins-slave-tsz20" not found
Warning FailedScheduling 12s (x2 over 74s) default-scheduler running "VolumeBinding" filter plugin for pod "jenkins-slave-tsz20": pod has unbound immediate PersistentVolumeClaims
2.查看pvc:无法创建pvc
# kubectl get pvc -n devops
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-jenkins-slave-v1tw8 Pending
3.查看pv:pvc和pv无法绑定
# kubectl describe pvc pvc-jenkins-slave-v1tw8 -n devops
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal FailedBinding 11s (x4 over 44s) persistentvolume-controller no persistent volumes available for this claim and no storage class is set
原因: 由于pvc无法和pv绑定,无法为Jenkins slave分配存储,导致Jenkins slave创建失败。
具体分析: 从k8s内默认自动创建的jenkins slave 所使用的pvc 以及我们事先建好的pv来看,由于其"Access modes"不匹配将会导致pv和pvc无法绑定,从而使jenkins slave镜像创建不成功。
因此只要保证pv的access mode 和 默认pvc一致为RWO即可,而我当时pv设置为ReadWriteMany
。
# PV信息
# kubectl describe pv jenkins-pv
Name: jenkins-pv
Labels: <none>
Annotations: Finalizers: [kubernetes.io/pv-protection]
StorageClass:
Status: Available
Claim:
Reclaim Policy: Recycle
Access Modes: RWX
VolumeMode: Filesystem
Capacity: 15Gi
Node Affinity: <none>
Message:
Source:
Type: NFS (an NFS mount that lasts the lifetime of a pod)
Server: 192.168.3.217
Path: /App/nfs
ReadOnly: false
Events: <none>
# PVC信息
# kubectl describe pvc pvc-jenkins-slave-m4ptp -n devops
Name: pvc-jenkins-slave-m4ptp
Namespace: devops
StorageClass:
Status: Bound
Volume: jenkins-pv
Labels: jenkins=slave
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 15Gi
Access Modes: RWO
VolumeMode: Filesystem
Mounted By: jenkins-slave-m4ptp
Events: <none>
解决: 将pv的accessModes 设置为ReadWriteOnce。
现象:
通过Jenkins master日志发现报如下信息:
Aug 05, 2020 11:04:52 AM INFO org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch
Waiting for agent to connect (0/100): jenkins-slave-kzxzg
Aug 05, 2020 11:04:53 AM INFO org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch
Waiting for agent to connect (1/100): jenkins-slave-kzxzg
Aug 05, 2020 11:04:54 AM INFO org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher launch
Waiting for agent to connect (2/100): jenkins-slave-kzxzg
在Jenkins master查看node状态:
原因排查:
java -jar agent.jar -jnlpUrl http://jenkins.test.cn/computer/jenkins-slave-p591m/slave-agent.jnlp -secret 6bd8d43952fe6dc199d95aa55cb975ad2ebde2648c2b260e8dfc1ea6a53042cb -workDir "/root"
注意不要加http
ARG version=4.3-7-alpine
FROM jenkins/agent:$version
ARG version
LABEL Description="This is a base image, which allows connecting Jenkins agents via JNLP protocols" Vendor="Jenkins project" Version="$version"
ARG user=jenkins
USER root
COPY jenkins-agent /usr/local/bin/jenkins-agent
RUN chmod +x /usr/local/bin/jenkins-agent &&\
ln -s /usr/local/bin/jenkins-agent /usr/local/bin/jenkins-slave
USER ${user}
ENTRYPOINT ["jenkins-agent"]
镜像默认通过entrypoint启动,通过docker run
直接运行
# docker run jenkins/inbound-agent
two arguments required, but got []
java -jar agent.jar [options...] <secret key> <agent name>
-agentLog FILE : Local agent error log destination
(overrides workDir)
-cert VAL : Specify additional X.509 encoded PEM
certificates to trust when connecting
......输出省略......
可见镜像entrypoint设置的jenkins-agent就是运行类似上文的java -jar agent.jar -jnlpUrl http://jenkins.test.cn/computer/jenkins-slave-p591m/slave-agent.jnlp -secret 6bd8d43952fe6dc199d95aa55cb975ad2ebde2648c2b260e8dfc1ea6a53042cb -workDir "/root"
来连接agent。
再次查看docker ps -a
发现容器的entrypoint被重写为/bin/sh -c cat
,导致默认的jenkins-agent无法运行。
# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c53e446efb44 d7be84a67382 "/bin/sh -c cat" 6 seconds ago Up 5 seconds k8s_jnlp_jenkins-slave-hhx00_devops_246d322a-1bde-4fc8-b436-d0fb3b5b076e_0
解决:
务必将运行的命令
留空,否则会重写镜像的entrypoint,而命令参数
可有可无。
重新设置后,实际此问题仍存在,进一步排查发现:
# 在jenkins slave所在节点上查看容器日志
# docker logs 49f51724e101
Aug 05, 2020 3:06:23 AM hudson.remoting.jnlp.Main createEngine
INFO: Setting up agent: jenkins-slave-z1fqn
Aug 05, 2020 3:06:23 AM hudson.remoting.jnlp.Main$CuiListener <init>
INFO: Jenkins agent is running in headless mode.
Aug 05, 2020 3:06:23 AM hudson.remoting.Engine startEngine
INFO: Using Remoting version: 4.3
Exception in thread "main" java.io.IOException: The specified working directory should be fully accessible to the remoting executable (RWX): /home/jenkins/agent
at org.jenkinsci.remoting.engine.WorkDirManager.verifyDirectory(WorkDirManager.java:249)
at org.jenkinsci.remoting.engine.WorkDirManager.initializeWorkDir(WorkDirManager.java:201)
at hudson.remoting.Engine.startEngine(Engine.java:288)
at hudson.remoting.Engine.startEngine(Engine.java:264)
at hudson.remoting.jnlp.Main.main(Main.java:284)
at hudson.remoting.jnlp.Main._main(Main.java:279)
at hudson.remoting.jnlp.Main.main(Main.java:231)
由此可见/home/jenkins/agent 没有写入权限,由于容器目录是通过pvc绑定pv,因此我们只需将pv的目录192.168.3.217:/App/nfs 的权限改为777,最终问题解决。
通过k8s+jenkins的部署不仅仅是实现了CI/CD的需求,而且让我们发现了一些细节性问题,解决这些问题可以帮助我们更好的了解与使用k8s和docker:
以上问题虽小,但其实是花了很长时间才解决的,在此分享出来,希望对大家有所帮助。