Skip to content

Lifecycle

VM Restart

Scenario

A reboot or restart of the OVA 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. If notifications are enabled, the Controller will automatically send a notification to both Operations and the customer.

Typical Steps

  • Restart the VM via vSphere 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 management 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 management operator becomes operational, it will re-establish 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 management operator in approximately 2-5 minutes.

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 the 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.