6 Highly Available Clusters
Important:
The software described in this documentation is either in Extended Support or Sustaining Support. See Oracle Open Source Support Policies for more information.
We recommend that you upgrade the software described by this documentation as soon as possible.
This chapter contains high level information about the types of highly available (HA) Kubernetes clusters you can deploy using Oracle Cloud Native Environment.
Kubernetes can be deployed with more than one replica of the control plane node. Automated failover to those replicas provides a more scalable and resilient service. This type of cluster deployment is referred to in this document as an HA cluster.
Important:
To create an HA cluster you need at least three control plane nodes and two worker nodes.
Creating an HA cluster with three control plane nodes ensures
replication of configuration data between them through the
distributed key store, etcd, so your HA cluster is
resilient to a single control plane node failing without any loss of
data or uptime. If more than one control plane node fails, you
should restore the control plane nodes in the cluster from a backup
file to avoid data loss.
Oracle Cloud Native Environment implements the Kubernetes stacked etcd
topology, where etcd runs on the control plane
nodes. For more information on this topology, see the upstream
documentation at:
Load Balancer
An HA cluster needs a load balancer to provide high availability of the control plane nodes. A load balancer communicates with the Kubernetes API Server to maintain high availability of the control plane nodes.
You can use your own load balancer instance, use a load balancer provided by your cloud infrastructure, or have the Platform CLI install a load balancer on the control plane nodes.
For more information about the configuration requirements of the load balancer, see Getting Started.
Highly Available Cluster with External Load Balancer
When you set up an HA cluster to use an external load balancer, the load balancer is used to manage the resource availability and efficiency of your control plane nodes to make sure instances of the Kubernetes API Server on control plane nodes can fail without impacting cluster availability.
If you want to use your own load balancer implementation, it should be set up and ready to use before you perform an HA cluster deployment. The load balancer hostname and port is entered as an option when you create the Kubernetes module.
A load balancer provided by your cloud infrastructure can also be used, for example, an Oracle Cloud Infrastructure load balancer. This should also be set up and ready to use before you create the Kubernetes module.
Highly Available Cluster with Internal Load Balancer
When you set up an HA cluster to use an internal load balancer, the Platform CLI installs NGINX and Keepalived on the control plane nodes to enable the container-based deployment of the load balancer. The internal load balancer configures the native active-active high availability solution for the Kubernetes API server.
NGINX improves the resource availability and efficiency of your control plane nodes to make sure instances of the Kubernetes API server on control plane nodes can fail without impacting cluster availability.
If you use the internal load balancer, you must set aside an IP address on the control plane network to use as a virtual IP address. The Keepalived instance makes sure the virtual IP address is always reachable by monitoring the health of other control plane nodes and appropriating the IP address if a node fails. Keepalived is used to failover automatically to a standby control plane node if problems occur.
As part of deploying the internal load balancer, the
olcne-nginx and keepalived
services are enabled and started on the control plane nodes.