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.
To use the CloudBees CI requirements validation tool, you must have:
A valid context with overall access (cluster-admin preferred) to the Kubernetes cluster you want to verify
To run the CloudBees CI requirements validation tool, using the following command, replacing
your.example.comwith the domain name for your CloudBees CI installation:
shell% cloudbees check kubernetes --host-name your.example.com
To view other available commands:
shell% cloudbees check kubernetes --help`
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
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.
If the NGINX ingress service is not deployed, an error message similar to the following is shown:
[KO] Ingress service exists
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.
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.