KOP Upstream Clusters - Lifecycle - Rafay Product Documentation

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

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.

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.