Kubernetes - Jenkins integration

前端 未结 3 619
死守一世寂寞
死守一世寂寞 2021-01-18 07:47

I\'ve bootstrapped with kubeadm Kubernetes 1.9 RBAC cluster and I\'ve started inside a POD Jenkins based on jenkins/jenkins:lts. I would like to try out https://github.com/j

相关标签:
3条回答
  • 2021-01-18 07:54

    The best practice is to launch you Jenkins master pod with the serviceaccount you created, instead of creating credentials in Jenkins

    See example yaml

    0 讨论(0)
  • 2021-01-18 07:58

    The Kubernetes plugin for Jenkins reads this file /var/run/secrets/kubernetes.io/serviceaccount/token. Please see if your Jenkins pod has this. The service account should have permissions targeting pods in the appropriate namespace.

    In fact, we are using Jenkins running outside kubernetes 1.9. We simply picked the default service account token (from default namespace), and put it in that file on the Jenkins master. Restarted ... and the kubernetes token credential type was visible.

    We do have a role and rolebinding though:

    kubectl create role jenkins --verb=get,list,watch,create,patch,delete --resource=pods
    kubectl create rolebinding jenkins --role=jenkins --serviceaccount=default:default
    

    In our case, Jenkins is configured to spin up slave pods in the default namespace. So this combination works.

    More questions (similar): Can I use Jenkins kubernetes plugin when Jenkins server is outside of a kubernetes cluster?

    0 讨论(0)
  • 2021-01-18 08:01

    After some digging it appears that the easiest way to go(without giving extra permissions to the default service account for the name space) is to

    kubectl -n <your-namespace> create sa jenkins
    kubectl create clusterrolebinding jenkins --clusterrole cluster-admin --serviceaccount=<your-namespace>:jenkins
    kubectl get -n <your-namespace> sa/jenkins --template='{{range .secrets}}{{ .name }} {{end}}' | xargs -n 1 kubectl -n <your-namespace> get secret --template='{{ if .data.token }}{{ .data.token }}{{end}}' | head -n 1 | base64 -d -
    

    Seems like you can store this token as type Secret text in Jenkins and the plugin is able to pick it up. Another advantage of this approach compared to overwriting the default service account, as mentioned earlier above is that you can have secret per cluster - meaning you can use one jenkins to connect to for example dev -> quality -> prod namespaces or clusters with separate accounts.

    Please feel free to contribute, if you have a better way to go.

    Regards, Pavel

    For more details you can check: - https://gist.github.com/lachie83/17c1fff4eb58cf75c5fb11a4957a64d2 - https://github.com/openshift/origin/issues/6807

    0 讨论(0)
提交回复
热议问题