An open-source container management tool which automates the container deployment, container scaling, and container load balancing.
It’s a Google-developed product.
We can group a number of docker containers into one logical unit for managing and deploying an application or particular services.
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.
- 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.
- 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.
- 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.
- 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.
- 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 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
#How to proceed deployment on k8s
create deployment my-nginx-deployment \
#How to expose deployment via service
expose deployment my-nginx-deployment \
Create Horizontal Pod Autoscaler
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
Link for creating Kubernetes Cluster.