Source:
https://medium.com/the-programm
er/kubernetes-fundamentals-for-ab
solute-beginners-architecture-comp
onents-1f7cda8ea536
Kubernetes Main components:
Kubernetes Cluster contains two types of Nodes
• Master Nodes
• Worker Nodes or Slave Nodes
The worked node component is depicted in the right-side figure
Source:
https://medium.com/the-programm
er/kubernetes-fundamentals-for-ab
solute-beginners-architecture-comp
onents-1f7cda8ea536
Worker Node components
Kubelet:
• It is an agent that runs on each node in the cluster.
• It acts as a channel between the API server and the node.
• It makes sure that containers are running in a Pod and they are healthy.
• It instantiates and executes Pods.
• It watches API Server for work tasks.
• It gets instructions from master and reports back to Masters
Kube-Proxy:
• It is networking component that plays vital role in networking.
• It manages IP translation and routing.
• It is a network proxy that runs on each node in cluster.
• It maintains network rules on nodes. These network rules allow network communication to Pods from inside or outside of cluster.
• It ensure each Pod gets unique IP address.
• It makes possible that all containers in a pod share a single IP.
• It facilitates Kubernetes networking services and load-balancing across all pods in a service.
• It deals with individual host sub-netting and ensure that the services are available to external parties
Container Runtime:
• The container runtime is the software that is responsible for running containers (in Pods).
• To run the containers, each worker node has a container runtime engine.
• It pulls images from a container image registry and starts and stops containers
Kubernetes supports several container runtimes:
• Docker
• containerd
• CRI-O
• Any implementation of the Kubernetes CRI (Container Runtime Interface).
Master Node components
API Server:
• API server exposes the Kubernetes API.
• Entry point for REST/kubectl — It is the front end for the Kubernetes control plane.
• It tracks the state of all cluster components and managing the interaction between them.
• It is designed to scale horizontally.
• It consumes YAML/JSON manifest files.
• It validates and processes the requests made via API
etcd:
• It is a consistent, distributed, and highly-available key value store.
• It is stateful, persistent storage that stores all of Kubernetes cluster data (cluster state and config).
• It is the source of truth for the cluster.
• It can be part of the control plane, or, it can be configured externally.
Scheduler (kube-scheduler):
• It schedules pods to worker nodes.
• It watches api-server for newly created Pods with no assigned node, and selects a healthy node for them to run on.
• If there are no suitable nodes, the pods are put in a pending state until such a healthy node appears.
• It watches API Server for new work tasks.
Controller Manager (kube-controller-manager)
• It watches the desired state of the objects it manages and watches their current state through the API server.
• It takes corrective steps to make sure that the current state is the same as the desired state.
• It is controller of controllers.
• It runs controller processes. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and
run in a single process.
• Some types of controllers are:
• Node controller: Responsible for noticing and responding when nodes go down.
• Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion
• Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
• Service Account & Token controllers: Create default accounts and API access tokens for new namespaces
Master Node components
Cloud Controller Manager
• The cloud controller manager integrates with the underlying cloud technologies in your cluster when the cluster is running in a cloud environment.
• The cloud-controller-manager only runs controllers that are specific to your cloud provider.
• Cloud controller lets you link your cluster into cloud provider’s API, and separates out the components that interact with that cloud platform from
components that only interact with your cluster.
• The following controllers can have cloud provider dependencies:
o Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding.
o Route controller: For setting up routes in the underlying cloud infrastructure.
o Service controller: For creating, updating and deleting cloud provider load balancers.
Other Services
Container Registry
• The container images that Kubernetes relies on are stored in a container registry. This can be a registry you
configure, or a third party registry like
o Docker Hub
o Amazon Elastic Container Registry (ECR)
o Azure Container Registry (ACR)
o Google Container Registry (GCR)
Persistent Storage
Managing the containers that run an application, Kubernetes can also manage application data attached to a
cluster. Kubernetes allows users to request storage resources without having to know the details of the
underlying storage infrastructure.
Underlying Infrastructure
One of Kubernetes’s key advantages is it works on many different kinds of infrastructure. This can be bare
metal servers, virtual machines, public cloud providers, private clouds, and hybrid cloud environments.
Key Kubernetes components
Pods
• A pod is the basic object of Kubernetes. It is in charge of encapsulating containers, storage resources, and internal IPs.
• A node is a worker machine (Vm or physical machine) that has a container runtime environment. This means that a pod runs on a node but can
easily be instantiated on another node (for fault tolerance and high availability reason)
• Pods are meant to be ephemeral in fact Kubernetes can scale the number of these pods to adapt for incoming traffic, consequently creating or
deleting pods on demand.
Services / Ingress
• It is an abstraction that maintains a logical set of pods that accept incoming traffic and expose a service port to access the underlying pods.
Deployments
• Deployments are Kubernetes objects that manage pods. They allow you to deploy a specific version of your application and specify the number of
pods you require for it to be operational.
• When a new version is ready to go live in production, deployment can easily manage this upgrade with no downtime by applying two basic rules:
o maxSurge specifies the maximum number of pods that can be created beyond the desired pod count.
o Max Unavailable specifies the maximum number of pods that can be unavailable during the deployment.
Configmap / Secrets
Configmap is a Kubernetes object that maintains a key value store that can easily be used by other Kubernetes objects such as pod, deployments, and
services.
