Introduction to Kubernetes
What is Kubernetes?
It is a container orchestrator, that helps in making sure that each container is where it is supposed to be and these containers can work together. It makes sure that the services are running smoothly the way the app developer wants.
What is Container?
Containers are built to deploy smaller services with isolation and consistency. Scalling and deployment is a major bottleneck with monolithic architecture. With container the teams can package up their servcices, all the applications and their dependencies neately, and depending configuration is bundled together. They run at the same way no matter where they run.
Why we need Kubernetes?
With the changes in requirement, addition of new features or code fixes, the application required to be upgraded.
However it is ok to upgrade the container but how it can be done without downtime? How do these container knows how to talk to the other ones? How to debut the issuer and obsecured what is happening?
The answer is Kubernetes. It is all about managing these containers on Virtual Machines or Nodes.
Some major players in Container Orcherastration
- Kubernetes
- Docker Swarm
- Rancher
- Full stack container management plateform
- Install and manage Kubernetes clusters
- Early Docker ecosystem player
- Great user interface and API to interact with clusters
- Enterprise supports
- Users
- Small teams to enterprises
- Support organizations and teams out of box
- Nice user interface and APIs
- Easy to manage infrastructure effectively
- Mesos
- Written in C++, APIs in Java, C++, Python
- Oldest, most stable tool
- Distributed kernel
- Marathon Framework to schedule and execute tasks
- More complicated architecture than Swarm
- Typical Mesos Users
- Larger enterprises
- Projects that requires lots of compute (bid data jobs) or task-oriented workloads
- Driven by developers
- Need an Ops team to manage
- Cloud Specific
- Amazon EC2 Container Service
- Google Anthos
The Kubernetes Architecture
Image <tbd>
The architecture of Kubernetes consists of Cluster, nodes and pods.
What are nodes?
Node is a virtual or physical machine, that you run your workload on. Each node actually contains the service necessary to run pods. The nodes are grouped togeher as a Cluster to run your containerized applications.
There are two types of nodes involved in a Kubernetes architecture.
- Master Node
- Work Node
Master node
It contains API server, Scheduler, Controll Managers, cubeconfig and etcd. Collectively it is called Control Plane.
Control Plane
It is responsibel for handling all the details like exposing an API. This is where the Kubernetes can define and deploy and manage the licycle of the Pod.
API Server
Which handles data validation and configuration for all the API Objects.
Scheduler
Here is where the important decisions are made about where exactly a POD will run. The scheduler can look at the available resources for all the nodes and make sure that a POD goes to a node that can handle it.
Controller Manager
Where the core Kubernetes logics happens. It is responsible for lifecycle management to make sure all the various processes are working correctly.
etcd
It is a key/value store for holding on to all the important cofiguration data that Kubernetes uses.
Work Node
It contains a Kublet, Kube-proxy and container runtime (Docker).
Container runtime
It is used to running containers.
Kubelet
A kubelet is for making sure that everything that should be running is alright. Control Plane interacts with Kubelet to manage the pods on the nodes.
- Communicates with API server to see if pods have been assinged a nodes
- Exectues pod containers via a container engine
- Mounts and runs pod volumes and secrets
- Executes health checks to dentify pod/node status
- Podspec: YAML file that descirbes a pod
- The e takes a set of Podspecs that are provided by the kube-apiserver and ensures that the containers describe in those Podspecs are running and healthy
- Kubelet only manages containers that were created by the API server -- not any container running on the node
Kube-proxy
It is for handling networking.
- Process that runs on all worker nodes
- Reflects services as defined on each node, and can do simple network stream or round-robin forwarding across a set of backends
- Service cluster IPs and ports are currently found through Docker
--link compatible environment variables specifying ports opened by the service proxy. - Three modes of Kube-proxy
- User space mode
- Iptable mode
- Ipvs mode (alpha feature)
- Why these modes are important?
- Services defined against the API server: Kube-proxy watches the API server for the addition and removal of services
- For each new service, Kube-proxy opens a randomly chosen port on the local node
- Connections made to the chosen port are proxied to one of the corresponding back-end pods
What is POD?
A pod is like a collection of multiple container sort of a pseudo application. It could be just one app or it could be multiple different one that needs to work together. The simplest unit that you can interact with. You can create, deploy, and delete pods, and it represents one running process on your cluster.
What is in the Pod?
- your Docker applicaton container
- Storage resources
- Unique network IP
- Options that govern how the container(s) should run
- Pods are,
- Ephemeral, disposable
- Never self-heal, and not restarted by the scheduler by itself
- Never create pods just by themselves
- Always use higher-level constructs
- Pod States
- Pending
- Running
- Succeeded
- Failed
- CrashLoopBackOff
How Kubernetes ensure that the pod should be running in a desired state?
Using the Master Node Controller Manager the desired state is managed by Kubernetes. The controllers are,
- Depoyments
- Replicasets
- Services
- DaemonSets
- Jobs
Benefits of controllers are,
- Application reliablility
- Scaling
- Load Balancing
ReplicaSet
Ensures that a specified numbers of replicas for a pod are running at all times
Deployment
A Deployment controller provides declarative updates for pods and ReplicaSets
Use Cases
- Pod Management: running a ReplicaSet allows us to deploy a number of pods, and check their status as a single unit
- Scaling a ReplicaSet scales out the pods, and allows for the deployment to handle more traffic
- Pause and Resume:
- used with larger changesets
- Pause deployment, make changes, resume deployment
- Status
- Easy way to check the health of pods, and identify issues
DaemonSets
DaemonSets ensure that all nodes run a copy of specific pod.
As nodes are added or removed from the cluster, a DaemonSet will add or remove the required pods.
Jobs
Supervisor process for pods carrying out batch jobs
Run individual processes that run once and comlete successfully
Services
Allow the communication between one set of deployment with another
Use a service to get pods in two deployments to talk to each other.
- Kind of Services
- Internal: IP is only rechable within the cluster
- External: endpoint available through node ip:port called (NodePort)
- Load balancer: Exposes application to the internet with a load balancer (Available with a cloud provider)
Labels
Labels are key/value pairs that are attached to objects like pods, services, and deployments. Labels are for users of Kubernetes to identify attributes for objects.
Labels used with selectors gives you a powerful feature, as it allows you to identify a set of objects.
Selectors
- Equality-based
=Two labels or values of labels should be equal!=The values of the labels should not be equal
- Set-based
- IN: A value should be inside a set of defined values
- NOTIN: a value should not be in a set of defined values
- EXISTS: Determines wether a label exists or not
Namespaces
- Great for large enterprises
- Allows teams to access resources, with accountability
- Great way to divide cluster resources between users
- Provides scope for names-must be unique in the namespace
- "Default" namespace created when you lunch Kubernete.
- Objects placed in "default" namespace at start
- Newer applications install their resources in a different namespace