Architecture of kubernetes
Table of contents
Working with kubernetes
- We create manifest (.yml file)
- Apply this to cluster (to master) to bring into desired state
- Pod runs on node, which is controlled by master
Roles of Master Node
Kubernetes cluster contains containers running on bare metal/ VM instances/ Cloud instances/ all mix
- Kubernetes designates one or more of these as master and all other as workers
- This master is now going to run set of K8s process. These process will ensure smooth functioning of clusters. These processes are called "Control Plane"
- Can be multi-master for high avaliability
- Master runs control plane to run cluster smoothly.
Components of Control Plane (Master)
• Kube-apiserver
• etcd
• kube-scheduler
• Controller-Manager
Kube-apiserver: (for all communications)
- This api-server interacts directly with user (i,e: we apply yaml or json manifest to kube-apiserver)
- This Kube-apiserver is meant to scale automatically as per load
- Kube api-server is front-end of control-plane
etcd:
- stores metadata and status of cluster
- etcd is consistent and high-available store (key-value store)
- source of touch for cluster state
etcd has following features:
• fully replicated: The entire state is available on every node in the cluster
• Secure: Implements automatic TLS with optional client-certificate authentication
• Fast: Benchmarked at 10000 writes per second
Kube-scheduler: (action)
- When users make request for the creation & management of pods, kube-scheduler is going to take action on these requests.
- HAndles Pods creation and management.
- Kube-schedular match/assign any node to create and run pods.
- A schedular watches for newly created pods that have no node assigned for every pod that scheduler discovers, the scheduler becomes responsible for finding best node for that pod to run on.
- Scheduler gets the information for hardware configuration from configuration files and scheduler the pods on nodes accordingly.
Controller-Manager:
- Makes sure actual state of cluster matches to the desired state.
Two possible choices for controller manager:
• If K8s on cloud, then it will be cloud-controller-manager.
• If k8s on non-cloud, then it will be kube-controller-manager
Components on master that run Controller:
• Node-Controller: for checking the cloud provider to determine if a node has been detected in the cloud after it stops responding.
• Route-controller: Responsible for setting up network, routes on your cloud
• Service Controller: Responsible for load balancer on your cloud against services of type load balancer
• Volume Controller: for creating, attaching and mounting volumes and interacting with the cloud provider to orchestrate volume.
Nodes (kubelet and container engine)
Node is going to run 3 important pieces of software/ process
Kubelet:
- Agent running on the node
- Listens to kubernetes master (eg: pod creation request)
- use port 10255
- Send sucess/ fail reports to master
Container Engine: (eg.:Docker)
- Works with kubelets
- Pulling images
- Start/Stop container
- Exposing container on port specified in manifest.
Kube proxy:
- Assign IP to each Pod
- It is requested to assign IP addresses to pods (dynamic)
- Kube-proxy runs on each node & this make sure that each pod will get its own unique IP address
These 3 components collectively consist 'node'.
Pod:
- Smallest Unit in Kubernetes
- Pod is a group of one or more container that deployed together on same host
- A cluster is a group of nodes
- A cluster has at least one worker node and master node
- In kubernetes, the control unit is POD, not Containers
- Consist of one or more tightly coupled container.
- Pod runs on node which is control by master.
- Kubernetes only knows about Pods (does not knows about individual container)
- Cannot start container without a Pod
- One pod ususally contains one container
Multi-container Pods:
- Share access to memory space
- Connect to each other using loaclhost <container port>
- share access to the same volume
- containers within pod are deployed in an all-or-nothing manner
- Entire pod is hosted on the same node (schedular will decide about which node)
Pod Limitations:
- No auto-healing or scaling
- Pod crashes
Higher Level Kubernetes object:
Replication set - auto scaling and auto healing
Deployment - versioning and rollback
service - static (non-ephemeral ) IP and networking
Volume - Non- ephemeral storage
Important (Points):
Kubctl - Single cloud
kubeadm - on premise
kubefed - federated
Some more Resources to check:
https://spacelift.io/blog/kubernetes-architecture
and for more resources on kubernetes go check on spacelift.io and follow Mariusz Michalowski on Linkedin.
Subscribe to my newsletter
Read articles from Shishir Tambe directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Shishir Tambe
Shishir Tambe
Newbie to IT/CS