Skip to main content

Kubernetes Architecture


Kubernetes Architecture and Concepts

Kubernetes mainly consists of :

  1. Master node(Control plane nodes(api-server, kube-scheduler, controller-manager, etcd)

  2. 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 the only component to which etcd talks to. Any user/client, needing access to etcd can only be done via APIs exposed by api-server.
  • kube-controller-manager: Kubernetes manages applications through various controllers. They basically are control loops that operate on the concept of comparing the current status against the desired state. They watch the current cluster state stored in etcd through the kube-apiserver and create, update, and delete resources as necessary. Various kube-controller-manager are : - Node Controller - Deployment Controller - DaemonSet - Replica Set - Replica Controller
  • kube-scheduler: Scheduler is responsible for placing pods on Nodes. A scheduler watches for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, the scheduler becomes responsible for finding the best Node for that Pod to run on. It consider various factors like - The requirement for pods. - Resource availability at Nodes. - Taints / Toleration , Node Affinity, Node Selectors.

Components of Worker Node:
  • kubelet: A Kubelet tracks the state of a pod to ensure that all the containers are running. It provides a heartbeat message every few seconds to the master server. If a replication controller does not receive that message, the node is marked as unhealthy.
  • kube-proxy: The Kube proxy routes traffic coming into a node from the service. It forwards requests for work to the correct containers. The kube-proxy component is a network proxy that runs on each node.

Labels:

Comments

Post a Comment

Popular posts from this blog

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 : Ing...
Post a Comment
Read more

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 b...
Post a Comment
Read more