hi，你好！欢迎访问本站！登录
 本站由网站地图腾讯云宝塔系统阿里云强势驱动
当前位置：首页 - 教程 - 杂谈 - 正文 君子好学，自强不息！

在k8s上装置Jenkins及常见问题

2019-11-18杂谈搜奇网40°c
A+ A-

延续集成和布置是DevOps的重要组成部份，Jenkins是一款异常盛行的延续集成和布置东西，近来实验了一下Jenkins，发明它是我一段时刻以来用过的东西中最复杂的。一个可以的原因是它须要与种种别的东西集成才完成使命，而集成的要领又各不相同。在这些东西中，Docker是最简朴的，真的异常好用。K8s比较复杂，最先要花些时刻熟习，但它的团体设想非常合理，一旦搞清中心观点，控制头绪今后，就异常顺遂。它的敕令花样即范例又一致，使得有些敕令本身都能猜出来，这就是好的设想带来的福利。。但Jenkins给人的觉得就是最先的时刻没有设想得很好，背面在不断地打补丁，致使一件事情有好几种差别的做法，对不熟习的人来说莫衷一是。没有一致的作风，到处都是不测，使得悉数体系看起来既复杂又没有章法，固然这也跟它出来的时刻比较长有关。虽然它可以不是最好的，但它是免费的，因而不能请求太高。

因为种种原因，我的Jenkins装置碰到了林林总总的题目，为此我检察了大批的材料。但遗憾的是每个人装置Jenkins的要领都有些差别，很难找到一篇文章能处理一切题目。在我看来，Jenkins的装置有两三个症结的地方，异常轻易失足，肯定要邃晓透辟才胜利。

本文分红两部份，第一部份讲一般装置步骤，假如一切顺遂，就不须要看第二部份了。我只能说祝贺你，你的命运运限太好了。第二部份是讲种种题目及处理办法，这应该是本文最有代价的部份。

第一部份：在 k8s上布置Jenkins

1. 装置在什么地方?

容器化是大势所趋，它不只包含应用顺序的容器化，还包含与之相干的东西的容器化。当把Jenkins布置在K8s上时，Jenkins的主节点会依据状况自动生成子节点（新的容器）来完成使命，使命完毕后会自动烧毁子节点。

我先在Windows上布置了VirtulBox虚机，并用Vagrant来治理虚机，再在虚机上布置了k8s。并经由过程Vagrant设置虚机和宿主机之间的收集共享，如许就可以在宿主机上用游览器直接接见k8s上的Jenkins。别的还要把宿主机的硬盘挂载到Jenkins上，如许Jenkins的物理存储照样在宿主机上，纵然虚机出了题目，一切的设置和数据都不会丧失。

2. 挑选镜像文件

这个看起来不是题目，然则一不留神就轻易失足。我就是因为选错了镜像，致使装置了许多遍，末了才胜利，在本文的第二部份会细致申明。我终究用的镜像文件是“jenkinsci/jenkins:2.154-slim”，厥后发明这个是比较旧的版本，新的镜像 是“jenkins/jenkins:lts”， 但因为已装置胜利了，就没有再换。Jenkins真的很坑人，有三个镜像“Jenkins”，“jenkinsci/jenkins”, "jenkins/jenkins", 个中准确的是"jenkins/jenkins"。

选好镜像今后，可以先运转下面敕令，下载Jenkins镜像文件到当地（虚机上）。

vagrant@ubuntu-xenial:~$ docker pull jenkinsci/jenkins:2.154-slim

3. 装置Jenkins镜像：

在装置之前，须要先把宿主机的Jenkins装置目次挂载到虚机上，如许可以在当地直接操纵Jenkins。
下面是Vagrant的设置文件（Vagrantfile）中的设置，它把宿主机的app目次挂载到虚机的"/home/vagrant/app"。Jenkins就装置在app目次下。

config.vm.synced_folder "app/", "/home/vagrant/app", id: "app"

下面就是在宿主机上装置好了的Jenkins目次

装置Jenkins镜像分红四部份，竖立效劳账户，装置耐久卷，装置布置和装置效劳，须要按递次举行。个中的症结是竖立效劳账户，这个是必需的，没有它不会胜利。不知为何网上的有些文章没有提到它。

效劳账户设置文件（service-account.yaml）：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: service-reader
rules:
  - apiGroups: [""] # "" indicates the core API group
    resources: ["services"]
    verbs: ["get", "watch", "list"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get","list","watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

这里竖立了一个名为“service-reader”的“ClusterRole”，并把特定的权限（比方["get", "watch", "list"]）赋给特定的资本（比方["services"]）。

运转以下敕令，竖立一个名为“service-reader-pod”的集群角色绑定，它的“clusterrole”是“service-reader”，它的名字是“default:default”，个中第一个“default”是名空间（namespace），第二个“default”是效劳账户名字，背面的布置设置文件会援用这个名字（default）。这里因为我没有给Jenkins竖立零丁的名空间，因而它用的默许名空间（“default”）。

kubectl create clusterrolebinding service-reader-pod --clusterrole=service-reader  --serviceaccount=default:default

关于效劳账户的权限定义，请参阅“Kubernetes plugin for Jenkins” .

耐久卷设置文件（jenkins-volumn.yaml）：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: k8sdemo-jenkins-pv
  labels:
    app: k8sdemo-jenkins
spec:
  capacity:
    storage: 1Gi
  # volumeMode field requires BlockVolume Alpha feature gate to be enabled.
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  local:
    path: /home/vagrant/app/jenkins
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - minikube
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: k8sdemo-jenkins-pvclaim
  labels:
    app: k8sdemo-jenkins
spec:
  accessModes:
    - ReadWriteOnce
  # storageClassName: local-storage
  resources:
    requests:
      storage: 1Gi #1 GB

布置设置文件（jenkins-deployment.yaml）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: k8sdemo-jenkins-deployment
  labels:
    app: k8sdemo-jenkins
spec:
  selector:
    matchLabels:
      app: k8sdemo-jenkins
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: k8sdemo-jenkins
    spec:
      serviceAccountName: default # 效劳账户的名字是default
      containers:
        - image: jenkinsci/jenkins:2.154-slim
          name: k8sdemo-jenkins-container
          imagePullPolicy: Never
          ports:
            - containerPort: 8080
            - containerPort: 50000
          volumeMounts:
            - name: k8sdemo-jenkins-persistentstorage
              mountPath: /var/jenkins_home
      volumes:
        - name: k8sdemo-jenkins-persistentstorage
          persistentVolumeClaim:
            claimName: k8sdemo-jenkins-pvclaim

注重，这里援用了效劳账户“default”（serviceAccountName: default）。

效劳设置文件（jenkins-service.yaml）：

apiVersion: v1
kind: Service
metadata:
  name: k8sdemo-jenkins-service
  labels:
    app: k8sdemo-jenkins
spec:
  type: NodePort
  selector:
    app: k8sdemo-jenkins
  ports:
    - port: 8080
      name: http
      protocol : TCP
      nodePort: 30080
      targetPort: 8080
    - port: 50000
      name: agent
      protocol: TCP
      targetPort: 50000

这里面的一个症结点是布置和效劳都暴露了两个容器端口，一个是8080，另一个是50000. “8080”是外部接见Jenkins的端口，“50000”是Jenkins内部集群之间的相互通讯端口。这里的Jenkins集群不须要你搭建，而是Jenkins依据须要自动生成的，因而这两个端口是必需设置的。这里的设置敕令都是比较规范的k8s设置，因而没有细致诠释。

假如你想相识k8s敕令概况（包含Vagrant设置），请参阅“经由过程搭建MySQL控制k8s（Kubernetes）重要观点（上）：收集与耐久卷”.

运转下面敕令竖立Jenkins：

kubectl apply -f jenkins-volume.yaml
kubectl apply -f jenkins-deployment.yaml
kubectl apply -f jenkins-service.yaml

考证装置：

取得Jenkins的Pod名

vagrant@ubuntu-xenial:~$ kubectl get pod
NAME                                           READY   STATUS    RESTARTS   AGE
envar-demo                                     1/1     Running   15         27d
k8sdemo-backend-deployment-6b99dc6b8c-tbl4v    1/1     Running   7          11d
k8sdemo-database-deployment-578fc88c88-mm6x8   1/1     Running   9          16d
k8sdemo-jenkins-deployment-675dd574cb-bt7rx    1/1     Running   2          24h

检察Jenkins日记

vagrant@ubuntu-xenial:~$ kubectl logs k8sdemo-jenkins-deployment-675dd574cb-bt7rx

Running from: /usr/share/jenkins/jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")
Nov 02, 2019 1:33:30 AM org.eclipse.jetty.util.log.Log initialized
INFO: Logging initialized @3749ms to org.eclipse.jetty.util.log.JavaUtilLog

。。。

INFO: Invalidating Kubernetes client: kubernetes null
Nov 02, 2019 1:35:50 AM hudson.WebAppMain$3 run
INFO: Jenkins is fully up and running
--> setting agent port for jnlp
--> setting agent port for jnlp... done

当看到“INFO: Jenkins is fully up and running”，就申明Jenkins已运转好了，Jenkins的第一次启动须要肯定时刻，要耐烦守候。

4. 登录

前面已讲过，你可以在Vagrant里设置宿主机和虚机之间的收集互访，我的虚机的地点是“192.168.50.4”，“30080”是Jenkins效劳的NodePort的对外地点，因而可以用“http://192.168.50.4:30080/” 接见Jenkins。

登录之前先要取得初始口令，你可以在Jenkins的“secrets\initialAdminPassword”目次里取得治理员用户初始口令，我挂载Jenkins的宿主机目次是“E:\app2\kub\app\jenkins”， 因而口令文件是“E:\app2\kub\app\jenkins\secrets\initialAdminPassword”。口令是“072d7157c090479195e0acaa97bc1049”。第一次登录今后，须要从新设置用户和口令。

5. 装置引荐插件

登录今后，先要装置必要的插件才完成悉数装置工程， 直接选“Install suggested plugins”就可以了。

6 装置Kubernetes Plugin

用治理员账户登录 Jenkins主页面后，找到
Manage Jenkins-》Manage Plugins-》Available， 勾选装置“Kubernetes plugin”即可。

下图是装置今后的图：

7. 设置Kubernetes Plugin

用治理员账户登录 Jenkins Master主页面后，找到
Manage Jenkins-》Configure System-》，然后设置Kubernetes Plugin。以下图所示：

这是最重要的一个设置，决议悉数装置的成败。默许的“name”是“Kubernetes“，这个不须要修正，但今后设置Pipelines时要用到。“Kubernetes URL”用 “https://kubernetes.default” 就可以了。设置今后点击“Test Connection”，见到“Connection test successful”就胜利了。

“Jenkins URL”是从外部（从虚拟机而不是宿主机）接见Jenkins的地点。
你可以用以下敕令，找到Kubernetes的“Jenkins Url”：

vagrant@ubuntu-xenial:~$  sudo minikube service k8sdemo-jenkins-service  --url
http://10.0.2.15:30080
http://10.0.2.15:32289

别的一个参数是“Jenkins tunnel”，这个参数是Jenkins Master和Jenkins Slave之间通讯必需设置的，但不晓得为何，网上的许多文章都没提这个参数，也许是Jenkins的版本差别，有些版本可以不须要。

检察容器名

vagrant@ubuntu-xenial:~$ docker ps -a
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS                      PORTS               NAMES
d15e30169568        f793ea0abe00            "/sbin/tini -- /usr/…"   15 minutes ago      Up 15 minutes                                   k8s_k8sdemo-jenkins-container_k8sdemo-jenkins-deployment-675dd574cb-2thn2_default_fb10e438-0231-4fd2-8dbd-d9e2f0bb9d09_0

检察容器地点：

vagrant@ubuntu-xenial:~$ docker inspect d15e |grep _8080
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_ADDR=10.100.3.79",
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP=tcp://10.100.3.79:8080",
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PROTO=tcp",
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PORT=8080",

依据上面信息，Jenkins的地点是“tcp://10.100.3.79:8080”，把8080换成50000就可以了。终究效果是“10.100.3.79:50000”，注重不要增加“http”。

8. 测试Jenkins：

如今Jenkins已悉数装置好了， 下面举行测试。在Jenkins主页面点击“New Item”竖立新项目，以下图所示，输入项目名，然后挑选“Pipeline”。

进入项目设置页面，以下图所示，剧本文件是jenkinsfile-test：

这是最简朴的测试，它直接运用Jenkins主节点(主节点名是master），不须要启动子节点，因而基本上都不会有什么题目。
在Jenkins主页面选项目“test”，然后选“Build Now”运转项目，再到“Console Output”中检察效果以下：

Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/test
[Pipeline] {[Pipeline] stage[Pipeline] { (Run shell)[Pipeline] sh+ echo hello world.
hello world.
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // podTemplate
[Pipeline] End of Pipeline
Finished: SUCCESS

9. 测试子节点：

这是复杂一点的测试，须要启动子节点，这个才真正检测出装置的成败。先竖立一个新的项目“slave-test”。


def POD_LABEL = "testpod-${UUID.randomUUID().toString()}"
podTemplate(label: POD_LABEL, cloud: 'kubernetes', containers: [
    containerTemplate(name: 'build', image: 'jfeng45/k8sdemo-backend:1.0', ttyEnabled: true, command: 'cat'),
    containerTemplate(name: 'run', image: 'jfeng45/k8sdemo-backend:1.0', ttyEnabled: true, command: 'cat')
  ]) {

    node(POD_LABEL) {
        stage('build a go project') {
            container('build') {
                stage('Build a go project') {
                    sh 'echo hello'
                }
            }
        }

        stage('Run a Golang project') {
            container('run') {
                stage('Run a Go project') {
                    sh '/root/main.exe'
                }
            }
        }

    }
}

上面是剧本（jenkins-salve-test）。个中“POD_LABEL”取任何名字都可以（在Kubernetes-plugin 1.17.0 版本今后，体系会自动定名，但之前须要本身取名），“cloud: 'kubernetes'”要与前面定义的“Kubernetes Plugin” 相匹配。它有两个stage，一个是“build”，另一个是“run”。在“podTemplate”里定义了每个stage的镜像（如许背面的stage剧本里就可以援用），这里为了简便把两个镜像设成是一样的。因为是测试，第一个stage只是输出“echo hello”， 第二个运转镜像“jfeng45/k8sdemo-backend:1.0”里的main.exe顺序。

在Jenkins主页面选项目“slave-test”，然后选“Build Now”运转项目，再到“Console Output”中检察效果以下：

Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] node
Still waiting to schedule task
‘testpod-f754a7a4-6883-4be0-ba4f-c693906041ae-fjwqs-kbb7l’ is offline

Agent testpod-f754a7a4-6883-4be0-ba4f-c693906041ae-fjwqs-kbb7l is provisioned from template Kubernetes Pod Template
Agent specification [Kubernetes Pod Template] (testpod-f754a7a4-6883-4be0-ba4f-c693906041ae): 
* [build] jfeng45/k8sdemo-backend:1.0
* [run] jfeng45/k8sdemo-backend:1.0

Running on testpod-f754a7a4-6883-4be0-ba4f-c693906041ae-fjwqs-kbb7l in /home/jenkins/workspace/slave-test
[Pipeline] {
[Pipeline] stage[Pipeline] { (build a go project)
[Pipeline] container[Pipeline] {
[Pipeline] stage
[Pipeline] { (Build a go project)[Pipeline] sh
+ echo heollo
heollo

[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // container
[Pipeline] }

[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Run a Golang project)[Pipeline] container
[Pipeline] {[Pipeline] stage[Pipeline] { (Run a Go project)
[Pipeline] sh
+ /root/main.exe
time="2019-11-03T01:56:59Z" level=debug msg="connect to database "
time="2019-11-03T01:56:59Z" level=debug msg="dataSourceName::@tcp(:)/?charset=utf8"
time="2019-11-03T01:56:59Z" level=debug msg="FindAll()"
time="2019-11-03T01:56:59Z" level=debug msg="user registere failed:dial tcp :0: connect: connection refused"

[Pipeline] }
[Pipeline] // stage

[Pipeline] }
[Pipeline] // container
[Pipeline] }

[Pipeline] // stage
[Pipeline] }
[Pipeline] // node

[Pipeline] }
[Pipeline] // podTemplate

[Pipeline] End of Pipeline
Finished: SUCCESS

运转胜利，测试阶段就完成了。

用剧本来写Pipeline有两种要领，“Scripted Pipleline”和“Declarative Pipleline”，这里用的是第一种要领。概况请见“Using a Jenkinsfile”. “Declarative Pipleline”是新的要领，我在今后的文章里会讲到。这里因为是测试，只需经由过程了就行。

不必需的装置步骤：

另有些装置步骤在某些文章中提到了，但它们只是如虎添翼，不是必需的。假如你的设置涌现了题目，不要怀疑是这些步骤没实行形成的。

  1. 设置名空间（namespace）：
    有些装置步骤为Jenkins设置了零丁的名空间，如许固然更好，但你纵然没有设置也不会涌现题目。
  2. Kubernetes server certificate key：
    有些装置步骤提到要设置“Kubernetes server certificate key ”，但我并没有设置它，也没有影响运转。

第二部份： 常见题目

1. Jenkins版本不对：

最最先用的是jenkins:2.60.3-alpine(这个已是Jenkins镜像的最高版本了），这个版本太低，在装置插件时基本上都不胜利，以下图

厥后换成jenkins:latest，这个应该是最新的吧，效果 版本照样一样的，只不过Linux不是Apline的。

厥后终究邃晓了是镜像错了（而不是版本的题目），是要用Jenkinsci， 而不是Jenkins。我用了当时排在第一位的jenkinsci/jenkins:2.150.1-slim，装置今后，上面的插件毛病悉数消逝了，真不轻易。

2. 不支持Kubernetes Plugin

但当装置Kubernetes Plugin插件时，提醒须要 2.150.3（我的是2.150.1），这也太坑了。只好再次重装，此次用的是jenkinsci/jenkins:2.154-slim，还好终究胜利了。不过这个实在照样之前的镜像，最新的在“jenkins/jenkins”。

3. 不能接见Kubernetes

毛病信息以下：

Forbidden!Configured service account doesn't have access. Service account may have been revoked. User "system:serviceaccount:default:default" cannot get services in the namespace "default"

概况请拜见Kubernetes log, User “system:serviceaccount:default:default” cannot get services in the namespace。

毛病原因是没有竖立service account。处理办法是先竖立“service-account.yaml”文件，然后运转以下敕令：

kubectl create clusterrolebinding service-reader-pod --clusterrole=service-reader  --serviceaccount=default:default

再次运转，毛病消逝。

4. Jenkins URL地点不对

在Jenkins主页面，进入Manage Jenkins-》System Log-》All Jenkins Logs, 毛病信息以下。

SEVERE: http://192.168.50.4:30080/ provided port:50000 is not reachable
java.io.IOException: http://192.168.50.4:30080/ provided port:50000 is not reachable
     at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:303)
     at hudson.remoting.Engine.innerRun(Engine.java:527)
     at hudson.remoting.Engine.run(Engine.java:488)

这个毛病主如果和Kubernetes-plugin设置有关。在Jenkins主页面，进入Manage Jenkins-》Configure System》，在“http://192.168.50.4:30080/configure” 里有两个“Jenkins URL”，不要弄混了。
第一个是“Jenkins Location”下的“Jenkins URL”， 它是宿主机接见Jenkins的地点。

第二个是“Cloud”下的“Jenkins URL”， 它是从虚拟机接见Jenkins的地点。

在上图中，我最先时用的是“http://192.168.50.4:30080/” ，但这个是从宿主机接见Jenkins的Url，不是从虚机内部接见的Url。
你可以用以下敕令，找到Kubernetes的“Jenkins Url”

vagrant@ubuntu-xenial:~$  sudo minikube service k8sdemo-jenkins-service  --url
http://10.0.2.15:30080
http://10.0.2.15:32289

键入以下敕令测试URL。

vagrant@ubuntu-xenial:~$ curl http://10.0.2.15:30080
<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2F'/><script>window.location.replace('/login?from=%2F');</script></head><body style='background-color:white; color:white;'>

Authentication required
<!--
You are authenticated as: anonymous
Groups that you are in:

Permission you need to have (but didn't): hudson.model.Hudson.Read
... which is implied by: hudson.security.Permission.GenericRead
... which is implied by: hudson.model.Hudson.Administer
-->

</body></html>

这就申明URL是好的。

5. 不能衔接slave

“Jenkins Url”改了今后，地点是对的，但照样不通。运转项目时，页面显现以下信息：

“Console Output”（在Jenkins->salve-test->#13中，个中#13是build #）显现以下信息：

Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] node
Still waiting to schedule task
‘testpod-d56038a0-45a2-41d1-922d-2879e3610900-0hr0m-sfv8s’ is offline

厥后发明另有一个参数要填写，就是“Jenkins tunnel”。以下图所示。

概况请见 Kubernetes Jenkins plugin - slaves always offline.

填写今后本来的信息没有了，而且涌现了“Agent discovery successful”，这个信息是本来没有的。但又有新的毛病。
可用以下要领检察体系日记，在Jenkins主页面，挑选Manage Jenkins-》System Log-》All Jenkins Logs, 信息是如许的：

INFO: Agent discovery successful
  Agent address: http://10.0.2.15
  Agent port:    50000
  Identity:      3e:1b:5f:48:f7:5b:f8:6d:ea:49:1d:b9:44:9a:2f:6c
Oct 30, 2019 12:18:51 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Handshaking
Oct 30, 2019 12:18:51 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to http://10.0.2.15:50000
Oct 30, 2019 12:18:51 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: null
java.nio.channels.UnresolvedAddressException
     at sun.nio.ch.Net.checkAddress(Net.java:101)
     at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:622)
     at java.nio.channels.SocketChannel.open(SocketChannel.java:189)
     at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:203)
     at hudson.remoting.Engine.connectTcp(Engine.java:678)
     at hudson.remoting.Engine.innerRun(Engine.java:556)
     at hudson.remoting.Engine.run(Engine.java:488)

它的原因是“JenkinsTunnel”的地点照样不对，可用以下要领找到“Jenkins tunnel”地点：

vagrant@ubuntu-xenial:~$ docker ps -a
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS                      PORTS               NAMES
d15e30169568        f793ea0abe00            "/sbin/tini -- /usr/…"   15 minutes ago      Up 15 minutes                                   k8s_k8sdemo-jenkins-container_k8sdemo-jenkins-deployment-675dd574cb-2thn2_default_fb10e438-0231-4fd2-8dbd-d9e2f0bb9d09_0

vagrant@ubuntu-xenial:~$ docker inspect d15e |grep _8080
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_ADDR=10.100.3.79",
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP=tcp://10.100.3.79:8080",
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PROTO=tcp",
                "K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PORT=8080",

依据上面信息，Jenkins容器地点是“tcp://10.100.3.79:8080”，把8080换成50000就可以了。终究效果是“10.100.3.79:50000”，注重不要增加“http”。
概况请见 What setting to use for jenkins tunnel?

6. 镜像题目

当运用的镜像文件是“k8sdemo-backend：latest”或“k8sdemo-backend：1.0”时，“Console Output”显现毛病以下：

Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] nodeStill waiting to schedule task
All nodes of label ‘testpod-2971e0ce-e023-475f-b0ec-6118c5699188’ are offline
Aborted by admin[Pipeline] // node
[Pipeline] }
[Pipeline] // podTemplate
[Pipeline] End of Pipeline
Finished: ABORTED

检察Pod, 毛病是“ImagePullBackOff”：

vagrant@ubuntu-xenial:~$ kubectl get pod
NAME                                                       READY   STATUS             RESTARTS   AGE
envar-demo                                                 1/1     Running            15         28d
k8sdemo-backend-deployment-6b99dc6b8c-tbl4v                1/1     Running            7          12d
k8sdemo-database-deployment-578fc88c88-mm6x8               1/1     Running            9          17d
k8sdemo-jenkins-deployment-675dd574cb-bt7rx                1/1     Running            2          2d
testpod-2971e0ce-e023-475f-b0ec-6118c5699188-xwwqq-vv59p   2/3     ImagePullBackOff   0          38s

检察镜像：

vagrant@ubuntu-xenial:~$ docker image ls
REPOSITORY                                TAG                 IMAGE ID            CREATED             SIZE
jfeng45/k8sdemo-backend                   1.0                 f48d362fdebf        11 days ago         14.4MB
k8sdemo-backend                           1.0                 f48d362fdebf        11 days ago         14.4MB
k8sdemo-backend                           latest              f48d362fdebf        11 days ago         14.4MB

这里一共有三个“k8sdemo-backend”镜像，它们的“Image ID”都是一样的，之所以有三个是因为我用以下敕令竖立了tag

docker tag k8sdemo-backend jfeng45/k8sdemo-backend：1.0

但竖立了今后，就只有“jfeng45/k8sdemo-backend：1.0”（最晚竖立的）可以用在Jenkins的Pipeline剧本里，其他两个都邑报错。修正了准确的镜像文件今后就运转胜利了。

7. pv和pvc删除慢

当用以下敕令删除pv时，敕令迟迟不能返回。

kubectl delete pv k8sdemo-jenkins-pv

当你检察时，状况（status）显现一直是“Terminating”，但老是不能完毕退出。pvc也是一样。

vagrant@ubuntu-xenial:~$ kubectl get pv
NAME                  CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                              STORAGECLASS   REASON   AGE
k8sdemo-backend-pv    1Gi        RWO            Retain           Bound         default/k8sdemo-backend-pvclaim    standard                13d
k8sdemo-database-pv   1Gi        RWO            Retain           Bound         default/k8sdemo-database-pvclaim   standard                18d
k8sdemo-jenkins-pv    1Gi        RWO            Retain           Terminating   default/k8sdemo-jenkins-pvclaim    standard                6d8h

这个重要原因是用到它们的效劳和布置还在运转，先把效劳和布置删除今后，pv和pvc的删除操纵就立时完毕，顺遂返回了。

源码:

完全源码的github链接

注重，本文的顺序在0.1（tag）下，这个顺序的主分支今后还会修正。

下面是顺序的目次构造，黄色部份是与本文有关的设置文件。

索引：

  1. Kubernetes plugin for Jenkins
  2. 经由过程搭建MySQL控制k8s（Kubernetes）重要观点（上）：收集与耐久卷
  3. Using a Jenkinsfile
  4. Kubernetes log, User “system:serviceaccount:default:default” cannot get services in the namespace
  5. Kubernetes Jenkins plugin - slaves always offline.
  6. What setting to use for jenkins tunnel?
  7. 初试 Jenkins 运用 Kubernetes Plugin 完成延续构建与宣布

本文由博客一文多发平台 OpenWrite 宣布！

人赞 二维码 打赏
  选择打赏方式
微信赞助

打赏

QQ钱包

打赏

支付宝赞助

打赏

  移步手机端
在k8s上装置Jenkins及常见问题
1、打开你手机的二维码扫描APP
2、扫描左则的二维码
3、点击扫描获得的网址
4、可以在手机端阅读此文章
未定义标签

本文来源：搜奇网

本文地址：https://www.sou7.cn/282260.html

关注我们：微信搜索“搜奇网”添加我为好友

版权声明： 本文仅代表作者个人观点，与本站无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。请记住本站网址https://www.sou7.cn/搜奇网。

推荐阅读
更多>>
上一篇 阿里巴巴 Kubernetes 运用治理实践中的履历与经验
下一篇 在非洲运营互联网体系-体系研发进程（中）

发表评论

选填

必填

必填

选填

请拖动滑块解锁
>>