这篇文章主要介绍在K8S上安装Jenkins有哪些常见问题,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
10年建站经验, 成都网站制作、做网站客户的见证与正确选择。创新互联提供完善的营销型网页建站明细报价表。后期开发更加便捷高效,我们致力于追求更美、更快、更规范。最开始用的是jenkins:2.60.3-alpine(这个已经是Jenkins镜像的高版本了),这个版本太低,在安装插件时基本上都不成功,如下图
后来换成jenkins:latest,这个应该是新的吧,结果 版本还是一样的,只不过Linux不是Apline的。
后来终于明白了是镜像错了(而不是版本的问题),是要用Jenkinsci, 而不是Jenkins。我用了当时排在第一位的jenkinsci/jenkins:2.150.1-slim,安装之后,上面的插件错误全部消失了,真不容易。
但当安装Kubernetes Plugin插件时,提示需要 2.150.3(我的是2.150.1),这也太坑了。只好再次重装,这次用的是jenkinsci/jenkins:2.154-slim,还好终于成功了。不过这个其实还是以前的镜像,新的在“jenkins/jenkins”。
错误信息如下:
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"
错误原因是没有建立service account。解决办法是先创建“service-account.yaml”文件,然后运行如下命令:
kubectl create clusterrolebinding service-reader-pod --clusterrole=service-reader --serviceaccount=default:default
再次运行,错误消失。
在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 Authentication required
这就说明URL是好的。
“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”。如下图所示。
填写之后原来的信息没有了,而且出现了“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”。
当使用的镜像文件是“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脚本里,其他两个都会报错。修改了正确的镜像文件之后就运行成功了。
当用以下命令删除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链接:https://github.com/jfeng45/k8sdemo/tree/0.1
注意,本文的程序在0.1(tag)下,这个程序的主分支以后还会修改。
下面是程序的目录结构,黄色部分是与本文有关的配置文件。
以上是在K8S上安装Jenkins有哪些常见问题的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注创新互联行业资讯频道!