Abstract: The disclosure provides migration of control plane nodes across multiple architecture platforms. Embodiments include one or more processors configured to backup data of a source control plane node running on a first host, the first host having a first architecture platform, identify a second architecture platform of a second host, the second architecture platform being different than the first architecture platform, select a first control plane binary of a plurality of control plane binaries based on the first control plane binary being for the second architecture platform, wherein the plurality of control plane binaries are for a plurality of architecture platforms, deploy a target control plane node on the second host using the selected first control plane binary, copy the backed up data to the second host to configured the target control plane node, and run the target control plane node on the second host.

Abstract: The disclosure provides a method for providing a high availability control plane in a container-based cluster. The method generally includes determining a first control plane node is unreachable within a cluster; in response to determining the first control plane node is unreachable, activating a second control plane node previously deployed in the cluster, wherein prior to activing the second control plane node the second control plane node comprises: control plane components, not actively running on the second control plane node, that are configured to manage the other components within the cluster; removing the active control plane node from the cluster; determining a number of inactive control plane nodes associated with the second control plane node is less than a minimum number of inactive control plane nodes; and deploying one or more inactive control plane nodes associated with the second control plane node until the minimum number is reached.

Abstract: The disclosure provides a method for disaster recovery of a containerized workload running on a first host cluster. The method generally includes prior to determining the containerized workload is unreachable at the first host cluster: obtaining a current state of the containerized workload indicating a number of instances of the containerized workload that are running on the first host cluster; storing one or more images associated with the containerized workload on a second host cluster; and configuring the containerized workload at the second host cluster using the obtained current state without launching the containerized workload at the second host cluster; determining the containerized workload is unreachable; and instantiating instances of the containerized workload in the second host cluster using the stored one or more images, a number of the instances being based on the number of instances of the containerized workload that were running on the first host cluster.

Abstract: Techniques for migrating a workload between two container clusters (i.e., source and destination container clusters) that use different processor architectures are provided. In one set of embodiments, these techniques involve implementing a migration container cluster that (1) creates a backup of the workload from the source container cluster, where the backup includes metadata regarding one or more objects or resources of the workload, and (2) restores the backup on the destination container cluster, where the restoring causes a worker node of the destination container cluster to automatically retrieve, from an image repository, a container image for the workload that is specific to the second processor architecture and deploy the container image as a running container on the worker node.