Kubernetes Hands On

Why the need arises for putting multiple containers in single pod ? Sometime we want to co-locate the containers, for that pod is the best solution. We will put the related containers into single pod. Since pod is the smallest unit of deployment in Kubernetes, so automatically when pod will get launched on a particular node, all the containers in that pod will also be running on that particular node.

The containers in pod can share the storage, can communicate with each other using localhost. Pod is allocated a unique private address. Remember by default, no one from outside the cluster can access the pod. For that, we need to use the service object in Kubernetes. The secondary container is often used to enhance the functionality of the first container.

How to create pod using "YAML" file. How create and view pod details. How to get detailed information about pod.

How to access web server pod using curl and elinks browser. How to enter into pod in interactive mode. Check host to pod communication.

Create other pod and check pod to pod communications.

Create other pods and draw some important conclusions.

- Pod are able to communicate with each other. Pods running on different nodes under same Kubernetes cluster are also able to communicate.

- Host to pod accessibility is there.

- Every pod is given unique private IP address. We can not access the pod from outside (internet). Later on we will see how to enable access to the pod from outside.

- New pods are scheduled based on current load on nodes.

- Pods are not scheduled on master node.

How to delete pods. How to verify that we have successfully deleted the pods.

How to create pod using CLI mode.

How to troubleshoot pod creation. What are pod labels.

How to manage pod labels.

How to create pod with labels in CLI mode. How to view pod details and manage labels.

How to create pod by specifying container port and label. What is container port.

How to create pod by specifying label and port in CLI mode. How to access and remove pod.

Create pod with host port. What is the use of host port. Is host port helpful in accessing pods from outside (internet).

Understand how host port actually behaves by launching new pods with host port option enabled.

Understand role played by ReplicaSet object. How to create ReplicaSet using "YAML" file.

There are many ways we can create pods. Till now we have created the pods directly by using “yaml” file and CLI options. As such, creating pods in this way is not the recommended. There are many issues with this approach. First of all if we have to create hundreds of pods, we will have to create hundreds of “yaml” files or run pod creation commands hundreds times. Not a good idea at all. Other is when pods gets terminated unexpectedly, we have to create that pod manually.

So to solve these problems, Kubernetes have defined numbers of objects which can create pods at a scale and can solve pod termination issue. Two of the most used objects are ReplicaSet and Deployment. We can specify numbers of pods required to these objects. Now it is the responsibility of these objects to keep that numbers of pods running. Nothing less, nothing more. These Kubernetes objects use declarative approach.

What do you mean by declarative approach? We tell the Kubernetes that we need specific numbers of pods always running with particular parameters. Now it is the Kubernetes’s duty to fulfill our request.

How to scale up pods using ReplicaSet.

How ReplicaSet reacts when we delete pod, remove pod label or create new pod.

Fully understand behavior of ReplicaSet.

How to use match expression type selector in ReplicaSet.

How to use both match expression and match label type selectors in ReplicaSet.

What is Kubernetes deployment. How to create Kubernetes deployment.

Till now we have seen how to create pods and ReplicaSets. The purpose of the ReplicaSet again was to create pods but with much more efficiency. The manageability and scalability is easier with Replicasets. But ReplicaSets also suffer from certain drawbacks.

The rollout of new versions of applications is not efficient with ReplicaSets. To solve this major problem, deployment object was created. We can use different deployment strategies such as rolling updates, canary deployment, fixed strategy and blue-green deployments.

The end purpose of deployment object is again creating pods with the greatest flexibility and efficiency. When we create deployment object, behind the scene it creates ReplicaSet, which handles the pods.

How to scale up using deployments. How deployment reacts when we delete pods or ReplicaSet.

Why the need for custom images. What problems can be solved by using custom Docker images.

What is Dockerfile. How to use Dockerfile to create first custom Docker image.

How to test custom Docker image. Create other custom images to be used later on.

How to push custom Docker images to Docker hub.

How to pull custom Docker images and verify working of these images.

What is deployment strategy. Create web server deployment for understanding rolling update deployment strategy.

By default, deployment object uses rolling update strategy. Sometimes we might want to change the image of the container. Kubernetes deployment allows this without any downtime. Kubernetes makes sure that at least 25% of pods are always available. It creates new pods and then deletes the old pods.

How to access pods from outside. What is service object. What are different types of service available.

Create Load Balancing service.

Types of service available

ClusterIP: A virtual private internal IP address is allocated to service. This IP can be used only within the cluster. Pods and nodes in cluster can access this IP address. If we are not going to specify service type during object creation time, default ClusterIP is chosen. The external clients can not access the service IP.

NodePort: A port is dynamically allocated from port range 30000-32768 to each node of the cluster and any one can access pods using these nodesip:nodeport combination. NodePort itself behind the scenes uses ClusterIP to send the traffic to pods. When we send the request to nodeip:nodeport, it is forwarded to clusterip:serviceport and finally forwarded to podip:targetport combination. The problem with NodePort is that if there are 3 node in cluster we may have to use 3 combinations of nodeip:nodeport, which is again difficult.

LoadBalancer: By default, no load balancer is available internally in Kubernetes. We have to use external Load balancer (LB) from cloud providers such as AWS, GCP or Azure. LB behind the scene creates NodePort service and just load balance the traffic to nodeip:nodeport combinations.

How to perform rolling update.

View rolling update details.

Again perform rolling update by changing the image used by deployment. Observe the behavior.

How to perform rollback.

Create deployment for using fixed deployment strategy.

How to use fixed deployment strategy.

Create two different deployments for understanding blue green deployment strategy.

How to send traffic to green deployment.

How to send traffic to blue deployment

Create Stable deployment and send traffic to Stable deployment.

Create Canary deployment and send some traffic to Canary deployment.

Understand working of canary deployment strategy.

What are health probes. What are readiness and liveness probes. Create deployment for understanding readiness probe.

Readiness probes: help Kubernetes in deciding when your app is ready to handle the traffic. Kubernetes allows the service to send traffic to pods only when readiness probes passes. Since readiness probes are periodic, if at some time they start failing, Kubernetes will stop sending traffic to pods. If it again passes readiness probe at some time, the traffic will again start flowing to these pods.

Liveness probes: is to check whether your app is alive or dead. If it is alive, then no action taken otherwise remove the container and start a new one. It is very useful when your app often hangs or stops responding.

How to test whether readiness probes are working or not.

Fully understand readiness probes by manipulating files.

How to use liveness probe.

Enhance understanding of readiness probe by creating another pod.

Understand liveness probes by creating other pods.

Understand liveness probe using Kubernetes deployment.

How to configure both readiness and liveness probes.

Why we need Kubernetes service object.

We have seen that the purpose of pod, ReplicaSet and deployment objects is to create pods and manage them properly. But pods are useless, if external clients can not connect to them. Which object is going to send the traffic to pods. It is the “Service” object. It is one of the most important object in Kubernetes. Understanding services is extremely important.

What is default service type.

How to create ClusterIP service.

When we create service object, we are given unique address and port. We have to send our requests to this combination of IP address and port. It will automatically distributes the requests to the relevant pods. Three different types of services are available namely ClusterIP, NodePort and LoadBalancer.

ClusterIP: A virtual private internal IP address is allocated to service. This IP can be used only within the cluster. Pods and nodes in cluster can access this IP address. If we are not going to specify service type during object creation time, default ClusterIP is chosen. The external clients can not access the service IP.

How to create NodePort service.

NodePort: A port is dynamically allocated from port range 30000-32768 to each node of the cluster and any one can access these nodeip:nodeport combinations. NodePort itself behind the scene uses ClusterIP to send the traffic to pods. When we send the request to nodeip:nodeport, it is forwarded to clusterip:serviceport and finally forwarded to podip:targetport. The problem with NodePort is that if there are 3 nodes in cluster we may have to use 3 combinations of nodeip:nodeport, which is again difficult.

How to create Fixed NodePort service.

NodePort: A port is dynamically allocated from port range 30000-32768 to each node of the cluster and any one can access these nodeip:nodeport combinations. NodePort itself behind the scene uses ClusterIP to send the traffic to pods. When we send the request to nodeip:nodeport, it is forwarded to clusterip:serviceport and finally forwarded to podip:targetport. The problem with NodePort is that if there are 3 nodes in cluster we may have to use 3 combinations of nodeip:nodeport, which is again difficult.

How to create Load Balancer service.

LoadBalancer: By default, no load balancer is available internally in Kubernetes. We have to use external Load balancer (LB) from cloud providers such as AWS, GCP or Azure. LB behind the scene creates NodePort service and just load balance the traffic to nodeip:nodeport combinations.

How to Use ClusterIP service with deployment.

How to use NodePort service with deployment

How to use Load Balancer service with deployment

Create pod and ClusterIP service using CLI mode.

Create pod and NodePort service using CLI mode.

Create deployment and Load Balancer service using CLI mode.

How to create 3 node Kubernetes cluster using Google Kubernetes Engine (GKE).