Validating Kubernetes requirements

This CloudBees CI requirements validation tool examines your CNCF cluster, mainly Kubernetes, to determine if it meets the known requirements for CloudBees CI. It can not guarantee that CloudBees CI will run successfully on an examined cluster, but it will point out known problems.

It extends Sonobuoy.

Downloading

Download the appropriate package for your operating system:

Unpack the file, and place it in your executable path.

Using

To use the CloudBees CI requirements validation tool, you must have:

kubectl installed
A valid context with overall access (cluster-admin preferred) to the Kubernetes cluster you want to verify
1. To run the CloudBees CI requirements validation tool, using the following command, replacing your.example.com with the domain name for your CloudBees CI installation:
  shell% cloudbees check kubernetes --host-name your.example.com
2. To view other available commands:
  shell% cloudbees check kubernetes --help`

Example

An example of a successful run:

# cloudbees check kubernetes --host-name your.example.com
[OK] Kubernetes Client version is higher or equal to 1.10 - v1.11.5
[OK] Kubernetes client can be created
[OK] Kubernetes server is accessible
[OK] Kubernetes Server version is higher or equal to 1.10 - v1.11.5
[OK] Client and server have same major version - 1
[OK] Client and server have less than 1 minor version difference
[OK] Ingress service exists - nginx-ingress/nginx-ingress-controller
[OK] Ingress has an external address - good.address.amazonaws.com
[OK] Ingress deployment exists - nginx-ingress/nginx-ingress-controller (image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.17.1)
[OK] Host name resolves to ingress external address
[OK] Can access the ingress controller using http
[OK] Can access the ingress controller using https
[OK] Has a default storage class - gp2
[OK] Storage provisioner is supported - gp2
--------------------------
Summary: 14 run, 14 passed

Troubleshooting

DNS misconfigured

A misconfigured DNS that doesn’t point to the external address of the ingress:

[KO] Host name resolves to ingress external address - Unable to resolve bad.example.com (lookup bad.example.com on 10.0.0.1:53: no such host)

Solution: Correct DNS entry to have hostname route to the external address of the ingress controller.

Missing NGINX ingress service

If the NGINX ingress service is not deployed, an error message similar to the following is shown:

[KO] Ingress service exists

Solution: install the NGINX Ingress service using Helm or install the NGINX Ingress service using the Kubernetes Installer.

Certificate problems

Problems with TLS certificates that are preventing HTTPS access:

[KO] Can access the ingress controller using https - Accessing https://id.zone.elb.amazonaws.com/ won't work : Get https://id.zone.elb.amazonaws.com/: x509: certificate is valid for ingress.local, not id.zone.elb.amazonaws.com

[KO] Can access the ingress controller using https - Accessing https://10.0.0.10/ won't work : Get https://10.0.0.10/: x509: cannot validate certificate for 10.0.0.10 because it doesn't contain any IP SANs

Solution: Correct TLS Certificates to support HTTPS at Ingress or at load balancer.

Storage problems

Problem: Unsupported storage type.

[KO] Storage provisioner is supported - Change the default storage to one of these: [ssd]. Or specify supported storage class upon installation.

Solution: Change default storage provisioner for the cluster to a supported type.

Problem: User doesn’t have permission to view storage settings.

[KO] Has a default storage class - A storage class name has to be provided in configuration or dynamic provisioning won't work. failed to load StorageClasses storageclasses.storage.k8s.io is forbidden: User "user" cannot list storageclasses.storage.k8s.io at the cluster scope

Solution: Fix user permissions or change contexts to allow user to examine the storage defaults.