Simplifying orchestration with Kubernetes
Before jumping to the Kubernetes, we need to understand how’s it get evolved and what the nature and benefit of it.
A lot of people seem confused about what is orchestration , docker and Kubernetes . So here i will try to clear some of those doubts and after this article you will have a clear understanding what is what ! and how is what ! And also am going to share some info about Kubernetes components as well.
What are Containers?
Method of OS virtualization
Contains entire runtime environment, including application code, configurations, and dependencies, libraries and other binaries — and packages them into self-contained building blocks.
- De-couples application from host OS
- Reliably run across different environments
- Development, test, staging, and productions environments
- Containers take up less space than vm’s and start instantly.
Containers vs VM’s
What is orchestration and how Kubernetes helps here
let’s find out : So, let’s assume we are running a simple website backed by DB which is having some feature A,B,C and D and running in 2 VMs and in type of scenario we do not require container orchestration, we can probably manage everything ourself.
Our Dev or customer asked for more enhancements and you have started adding more and more enhancements to the A,B,C and D and now your application keeps on growing and you need more vms and system resource to manage and assume you added some enhancement to B feature but you need to build the whole bundle and deploy it fully , now if something goes wrong in the deployment , it’s bit time consuming to strace why it’s failing although you know you have deployed B feature and you may have to rollback everything to the earlier working version.
Now you decided to go ahead with the container world and split your application into smaller chunks, each responsible for one specific task, maintained by a team, aka. microservices.
You have decomposed the monolith apps to smaller chunks (A,B,C,D) and now if there is some changes to A , you will only build and deploy A and this becomes very useful , incase of doing deployment or rollback.
But there is a catch , once you created the microservices and there are now 4 different containers running in different vms having different network etc…and now the problems arises like :
- Service discovery
- Healthcheck
- Loadbalancers
- Networking
- Auto-[scaling/restart/healing] of containers and nodes
- Storage
- Zero-downtime deploys/ auto rollback and canary testing
This is where container orchestration comes for rescue and become extremely useful and powerful, because they offer a solution for most of those challenges.
So, in other words managing the moving parts between the different nodes and maintaining the state and sanitizing environment is called as orchestration and in technical terms :
- Provisioning and deployment of containers
- Managing multiple containers as one entity — for purposes of availability, scaling, and networking.
Orchestration tools to know about :
Amazon ECS ,Azure Container Service, Cloud Foundry’s Diego, CoreOS Fleet , Docker Swarm, Google Container Engine , Kubernetes , Mesosphere Marathon , nomad, rancher ; let’s find out more on the Kubernetes aka k8's
What is Kubernetes and what it can do ?
- Open source container manager.
- Created by Google for internal use, now open source for anyone
- Kubernetes is a system for auto deploy, scale, and management of containerized application
- Improves reliability
- Continuously monitors and manages your containers
- Will scale your application to handle changes in load
- Better use of infrastructure resources
- Helps reduce infrastructure requirements by gracefully scaling up and down your entire platform
- Coordinates what containers run where and when across your system
- How do all the different types of containers in a system talk to each other?
- Easily coordinate deployments of your system
- Which containers need to be deployed
- Where should the containers be deployed
Kubernetes Architecture
•Basic Architecture
Kubernetes architecture : Masters
The Kubernetes Control Plane.
K8 clusters consists of bunch of master and nodes and here master is consists of multiple moving parts and they all run on a single server . The Kubernetes logic (its “brains”) is a collection of services
- KUBE-APISERVER — our point of entry to everything!
- ETCD/KVSTORE — a highly available key/value store; the “database” of Kubernetes
- KUBE-CONTROLLER-MANAGER — controls everything and core service
- KUBE-SCHEDULER — assigns work to nodes.
KUBE-APISERVER:
- Front-end to the control plane and one and only external facing interface.
- Exposes the API (REST)
- Consumes JSON
Etcd/kvstore:
Since etcd is a critical service, some people deploy it directly on a dedicated cluster (without containers).
- Persistent storage
- Cluster state and config
- Distributed, consistent, watchable
more info — https://coreos.com/etcd/
kube-controller-manager:
It also known as Controller of controllers
- Node controller
- Endpoints controller
- Namespace controller
- Monitors the cluster state via the apiserver and steers the cluster towards the desired state.
kube-scheduler:
- Watches apiserver for new pods
- Assigns work to nodes.
- Workload Requirements can include: general hardware requirements, affinity/anti-affinity, labels, and other various custom resource requirements.
Nodes components:
- kubelet
- kube-proxy
- Container Runtime Engine
Kubelet:
Acts as the node agent responsible for managing the lifecycle of every pod on its host.
- Registers node with cluster
- Watches apiserver
- Instantiates pods
- Reports back to master
- Exposes endpoint on :10255
kube-proxy:
Manages the network rules on each node. Performs connection forwarding or load balancing for Kubernetes cluster services
Load balances across all services and all container in a pod Shares single ip
Pods:
- Containers always run inside of pods
- Pods can have multiple containers
Container Engine:
- Does container management:
- Pulling images
- Starting/stopping container and usually uses docker
- Interacts with them through the CRI — container runtime interface
BIG PICTURE :
- kubectl writes to the API Server.
- API Server validates the request and persists it to etcd.
- etcd notifies back the API Server.
- API Server invokes the Scheduler.
- Scheduler decides where to run the pod on and return that to the API Server.
- API Server persists it to etcd.
- etcd notifies back the API Server.
- API Server invokes the Kubelet in the corresponding node.
- Kubelet talks to the Docker daemon using the API over the Docker socket to create the container.
- Kubelet updates the pod status to the API Server.
- API Server persists the new state in etcd.
Closing notes :
These are the reference , from where i took help for my first medium article.
https://kubernetes.io/docs/home/?path=users&persona=app-developer&level=foundational
