Skip to main content

Kubernetes Architecture - High Availability Cluster

 

Kubernetes High Availability Cluster: No Single Point of failure


The basic Kubernetes architecture is described in the previous post.

With Kubernetes, we are trying to achieve more reliability to our architecture. But what about the cluster components. So suppose, if we talk about the api-server, if we have only one api-server and if that node crashes, then the complete cluster will fail.

So, in order to make the cluster components redundant, we need to ensure each component have their redundancies.


Basically with high availability, we have two types of cluster :

a) Stacked etcd:


Basically, for any type of cluster(either stacked/external), we need at least 3 etcd instances(since it uses the concept of quoram).

In this cluster, etcd storage is stacked on top of the other components of cluster. Here the local etcd member talks to only local api-server. api-server is exposed to worker-nodes via Load Balancers(like HAProxy).

This approach is simpler to manage than external etcd but it comes with a cost. Suppose if one master(control-plane) node goes down all components including etcd goes down.

Therefore minimum three instances of control-plane nodes are needed.

b) External etcd:


In this type, etcd is setup on different nodes as compared to other components.

Similar to the above-stacked cluster here also, we have control plane nodes like api-server, controller-manager, scheduler are on same nodes with api-server exposed via Load Balancer. But the difference is that etcd is not present on the same nodes. They are present on different nodes and now etcd nodes in the cluster can communicate with each api-server.

This approach decouples the control plane and etcd member. It therefore provides an HA setup where losing a control plane instance or an etcd member has less impact and does not affect the cluster redundancy as much as the stacked HA topology.

However, this approach requires twice the number of hosts as the stacked HA topology. A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster.

Comments

Post a Comment

Popular posts from this blog

Kubernetes Architecture

Kubernetes Architecture and Concepts Kubernetes mainly consists of : Master node(Control plane nodes(api-server, kube-scheduler, controller-manager, etcd) Worker Node(Kubelet + kube-proxy) Components of Master Node: kube-apiserver: This component is responsible for exposing all the APIs by Kubernetes cluster. All components from Master / Worker nodes can communicate with api-server directly, hence acting as an interface b/w master & worker node. Clients authenticate via the API Server and also use it as a proxy/tunnel to nodes and pods (and services). The kube-apiserver is responsible for API validation before the resources are actually generated and saved to the data store. Clients can communicate with the API server either through the kubectl command-line client or through a REST API call. etcd:  etcd is a distributed, highly-available key-value data store. It stores all the information about Pods, Nodes, services, desired / current state for all resources. Kube-apiserver is t
Post a Comment
Read more

Demystifying Kubernetes Networking: Concepts, Components, and Best Practices

Kubernetes has revolutionized the way we manage and deploy containerized applications at scale. One of the key aspects of Kubernetes is its robust networking model, which ensures seamless communication between different components within and outside the cluster. In this blog post, we will dive deep into the world of Kubernetes networking, exploring its core concepts, components, and best practices to help you effectively manage and optimize your Kubernetes clusters.  Kubernetes Networking Concepts      Before diving into the details, let's understand some basic networking concepts in Kubernetes: Pod Network : Each pod in a Kubernetes cluster gets its own unique IP address, which is used for communication between containers within the pod and with other pods in the cluster. Service Network : Kubernetes services are used to expose pods to other pods or external clients. Services get their own IP addresses and can load balance traffic across multiple pods. Ingress : Ingress resources
Post a Comment
Read more