Kubernetes
Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications.
Contrainer Orchestration Tool, made of thousands of containers (on server, physical machine or virtual environments)
It was originally developed by Google, and is now maintained by the Cloud Native Computing Foundation.
Orchestration Tools advantages
Low down time / High availability
Scalability
Disaster recovery
Others
Cost reduction, less resources required in devops team
Helps with microservice architecture instead of monolithic
Easy to manage multiple containers
Kubernetes Components
Pod
Smallest unit of kubernetes; it is a layer on top of a container. It abstraction over containers.
It is a logical host for one or more containers, which are the actual runtime environments for the applications
A pod is a logical host because it provides a set of shared resources for the containers it contains. This includes things like
network namespace,
IP address (internal, pods can communicate with each other using the ip address), containers don't get ip address
storage volumes
The containers in a pod are treated as a single entity by Kubernetes, and are always scheduled together on the same node. This means that the containers in a pod can communicate with each other using localhost, and share the same network and storage resources.
A pod is also the basic unit of scaling in Kubernetes. When you want to scale an application, you can add or remove replicas of the pod that contains the containers for that application. This allows you to increase or decrease the number of containers running your application, and adjust the capacity of your system to meet the changing demands of your workload.
Service
Static or permanent ip address that can be attached to each pod
Life cycle of a pod and service are not connected. Hence even if the pod dies, when it comes to life again, ip address stays (but internal ip address changes)
Pods communicate with each other using service
Service also acts as load balancer. When replicas are there, service decides where to forward the request.
Ingress
When an application is exposed for external access, we don't want application to be accessible via ip but a domain name. Domain name based requests first go to ingress, which then forward to service for making a connection to the application
ConfigMap
Contains configuration to external application like database or others
External configuration to application, hence we don't need to re-start the application. Changing configmap takes care of connection configuration within application
Secrets
ConfigMap is not encrypted and hence it is risky to put secrets in configmap
Secret is just like configmap, keeps secrets/configurations in base64 encoded form
Volumes
Persistent data, volume mapping; otherwise as the pods die, will lose the data
Attaches physical storage on hardware devise or server to pods
Deployment
Another abstraction on top of pods. Yaml file to give all settings
Apps are deployed with deployment, but database are deployed via statefulness
Statefulset
If we have clones and replicas of data. Then all pods (replicas of db) need to have access to same data. Statefulset ensures reads and writes are synchronised.
Architecture
Kubernetes is built on a microservices architecture, which means that it is composed of small, independent components that can be easily combined and scaled to meet the needs of different applications.
Works on master-slave architecture
Two main part:
Control Plane
Nodes / Workers
At the core of Kubernetes is the control plane, which is responsible for scheduling and managing the state of the various components in the system.
The control plane is made up of several components, including
the API server
The API server is the primary interface for interacting with the Kubernetes control plane, and provides a RESTful API that can be used to manage and configure the system
the controller manager
The controller manager is responsible for managing the state of the various components in the system, such as deployments, replica sets, and services
Node Controller
End-point Controller
Replication Controller
the etcd distributed key-value store
The etcd distributed key-value store is used to store the current state of the system
the scheduler
The scheduler is responsible for assigning work to the various nodes in the cluster
The worker nodes in a Kubernetes cluster are the physical or virtual machines that run the containerized applications.
Each node is managed by the control plane, and is responsible for running the containers assigned to it by the scheduler.
The nodes communicate with the control plane using the Kubernetes API, and can be added or removed from the cluster as needed to handle changes in workload or capacity.
Parts:
Kubelet
The kubelet is responsible for maintaining the desired state of the node, and ensuring that the containers and pods on that node are running and healthy
The kubelet communicates with the Kubernetes control plane to receive instructions about what to run on the node, and then manages the containers and pods on the node to ensure that they are in the desired state, includes
starting and stopping containers,
monitoring their health,
reporting their status to the control plane
The kubelet is also responsible for managing the container runtime on the node, which is the software that is used to run the containers.
Kubernetes supports multiple container runtime options, including Docker, rkt, and others, and the kubelet is responsible for interfacing with the chosen runtime to manage the containers on the node.
Kubeproxy
The kube-proxy is a component that is responsible for implementing the network proxy for services in the cluster.
It provides a way for the containers in a Kubernetes cluster to communicate with each other and with the outside world, by routing traffic to and from the appropriate containers and pods.
The kube-proxy runs on each node in the cluster, and is responsible for configuring the network rules for the services and endpoints on that node. It listens for changes in the Kubernetes API, and updates the network rules accordingly to ensure that traffic is routed to the correct containers.
The kube-proxy uses the iptables utility to implement the network proxy, and can be configured to use either the "userspace" or "iptables" mode. In userspace mode, the kube-proxy process itself handles the network traffic, while in iptables mode, the kube-proxy configures the iptables rules and relies on the Linux kernel to handle the actual network traffic.
Kubernetes Features
Support for rolling updates and rollbacks
Automatic scaling and self-healing
Integration with a wide variety of storage, networking, and other infrastructure services
Kubernetes provides a rich ecosystem of tools and extensions, including
monitoring and logging solutions,
continuous integration and deployment tools
Flow Example
yaml submitted with specifications in the form of key-value pairs (all configuration parameters specified here in the yaml file)
yaml is submitted to the control panel api server
Control panel checks in etcd, information related to version, last deployment etc.
Control manager checks the resources, and deployment related configurations, worker, pod and all information
Scheduler schedules for deployment to a worker node as per control manager instructions
References
Multiple sources readings
Last updated
Was this helpful?