Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Dynamic jenkins slav based on kubernetes

2025-03-09 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/03 Report--

* * CI/CD** based on Jenkins

Since we are going to create a deployment, let's first create a namespace for him.

Kubectl create namespace kube-ops

Then we create a deployment

We use an image called jenkins/jenkins:lts here, which is the official Docker image of jenkins, and then there are some environment variables. Of course, we can also customize an image according to our own needs. For example, we can package some plug-ins in a custom image. Refer to the documentation: https://github.com/jenkinsci/docker, we can use the default official image here. Another thing to note is that we mount the container's / var/jenkins_home directory to a PVC object named opspvc, so we also have to create a corresponding PVC object in advance.

Then we create pvc (pvc.yaml) for him.

For testing convenience, we use nfs to achieve persistent storage.

Then we create this pvc object.

Kubectl apply-f pvc.yaml

We also need to use a serviceAccount:jenkins2 with relevant permissions here. We only give jenkins some necessary permissions. Of course, if you are not familiar with the permissions of serviceAccount, we can bind the sa to a cluster role permission of cluster-admin. Of course, this has certain security risks: (rbac.yaml)

Kubectl apply-f rbac.yaml

In order to facilitate our testing, we expose the web service of Jenkins in the form of NodePort (we will use traefik,nginx-ingress later). It is fixed to port 30005, and we also need to expose a port of agent, which is mainly used for communication between master and slave of Jenkins.

After all the prepared resources are ready, we create the Jenkins service directly:

Kubectl apply-f jenkins2.yaml

When we first created it,

You can see that the Pod is in the Running state, but the READY value is 0, and then we use the describe command to view the details of the Pod:

You can see the above Warning message, the health check did not pass, what is the specific cause? You can learn more by looking at the log:

You can obviously see the error message above, which means that we do not have permission to create files under the home directory of jenkins. This is because the default image uses the user jenkins, while we mount it to the shared data directory of the nfs server through PVC, but it belongs to the root user, so we do not have permission to access this directory. It is also very simple to solve this problem. I just need to reassign our directory permissions under the nfs shared data directory:

Chown-R 1000 / data/k8s/jenkins2

And then we rebuild.

Kubectl delete jenkins2.yaml

Kubectl apply-f jenkins2.yaml

You can see that the status of this pods is normal.

We can access the jenkins service through the IP:30005 port of any node, and we can install and configure it according to the prompts:

On this page, we can go to pod to get the password, or check the password in the log.

Kubectl exec-it jenkins2-6bbb7d9f4c-v9cfd-n kube-ops bash

Then follow the prompts above to get the password.

Then I saw the main page of jenkins.

Don't use the collection yet.

We know that continuous construction and release is an essential step in our daily work. At present, most companies use Jenkins clusters to build CI/CD processes that meet their needs. However, there are some pain points in the traditional Jenkins Slave one-master-multi-slave approach, such as:

When a single point of failure occurs in the main Master, the whole process is unavailable

Each Slave has a different configuration environment to complete the compilation and packaging of different languages, but these differentiated configurations make it very inconvenient to manage and difficult to maintain.

Resource allocation is uneven. Some job to be run by Slave are queued, while some Slave are idle.

There is a waste of resources. Each Slave may be a physical machine or a virtual machine, and when the Slave is idle, the resources will not be completely released.

Because of the above pain points, we yearn for a more efficient and reliable way to complete this CI/CD process, and Docker virtualization container technology can solve this pain point well, especially in the Kubernetes cluster environment. The following is a simple diagram of building a Jenkins cluster based on Kubernetes:

So what are the benefits of using this approach?

The service is highly available. When Jenkins Master fails, Kubernetes automatically creates a new Jenkins Master container and assigns Volume to the newly created container to ensure that data is not lost, thus achieving high availability of cluster services.

Dynamic scaling and rational use of resources. Every time you run Job, a Jenkins Slave,Job is automatically created. After the Slave automatically logs out and deletes the container, the resources are automatically released. Moreover, according to the usage of each resource, Kubernetes dynamically allocates Slave to idle nodes to create them, reducing the situation that a node is queued to wait in the node because of its high resource utilization.

Good scalability, when the serious shortage of resources in the Kubernetes cluster causes the Job to wait in queue, it is easy to add a Kubernetes Node to the cluster to achieve expansion.

Configuration

Next we need to configure Jenkins so that it can generate the Pod of Slave dynamically.

Let's go in to the plug-in management first.

Since I have already installed it, all you need to do is choose kubernetes installation from the optional plugin.

Once installed, we go to the system configuration managed by the system, drag it to the bottom, and select kubernetes

Pay attention to namespace, we fill in kube-ops here, and then click Test Connection. If the Connection test successful message appears, it proves that Jenkins has been able to communicate with the Kubernetes system normally, and then the lower Jenkins URL address: http://jenkins2.kube-ops.svc.cluster.local:8080, where the format is: service name .namespace.svc.cluster.local. Fill in according to the service name of the jenkins created above. Here is the name jenkins that I created earlier. If we used the above, we would have created jenkins2.

In addition, it should be noted that if the Test Connection fails here, it is likely to be a permission problem. Here, we need to add the secret corresponding to the serviceAccount of the jenkins we created to the Credentials here.

Then we configure Pod Template, which is actually configuring the Pod template for Jenkins Slave to run. We also use kube-ops,Labels for namespaces, which is also very important here. We need to use this value for later Job execution, and then we use the cnych/jenkins:jnlp image here, which is customized based on the official jnlp image and added some practical tools such as kubectl.

We delete the commands and command parameters that are run later.

We also need to note that we need to mount two host directories below, one is / var/run/docker.sock, and the file is the Docker of the container in Pod that can share the host. This is what we call docker in docker. We have packaged the Docker binaries into the image above, another directory under the / root/.kube directory. We mounted this directory under the / root/.kube directory of the container so that we could use the kubectl tool in the Pod container to access our Kubernetes cluster, making it easier for us to deploy Kubernetes applications in Slave Pod later.

There is a permission problem when running Slave Pod after configuration. If there is a problem of insufficient permissions, click the advanced below in the Slave Pod configuration, and add the corresponding ServiceAccount:

At this point, our Kubernetes Plugin plug-in is configured.

Then we create a free project.

And then we save it.

We test the build.

At build time, we look at the status of jenkins and create a pod for jnlp.

After the build task is complete, let's take a look at the pod list. There is no pod for this jnlp.

At this point, we have completed the method of dynamically generating Jenkins Slave using Kubernetes.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report