Kubernetes & It’s Basic Terminology
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. Following is the basic terminology used in kubernetes :
Deployment Object: It represents the application is running on your cluster. In Deployment spec, one can also specify the number of replicas the application needed to be running. Kubernetes system reads the Deployment spec and starts number of needed instances of your desired application — updating the status to match your spec.
Ingress Object: It’s an API object that manages external access to the services in a cluster, typically HTTP. Basically it exposes HTTP and HTTPS routes from outside the cluster to services within the clusterIngress provide load balancing, SSL termination and name-based virtual hosting.
StatefulSet: StatefulSet is the workload API object used to manage stateful applications. It manages the deployment and scaling of pods. StatefulSet ensures that the desired number of Pods are running and available at all times. The StatefulSet automatically replaces Pods that fail or are evicted from their nodes, and automatically associates new Pods with the storage resources, resource requests and limits, and other configurations defined in the StatefulSet’s Pod specification.
Node: In Kubernetes, your workload is served by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster.A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the Nodes in the cluster.
Pods: In a Pod, there can be multiple docker containers which are running. Pod is the actual place where traffic hits for any service. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them. Each Pod is tied to the Node where it is scheduled, and remains there until termination or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.
Controller Manager: Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.
Deployment Controller: The Deployment controller is example of controllers that come as part of Kubernetes itself (“built-in” controllers). Deployment Controller changes the actual state to the desired state at a controlled rate. K8s deployment controller is responsible for the following functions:
– Managing a set of pods in the form of Replica Sets & Hash-based labels
– Rolling out new versions of application through new Replica Sets
– Rolling back to old versions of application through old Replica Sets
– Pause & Resume Rollout/Rollback functions
– Scale-Up/Down functions
Replica Set: A ReplicaSet ensures that a specified number of pod replicas are running at any given time. When a worker node dies, the Pods running on the Node are also lost. A Replica Set might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running.
Service Object: A Service in Kubernetes is a REST object. Like all of the REST objects, you can a create a new instance of service by making a post call with Service definition to the API server. The name of a Service object must be a valid DNS label name.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. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.
How a service is exposed?
Following are the different ways to expose a service deployed in a kubernetes cluster:-
- ClusterIP — 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> - LoadBalancer — We can expose a service by creating an an external load balancer and assigns a fixed, external IP to the Service.
- ExternalName — We can also expose a service by creating an external name i.e dns for particular service then exposing it.
Ip Masquerading: Ip masquerading is a form of network address translation(NAT). It used to perform many-to-one Ip translations that allows multiple clients to access a destination using a single IP address. A GKE cluster uses IP masquerading so that destinations outside of the cluster only receive packets from node IP addresses instead of Pod IP addresses. This is useful in
environments that expect to only receive packets from node IP addresses.
So above described terms are basic terminologies used in kubernetes. By understanding these how the basic building blocks fit together, you can begin to design systems that fully leverage the capabilities of the platform to run and manage your workloads at scale.
