Skip to content

Lifecycle

VM Restart

Scenario

A reboot or restart of the qcow image based VM has occurred due to a power cycle etc. with the underlying hardware

Once the VM goes down, the Controller will detect the missed heartbeat. The Controller will automatically send a notification to Operations and optionally to other recipients.

Typical Steps

  • Restart the VM via OpenStack and ensure VM comes up successfully with the previously attached storage volumes etc.
  • The remaining process is a zero touch, hands off process.

The k8s cluster, the k8s mgmt operator and all configured/deployed customer workloads will become automatically operational. No manual intervention is required by the customer or the infrastructure administrator.

Once the k8s Operator becomes operational, it will reestablish connectivity to the Controller, report its status/health, retrieve new instructions if any. If required, the infrastructure administrator can login into the Web Console to double check the cluster’s health.

Required Time

Assuming there are no issues with the hardware, storage or network, the VM will become operational with the core k8s services and k8s mgmt operator in approximately 2-5 mins.

Server Hardware Failure

Scenario

The server hardware has to be replaced because of hardware failure. This will require the VM to be recreated on a replacement server.

Typical Steps

Let's assume that the customer's expectation is that the replacement k8s cluster needs to be created with the “same name” as the older one. For example, assume the old cluster’s name was "Acme" with "Location = Boston" operating in the VM in the failed server.

  • Delete the "Acme" cluster in Controller.
  • Create a new cluster with the same name i.e. "Acme" in the Controller.
  • Follow the instructions for provisioning a new cluster
  • Once the cluster is operational and healthy, notify the end user to republish their workload to the replacement cluster.

Server Hardware Upgrade

Scenario

The server hardware has to be upgraded and replaced. This requires the VM to be created on the replacement server.

Typical Steps

Let's assume that the customer's expectation is that the replacement k8s cluster needs to be created with the “same name” as the older one. For example, assume the old cluster’s name was "Beta" with "Location = Chicago" operating in the VM in the older server slated for replacement.

  • Delete "Beta" cluster in the Controller.
  • Create a new cluster with the same name i.e. "Beta" in the Controller.
  • Follow the instructions for provisioning the new cluster
  • Once the cluster is operational and healthy, notify the end user to republish their workload to the replacement cluster.