Kubernetes (K8s) is an open-source container-orchestration platform for automating application deployment, management and scaling.
Concepts
1. Kubernetes uses the concepts of pods - an object that consists of one or more containers which share network namespace
2. Kubernetes automates deploying, scaling and managing containerized application on a group (cluster) of (bare metal or virtual) servers, such as ensuring that in case a container within a pod crashes, it will be restarted.
Use case:
A developer needs 5 application containers on a host. The way he can do it using docker is type the command: "docker run <application_name>" individually 5 times, to create 5 containers on the host machine.
What if a production environment requires 200 containers?
If you have an automation script that does run the above command 200 times to create 200 containers, how do you monitor them? How do you ensure the underlying host resources aren't stretched or depleted?
K8s to the rescue! It can deploy, monitor, heal and redeploy containers automatically as needed.
Kubernetes Components
1. API Server - Acts as front end. All talk to API server to interact with K8s cluster
2. Scheduler - Identifies the right node to place the container based on multiple parameters
3. Controller - This is the brain behind orchestration. It takes care of nodes. Handles situation where node becomes unavailable. Also takes care of replications
4. Container Runtime - This is the container runtime which each worker node hosts
5. kubelet - Agent that runs on each node of the cluster and responsible for communication with Master
6. etcd - Reliable key-value store (consider a database) that is fast, secure and reliable. It stores all the data about K8s cluster (configuration etc.)
Master node components:
Kube-apiserver, etcd, controller, schedular
Worker node components:
kubelet, kube-proxy, container runtime
(kube-proxy ensures necessary rules are in place to allow containers in worker nodes to reach each other)
Node : A node is a machine (physical or virtual) on which Kubernetes is installed. This is where containers will be deployed on.
Cluster : A cluster is a group of Nodes. Even if one node fails, you will be able to access your application
Master : A Master is responsible for managing all worker nodes in a cluster. Master is responsible for actual orchestration.
Pod : A Pod is the basic execution unit of a Kubernetes application. It is the smallest and simplest unit in the K8s object model that you create or deploy.
A pod represents processes running on your cluster.
A Pod encapsulates an application's container (in some cases, multiple containers), storage, resources, a unique network identity (IP address), as well as options that govern how the containers should run.
You can deploy multiple containers in a Pod, but those kind of deployments are very rare.
ReplicaSet
A ReplicaSet's purpose is to maintain a stable set of replica pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical pods. Even if you have one pod on a node, the ReplicaSet makes sure that one pod is always available. If something goes wrong with the pods, a new pod will be created by ReplicaSet, thus providing HA. ReplicaSet can span across multiple nodes.
DaemonSet
A DaemonSet runs one copy of your pod on each worker node in the cluster. When a new node is added to the cluster, a copy of the pod is automatically created on the node. When a node is removed, the pod will also be removed. It ensures one copy of the pod is always present on all nodes. The definition file of a DaemonSet is similar to that of a ReplicaSet. The only difference is the "Kind" in the YAML file.
Service
Service is a way to expose an application - running on a set of pods as a network service. The purpose of a service is to group a set of pods to a single resource. You can create many services within a single application. This ensures that you always have access to a group of pods even as they're added or torn down.
Deployments
Deployments provide the capability to upgrade the underlying instances seamlessly using rolling updates, undo changes, pause and resume changes as required.
Inside a deployment, there is a ReplicaSet. Inside a ReplicaSet, there are pods, and inside pods there are containers. The ReplicaSet ultimately creates the pods with the name of Deployment and ReplicaSet. Creating a deployment automatically creates a ReplicaSet within the name of the deployment.
Horizontal Pod Autoscaler
The HPA automatically scales the number of pods in a replication controller, deployment, ReplicaSet or StatefulSet based on standard or custom metrics.
StatefulSet
StatefulSet pods are created and deployed in a sequence. After the first pod is deployed, it must be in a running state for the next pod to be deployed. Each pod is assigned a unique index starting from suffix O and incremented by one. Each Pod thus gets a unique name combined with the StatefulSet name. There are no random names for the Pods. The last instance is deleted first, followed by second, then last, and so on.
Volumes
Docker containers are meant to be transient. This means they last only for a short period of time. They are called upon to process data and then are destroyed once they are finished. The same is true for the data within the container. To persist data within a container, we attach a volume at the time that they are created. Hence, the data processed by the container will stay in this volume even if the container itself is destroyed.
Similar to container data, the pods created are transient in nature. Hence, a volume is attached to the pod so that the data generated or processed by the pod remains, even if the pods are deleted.
Kubernetes supports different types of storage solutions include NFS, ceph, GlusterFS, Flocker, AWS EBS, Azure Disk and others.
Persistent Volumes
Persistent Volumes allows central management of the volumes for pods.
1. Persistent Volume Claims (PVC) - Persistent Volumes is a cluster-wide pool of storage volumes configured by an administrator to be used by users deploying applications on the cluster. The users can select the storage from this pool using Persistent Storage Claims (PVC).
2. Storage Allocation : Persistent Volumes allow the use of a large pool of storage and allow the pods to carve out storage from the pool as and when required.
3. Volume Challenges : When you have a large environment with a lot of pods to be deployed, you will have to configure volume and volume storage for each pod using the definition file. Whenever a change is to be made with respect to volumes or storage, the user will have to make those changes on all of the pods.
Container Network Interface
CNI is a set of standards that define how a plugin should be developed to solve networking challenges in container runtime environments.
Plugin-Based Networking Solution - The goal of CNI is to create a generic plugin-based networking solution for containers.
Comments
Post a Comment