Kubernetes — Fundementals

Kubernetes:

It follows the master-slave model, which uses a master to manage Docker containers across multiple Kubernetes nodes. A master and its controlled nodes (worker nodes) constitute a “Kubernetes cluster”. A developer can deploy an application in the docker containers with the assistance of the Kubernetes master.

Control Plane:

1. API Server — contact through API & kubectl commands
2. Controller manager — checks that the cluster is running properly.
3. Scheduler — assigns pods to nodes
4. etcd — key value store, state of cluster

Worker node:

1. Kubelet — Check that the containers are healthy.
2. Kube-proxy — Network
3. container runtime interface — Create containers using a supported engine

So, the correct hierarchy is:

Cluster -> Node(s) -> Namespace(s) -> Pod(s)

In summary, a cluster consists of one or more nodes. Each node can host multiple pods, and pods are organized within namespaces.

1. Cluster: A Kubernetes cluster is the highest level of abstraction in the Kubernetes architecture. It consists of one or more physical or virtual machines called nodes.

2. Node: A node is an individual machine within the Kubernetes cluster where containers are deployed and run. Nodes can be physical or virtual machines and are responsible for running and managing the containers that make up the applications.

3. Namespace: A namespace is a logical boundary within a Kubernetes cluster. It is used to partition resources and create isolated environments. Namespaces provide a scope for Kubernetes objects, such as pods, services, and deployments. They help in resource management and access control.

4. Pod: A pod is the smallest deployable unit in Kubernetes. It represents a group of one or more containers that are co-located and share the same network and storage resources. Pods are scheduled onto nodes and are the basic building blocks for running applications in Kubernetes.

Kubernetes Services:

In a Kubernetes cluster, each Pod has an internal IP address. But the Pods in a Deployment come and go, and their IP addresses change. So, it doesn’t make sense to use Pod IP addresses directly. With a Service, you get a stable IP address that lasts for the life of the Service, even as the IP addresses of the member Pods change.

A Service also provides load balancing. Clients call a single, stable IP address, and their requests are balanced across the Pods that are members of the Service.

Types of Kubernetes Services

There are five types of Services:

ClusterIP (default): Internal clients send requests to a stable internal IP address.

NodePort: Clients send requests to the IP address of a node on one or more nodePort values that are specified by the Service.

LoadBalancer: Clients send requests to the IP address of a network load balancer.

ExternalName: Internal clients use the DNS name of a Service as an alias for an external DNS name.

Headless: You can use a headless service when you want a Pod grouping, but don’t need a stable IP address.

• The NodePort type is an extension of the ClusterIP type. So a Service of type NodePort has a cluster IP address.
• The LoadBalancer type is an extension of the NodePort type. So a Service of type LoadBalancer has a cluster IP address and one or more nodePort values.

Kubernetes controller

1. Deployment: Manages stateless applications like web servers, ensuring a desired number of identical pods are running. For example, a Deployment can be used to manage a web application with three replicas of a frontend pod to handle incoming user requests.

2. StatefulSet: Suited for stateful applications like databases, maintains unique pod identities and ordered scaling. For instance, a StatefulSet can be used to manage a distributed database cluster where each pod has a unique identity and requires stable storage and network identities.

3. DaemonSet: Ensures a specific pod runs on every node in the cluster, useful for system-level services like log collectors. For example, a DaemonSet can be employed to deploy a monitoring agent on every node in the cluster to collect metrics and monitor system health.

4. Job: A Kubernetes Job will spin up a pod, run the container until its task is complete, and then terminate the pod. A Job is best for applications that perform one-time operations, like an ETL.