Kubernetes

1. Nodes

2. Cluster

3. Master

Components

• API Server - Acts as a frontend for kubernetes. Users, management devices, cli all talk to api server to interact with k8s cluster
• etcd - distributed key value store to store all data used to manage cluster.
• Scheduler - responsible for distributing work or containers across multiple nodes. Looks for newly created containers and assigns them to nodes.
• Controller - responsible to noticing & responding when nodes, containers or end points goes down and bring up nwe containers in such cases.
• Container runtime - the softeare used to run containers.
• kubelet - is an agent that runs on each node in the cluster. it makes sure that the containers are running on nodes as expected.

CRI (Container run time interface)

Initially since docker was very popular & dominant container tool so the kubenetes worked tightly with docker runtime. Then other vendors like rkt (rocket) wanted to come as container runtime for kubernetes. That is when CRI came into the picture.

CRI allows any vendor to work as a container runtime for kubernetes as long as they adhere to OCI (Open container initiatives) standards. OCI - imagespec & runtimespec.

Docker vs ContainerD

• Docker does not follow CRI standards, only follows the imagespec. Docker was still supported with docker shim which was removed later.

• As docker followed imagespec of CRI that’s why docker images are still supported.

• Docker uses containerD as the runtime.

• ConatinerD - being CRI compatible can directly work eith kubernetes as a runtime. Containerd can be used as a runtime on it’s own separate from docker ConatinerD is a separate project out of docker and is part of cncf.

• ctr tool comes with containerd for debugging but is not very friendly.

• Alternative is nerdctl - provides docker like cli for containerD. supports docker compose, newest features in containerD.

• crictl - can be used with all CRI cupported runtime, was built by k8s community. is used for debuging purpose.

PODs

K8s does not directly deploy containers on the worker nodes. The containers are encapsulated into a kubernetes object known as pods. A POD is a single instance of an application. It is the smallest object object you can create in k8s.

We create more pods to scale up and delete existing pods to scale down.

Multi-Container POD - We can have our application container with helper containers in single pod as well.

Kubernetes Components

• Pod

  • This is an abstraction layer on top of the container. This abstraction is there so that you can replace the container runtime technology is you want to.
  • Ideally a pod should have only one container but you can have more than one container also in a pod. Sometime your application container does need helper containers to run the app and that is when a pod can have more than one container inside.

• Node

  • A Node can be physical or virtual machine on the cluster. The conatiners are placed into pod and then run on the node to execute the workload.
  • A node can run multiple pods in it.
  • How do pods communicate with each other? Kubernetes offers a virtual network out of the box where each pod gets it’s own IP address and can communicate with each other using that IP address which is internal IP address and not a public IP.
  • Pods in k8s are ephemeral and when they die, a new Pod is created which gets assigned a new IP. To solve this problem comes the “service” component.

• Service

  • A service is a permanent IP address which can be attached to each pod, so even if a pod dies the service IP address stays the same.
  • One of the type an internal service like db where we don’t want to expose this for public and only need internal communication.
  • When we want our app to be accessible through the browser and for that we need external service which opens communication for external sources for service public requests. It wll have ip address & port for public access like http://124.89.101.2:8080.
  • We want to an external service which can be accessed with domain names like https://howtocoder.com then for that we need next component ingress.

• Ingress

  • It is an entry point in your cluster for the external traffic.
  • It helps you map http & https traffic to different backends based on the rules defined.
  • An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.

• ConfigMap

  • The applications do need configurations like db urls, api endpoints etc which are used. If we keep it in the application container and later when it needs to change then we need to change the configs, rebuild image and again deploy with updated image which could be time consuming.
  • We can store configs like db urls, api endpoits etc in the configMap and that can be applied to the cluster and pods can consume it. And you won’t need to rebuild the containers image.
  • Remember that a ConfigMap object is only used to store non-confidential config data as key value pairs. If the config is confidential like db username. password or api keys then we can use secrects instead.

• Secrets

  • Secrets are similar to ConfigMaps but are specifically intended to hold confidential data like credentials, token, certificate etc.
  • Are stored in base64 encoded format. The base64 encoded strings are recommended as we have binary data like SSL certificates, json files, SSH keys etc which are not human readable anc can cause issue while storing in yaml files.
  • Also allows to store stringdata by specifying the data in the configuration file.
  • We can use the data from configmap & secret inside of application pods using env variables & properties file.

• Volumes

  • Since Pods are ephemeral storage so when pod dies & restarts the data is gone. If we want the data like logs data, db data to be persisted reliably for longterm then we can do that using volume.
  • Think of vollumes as a hard drive which attaches storage to your pod. This storage can be either local machine when cluster is running or remote storage outside of cluster as external reference.
  • This way whenever pod restarts the data will be persisted.

• Deployment

  • In practice We will never be creating pods manually. Because if one pod crashes then the app will be down and we will have to create the second pod.
  • A deployment is a blueprint of the pod and we can define how many replicas we want to have. SO if one of the replica’s pod dies the service will forward the request to the other one and app will still be usable and accessible.
  • We can also scale up and scale down on pods using deployments.
  • Note - we can’t replicate db services using deployments as the db will have a state and all replica’s should have the same shared data storage. Deployment are ideal for stateless apps.
  • For stateful applications if the want the replication feature with state then we need Statefulset and not deployment.

• Statefulset

  • A Statefulset just like deployments will take care of replicating pods, scale up & down and making sure the state is synchronised and no inconsistencies are offered.
  • A statefulset can be used for stateful applications.
  • It’s a common practice to host dbs outside of k8s clusters.