Introduction to Kubernetes

As the tech industry grew in terms of workload, microservices and increased usage of containers that work together (where one whole project could have tons of containers), so did the necessity of managing these containers effectively and dealing with the complex environment surrounding it.

This requirement made way for Kubernetes, we define Kubernetes as an open-source (yay!) container orchestration platform for scheduling and automating the deployment, scaling, and management of containerized applications and optimizing the DevOps pipeline as much as possible.

Fun fact 1: Kubernetes is also coined as "K8s", where "8" represents the eight letters between "K" and "s".

Fun Fact 2: Kubernetes-like technology was already being used by top companies like Google, and Kubernetes is built upon that philosophy of running billions of containers a week and combining it with best-of-breed ideas and practices from the open-source community.

Fun Fact 3: Kubernetes is the fastest growing project in the history of open-source software, the first being Linux.

P.S.: This blog will focus more on informational points, rather than a story-telling approach.

Advantages and Features of Kubernetes

1. Cost Savings: It helps in container orchestration savings by automating ecosystem management (including pod and node failures). It also requires fewer API servers and other redundancies.

2. Minimal Downtime and High Availability: By ensuring that the Kubernetes clusters have no single point of failure by replicating Master Nodes/ Control Planes as well as the Worker Nodes.

3. Automated Deployment and Scalability: Kubernetes clusters are configured and can be warmed up to meet demands quickly and cost-effectively based on metrics such as CPU Usage, memory thresholds, etc.

4. Automated rollouts and rollbacks while monitoring application health: To ensure that instances (and services) are still available during updates and process requests without error. Thus, it promotes and almost guarantees zero-downtime deployments.

5. Deploy workloads in multi-cloud environments without vendor lock-ins: Cloud platforms like AWS, Google Cloud, and Azure, all offer straightforward integrations with Kubernetes-based apps. This enhances the portability of your application since Kubernetes follows OCI (Open container initiative) and CRI (Container Runtime Interface) so we don't need to rearchitect our infrastructure.

Kubernetes Architecture

Important terms in the Kubernetes

1. Pods
   Pods are the smallest working unit (Not containers, as in Docker) that generally wrap one container in Kubernetes. They are the most basic deployable object and represent a single instance of a running process/application in the cluster.

2. API Server
   It is the central hub of all the transmissions going on in the Kubernetes cluster. Residing in the Master node, API Server is the point of contact for requests coming from kubectl, keeps the communication with Master Node components such as etcd, Schedulers, Control Manager, and also with the Worker Node components such as the kube-proxy and kubelet and thus it manages cooperation and coordination around the Kubernetes cluster.

3. Kubectl
   Kubectl is the Kubernetes command-line tool that allows us to run commands against the clusters. We can use kubectl to deploy applications, inspect and manage cluster resources, view logs, etc.

4. Controllers
   Controllers act as a non-terminating loop that watches the state of the cluster, then makes or requests changes to bring the current state closer to the desired state. The analogy can be made with a thermostat. 🌡

5. Controller Manager
   It is a daemon that runs and manages the Controller processes. Logically, each Controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process. Controllers can be for Node, Job, Endpoints, Service Account and Token, and more.

6. Schedulers
   Schedulers "schedule" pods to the worker nodes. They are responsible for finding the best Node for the pod based on a 2-step operation named Filtering and Scoring.

7. Etcd
   etcd is a key-value store used to store metadata and backup related data of the entire Kubernetes cluster.

8. Kubelets
   Kubelets are primary "Node agents" that run of each Node. It can register its Node with the API Server of Master Node. It is the technology that applies, creates, updates, and destroys containers on a Kubernetes node.

9. Kube-proxy
   Kube-proxy is a network proxy that runs on each Node of the cluster and maintains network rules on Nodes. These network rules allow network communication to the Pods from network sessions inside as well as outside of the cluster.

10. Kind
    Kind is a part of the Manifest (YAML) file which helps us to define what kind of Kubernetes object do you want to create. They can be Deployment, Services, etc. and helps us run Kubernetes on our local machine, given that Docker is already installed and configured.

11. Service
    Generally, the Pods are ephemeral, thus they get created and terminated as per requirement and every new pod, even if it was restarted, gets a new IP Address. This makes the communication with and between the Pods (for example, frontend pods should not care which backend pod processes their requests) tricky in the long term. Services provide an abstraction over the set of Pods and define the policy by which they can be accessed by providing unique name and (non-ephemeral) IP address and more.

12. Ingress
    It can be said that Services help in internal communication of the Kubernetes clusters. To manage external traffic (typically HTTP/S) coming from outside the cluster to the services within the cluster, we use Ingress and define routing rules on the Ingress resource. We can also give externally-reachable URLs to our Services. Ingress also provide load balancing, SSL termination, and name-based virtual hosting.

13. NodePort
    NodePort publicly exposes a Service on a fixed port number. It lets you access the service from outside your cluster. The NodePort has port range from 30000 to 32767, so you can create up to 2768 services with NodePorts. The NodePort range makes it unlikely to match a service's intended port (for example, 8080 may be exposed as 31010). When used, the cluster's IP address and the NodePort are represented as e.g. 123.123.123.123:31010 .

14. ConfigMap & Secret
    Kubernetes has two types of objects that can inject configuration data into a container when it starts up: ConfigMaps and Secrets. Both ConfigMaps and Secrets store the data in key-value pairs, but the latter is meant for sensitive data that shouldn't be readable to anybody except the particular application.

15. Deployment
    You describe the desired state in a Deployment, and the Deployment Controller (as all controllers do) tries to change the current state to the desired state at a controlled rate. Deployments wrap over ReplicaSets (which wrap over Pods) and thus Deployments help to create, manage, and modify the instances of the pods along with scaling, replicating, handling of update rollouts/rollbacks in a controlled manner, etc.

16. StatefulSet
    StatefulSet manages the deployment and scaling of sets of Pods (similar to Deployments) and also provides a guarantee about the ordering and uniqueness of these Pods. If we want to use storage volumes to provide persistence to our workload, we can integrate them with StatefulSet so that only the specified Pods get reconnected to the storage volumes even if the Pods are restarted or replaced in case of failures (e.g., Pods that are running databases).
    Note: Deployments are for stateless applications (pods are interchangeable), StatefulSets are for stateful applications (each pod has a persistent identifier).

17. ReplicaSet
    ReplicaSets ensure that there is always a stable and specified set of running pods for a specific workload. Its configuration defines the number of identical pods required and restarts or replaces the Pods in case of failures.

18. DaemonSet
    DaemonSet ensures that all (or some specific subset of them) Worker Nodes run one copy of a Pod as defined in our configuration. DaemonSets will even create the pod on new nodes that are

Note: Both ReplicaSet and DaemonSet are also used as mechanisms for scaling in Kubernetes.

Kubernetes Scaling

There are two ways in which Kubernetes' resources are scaled, they can be remembered as PA and CA, where:

• PA: Pod Autoscaling, divided into the philosophies of Horizontal Pod and Vertical Pod Autoscaling. Generally, HPA is the preferred choice out of the two, which focuses on adding or removing pod replicas based on the changing levels of application usage. HPA uses the resource, object, external, and custom metrics to determine how the auto scaling is executed.

• CA: Cluster Autoscaling, changes the number of cluster nodes in a given node pool and thus acts on a layer above the HPA in a way. This adjustment is handled automatically based on the workload's demands and focuses on unschedulable pods and potential rescheduling of pods based on metrics such as inadequate memory, CPU, pod toleration or affinity rules, etc. When scaling down, the CA allows a 10-minute graceful termination duration before forcing a node termination. This allows time for rescheduling the terminating node's pods to another node.

It is recommended to use HPA with Cluster Autoscaler to keep coordination between the scalability of the pods with the behavior of nodes in the cluster.

Helpful Software and Tools for working with Kubernetes

Once you get familiar with Kubernetes. You can use these tools which help with monitoring, dealing with YAML and manifest files, IDEs for Kubernetes, etc.

• Minikube, Kubeadm, Monokle, Lens, Kubescape, Helm, Datree, Teleport, etc.

For the time being, you can also check out this blog for more reference spacelift.io/blog/kubernetes-tutorial .

I plan on making the next articles either specific topic-based or generalized ones. Do share your feedback, any suggestions and critics are welcome :)