Kubernetes: A Synopsis and Introduction

 Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications. It was developed by Google later the project was open-sourced.

Before getting into the details of K8S, a concept of Containerization and Docker is essential, go through my blog on once.

K8s features -

  • Service discovery and load balancing
  • Storage orchestration
  • Automated rollouts and rollbacks
  • Automatic bin packing
  • Self-healing
  • Secret and configuration management

Kubernetes Components

A Kubernetes cluster comprises of — Control Planes and Worker Nodes. Our application runs in its containerized form inside a pod, which is deployed in a node. Each of those nodes, also called Worker Node, is managed by a Control Plane or Master Node which as a whole constitutes a Cluster.

The components of a Master Node / Control Plane -

The components of a Worker Node -

  • kubelet — agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.
  • kube-proxy — maintains network rules on nodes that allow network communication to Pods from network sessions inside or outside of the cluster.
  • container runtime — responsible for running containers.

Kubernetes objects and basic terms

A proper understanding of the objects in the API is essential. Below are the few objects and terms in K8s -

  • Namespace — multiple virtual clusters backed by the same physical cluster used to divide cluster resources between multiple users.
  • Pod — a set of running containers in a cluster that acts as a building unit of K8s.
  • Service — an abstract way to expose an application running on a set of Pods as a network service.
  • Deployment — provides declarative updates to applications and allows you to describe an application’s life cycle — image to be used, pod count, etc.
  • ReplicationController — ensures that a specified number of pod replicas are running at any one time.
  • ReplicaSet — used to maintain a stable set of replica Pods running at any given time.
  • StatefulSets — workload API object used to manage stateful applications.
  • DaemonSet — ensures that all Worker Nodes run a copy of a Pod.
  • Ingress — manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination and name-based virtual hosting.
  • Configmap — used to store non-confidential data in key-value pairs.
  • Secrets — store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys.
  • Job — creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate.
  • CronJob — useful for creating periodic and recurring tasks, like running backups or sending emails.
  • StorageClass — provides a way for administrators to describe the “classes” of storage they offer.
  • PersistentVolume (PV) — a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.
  • PersistentVolumeClaim (PVC) — a request for storage by a user. They consume PV resources and can request specific size and access modes.
  • VolumeSnapshotClass — provides a way to describe the “classes” of storage when provisioning a volume snapshot.

Pods

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

A pod comprises of one or more containers, with shared storage and network resources, and a specification for how to run the containers. Pods are ephemeral in nature, they are created and terminated based on the health of the application deployed in a container.

Pods are of two types — Single container pod and Multi container pod. As the names suggest, these are based on the container count in a pod.

Multi container pod mainly comprises of 2 or more Application containers or a single container with a sidecar container.

SIDECAR CONTAINER IN A MULTICONTAINER POD

Sidecar containers are the containers that runs along with the main container in the pod, extending and enhancing the functionality of main containers without changing it.

Lifecycle of Pod and Containers

Pods follow a defined lifecycle. Whilst a Pod is running, the kubelet is able to restart containers to handle some kind of faults.

There are phases of a pod during its creation -

Below are the status of a pod during creation -

Container restart policies — Always / OnFailure / Never

Three possible container states -

Container Probes

A Probe is a way of checking the health of a container by the kubelet of a node of a K8S cluster, periodically. There can be one of the three results— Success, Failure and Unknown.

Three types of Probes are -

  • Liveness — Checks whether the container is Up or not.
  • Readiness — Checks whether the container is ready for handling any traffics
  • Startup — Checks whether the containerised application has started or not.

Kubectl Usage

Every K8s Objects are created using kubectl — a command-line tool that lets you control Kubernetes clusters. It can take manifest files in YAML, YML, or JSON format as its input for object creation and updating. A manifest file is basically a configuration file.

Let us now see how to use this command to communicate with a cluster.

object creation —

kubectl apply -f ./manifest.yaml
OR
kubectl create -f ./manifest.yaml

view or find resource —

kubectl get nodes
kubectl get pods
kubectl get svc
kubectl get ingress
...

You can refer to kubectl cheat sheet here.

Pod creation using kubectl

Look into the below content of a manifest file named — create-pod.yaml, for creating a Pod containing an nginx server.

apiVersion — Its a K8s api-server supported schema to identify it as a Pod schema.
kind — discloses the type of K8s object, here it is a Pod.
name — Gives a unique name to these objects.
labels — Allows us to give a group name to multiple instances of the Pod.
image — specifies the app build IMAGE file to be used, which is nginx:1.18
port — Provides the port at which the app will run. It is 5000 here.

From the CLI, you have to execute-

kubectl apply -f create-pod.yaml

Since the above configuration is simple enough, a pod can be created using a single kubectl command without manifest file -

Once you execute either of the two above commands you will get a below output-

pod/appA created

Now in order to expose any pod, created in a cluster, to cater traffic to the outer world, a service object is required along with an ingress.

In my other upcoming blogs, I will be discussing Service, Ingress, and many more concepts in detail.

Most of the cloud service providers have K8S services available — 
EKS for AWS, AKS for Azure, and GKE for GCP. Don’t forget to Google and learn about them.

Hope you like it, keep learning!

Important links -

Comments

Popular posts from this blog

Kubernetes : Pod Communications, Deployments and ReplicaSets

Handle errors in Amazon API Gateway from integrated Lambda functions