Is Your Cluster Ready for Jenkins X?

In this lesson, we will discuss the risks of using an existing cluster with jx and how we can use compliance tests to check if the existing cluster is ready for Jenkins X.

If you’re reading this, chances are that you do not want to use jx cluster create to create a new cluster that will host Jenkins X. That is OK and even welcome. That likely means that you are already experienced with Kubernetes and that you already have applications running in Kubernetes. That’s a sign of maturity and your desire to add Jenkins X into the mix of whatever applications you are already running there. After all, it would be silly to create a new cluster for each set of applications.

However, using an existing Kubernetes cluster is risky.

Risks involving the usage of an existing cluster

Many people think they are smart enough to assemble their Kubernetes cluster from scratch. The story goes something like:

“We’re so awesome that we don’t need tools like Rancher to create a cluster for us.”

…or better yet…

“We’ll do it with kubeadm.”

Then, after a lot of sweat, we announce that the cluster is operational, only to discover that there is no StorageClass or that networking does not work. If you assembled your own cluster and you want to use Jenkins X inside it, you need to ask yourself whether or not that cluster is set up correctly.

  • Does it have everything we need?
  • Does it comply with standards, or did you tweak it to meet your corporate restrictions?
  • Did you choose to remove StorageClass because all your applications are stateless?
  • Were you forced by your security department to restrict communication between Namespaces?
  • Is the Kubernetes version too old? …

We can answer those and many other questions by running compliance tests.

Before we proceed, we’ll verify whether the cluster we’re hoping to use meets the requirements. Fortunately, jx has a command that can help us. We can run compliance tests and check to see if there is anything suspicious in the results. Among many other things, jx has its own implementation of the Sonobuoy SDK.

What is Sonobuoy?

Sonobuoy is a diagnostic tool that makes it easier to understand the state of a Kubernetes cluster by running a set of Kubernetes conformance tests in an accessible and non-destructive manner.

Sonobuoy supports Kubernetes versions 1.11, 1.12 and 1.13, so keep that in mind before running it in your cluster. In fact, if your Kubernetes cluster is older than 1.11, you likely think that creating a cluster is a one-time deal and that there is nothing to maintain or upgrade.

Given that I do not know whether your cluster complies with Kubernetes specifications and best practices, I cannot guarantee that Jenkins X installation will be successful. Compliance tests should give us that kind of comfort.

Running compliance tests

Before we proceed with the compliance tests, I must warn you that the tests will run for over an hour. Is it worth it? That depends on your cluster. Jenkins X does not need anything special. It assumes that your Kubernetes cluster has the bare minimum and that it complies with Kubernetes standards. If you created it with one of the Cloud providers and you did not stray from the default setup and configuration, you can probably skip running the compliance tests.

On the other hand, if you baked your own Kubernetes cluster, or if you customized it to comply with some corporate restrictions, running compliance tests might be well worth the wait. Even if you’re sure that your cluster is ready for Jenkins X, it’s still a good idea to run them. You might find something you did not know exists or you might see that you are missing things you want to have.

Anyway, the choice is yours. You can run the compliance tests and wait for over an hour, or you can be brave and skip right into the lesson: Install Jenkins X in an Existing Kubernetes Cluster.

Create a free account to view this lesson.

By signing up, you agree to Educative's Terms of Service and Privacy Policy