Why Kubernetes
With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day.
Containerization helps package software to serve these goals, enabling applications to be released and updated without downtime.
Kubernetes helps you make sure those containerized applications run where and when you want and helps them find the resources and tools they need to work.
Kubernetes is a production-ready, open-source platform designed with Google’s accumulated experience in container orchestration, combined with best-of-breed ideas from the community.
Kubernetes Clusters
Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit.
Kubernetes automates the distribution and scheduling of application containers across a cluster in a more efficient way. Kubernetes is an open-source platform and is production-ready.
A Kubernetes cluster consists of two types of resources
- The Control Plane coordinates the cluster
- Control Planes manage the cluster and the nodes that are used to host the running applications.
- The Control Plane is responsible for managing the cluster.
- The Control Plane coordinates all activities in your cluster, such as
- scheduling applications
- maintaining applications’ desired state
- scaling applications
- rolling out new updates.
- When you deploy applications on Kubernetes, you tell the control plane to start the application containers.
- The control plane schedules the containers to run on the cluster’s nodes.
- The nodes communicate with the control plane using the Kubernetes API, which the control plane exposes.
- End users can also use the Kubernetes API directly to interact with the cluster.
- Nodes are the workers that run applications
- A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.
- Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane.
- The node should also have tools for handling container operations, such as container or Docker.
A Kubernetes cluster that handles production traffic should have a minimum of three nodes because if one node goes down, both an etcd member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes
After Deploying your first app on Kubernetes Cluster
Kubernetes Pods
Containers should only be scheduled together in a single Pod if they are tightly coupled and need to share resources such as disks.
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. Those resources include:
- Shared storage, as Volumes
- Networking, as a unique cluster IP address
- Information about how to run each container, such as
- the container image version
- specific ports to use
A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver.
The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.
Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly).
Each Pod is tied to the Node where it is scheduled and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.
Kubernetes Node
A Pod always runs on a Node. A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster.
Each Node is managed by the control plane.
A Node can have multiple pods, and the Kubernetes control plane automatically handles scheduling the pods across the Nodes in the cluster.
The control plane’s automatic scheduling takes into account the available resources on each Node.
Every Kubernetes Node runs at least: –
- Kubelet is a process responsible for communication between the Kubernetes control plane and the Node; it manages the Pods and the containers running on a machine.
- A container runtime (like Docker) 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
Kubernetes Services
A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them.
Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects.
The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including a selector in the spec).
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(it does not expose pods ip to the outside world directly it’s just all outside traffic to its own IP and then internally forwarded to pods and response).
Services can be exposed in different ways by specifying a type in the ServiceSpec:
- ClusterIP (default) – Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.
- 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>. Superset of ClusterIP.
- LoadBalancer – Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.
- ExternalName – Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of kube-dns, or CoreDNS version 0.0.8 or higher.
ExternalName(Domain) <– LoadBalancer (Cloud or Own / SW or HW) <– NodePort <– ClusterIP
Services and Labels
A Service routes traffic across a set of Pods. Services are the abstraction that allows pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) are handled by Kubernetes Services.
Services match a set of Pods using labels and selectors, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:
- Designate objects for development, test, and production
- Embed version tags
- Classify an object using tags
Deployments
A Deployment provides declarative updates for Pods and ReplicaSets
The following are typical use cases for Deployments:
- Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
- Declare the new state of the Pods by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
- Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
- Scale up the Deployment to facilitate more load.
- Pause the rollout of a Deployment to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
- Use the status of the Deployment as an indicator that a rollout has stuck.
- Clean up older ReplicaSets that you don’t need anymore.
Scaling
Scaling is accomplished by changing the number of replicas in a Deployment.
You can create from the start a Deployment with multiple instances using the –replicas parameter for the kubectl create deployment command.
Scaling is accomplished by changing the number of replicas in a Deployment.
Service when there is no replica only one-node, one-pod service also gets expanded with replicas
- Fixed Number – Scaling will increase the number of Pods to the new desired state.
- Auto Scaling – Kubernetes also supports the autoscaling of Pods.
- Zero Scaling – Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.
Rolling Update
Rolling updates allow Deployments’ update to take place with zero downtime by incrementally updating Pods instances with new ones.
If a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update.
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
Kubernetes ConfigMaps & Secrets
ConfigMaps are API Objects that store non-confidential key-value pairs.
Can be use by any container.
Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that they’re intended for confidential/sensitive information and are stored using Base64 encoding.
Storing such things as credentials, keys, and tokens.