Once the installation is done and the CloudBees Core cluster is already up and running, then we can easily check the status of the most important CloudBees Core resources: pod,statefulset,svc,ingress,pvc and pv.

In the following sections the expected results of different Kubernetes resources are defined. The definition of each Kubernetes resource was taken from Kubernetes official documentation.

Pods

A pod is the smallest and simplest Kubernetes object, which represents a set of running containers on your cluster. A Pod is typically set up to run a single primary container, although a pod can also run optional sidecar containers that add supplementary features like logging. Pods are commonly managed by a Deployment.

The get pod will provide you current applications running in the cluster. Applications which are currently stopped or not deployed will not appear as a pod of the cluster.

Pods Events

Pod events provide you insights about why a specific pod is failing to start in the cluster. In other words, pod events will tell you the reason why a specific application cannot start or be deployed in the cluster.

The table below summarize the most common pods event which might happen in CloudBees Core.

To get the list of events associated with a given pod you will need to run:

$ kubectl describe pod the_pod_name

For example:

$ kubectl describe pod cjoc-0

Status

Events

Cause

ImagePullBackOff

The image you are using cannot be found in the Docker registry, or when using a private registry there is no secret configured

Node issues

See below. Get node info with kubectl describe nodes

Pending

Insufficient memory

Not enough memory, either increase the nodes or node size in the cluster or reduce the memory requirement of Operations Center (yaml file) or Master (under configuration)

Pending

Insufficient cpu

Not enough CPUs, either increase the nodes or node size in the cluster or reduce the CPU requirement of Operations Center (yaml file) or Master (under configuration)

Pending

NoVolumeZoneConflict

There are no nodes available in the zone where the persistent volume was created, start more nodes in that zone

Pending

CrashLoopBackOff

Find out why the Docker container crashes. The easiest and first check should be if there are any errors in the output of the previous startup, e.g.:

The Xmx or MaxRAM JVM parameters are too high for the container memory, try increasing memory limit

Unknown

This usually indicates a bad node, if there are several pods in that node in the same state. Check with `kubectl get pods --all-namespaces -o wide

StatefulSet

A StatefulSet manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods.

Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

A StatefulSet operates under the same pattern as any other Controller. You define your desired state in a StatefulSet object and the StatefulSet controller makes any necessary updates to get there from the current state.

The product expects these ingresses to be present and so they must not be modified - even to reduce the complexity of scope. Modifying ingresses at the Kubernetes level might produce issues in the product, such as Managed Masters becoming unable to communicate correctly with the Operations Center.

Persistent Volume Claims (PVC)

Persistent volume claims (PVCs) represent the volumes associated which each application running in the cluster.

Expanding Managed Master Disk Space

A Managed Master may run out of disk space when the provisioned storage is insufficient for the users of that master.
Kubernetes persistent volumes are fixed sizes defined when the volume is created.
Expanding the space for a Managed Master requires a restore of the existing Managed Master into a persistent volume for a new (larger) Managed Master.

Use these steps to restore a backup of an existing Managed Master to a new (larger) Managed Master:

Create a restore job on the master to restore from the backup made in step 1

Run the restore job, watch the console output of the job, there will be a link to restart the master after the restore completes

After the expanded master restarts, verify the jobs on it

Create a Support Request

You can call on CloudBees to help resolve your problems.
To do this, submit a support request through CloudBees Zendesk.
In your request, state the problem and the steps to reproduce the problem.
Include support bundles and a cluster description as noted below.

The registered trademark Jenkins® is used pursuant to a sublicense from the Jenkins project and Software in the Public Interest, Inc. Read more at
www.cloudbees.com/jenkins/about.

Apache, Apache Ant, Apache Maven, Ant and Maven are trademarks of
The Apache Software Foundation. Used with permission. No endorsement by
The Apache Software Foundation is implied by the use of these marks.

Other names may be trademarks of their respective owners.
Many of the designations used by manufacturers and sellers
to distinguish their products are claimed as trademarks. Where those
designations appear in this book, and CloudBees was aware
of a trademark claim, the designations have been printed in caps or initial
caps.

While every precaution has been taken in the preparation of this book,
the publisher and authors assume no responsibility for errors or omissions,
or for damages resulting from the use of the information contained
herein.