An open-source container management tool which automates the container deployment, container scaling, and container load balancing.

It’s a Google-developed product.

For example:

We can group a number of docker containers into one logical unit for managing and deploying an application or particular services.

Self-healing

Whenever Kubernetes realizes one of its container’s failed, then it will restart that container on its own. It will create a new container in place of the crashed one.

In case if the Node itself fails, then whatever container’s running in that failed node, those containers will start in another node.

A Kubernetes (also called a Kubernetes cluster)  consists of two types of resources: 

Master node – coordinates the cluster.

Worker  Nodes – are the workers that run applications.

Master Node

• The Master is responsible for managing the cluster.
• The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications desired state, scaling applications, and rolling out new updates. 

 Worker Nodes

• Node – serves as a worker machine in a Kubernetes cluster.
• The node has tools for handling container operations, such as Docker.
• A Kubernetes cluster that handles production traffic should have a minimum of three nodes.
• The nodes communicate with the master using the Kubernetes API, which the master exposes.
• End-users can also use the Kubernetes API directly to interact with the cluster.
• Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it.

Create a Kubernetes Deployment configuration

• If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. This provides a self-healing mechanism to address machine failure or maintenance.
•  You can create and manage a Deployment by using the Kubernetes command-line interface called Kubectl.
• When you create a Deployment, you’ll need to specify the container image for your application and the number of replicas that you want to run.
• You can change that information later by updating your Deployment.

Pod

• When you created a Deployment, Kubernetes created a Pod to host your application instance.
•  A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources for those containers.
• When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them.
• A Pod always runs on a Node.

Every Kubernetes Node runs at least:

• Kubelet, a process responsible for communication between the Kubernetes Master and the Node. It manages the Pods and the containers running on a machine.
• A container runtime (like Docker, rkt) responsible for pulling the container image from a registry, unpacking the container and running the application. 
• Containers should only be scheduled together in a single Pod if they are tightly coupled and need to share resources such as disk.

To Expose our App publically.

• Each pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node.
• Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service.
• Services allow your applications to receive traffic.
•  A Kubernetes Service is an abstraction layer that defines a logical set of Pods and enables external traffic exposure, load balancing.
• NodePort – Exposes the Service on the same port of each selected Node in the cluster using NAT.
• Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>
•  A Service routes traffic across a set of Pods.
• Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application.

Scaling

•  When traffic increases, we will need to scale the application to keep up with user demand.
• Scaling is accomplished by changing the number of replicas in a Deployment.
•  Scaling will increase the number of Pods to the new desired state.
•  Kubernetes also supports the autoscaling of Pods.
• Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment.
• Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.

Rolling Updates

• Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime.
• Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. Kubernetes this is done with rolling updates.
• Rolling updates allow Deployment update to take place with zero downtime by incrementally updating Pods instances with new ones.
• In Kubernetes, updates are versioned and any Deployment update can be reverted to the previous (stable) version.

Rolling updates allow the following actions:

• Promote an application from one environment to another (via container image updates)
• Rollback to previous versions
• Continuous Integration and Continuous Delivery of applications with zero downtime.

Ingress

• Ingress allows inbound connections to the cluster
• Its an alternative to the external load balancer and node ports
• Ingress allows you to easily expose services that need to be accessible from outside to the cluster.

Deploying Nginx to our Kubernetes cluster on AWS

(Docker Containers)

#How to proceed deployment on k8s
 kubectl \ 
create deployment my-nginx-deployment \ 
--image=nginx

#How to expose deployment via service 
kubectl \ 
expose deployment my-nginx-deployment \
--port=80 \
--type=NodePort \
--name=my-nginx-service

Create Horizontal Pod Autoscaler

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Reference

Link for creating Kubernetes Cluster.