Kubernetes Tutorial for Kubernetes Certification [PART-1]

If you are looking to learn to Kubernetes, you are at the right place; this Kubernetes Tutorial for Kubernetes Certification tutorial will help you gain complete knowledge that you need from basics to becoming a Kubernetes pro.

Kubernetes is more than just management of docker containers as it keeps the load balanced between the cluster nodes, provides a self-healing mechanism such as replacing a new healthy container and many features.

Let’s get started with Kubernetes Tutorial for Kubernetes Certification without further delay.

Join 46 other followers

Table of Content

  1. What is kubernetes?
  2. Why Kubernetes?
  3. Docker swarm vs kubernetes
  4. kubernetes Architecture: Deep dive into Kubernetes Cluster
  5. kubernetes master components or kubernetes master node
  6. Worker node in kubernetes Cluster
  7. Highly Available Kubernetes Cluster
  8. What is kubernetes namespace?
  9. Kubernetes Objects and their Specifications
  10. Kubernetes Workloads
  11. What is a kubernetes Pod? 
  12. Deploying multi container Pod
  13. Conclusion

What is kubernetes?

Kubernetes is an open-source Google-based container orchestration engine for automating deployments, scaling, and managing the container’s applications. It is also called k8s because eight letters are between the “K” and the “s” alphabet.

Kubernetes is portable and extensible which supports declarative as well as automatic approaches.

Kubernetes also helps in service discovery, such as exposing a container using the DNS name or using their own IP address, provides a container runtime, zero downtime deployment capabilities, automatic rollback, automatic storage allocation such as local storage, public cloud providers, etc.

Kubernetes has the ability to scale when needed, which is known as AutoScaling. You can automatically manage configurations like secrets or passwords and mount EFS or other storage when required.

Why Kubernetes?

Now that you have a basic idea about what is Kubernetes. Earlier applications used to run on the physical server that had issues related to resource allocation, such as CPU memory. You would need more physical servers, which were too expensive.

To solve the resource allocation issue, virtualization was adopted in which you could isolate applications and align the necessary resources as per the need. With virtualization, you can run multiple virtual machines running from single hardware, allowing better utilization of resources and saving hardware costs.

Later, the containerizations-based approach was followed, such as docker and after Kubernetes, which is light-weighted and allowed portable deployments in which containers share the same OS, CPU, and memory from the host but have their own file systems and can launch anywhere from local machines or on cloud infrastructure.

Finally, Kubernetes takes care of scaling and failover for your applications and easily manages the canary deployment of your system.

Some of the key features of Kubernetes are:

  • Kubernetes exposes a container using a DNS name or using an IP address.
  • Kubernetes allows you to mount storage system of your choice such as local storage, public cloud providers and more.
  • You can rollback the state anytime for your deployments.
  • Kubernetes replaces containers that fails or whose health check fails.
  • Kubernetes allows you to store secrets and sensitive information such as passwords, OAuth tokens and SSH keys. Also you can update the secret information multiple times without impacting container images.

Every Kubernetes object contains two nested objects (object spec and object status) whee spec describes the description of the object you set and status shows

Physical Server to Virtualization to Containerization
Physical Server to Virtualization to Containerization

Docker swarm vs kubernetes

In previous sections, you learned what Kubernetes is and why there is a shift from physical to virtual machines and towards docker, the container-based technology.

Docker is a light weighted application that allows you to launch multiple containers. Still, to manage or orchestrate the containers, you need orchestration tools such as the Docker swarm or the Kubernetes.

Let’s look at some of the key differences between Docker swarm vs Kubernetes.

Docker SwarmKubernetes
Docker swarm use YAML files and deploy on nodesUsers can encrypt data between nodes.
Users can encrypt data between nodesAll Pods can interact with each other without encryption
Kubernetes Installation is difficult, but the cluster is powerfulDocker swarm is easy to install, but the cluster doesn’t ha many advanced features.
There is no autoscaling enabled in the Docker swarm.Can do autoscaling
Docker swarm is easy to install but the cluster doesn’t ha many advanced features.Kubernetes Installation is difficult but the cluster is very strong
Docker swarm vs Kubernetes

kubernetes Architecture: Deep dive into Kubernetes Cluster

When you Install Kubernetes, you create a Kubernetes cluster that mainly contains two components master or the controller nodes and worker nodes. Nodes are the machines that contain their own Linux environment, which could be a virtual machine or either physical machine.

The application and services are deployed in the containers within the Pods inside the worker nodes. Pods contain one or more docker containers. When a Pod runs multiple containers, all the containers are considered a single entity and share the Node resources.

Bird-eye view of kubernetes cluster
Bird-eye view of Kubernetes cluster

kubernetes master components or kubernetes master node

Kubernetes master components or Kubernetes master node manages the Kubernetes clusters state, storage information about the different nodes, container alignments, the data, cluster events, scheduling new Pods, etc.

Kubernetes master components or Kubernetes master node contains various components such as Kube-apiserver, an etcd storage, a Kube-controller-manager, and a Kube-scheduler.

Let’s learn about each Kubernetes master component or Kubernetes master node.

kube api server

The most important component in the Kubernetes master node is the kube API server or API server that orchestrates all the operations within the cluster. Kubernetes cluster exposes the Kube API server and acts as a gateway or an authenticator for users.

Kube API server also connects with worker node and other control panel components. It also allows you to query and manipulate the state of API objects in Kubernetes such as Pods, Namespaces, ConfigMaps, and events from the etcd server.

The kubectl command-line interface or kubeadm uses the kube API server to execute the commands.

If you deploy the kube API server using the kubeadm tool, it is installed as a Pod else for non-kubeadm setup; you will find it on cat /etc/systemd/system/kube-apiserver.service.

  • To check if kube api server is running in the kubernetes cluster using kubectl command.
kubectl get pods --all-namespaces
Checking the kube API server in the Kubernetes cluster with the kubectl command
Checking the kube API server in the Kubernetes cluster with the kubectl command
  • To check if kube api server is running in the kubernetes cluster with the process command.
ps -aux | grep kube-apiserver
Checking the kube API server in the Kubernetes cluster with process command
Checking the kube API server in the Kubernetes cluster with process command

You can also use client libraries if you want to write an application using Kubenetes API server based on different languages.

etcd kubernetes

etcd is again an important component in the Kubernetes master node that allows storing the cluster data, cluster state, secrets, configs, pod state, etc. in key-value pair format. etcd holds two types of state; one is desired, and the other is the current state for all resources and keeps them in sync.

When you run the kubectl get command, the request goes to the etcd server, and the same command to add or update anything in the Kubernetes cluster using kubectl add or kubectl update, etcd is updated.

For example, the user runs the kubectl command, then the request goes to ➜ the Kube API server (Authenticator) ➜ , etcd ( reads the value) and pushes those values back to the kube API server.

Tabular or relational database
Tabular or relational database
Key-value store
Key-value store

Kube scheduler

Kube scheduler helps schedule new Pods and containers to the appropriate worker nodes according to the pod’s requirement, such as CPU or memory, before allocating the pods to the worker node of the cluster.
Whenever the controller manager finds any discrepancies in the cluster, it forwards the request to Scheduler via the kube API server to fix the gap. For example, If there is any change in node or if pod is created without assigned node, then:

  • Scheduler monitors the kube API server continously.
  • Kube API server checks with etcd and etcd respond back to kube API server with required information.
  • Next Controller manager informs Kube API server to schedule new pods using Scheduler.
  • Scheduler takes use of Kube API server asks kublet to assigns the node to the Pod.
  • Kubectl after assigning the pod responds back to kube API server with the information and kube API further communicates to etcd to update.
Scheduling a Pod
Scheduling a Pod

Kube controller manager

Kube controller manager runs the controller process. Kubernetes comes with a set of built-in controllers that run inside the kube-controller-manager. These built-in controllers provide important core behaviors.

  • Node Controller: Node controller in kube controller manager checks the status of the node like when would node gets on or off.
  • Replication controller: Replication controller in kube controller manager maintains the correct number of containers are running in the replication group.
  • Endpoint controller: Providers endpoints of pods and services.
  • Service and token controller: Create Accounts and API access tokens.

In Kubernetes kube controller managers control loops that watch the state of your cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state and if there are any gaps, then forwards the request to Scheduler via the kube API server to fix the gap.

Worker node in kubernetes Cluster

Worker Node is part of a Kubernetes cluster used to manage and run containerized applications. The worker node performs any actions when any Kube API server triggers any request. Each node is managed by the control plane or Master Node that contains the services necessary to run Pods.

The Worker node contains various components, including a Kubelet, Kube-proxy, container runtime, and Node components run on every node, maintaining the details of all running pods.

kubelet in kubernetes

kubelet in Kubernetes is an agent that runs on each worker node and manages containers in the pod after communicating with the kube API server. Kubelet command listens to the Kube API server and acts accordingly, such as adding or deleting containers.

Kube API server fetches the information from kubelet about the worker nodes’ health condition and, if necessary, schedules the necessary resources with the help of Scheduler.

Kubelet is not installed as a pod with the kubeadm tool; you must install it manually.

kube proxy in kubernetes

Kube proxy is a networking component that runs on each worker node in the Kubernetes cluster, forwards traffic within the worker nodes, and handles network communications.

Container Runtime

Container Runtime is an important component responsible for providing and maintaining the runtime environment to containers running inside the Pod. The most common container runtime is Docker, but others like containerd or CRI-O may also be possible.

Other than Master or Worker Node

  • Now tha you know that a Kubernetes cluster contains a master and worker node but it also neds a DNS server which servers DNS records for kubernetes service.
  • Next, optional but it is a good practice that you to install or setup Kubernetes Dashbaod (UI) which allows users to manage and troubleshoot applications running in the cluster.

Highly Available Kubernetes Cluster

Now that you have a good idea and knowledge about the Kubernetes cluster components. Do you know Kubernetes auto-scales your cluster if required, and there are two ways to achieve it?

  • With etcd co-located with control panel nodes and have a stacked etcd.
  • With etcd running on separate nodes from the control panel nodes and have a external stacked etcd.

etcd is co-located with control panel

In the case of etcd are co-located with control panel all the three components API server, scheduler, controller manager communicates with etcd separately.

In this case, if any node gets down, both the components are down, i.e., API processor, etcd. To solve this, add more nodes to make it Highly Available. This approach requires less infrastructure.

etcd is co-located with control panel
etcd is co-located with control panel

etcd running on separate nodes from the control panel

In the second case of etcd running on separate nodes with control panel all the three components kube API server, scheduler, controller manager communicates with etcd externally with an external stacked etcd.

In this case, if any node gets down, your etcd is not impacted, and you still have a highly available environment than stacked etcd, but this approach requires more infrastructure.

etcd running on separate nodes from the control panel
etcd running on separate nodes from the control panel

What is kubernetes namespace?

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called Kubernetes namespace.

In the Kubernetes namespace, all the resources should have a unique name, but not across namespaces. Kubernetes namespaces help different projects, teams, or customers to share a Kubernetes cluster and divide cluster resources between multiple users.

There are three types of Kubernetes namespaces when you launch a Kubernetes cluster:

  • Kube-system: kube-system contains the all the cluster components such as etcd, api-server, networking, proxy server etc.
  • Default: Default namespace is where you will actually launch the resources or other kubernetes objects by default.
  • Kube-public: This namespace is available for all users accessing the kubernetes service publically.

Let’s look at an example related to the Kubernetes namespace.

  1. If you wish to connect service named db-service within the same namespace then you can access the service directly as:
 mysql.connect("db-service")
  1. To access service named db-service service in other namespace like dev then you should access the service as:
    • <service-name>.<namespace-name>.svc.cluster.local because when you create a service the DNS entry is created
    • svc is subdomain for the service.
    • cluster.local is default domain name of the kubernetes cluster
mysql.connect("db-service.dev.svc.cluster.local") 

Most Kubernetes resources (e.g., pods, services, replication controllers, and others) are created in the same namespace or different depending on the requirements.

  • To List the current namespaces in a cluster run the kubectl command as below.
kubectl get namespaces
kubectl describe namespaces
kubectl create namespace namespace-name
kubectl delete namespaces namespace-name
  • To allocate resource quota to namespace, create a file named resource.yaml and run the kubectl command.
apiVersion: v1
kind: ResourceQuota
metadata: 
    name: compute-quota
    namespace: my-namespace2
spec:
  hard:
    pods: "10"
    requests.cpu: "1"
    requests.memory: 0.5Gi
    limits.cpu: "1"
    limits.memory: 10Gi
kubectl create -f resource.yaml
allocate resource quota to namespace,
allocate resource quota to namespace
  • To check the resource consumption for a particular namespace run the below command.
kubectl describe resourcequota compute-quota
checking the resource consumption for a particular namespace
checking the resource consumption for a particular namespace

Kubernetes Objects and their Specifications

Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster, such as how many containers are running inside the Pod and on which node, what all resources are available If there are any policies on applications.

These Kubernetes objects are declared in .YAML formats are used during deployments. The YAML file is used by the kubectl command, which parses it and converts it into JSON.

  • Spec : While you create the object you need to specify the spc parameter which define the characteristics of the resources you want in the kubernetes cluster.
  • Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are relevant to users. Labels are used to organize and to select subsets of objects.
  • apiVersion – Which version of the Kubernetes API you’re using to create this object
  • kind – What kind of object you want to create
  • metadata – Data that helps uniquely identify the object, including a name string, UID, and optional namespace
apiVersion: apps/v1             # Which Version your kubernetes API server uses
kind:       Deployment          # What kind of Object you would like to have
metadata:   tomcat deployment   # To Identify the Object
specs:                                  # What would you like to achieve using this template
   replicas: 2                        # Run 2 pods matching the template
   template:
     metadata:                  # Data that identify object like name, UID and namespace
       labels: 
         app : my_tomcat_app
   spec:
     containers:
     - name: my_tomcat_container
       image: tomcat
       ports:
       - containerPort : 8080

Kubernetes Workloads

The workload is the applications running on the Kubernetes cluster. Workload resources manage the set of Kubernetes Pods in the form of Kubernetes deployments, Kubernetes Replica Set, Kubernetes StatefulSet, Kubernetes DaemonSet, Kubernetes Job, etc.

Kubernetes deployments, Kubernetes Replica Set, Kubernetes StatefulSet, Kubernetes DaemonSet, Kubernetes Job, etc
Kubernetes deployments, Kubernetes Replica Set, Kubernetes StatefulSet, Kubernetes DaemonSet, Kubernetes Job, etc

Let’s learn each of the Kubernetes in the upcoming sections.

What is a kubernetes Pod?

The Kubernetes pod is a Kubernetes entity where your docker container resides hosting the applications. The number of pods in the node increases, not containers, if there is an increase in traffic on the apps.

The Kubernetes pod contains a single or group of containers that work with shared storage and network. It is recommended to add Pods than adding containers in the Pod because more containers mean more complex structures and interconnections.

The Kubernetes Pods are created using workload resources such as Kubernetes deployment or Kubernetes Job with the help of yaml file or using directly calling Kubernetes API and are assigned unique IP addresses.

To create a highly available application, you should consider deploying multiple Pods known as replicas. Healing of Pods is done by controller-manager as it keeps monitoring the health of each pod and later asks the scheduler to replace a new Pod.

All containers in the Pod can access the shared volumes, allowing those containers to share data same network namespace, including the IP address and network ports. Inside a Pod, the containers that belong to the Pod can communicate with one another using localhost.

  • To create a Kubernetes Pod create a yaml file named pod.yaml and copy/paste the below content.
# pod.yaml template file that creates pod
apiVersion: v1        # It is of type String
kind: Pod               # It is of type String
metadata:             # It is of type Dictionary
  name: nginx
  labels: 
    app: nginx
    tier: frontend
spec:                  # It is of type List and Array
  containers:
  - name: nginx
    image: nginx
  • Now to create a Kubernetes Pod execute the kubectl command.
kubectl apply -f pod.yaml  # To run the above pod.yaml manifest file
Creating a Kubernetes Pod
Creating a Kubernetes Pod

Deploying multi container Pod

In the previous section, you learned how to launch a Pod with a single container, but you sometimes need to run Kubernetes pods with multiple containers. Let’s learn how you can achieve this.

  • To create a multi container Kubernetes Pod create a yaml file named multi-container-demo.yaml and copy/paste the below content.
apiVersion: v1
kind: Pod
metadata:
  name: multicontainer-pod
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: nginx-container-1                  # Container 1
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: ubuntu-container-2                  # Container 2
    image: nginx
  • Now to create multi container Kubernetes Pod execute the kubectl command.
kubectl apply -f multi-container-demo.yaml  # To run the above pod.yaml manifest file
  • To check the Kubernetes Pod run kubectl get pods command.
Creating multi-container Kubernetes Pod
Creating multi-container Kubernetes Pod
  • To describe both the containers in the kubernetes Pods run kubectl describe command as shown below.
kubectl describe pod multicontainer-pod
describe both the containers in the kubernetes Pods
describe both the containers in the Kubernetes Pods

Join 46 other followers

Conclusion

In this Ultimate Guide, you learned what is Kubernetes, Kubernetes architecture, and understood Kubernetes cluster end to end and how to declare Kubernetes manifest files to launch Kubernetes Pods.

Now that you have gained a handful of Knowledge on Kubernetes, continue with the PART-2 guide and become the pro of Kubernetes.

Kubernetes Tutorial for Kubernetes Certification [PART-2]

2 thoughts on “Kubernetes Tutorial for Kubernetes Certification [PART-1]

  1. Pingback: Kubernetes Tutorial for Kubernetes Certification [PART-2] | Automateinfra

  2. Pingback: The Ultimate Kubernetes Interview questions for Kubernetes Certification (CKA) | Automateinfra

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s