Kubernetes Fundamental – Part 2

In Part 1, We have gone through what is Kubernetes and its architecture.

Now in this section, we will go through the key components of Kubernetes. I am going to breakdown the component explanation over few parts of this Kubernetes series in order to go in detail.

In this part, we will go through Nodes, Namespaces and Pods.

KEY components

Nodes

Nodes are the machines within the cluster and this is where the container will be deployed and run. The machine that mentioned here could be either physical or virtual machine. It responsibility is to provide enough resources to run workload on it. Nodes can be scaled up/down on demand.

Example

Let say, if we have Kubernetes cluster with three nodes A, B and C and it will host and run containerised applications.

Node
 - Node A
 - Node B
 - Node C
Namespaces

Namespace provides the logical grouping the resources within the Kubernetes Cluster. It is quite useful in categorise the resources they are related. For example, if we have a product that contain multiple applications (microservices) that can be grouped together within a same namespace. We can also create namespace divide resources between users and teams by applying role based access control.

Pods

Pods are the smallest deployable units in the Kubernetes. It represents one or more containers which share same namespace within the node. Each pod is a single instance of process within the cluster. It will be always scheduled on the same same node. It can be communicated with each other via localhost.

Example

In case, we have a web application and it can be deployed with application server and database. So, it will be deployed as a single pod. It can be scaled on demand.

Pods
 - Pod 1 (Web App + Database)
 - Pod 2 (Web App + Database)

Let us create a Kubernetes YAML configuration that deploys web application with application server (Nginx) and database (MongoDB) in to a pod.

# webapp-with-db-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: webapp-with-db
  labels:
    app: my-webapp
spec:
  containers:
    - name: webapp
      image: nginx:latest
      ports:
        - containerPort: 80
    - name: database
      image: mongo:latest

In the above example,

  • We defined a pod : webapp-with-db
  • Create two containers: One for application and another MongoDb.
  • First Container : webapp . It takes the latest image of nginx and runs on it.
  • Second Container: database. It takes the latest image of mongo and runs on it.
  • Both container will share the same network and can be communicate with each other via localhost.
Why do we need pod instead of container?
  • Grouping Containers: Pod provides the logical grouping of related containers. It simplifies the scheduling, scaling and managing of related containers.
  • Shared Resources: All the containers within the pod will share the same network namespace and volumes. It will be easier to share and communicate data.
  • Atomic Unit: The pod is a atomic unit of deployment. So, the scheduling, scaling etc can be done at pod level.
  • Scheduling: Kubernetes will do scheduling at pod level instead of container. So, all the containers with in the pod should co-exist on the same node.

So in summary, Pod will provide additional layer of abstract on top of related containers to facilitate and simplify sharing and resource sharing capabilities.

Hope, it makes sense about these components and in the next part we will go through other components such as Services, ConfigMap and Secrets.

Happy Containerising 🙂

Leave a comment