Kubernetes Overview

Architecture at a Glance

┌──────────────────────────────────────────────────────────────────────────────────────────┐
│                  Kubernetes — Control Plane and Data Plane Architecture                  │
│                                                                                          │
│   ┌──────────────────────────────────────────────────────────────────────────────────┐   │
│   │              CONTROL PLANE  (cluster brain — runs on master nodes)               │   │
│   │                                                                                  │   │
│   │  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐  │   │
│   │  │ api-server │  │ scheduler  │  │ controller │  │    etcd    │  │ cloud-ctrl │  │   │
│   │  └────────────┘  └────────────┘  └────────────┘  └────────────┘  └────────────┘  │   │
│   │                                                                                  │   │
│   └──────────────────────────────────────────────────────────────────────────────────┘   │
│                                            │                                             │
│                     ▼  kubelet polls api-server, reports node state                      │
│   ┌──────────────────────────────────────────────────────────────────────────────────┐   │
│   │               WORKER NODE  (one per machine — runs scheduled pods)               │   │
│   │                                                                                  │   │
│   │          ┌────────────────┐    ┌────────────────┐    ┌────────────────┐          │   │
│   │          │    kubelet     │    │   kube-proxy   │    │  container-rt  │          │   │
│   │          └────────────────┘    └────────────────┘    └────────────────┘          │   │
│   │                                                                                  │   │
│   └──────────────────────────────────────────────────────────────────────────────────┘   │
│                                            │                                             │
│                        ▼  kubelet starts containers per Pod spec                         │
│   ┌──────────────────────────────────────────────────────────────────────────────────┐   │
│     │               PODS & CONTAINERS  (your application workloads)                │     │
│   │                                                                                  │   │
│   │       ┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐       │   │
│   │       │   Pod A    │    │   Pod B    │    │   Pod C    │    │   Pod D    │       │   │
│   │       └────────────┘    └────────────┘    └────────────┘    └────────────┘       │   │
│   │                                                                                  │   │
│   └──────────────────────────────────────────────────────────────────────────────────┘   │
│                                                                                          │
│  kubectl talks to api-server. api-server is the only component that reads/writes etcd.   │
│  scheduler decides which node a new Pod runs on; controller-manager reconciles state.    │
└──────────────────────────────────────────────────────────────────────────────────────────┘

Three layers: control plane (cluster brain) → worker nodes → pods running your containers.

What is Kubernetes?

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).

What is Kubernetes used for?

Kubernetes is used to manage clusters of containerized applications. It provides the infrastructure needed to deploy and run applications in a cloud-native environment, allowing for easy scaling, load balancing, and self-healing. Kubernetes is especially powerful for managing complex, microservices-based architectures that require automated deployment and scaling.

Example Interview Questions:

1. What are the key components of Kubernetes architecture?

Answer: The key components include the Master Node, which contains the API Server, Scheduler, Controller Manager, and etcd (a key-value store), and the Worker Nodes, which run the containerized applications in Pods. Each worker node has a Kubelet, a container runtime (like Docker), and a Kube-proxy for network routing.

2. How does Kubernetes handle scaling?

Answer: Kubernetes handles scaling through the use of Horizontal Pod Autoscalers (HPA). The HPA can automatically adjust the number of pods in a deployment based on observed CPU utilization or other select metrics.

3. Can you explain what a Kubernetes Pod is?

Answer: A Pod is the smallest and simplest Kubernetes object. It represents a single instance of a running process in the cluster. Pods can contain one or more containers that share storage, network, and have a specification for how to run them.

4. How do you perform a rolling update in Kubernetes?

Answer: Rolling updates in Kubernetes can be performed using the kubectl rollout command. This allows you to update the deployment without downtime by incrementally replacing old pods with new ones.

5. What are Kubernetes namespaces, and how do they work?

Answer: Namespaces in Kubernetes provide a way to divide cluster resources between multiple users. They allow you to manage different environments (e.g., dev, staging, production) within the same cluster while ensuring resource isolation.

6. How do you secure a Kubernetes cluster?

Answer: Security in Kubernetes can be enhanced by implementing Role-Based Access Control (RBAC), using network policies to control traffic between pods, securing the API server with TLS certificates, and regularly updating the cluster to address vulnerabilities.

Key Points of Kubernetes

Container Orchestration: Kubernetes automates the deployment, scaling, and management of containerized applications, making it easier to manage complex, distributed systems.
Pods: The smallest deployable units in Kubernetes, which encapsulate one or more containers. Pods share the same network namespace, storage, and configuration.
Services: Kubernetes uses services to expose pods as network services, enabling communication between different parts of the application and providing load balancing.
Deployments: Used to manage the rollout and scaling of a set of pods. Deployments ensure the desired state of applications and handle updates or rollbacks.
Namespaces: Provide a way to divide cluster resources between multiple users or applications, offering isolation and resource management.
Ingress: Manages external access to services within a cluster, typically HTTP or HTTPS, allowing for load balancing, SSL termination, and name-based virtual hosting.
ConfigMaps and Secrets: Kubernetes uses ConfigMaps to manage configuration data and Secrets to handle sensitive information like passwords and tokens, both of which can be injected into pods.
Persistent Volumes: Kubernetes abstracts storage resources through Persistent Volumes (PV) and Persistent Volume Claims (PVC), allowing containers to persist data beyond their lifecycle.
Horizontal Pod Autoscaling (HPA): Automatically scales the number of pods based on observed CPU utilization or other metrics, ensuring applications can handle varying loads.
Cluster Management: Kubernetes manages clusters of nodes (machines), ensuring they operate efficiently, with features like self-healing, automated rollouts, and rollbacks.
Monitoring and Logging: Kubernetes integrates with monitoring and logging tools (e.g., Prometheus, ELK stack) to track performance, health, and logs of applications running in the cluster.
Security: Kubernetes provides security features such as RBAC (Role-Based Access Control), network policies, and Pod Security Standards to ensure secure operations and access control.
Helm: A package manager for Kubernetes, Helm simplifies the deployment and management of applications within the cluster through reusable charts.
Extensibility: Kubernetes is highly extensible, allowing for custom resources, controllers, and operators to extend its functionality and automate complex tasks.
Community and Ecosystem: Kubernetes has a large, active community and a rich ecosystem of tools and integrations that enhance its capabilities and make it the de facto standard for container orchestration.

Simple Kubernetes Deployment Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80

This example creates a deployment named nginx-deployment with three replicas of the nginx container running version 1.21.6. The containers listen on port 80.

Kubernetes Hierarchy: Containers, Pods, and Nodes

1. Containers (Image Based)

Lowest Level Unit: Containers are the most granular and smallest deployable units that encapsulate an application and its dependencies.
Execution Environment: Containers run within Pods and provide the isolated environment necessary for running specific processes or services.
Image-based: Containers are created from container images, which define the application, its runtime, and libraries.

2. Pods (Smallest Deployable Units)

Next Level Up: Pods are the smallest deployable units in Kubernetes that can host one or more tightly coupled containers.
Shared Environment: Containers within a Pod share the same network namespace, storage volumes, and configuration, allowing them to communicate easily with each other.
Lifecycle Management: Kubernetes manages Pods, ensuring they are created, scheduled, and run on appropriate Nodes.

3. Nodes (Virtual Machines make up Kubernetes Cluster)

Highest Level Unit: Nodes are the physical or virtual machines that make up the Kubernetes cluster.
Hosting Pods: Nodes provide the necessary resources (CPU, memory, storage) to run Pods, which in turn run containers.
Cluster Component: Nodes are managed by the Kubernetes control plane, which schedules Pods onto Nodes based on resource availability and constraints.

Hierarchy Summary

Containers are the application units that run inside Pods.

Pods are the deployment units that encapsulate one or more containers, running on Nodes.

Nodes are the infrastructure units that provide the necessary resources to run Pods and manage the execution of containers within those Pods.

Difference Between Pods, Nodes, and Containers in Kubernetes

Containers

Lightweight and Portable: Containers are lightweight, portable units that package an application and its dependencies, allowing it to run consistently across different environments.
Run Inside Pods: In Kubernetes, containers run inside pods. A pod can host one or more containers, and these containers share the pod’s network and storage.
Isolation: Containers are isolated from each other and from the host system, which enhances security and reduces the risk of conflicts between applications.
Images: Containers are created from container images, which are snapshots of the application and its environment. Images can be stored in container registries like Docker Hub or private registries.
Resource Efficiency: Containers share the host system's kernel and resources, making them more efficient compared to traditional virtual machines.

Pods

Smallest Deployable Unit: Pods are the smallest deployable units in Kubernetes. A pod represents a single instance of a running process in your cluster.
Multiple Containers: A pod can contain one or more containers that are tightly coupled and share the same network namespace, storage, and configuration. Typically, one pod contains one container, but in some cases, multiple containers that need to work together are placed in the same pod.
Ephemeral: Pods are ephemeral in nature. They can be created and destroyed as needed. When a pod is deleted, it does not get restarted, and a new pod with a different name is created in its place if needed.
IP Address: Each pod has a unique IP address within the cluster, which allows the containers inside the pod to communicate with each other and other pods.
Use Cases: Pods are used to run application workloads. They encapsulate the environment in which containers run, including the container images, storage resources, and network settings.

Nodes

Cluster Component: Nodes are the physical or virtual machines that make up the Kubernetes cluster. A node provides the necessary environment for running pods.
Types: There are two main types of nodes in Kubernetes:
- Master Node: Manages the Kubernetes cluster and controls the scheduling of pods. It runs the control plane components like the API server, controller manager, and scheduler.
- Worker Node: Where the actual application workloads (pods) are run. Worker nodes have the necessary tools to manage and run containers.
Resources: Nodes have resources such as CPU, memory, storage, and network capacity. These resources are allocated to the pods running on the node.
Kubelet: Each node runs a process called the kubelet, which is responsible for communicating with the Kubernetes control plane and ensuring that the containers in the pods are running as expected.
Scalability: Nodes can be added or removed from the cluster to scale the environment horizontally. This allows the cluster to handle more workloads by distributing them across multiple nodes.

Summary

Pods are the smallest deployable units in Kubernetes, designed to host one or more containers that share the same environment and network. They are ephemeral and run the application workloads.

Nodes are the machines (physical or virtual) that make up the Kubernetes cluster. They provide the computational resources needed to run the pods and ensure that the containers within the pods are running correctly. Nodes are categorized into master nodes (which manage the cluster) and worker nodes (which run the application workloads).

Containers are lightweight, portable units that package an application and its dependencies. They run inside pods and provide isolation and resource efficiency, making them ideal for running applications in distributed environments like Kubernetes.

Kubernetes Deployments

What is a Kubernetes Deployment?

A Kubernetes Deployment is a resource object in Kubernetes that provides declarative updates to applications. Deployments manage the creation and scaling of a set of Pods and ensure that the desired number of Pods are running at any given time. They provide a way to manage the rollout of new versions of an application, rollback to previous versions, and scale the application up or down.

What is a Kubernetes Deployment used for?

Kubernetes Deployments are used to automate the management of application lifecycle, including the following:

Rolling Updates: Gradually updating the application to a new version without downtime.
Scaling: Adjusting the number of replicas (Pods) of an application to handle varying levels of load.
Self-Healing: Automatically replacing failed Pods to maintain the desired state.
Rollback: Reverting to a previous version of the application in case of issues with the new version.

Key Points about Kubernetes Deployments:

Declarative Configuration: Deployments use a declarative approach where you specify the desired state of your application, and Kubernetes ensures that the actual state matches the desired state.
Rolling Updates: Deployments support rolling updates, which allow you to update the application to a new version with minimal impact on the application's availability. Pods are updated incrementally, and old Pods are terminated only after the new Pods are running successfully.
Rollback Mechanism: Kubernetes Deployments provide an easy rollback mechanism. If a new update fails or has issues, you can quickly revert to a previous version of the Deployment.
Scaling: You can scale a Deployment up or down by simply changing the number of replicas in the Deployment specification. Kubernetes will automatically add or remove Pods to match the desired count.
Self-Healing: Deployments automatically replace unhealthy Pods or those that fail to meet the specified conditions, ensuring that the application remains in a healthy state.
ReplicaSets: Deployments manage ReplicaSets, which in turn manage the Pods. When you update a Deployment, Kubernetes creates a new ReplicaSet for the new Pods while keeping the old ReplicaSet around to facilitate rollbacks if necessary.

Most Asked Job Interview Questions and Answers on Kubernetes Deployments:

1. How do you create a Kubernetes Deployment?

Answer: A Kubernetes Deployment can be created using a YAML file or with the kubectl command. A basic YAML file for a Deployment includes metadata (like name and labels), specifications for the number of replicas, and a template for the Pods (which includes the container image, ports, and other settings). You can apply the Deployment with the kubectl apply -f deployment.yaml command.

2. What is a rolling update in Kubernetes, and how does it work?

Answer: A rolling update is a deployment strategy where Kubernetes gradually replaces old Pods with new Pods. The update proceeds incrementally, ensuring that a specified number of Pods are always running during the update. This strategy prevents downtime during application updates.

3. How can you roll back a Deployment in Kubernetes?

Answer: You can roll back a Deployment in Kubernetes using the kubectl rollout undo command. By default, it rolls back to the previous revision, but you can also specify a specific revision if needed.

4. How do you scale a Kubernetes Deployment?

Answer: You can scale a Deployment by changing the number of replicas in the Deployment's YAML file and applying the changes, or by using the kubectl scale command, for example, kubectl scale deployment my-deployment --replicas=5.

5. What is the difference between a Deployment and a StatefulSet?

Answer: Deployments are used for stateless applications where the identity of individual Pods is not important. StatefulSets, on the other hand, are used for stateful applications where each Pod requires a unique identity and persistent storage. StatefulSets are used for applications like databases where the state needs to be preserved across Pod restarts.

6. How does Kubernetes handle updates to a Deployment?

Answer: Kubernetes handles updates to a Deployment by creating a new ReplicaSet for the updated Pods and gradually replacing the old Pods with the new ones. The update can be configured to proceed at a specified rate, and the progress of the update can be monitored with the kubectl rollout status command.

7. What is a ReplicaSet in Kubernetes, and how is it related to Deployments?

Answer: A ReplicaSet is a Kubernetes resource that ensures a specified number of Pods are running at any given time. A Deployment manages one or more ReplicaSets to orchestrate rolling updates, rollbacks, and scaling. While you can create and manage ReplicaSets directly, it is more common to use Deployments to manage ReplicaSets for you.

Conclusion:

Kubernetes Deployments are a powerful tool for managing the lifecycle of applications in a Kubernetes cluster. Understanding how to create, update, scale, and roll back Deployments is essential for maintaining reliable and scalable applications. In interviews, be prepared to discuss your experience with Kubernetes Deployments, focusing on how you've used them to manage application updates, ensure high availability, and handle scaling.

CPU Usage in Kubernetes Pods

Can a Kubernetes Pod Use More than 1 CPU?

Yes, a Kubernetes Pod can use more than 1 CPU, and it is configurable.

CPU Resource Requests and Limits in Kubernetes

CPU Request: This is the amount of CPU that a Pod is guaranteed to have. Kubernetes uses this value to schedule Pods on nodes that have sufficient resources. For example, if a Pod requests 1 CPU, Kubernetes will ensure that the node where the Pod is scheduled has at least 1 CPU available for that Pod.

CPU Limit: This is the maximum amount of CPU that a Pod can use. If a Pod's process tries to exceed this limit, Kubernetes will throttle the CPU usage, ensuring that the Pod does not consume more than the specified amount.

Configuring CPU Requests and Limits

You can configure the CPU request and limit in the Pod or container definition using the resources field in the Pod's YAML file. Here's an example:

apiVersion: v1
kind: Pod
metadata:
  name: cpu-limits-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      requests:
        cpu: "0.5"       # Requesting 0.5 CPU (500 millicores)
      limits:
        cpu: "2"         # Limiting to 2 CPUs

Understanding CPU Units

1 CPU in Kubernetes:

1 CPU in Kubernetes equals 1 core on a node's CPU, or 1 virtual CPU (vCPU) in a cloud environment.
You can specify fractional CPUs like 0.5 (which means 500 millicores or half of a CPU).

Millicores: CPU resources can be specified in millicores, where 1000m equals 1 CPU. So 500m would be equivalent to 0.5 CPUs.

Multiple CPUs for a Pod

If you want a Pod to use more than 1 CPU, you would set the cpu limit to a value greater than 1. For example, setting cpu: "2" means the Pod can use up to 2 CPUs.

Example with Multiple CPUs

apiVersion: v1
kind: Pod
metadata:
  name: multi-cpu-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      requests:
        cpu: "1"       # Requesting 1 CPU
      limits:
        cpu: "4"       # Limiting to 4 CPUs

In this example:

The Pod is guaranteed 1 CPU (requests.cpu: "1").
The Pod can use up to 4 CPUs (limits.cpu: "4"), but no more than that.

Conclusion

Yes, a Kubernetes Pod can use more than 1 CPU, and it is configurable through the resources field in the Pod's specification. By setting appropriate requests and limits, you can control how much CPU a Pod can use, ensuring it gets the resources it needs while preventing it from overconsuming.