Prepare for your Kubernetes interviews with this curated list of 100 basic questions covering fundamental concepts, architecture, and components.

What is Kubernetes?h2

Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. It groups containers into logical units called pods, which are scheduled across a cluster of nodes. Kubernetes simplifies tasks like load balancing, service discovery, and auto-scaling while ensuring high availability and fault tolerance. It supports declarative configuration, allowing users to define desired states, and its control plane maintains those states. Key components include the API server, scheduler, controller manager, and etcd for state storage. It’s widely used for microservices and cloud-native applications.

What are K8s?h2

K8s is a shorthand term for Kubernetes, derived from replacing the eight letters between “K” and “s” with the number “8.” It’s an open-source platform designed to automate the deployment, scaling, and management of containerized applications. K8s organizes containers into pods, which run on a cluster of nodes, and provides features like auto-scaling, load balancing, service discovery, and self-healing. It uses a declarative approach, where users define the desired state, and the control plane ensures the cluster matches that state. Key components include the API server, scheduler, and etcd. K8s is widely adopted for managing cloud-native and microservices-based applications efficiently.

What is orchestration when it comes to software and DevOps?h2

Orchestration in software and DevOps refers to the automated management, coordination, and deployment of complex systems, particularly containerized applications. It involves organizing multiple containers to work together seamlessly, handling tasks like scheduling, scaling, load balancing, and fault recovery. In DevOps, orchestration tools like Kubernetes streamline workflows by automating resource allocation, service discovery, and application updates across a cluster. This ensures high availability, efficient resource use, and consistent environments. Orchestration reduces manual intervention, enabling teams to deploy and manage applications at scale while maintaining reliability and performance.

How are Kubernetes and Docker related?h2

Kubernetes and Docker are complementary technologies for managing containerized applications. Docker is a platform that creates, runs, and packages containers, which are lightweight, portable units for applications. Kubernetes is an orchestration system that automates the deployment, scaling, and management of these containers across a cluster of nodes. Kubernetes uses Docker (or other container runtimes like containerd) to execute containers within pods. While Docker handles container creation and runtime, Kubernetes manages scheduling pods, load balancing, auto-scaling, and self-healing. Together, they enable efficient development, deployment, and scaling of cloud-native applications, with Kubernetes relying on Docker for container execution.

What are the features of Kubernetes?h2

Kubernetes offers key features for managing containerized applications:

• Container Orchestration: Automates deployment, scaling, and management of containers across a cluster.
• Auto-scaling: Adjusts the number of pods or nodes based on demand (horizontal/vertical scaling).
• Self-healing: Automatically restarts, reschedules, or replaces failed pods to ensure availability.
• Service Discovery and Load Balancing: Distributes traffic across pods and enables communication via DNS or IP.
• Storage Orchestration: Integrates with storage systems to provide persistent storage for applications.
• Automated Rollouts and Rollbacks: Manages application updates and reverts if issues arise.
• Configuration Management: Handles secrets and configuration data securely without rebuilding images.
• Resource Management: Allocates CPU, memory, and other resources efficiently to pods.
• Multi-cloud Support: Runs on various cloud providers or on-premises infrastructure.
• Extensibility: Supports custom resources and plugins for tailored functionality.

These features enable reliable, scalable, and efficient management of cloud-native applications.

What is a pod in Kubernetes?h2

A pod in Kubernetes is the smallest deployable unit, consisting of one or more containers that share storage, network, and a specification for how to run. Containers in a pod share the same IP address, port space, and localhost communication, enabling tight integration. Pods are ephemeral, managed by the Kubernetes control plane, and scheduled onto nodes. They can be created directly or managed via controllers like Deployments for scaling and updates. Pods support sidecar containers for tasks like logging or monitoring, enhancing application functionality. They ensure efficient resource sharing and simplified management in a cluster.

What is Minikube?h2

Minikube is a lightweight tool for running a single-node Kubernetes cluster locally on a developer’s machine. It’s designed for testing, learning, or developing Kubernetes applications in a simplified environment. Minikube creates a virtual machine (or runs directly on Docker) to simulate a Kubernetes cluster, including core components like the API server, scheduler, and kubelet. It supports features like local storage, networking, and container runtimes, making it ideal for experimenting with Kubernetes without needing a full production setup. Minikube is easy to install and use, perfect for beginners or developers prototyping applications.

What is a Namespace in Kubernetes?h2

A Namespace in Kubernetes is a virtual partition within a cluster, used to organize and isolate resources like pods, services, and deployments. It enables multiple teams or projects to share the same cluster while maintaining separation, preventing naming conflicts and simplifying resource management. Default namespaces include “default” for general use, “kube-system” for system components, and “kube-public” for public resources. Namespaces support role-based access control (RBAC) for fine-grained permissions and resource quotas to limit usage, ensuring efficient and secure multi-tenancy in Kubernetes clusters.

Name the initial namespaces from which Kubernetes starts.h2

Kubernetes starts with three initial namespaces: “default,” “kube-system,” and “kube-public.” The “default” namespace is used for resources when no namespace is specified. “Kube-system” hosts system components like the API server, scheduler, and core add-ons. “Kube-public” contains publicly accessible resources, such as cluster information. These namespaces provide a foundational structure for organizing resources, enabling isolation and management within a Kubernetes cluster.

What is ClusterIP?h2

ClusterIP is the default Kubernetes service type, providing an internal virtual IP address for a set of pods within a cluster. It enables communication between pods without exposing them externally. The ClusterIP is accessible only within the cluster, abstracting pod IP changes and ensuring reliable service discovery. It uses kube-proxy to balance traffic across pods matching the service’s selector. This service type is ideal for internal microservices communication, such as connecting a frontend to a backend. Configuration is managed via YAML, specifying ports and selectors to route traffic efficiently.

What is NodePort?h2

NodePort is a Kubernetes service type that exposes a set of pods to external traffic by assigning a specific port on each cluster node. The port, typically in the range 30000–32767, is mapped to the service’s internal port, allowing access via <NodeIP>:<NodePort>. It builds on ClusterIP, enabling external communication while maintaining internal load balancing across pods. NodePort is useful for testing or when direct pod access is needed, but it’s less secure for production due to its static port exposure. Configuration is defined in a service YAML file, specifying the port and target pod selector.

What is Kubectl?h2

Kubectl is the command-line tool for interacting with Kubernetes clusters. It communicates with the Kubernetes API server to manage resources like pods, services, deployments, and namespaces. Users can create, update, delete, or inspect resources using commands like kubectl apply, kubectl get, or kubectl delete. It supports declarative configurations via YAML or JSON files and provides debugging tools like kubectl logs and kubectl exec. Kubectl is essential for administrators and developers to deploy applications, scale resources, and monitor cluster health, offering a flexible and powerful interface for Kubernetes management.

What is a Deployment in Kubernetes?h2

A Deployment in Kubernetes manages stateless applications by defining a desired state for pods and ensuring the cluster matches it. It uses a YAML configuration to specify the number of pod replicas, container images, and update strategies. Deployments handle rolling updates, rollbacks, and scaling, ensuring zero downtime during changes. They work with ReplicaSets to maintain the desired number of pods, automatically replacing failed ones. This abstraction simplifies application management, providing reliability and consistency for stateless workloads like web servers, making it easier to update and scale applications efficiently.

What is a Kubernetes Service, and why is it needed?h2

A Kubernetes Service is an abstraction that defines a logical set of pods and a policy to access them, typically via a single IP address or DNS name. It enables communication between application components within a cluster or externally, abstracting pod IP changes due to scaling or failures. Services use selectors to target pods and support types like ClusterIP (internal), NodePort (external via node ports), and LoadBalancer (cloud-provider integration). They provide load balancing, service discovery, and stable networking, ensuring reliable connectivity for microservices. Services are needed to maintain consistent access to dynamic pods, simplify networking, and support scalability and resilience in Kubernetes applications.

What service types are available at Kubernetes Services?h2

Kubernetes Services offer four main types to manage pod access and networking:

• ClusterIP: The default type, assigns an internal virtual IP for pod communication within the cluster. Ideal for internal microservices.

• NodePort: Exposes the service on a specific port (30000–32767) of each node, allowing external access via <NodeIP>:<NodePort>. Useful for testing or limited external access.

• LoadBalancer: Integrates with cloud providers to provision an external load balancer, assigning a public IP to route traffic to pods. Suited for production-grade external access.

• ExternalName: Maps a service to an external DNS name without creating a local proxy, redirecting traffic to external endpoints. Used for integrating external services.

These types enable flexible networking, load balancing, and service discovery for various application needs.

What is the role of ConfigMaps and secrets in Kubernetes?h2

ConfigMaps and Secrets in Kubernetes manage configuration data and sensitive information for applications.

• ConfigMaps: Store non-sensitive configuration data, like environment variables, command-line arguments, or configuration files, in key-value pairs. They decouple configuration from container images, enabling dynamic updates without rebuilding. ConfigMaps can be mounted as volumes or passed as environment variables to pods.

• Secrets: Handle sensitive data, such as passwords, API keys, or certificates, encoded in base64. They ensure secure storage and access, with stricter access controls than ConfigMaps. Secrets can also be mounted as volumes or environment variables, and Kubernetes encrypts them at rest (if configured).

Both allow applications to remain portable and reusable across environments by externalizing configuration. They simplify updates, enhance security, and support scalable, maintainable deployments in Kubernetes clusters.

What are Labels and Selectors in Kubernetes?h2

Labels and Selectors in Kubernetes organize and manage resources efficiently.

• Labels: Key-value pairs attached to resources like pods, services, or deployments. They identify and categorize objects, enabling flexible grouping based on attributes (e.g., app=frontend, env=prod). Labels are metadata for querying and managing resources.

• Selectors: Mechanisms to filter resources based on labels. They define how Kubernetes components, like services or deployments, identify pods to manage or route traffic to. Selectors can be equality-based (e.g., app=frontend) or set-based (e.g., env in (prod, dev)).

Labels allow resources to be tagged for easy identification, while selectors enable dynamic grouping for tasks like load balancing, scaling, or updates. Together, they provide a powerful way to manage and orchestrate resources in a Kubernetes cluster, ensuring flexibility and scalability.

What are Persistent Volumes (PVs) and Persistent Volume Claims (PVCs)?h2

Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) manage storage in Kubernetes.

• Persistent Volumes: PVs are cluster-wide storage resources provisioned by administrators or dynamically via storage classes. They define storage details like capacity, access modes (e.g., ReadWriteOnce), and backend storage (e.g., NFS, cloud storage). PVs are independent of pods, ensuring data persistence.

• Persistent Volume Claims: PVCs are requests by users or applications for storage from PVs. They specify requirements like size and access mode, binding to a matching PV. Pods use PVCs to mount storage, abstracting the underlying PV details.

PVs provide a pool of storage, while PVCs allow pods to consume it dynamically, enabling scalable and portable storage management. This abstraction supports data persistence across pod lifecycles, crucial for stateful applications like databases.

What is Kubelet?h2

Kubelet is a key agent running on each Kubernetes node, responsible for managing pods and ensuring they run as specified. It communicates with the Kubernetes API server to receive pod definitions and instructions from the control plane. Kubelet ensures containers within pods are healthy, running, and properly configured by interacting with the container runtime (e.g., Docker, containerd). It monitors pod status, executes health checks (liveness/readiness probes), and reports node metrics. Kubelet also mounts volumes, manages container lifecycles, and handles node-level tasks like logging and resource allocation, ensuring the node aligns with the desired cluster state.

What is the Google Container Engine?h2

Google Container Engine (GKE) is Google’s managed service for running Kubernetes, an open-source container orchestration platform. It automates the deployment, scaling, and management of containerized applications on Google Cloud infrastructure, using Compute Engine instances as nodes in clusters. Originally launched as Google Container Engine, it was rebranded to Google Kubernetes Engine in 2017, with the same abbreviation. GKE handles the control plane, providing features like auto-scaling, load balancing, self-healing, and integration with Google services for monitoring and security, allowing developers to focus on applications rather than infrastructure.

What is ‘Heapster’ in Kubernetes?h2

Heapster is a legacy monitoring tool in Kubernetes used to collect and aggregate performance metrics from cluster nodes and pods. It gathers data like CPU, memory, and network usage, making it available for visualization and analysis. Heapster runs as a pod, pulling metrics from kubelets and storing them in a backend like InfluxDB or Prometheus. It enables cluster-wide monitoring, helping administrators track resource utilization and troubleshoot issues. However, Heapster is deprecated in favor of more modern tools like Metrics Server and Prometheus, which offer better scalability and integration for Kubernetes monitoring needs.

What is the Kubernetes controller manager?h2

The Kubernetes Controller Manager is a core control plane component that runs controller processes to maintain the desired state of the cluster. It includes multiple controllers, such as the Node Controller (monitors node health), Replication Controller (ensures the correct number of pod replicas), Deployment Controller (manages application updates), and Service Controller (handles service configurations). Running as a single process, it continuously compares the cluster’s current state with the desired state defined in the API server, taking corrective actions when needed. This ensures resources like pods, deployments, and services operate reliably, supporting scalability and fault tolerance in Kubernetes.

What are the types of controller managers?h2

The Kubernetes Controller Manager includes several types of controllers to maintain the cluster’s desired state:

• Node Controller: Monitors node health, marks nodes as unreachable if they fail, and manages node lifecycle events.
• Replication Controller: Ensures the specified number of pod replicas are running, scaling up or down as needed.
• Deployment Controller: Manages application deployments, handling rolling updates, rollbacks, and scaling for stateless applications.
• StatefulSet Controller: Manages stateful applications, ensuring ordered pod creation, stable network identities, and persistent storage.
• DaemonSet Controller: Ensures a pod runs on every node (or a subset), ideal for cluster-wide services like logging or monitoring.
• Job Controller: Manages finite tasks, running pods to completion for batch processing.
• CronJob Controller: Schedules jobs to run at specific times or intervals.
• Service Controller: Manages service endpoints and load balancing.

These controllers work together to enforce the desired cluster state, ensuring reliability and scalability.

What is etcd?h2

etcd is a distributed key-value store used in Kubernetes to store all cluster data, such as configuration, state, and metadata. It acts as the cluster’s primary database, holding information about pods, services, deployments, and nodes. etcd ensures consistency and reliability through a distributed consensus algorithm (Raft), enabling high availability and fault tolerance. The Kubernetes API server interacts with etcd to persist and retrieve cluster state, making it critical for control plane operations. It supports watch operations for real-time updates and is typically deployed on control plane nodes, ensuring secure and scalable cluster management.

What is the LoadBalancer in Kubernetes?h2

A LoadBalancer in Kubernetes is a service type that exposes an application to external traffic by provisioning a cloud provider’s load balancer. It assigns a public IP address to route external requests to a set of pods, distributing traffic across them for scalability and reliability. The LoadBalancer integrates with cloud platforms like AWS, Google Cloud, or Azure, automatically configuring their load balancing infrastructure. It builds on ClusterIP, using selectors to target pods and kube-proxy for internal traffic management. This service type is ideal for production-grade applications requiring stable, high-availability external access, such as web services or APIs.

What is a headless service?h2

A headless service in Kubernetes is a service that does not assign a ClusterIP, allowing direct communication with individual pods instead of load balancing across them. Defined by setting clusterIP: None in the service YAML, it relies on DNS to return the IP addresses of all pods matching the service’s selector. This is useful for stateful applications, like databases, where clients need to connect to specific pods rather than a single endpoint. Headless services are commonly used with StatefulSets to enable stable network identities and direct pod-to-pod communication, supporting scenarios requiring precise control over pod access.

What is Kube-proxy?h2

Kube-proxy is a network proxy running on each Kubernetes node, responsible for managing network rules to enable communication between pods and services. It maintains network connectivity by implementing service discovery and load balancing for ClusterIP, NodePort, and LoadBalancer services. Kube-proxy operates in modes like iptables, IPVS, or userspace (deprecated), creating rules to route traffic to the correct pods based on service selectors. It ensures external and internal traffic reaches the appropriate pods, handles pod IP changes, and supports session affinity when needed. Kube-proxy is critical for reliable, scalable networking in Kubernetes clusters.

What do you understand by a node in Kubernetes?h2

A node in Kubernetes is a single machine, physical or virtual, within a cluster that runs containerized applications. It hosts pods, which contain one or more containers, and provides the necessary compute, memory, and storage resources. Nodes are managed by the Kubernetes control plane and run essential components like the kubelet (for pod management and communication with the API server), kube-proxy (for networking and load balancing), and a container runtime (e.g., Docker or containerd) to execute containers. Worker nodes handle application workloads, while control plane nodes manage cluster operations, ensuring efficient resource allocation and application execution across the cluster.

What are the main components of Kubernetes architecture?h2

Kubernetes architecture consists of key components split between the control plane and worker nodes.

• Control Plane Components:

  • API Server: Acts as the cluster’s front-end, handling RESTful API requests and managing cluster state.
  • etcd: A distributed key-value store that persists all cluster data, ensuring consistency.
  • Scheduler: Assigns pods to nodes based on resource availability, constraints, and policies.
  • Controller Manager: Runs controllers (e.g., Deployment, ReplicaSet) to maintain desired cluster state.
  • Cloud Controller Manager (optional): Integrates with cloud providers for resources like load balancers.

• Node Components:

  • Kubelet: Manages pods on each node, ensuring containers run as specified.
  • Kube-proxy: Handles networking, implementing service discovery and load balancing.
  • Container Runtime: Executes containers (e.g., Docker, containerd).

These components work together to automate deployment, scaling, and management of containerized applications, ensuring reliability and scalability across the cluster.

What is the role of Kube-apiserver?h2

The Kube-apiserver is the central component of the Kubernetes control plane, serving as the primary interface for managing the cluster. It exposes the Kubernetes API, handling RESTful requests from users, clients, and other components to create, update, or query resources like pods, services, and deployments. It validates and processes these requests, updating the cluster state in etcd, the distributed key-value store. The API server authenticates and authorizes requests, enforces policies, and coordinates with other control plane components like the scheduler and controller manager. It’s critical for cluster communication, enabling declarative management and ensuring the desired state is maintained across the cluster.

What process runs on the Kubernetes Master Node?h2

The Kubernetes Master Node, also known as the control plane node, runs several critical processes to manage the cluster:

• API Server (kube-apiserver): Handles API requests, serving as the primary interface for cluster management and state updates in etcd.
• etcd: Stores the cluster’s configuration and state data, ensuring consistency and reliability.
• Scheduler (kube-scheduler): Assigns pods to nodes based on resource availability, policies, and constraints.
• Controller Manager (kube-controller-manager): Runs controllers like Deployment and ReplicaSet to maintain the desired cluster state.
• Cloud Controller Manager (optional): Integrates with cloud providers for resources like load balancers or storage, if running in a cloud environment.

These processes work together to orchestrate cluster operations, manage resources, and ensure the desired state of applications is maintained across worker nodes.

What is the job of the kube-scheduler?h2

The kube-scheduler is a Kubernetes control plane component responsible for assigning pods to nodes in the cluster. It evaluates resource requirements, such as CPU and memory, and matches them with available node capacity. The scheduler considers constraints like node selectors, taints, tolerations, and affinity/anti-affinity rules to ensure optimal placement. It also accounts for policies, such as spreading pods for high availability or prioritizing nodes for efficiency. By continuously monitoring the cluster state via the API server, the kube-scheduler ensures workloads are distributed effectively, balancing performance, resource utilization, and fault tolerance across the cluster.

What is a cluster of containers in Kubernetes?h2

A cluster of containers in Kubernetes refers to a group of containerized applications running across multiple nodes managed by Kubernetes. The cluster consists of a control plane and worker nodes. The control plane, including components like the API server, etcd, scheduler, and controller manager, orchestrates the cluster. Worker nodes run pods, which are the smallest units containing one or more containers that share storage and network resources. Containers within pods are co-located, communicate via localhost, and are managed by the kubelet and container runtime (e.g., Docker, containerd). The cluster enables automated deployment, scaling, load balancing, and self-healing, ensuring reliable and scalable application management across nodes.

What are Daemon sets?h2

A DaemonSet in Kubernetes ensures that a single pod runs on every node in the cluster (or a subset of nodes, based on node selectors or taints/tolerations). It is used for deploying system-level services, such as logging agents (e.g., Fluentd), monitoring tools (e.g., Prometheus Node Exporter), or networking components, which need to run on each node. DaemonSets automatically create new pods when nodes are added to the cluster and remove them when nodes are removed. They are defined in YAML, specifying the pod template and optional node affinity. This ensures consistent, cluster-wide deployment of critical background processes for infrastructure tasks.

What is Container Orchestration?h2

Container orchestration automates the management, deployment, scaling, and networking of containerized applications. In Kubernetes, it involves coordinating containers across a cluster to ensure efficient operation. Key tasks include scheduling containers (pods) onto nodes based on resource needs, auto-scaling to handle varying workloads, load balancing for traffic distribution, and self-healing to replace failed containers. It also manages service discovery, storage allocation, and rolling updates for zero-downtime deployments. Orchestration simplifies complex tasks like maintaining high availability, optimizing resource utilization, and ensuring consistent application performance, making it essential for running scalable, reliable microservices in production environments.

What is the need for Container Orchestration?h2

Container orchestration addresses the complexity of managing containerized applications at scale. It automates critical tasks like deploying containers across nodes, ensuring optimal resource utilization, and maintaining desired application states. Orchestration enables auto-scaling to handle fluctuating workloads, load balancing for efficient traffic distribution, and self-healing to recover from container or node failures. It simplifies service discovery, networking, and storage management, ensuring seamless communication between containers. Without orchestration, manually managing hundreds or thousands of containers across clusters becomes error-prone and inefficient. Tools like Kubernetes provide a scalable, reliable framework to streamline operations, reduce downtime, and support microservices architectures in production environments.

What do you know about clusters in Kubernetes?h2

A Kubernetes cluster is a set of nodes (physical or virtual machines) that work together to run containerized applications. It consists of two main parts:

• Control Plane: Manages the cluster, including the API server (handles requests), etcd (stores cluster state), scheduler (assigns pods to nodes), and controller manager (maintains desired state). These components ensure cluster coordination and management.

• Worker Nodes: Run application workloads via pods, which group containers sharing storage and network. Each node has a kubelet (manages pods), kube-proxy (handles networking), and a container runtime (e.g., Docker, containerd) to execute containers.

Clusters enable automated deployment, scaling, load balancing, and self-healing. They support high availability by distributing pods across nodes and recovering from failures. Clusters can span multiple environments (cloud or on-premises) and use namespaces for resource isolation, making them essential for managing scalable, resilient microservices applications efficiently.

How does Kubernetes simplify containerized Deployment?h2

Declarative Configuration

Kubernetes uses YAML or JSON manifests to define desired states for deployments, services, and pods. Apply changes with kubectl apply, and the system reconciles the cluster automatically, reducing manual scripting and errors.

Automated Rollouts and Rollbacks

Deployments handle rolling updates with zero downtime, gradually replacing old pods with new ones. If issues arise, automatic rollbacks revert to previous versions, simplifying version management.

Abstraction of Infrastructure

It abstracts underlying nodes, storage, and networking. Pods are scheduled based on resource needs, and services provide stable endpoints, eliminating manual IP tracking or server provisioning.

Self-Healing and Scaling

Kubernetes monitors pods and restarts failed ones, reschedules them on healthy nodes, and auto-scales based on metrics like CPU usage, ensuring reliability without constant oversight.

Integrated Tools

Built-in features like ConfigMaps, Secrets, and Ingress manage configurations and external access, streamlining the entire CI/CD pipeline for faster, more consistent deployments.

What does the node status contain?h2

Node Status Components

The node status in Kubernetes provides critical information about a node’s health and operational state, including:

• Conditions: Indicates node health with statuses like Ready (node is operational), DiskPressure (low disk space), MemoryPressure (low memory), PIDPressure (process ID limits), and NetworkUnavailable (network issues).
• Addresses: Lists node’s IP addresses (e.g., InternalIP, ExternalIP, Hostname) for network communication.
• Capacity and Allocatable Resources: Shows total and available resources (CPU, memory, pods) for scheduling.
• Info: Details about the node, including Kubernetes version, container runtime, operating system, and kernel version.
• Taints and Tolerations: Indicates restrictions on pod scheduling (e.g., taints for control plane nodes).
• Phase: Reflects node lifecycle state (e.g., Running, Terminated).

This information, reported by the kubelet to the API server, helps administrators monitor node health and troubleshoot issues effectively.

What are minions in the Kubernetes cluster?h2

Minions in a Kubernetes cluster are an outdated term for worker nodes, used in early versions of Kubernetes (pre-v1.0). They refer to the individual machines (physical or virtual) that run the actual application workloads. Each minion (now called a node) hosts pods containing containers, managed by the kubelet for pod lifecycle, kube-proxy for networking, and a container runtime like Docker.

Role and Components

• Workload Execution: Run user-defined pods and handle compute tasks.
• Resource Management: Provide CPU, memory, and storage for applications.
• Communication: Report status to the master (control plane) via the API server.

The term “minion” has been deprecated in favor of “node” for clarity, but the concept remains: worker nodes execute the cluster’s containerized applications under the control plane’s orchestration.

Kubernetes cluster data is stored in which of the following?h2

Kubernetes cluster data is stored in etcd, a distributed key-value store. It serves as the cluster’s primary database, holding all configuration, state, and metadata, such as details about pods, services, deployments, and nodes. etcd ensures data consistency and reliability using the Raft consensus algorithm, supporting high availability and fault tolerance. The Kubernetes API server interacts with etcd to persist and retrieve cluster state, enabling real-time updates and watch operations. Typically deployed on control plane nodes, etcd is critical for maintaining the cluster’s desired state and enabling effective management of resources.

Which of them is a Kubernetes Controller?h2

In Kubernetes, a controller is a control plane process that manages resources to maintain the desired state. Common Kubernetes controllers include:

• Deployment Controller: Manages stateless applications, handling rolling updates, rollbacks, and scaling of pods.
• ReplicaSet Controller: Ensures the specified number of pod replicas are running.
• StatefulSet Controller: Manages stateful applications with stable pod identities and persistent storage.
• DaemonSet Controller: Ensures a pod runs on every node (or a subset) for cluster-wide services.
• Job Controller: Runs pods for finite tasks, ensuring completion.
• CronJob Controller: Schedules jobs to run at specific times or intervals.
• Node Controller: Monitors node health and manages node lifecycle.
• Service Controller: Manages service endpoints and load balancing.

These controllers, part of the kube-controller-manager, continuously reconcile the cluster’s current state with the desired state defined in the API server, ensuring reliability and scalability.

Which of the following are core Kubernetes objects?h2

Core Kubernetes objects are fundamental resources used to define and manage applications in a cluster. They include:

• Pod: The smallest deployable unit, containing one or more containers that share storage and network.
• Service: An abstraction for accessing a set of pods, providing load balancing and stable networking (e.g., ClusterIP, NodePort).
• Deployment: Manages stateless applications, handling scaling, updates, and rollbacks via ReplicaSets.
• Namespace: Partitions resources for isolation, enabling multi-tenancy and organization within a cluster.

Other core objects include ConfigMap (for configuration data), Secret (for sensitive data), PersistentVolume (for storage), and PersistentVolumeClaim (for storage requests). These objects form the foundation for building and orchestrating containerized applications, ensuring scalability, reliability, and efficient resource management in Kubernetes.

The Kubernetes Network proxy runs on which node?h2

The Kubernetes network proxy, kube-proxy, runs on every node in the cluster, including both worker nodes and control plane nodes. It manages network rules to enable communication between pods and services, implementing service discovery and load balancing for service types like ClusterIP, NodePort, and LoadBalancer. Operating in modes such as iptables or IPVS, kube-proxy ensures traffic is routed correctly to pods based on service selectors, handling dynamic pod IP changes and maintaining network connectivity across the cluster for reliable application access.

What are the responsibilities of a node controller?h2

The node controller, part of the Kubernetes Controller Manager, manages node lifecycle and health in the cluster. Its responsibilities include:

• Node Monitoring: Tracks node status via heartbeats from kubelet, updating conditions like Ready or NotReady.
• Node Health Checks: Detects node failures (e.g., network issues or crashes) and marks nodes as unreachable if they stop responding.
• Pod Eviction: Initiates eviction of pods from unhealthy nodes to maintain workload availability, rescheduling them to healthy nodes.
• Node Lifecycle Management: Handles node addition or removal, updating cluster state in the API server.
• Resource Reporting: Collects and reports node resource data (CPU, memory) for scheduling decisions.

By continuously reconciling node states with the desired cluster configuration, the node controller ensures high availability and efficient resource utilization across the Kubernetes cluster.

What are the responsibilities of Replication Controller?h2

The Replication Controller in Kubernetes ensures a specified number of pod replicas are running at all times. Its responsibilities include:

• Maintaining Desired Pod Count: Monitors the cluster to ensure the defined number of pod replicas matches the actual count, creating or deleting pods as needed.
• Pod Replacement: Automatically replaces failed, crashed, or terminated pods to maintain the desired state.
• Scaling: Adjusts the number of pods based on user-defined replica counts, supporting manual scaling.
• Label-Based Management: Uses selectors to identify and manage pods with specific labels, ensuring accurate targeting.
• Cluster Stability: Works with the API server to reconcile the current state with the desired state, ensuring high availability.

Though largely replaced by ReplicaSets and Deployments for advanced features like rolling updates, the Replication Controller provides basic replication and fault tolerance for stateless applications in Kubernetes.

How to define a service without a selector?h2

To define a Kubernetes Service without a selector, you create a service that does not automatically target pods based on labels. Instead, you manually specify endpoints or use it for external resources. Here’s how:

• Manual Endpoints: Define a service without a selector field in the YAML. Then, create an Endpoints object with the same name as the service, specifying the IP addresses and ports of the target endpoints (e.g., external databases or servers).

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  ---
  apiVersion: v1
  kind: Endpoints
  metadata:
    name: my-service
  subsets:
  - addresses:
    - ip: 192.168.1.100
    ports:
    - port: 8080

• ExternalName Service: Use type: ExternalName to map the service to an external DNS name without a selector or local proxy.

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    type: ExternalName
    externalName: example.com

This approach is useful for accessing external resources or custom endpoints without relying on pod labels.

What did the 1.8 version of Kubernetes introduce?h2

Kubernetes 1.8, released in September 2017, introduced several key features and enhancements:

• Role-Based Access Control (RBAC): Stabilized RBAC authorization, enabling fine-grained access control for cluster resources, improving security.
• Workload API Enhancements: Advanced the Apps/v1beta1 API, improving support for stateful workloads and introducing features like StatefulSet updates.
• Taints and Tolerations: Improved node scheduling with better taint/toleration mechanisms, allowing more precise pod placement control.
• Security Improvements: Added support for workload identity and pod security policies to enhance cluster security.
• Storage Enhancements: Introduced volume resizing for certain storage types and improved persistent volume management.
• Networking Features: Enhanced network policy APIs for better control over pod communication.

These updates focused on improving security, workload management, and cluster scalability, making Kubernetes more robust for production environments.

What is the difference between deploying applications on hosts and containers?h2

Deploying applications on hosts (traditional VMs or bare metal) versus containers differs in several ways:

• Isolation and Resource Usage: Hosts run full OS instances, consuming more resources and providing stronger isolation but at higher overhead. Containers share the host OS kernel, offering lightweight isolation with lower CPU/memory usage, enabling denser deployments.

• Portability: Containers package applications with dependencies into portable images, deployable across environments (dev, prod, cloud) without reconfiguration. Host deployments often require OS-specific tweaks, reducing portability.

• Scalability and Management: Containers support orchestration tools like Kubernetes for automated scaling, load balancing, and self-healing. Host deployments rely on manual scripting or tools like Ansible, making scaling complex and time-consuming.

• Deployment Speed and Updates: Containers allow rapid, immutable deployments via images and rolling updates with zero downtime. Host updates involve patching OS/applications, risking inconsistencies and downtime.

• Security: Containers reduce attack surface by minimizing OS components but require runtime security. Hosts offer broader isolation but expose more vulnerabilities.

Containers excel in microservices and cloud-native apps for efficiency and agility, while hosts suit monolithic or legacy applications needing full OS control.

What are the main differences between the Docker Swarm and Kubernetes?h2

Docker Swarm and Kubernetes are container orchestration platforms, but they differ significantly:

• Architecture and Complexity: Kubernetes has a more complex architecture with a control plane (API server, etcd, scheduler) and worker nodes, offering robust features but a steeper learning curve. Docker Swarm is simpler, with a native Docker API integration, making it easier for smaller deployments.

• Scalability: Kubernetes excels in large-scale, production-grade clusters, supporting thousands of nodes and advanced scheduling. Docker Swarm is better for smaller clusters, with less overhead but limited scalability.

• Features and Extensibility: Kubernetes provides extensive features like auto-scaling, RBAC, StatefulSets, and network policies, with a rich ecosystem of plugins. Docker Swarm offers basic orchestration (replication, load balancing) but lacks advanced workload management.

• Networking: Kubernetes uses services (ClusterIP, NodePort) and supports complex network policies. Swarm uses overlay networks with simpler load balancing but less granular control.

• Community and Adoption: Kubernetes has a larger community, broader cloud provider support, and is the industry standard. Docker Swarm, while integrated with Docker, has seen declining adoption.

Kubernetes is ideal for complex, scalable applications; Docker Swarm suits simpler, Docker-centric workflows.

Explain Kubernetes Architecture.h2

Kubernetes architecture consists of a distributed system designed to manage containerized applications across a cluster, divided into the control plane and worker nodes.

• Control Plane: The management layer, typically running on master nodes, includes:

  • API Server (kube-apiserver): Handles RESTful API requests, serving as the cluster’s front-end for managing resources like pods and services.
  • etcd: A distributed key-value store that persists cluster state and configuration data.
  • Scheduler (kube-scheduler): Assigns pods to nodes based on resource needs, constraints, and policies.
  • Controller Manager (kube-controller-manager): Runs controllers (e.g., Deployment, ReplicaSet) to maintain desired states.
  • Cloud Controller Manager (optional): Integrates with cloud providers for resources like load balancers.

• Worker Nodes: Execute application workloads and include:

  • Kubelet: Manages pods, ensuring containers run as specified via the API server.
  • Kube-proxy: Manages networking, enabling service discovery and load balancing.
  • Container Runtime: Executes containers (e.g., Docker, containerd).

The control plane orchestrates the cluster, while nodes run pods, which group containers. This architecture ensures scalability, high availability, and automated management of applications across diverse environments.

Explain the concept of Container Orchestration.h2

Container orchestration automates the management of containerized applications across a cluster. It handles deployment, scaling, and networking of containers to ensure efficient, reliable operation. Key aspects include:

• Deployment: Automatically schedules containers (grouped in pods in Kubernetes) onto nodes based on resource availability and constraints.
• Scaling: Adjusts the number of containers dynamically to match workload demands, supporting horizontal (more instances) or vertical (more resources) scaling.
• Load Balancing: Distributes traffic across containers to optimize performance and ensure high availability.
• Self-Healing: Detects and replaces failed containers, rescheduling them on healthy nodes to maintain application uptime.
• Service Discovery: Provides stable endpoints (e.g., DNS or IP) for containers to communicate, abstracting dynamic IP changes.
• Updates and Rollbacks: Manages rolling updates for zero-downtime deployments and reverts to previous versions if issues occur.

Orchestration tools like Kubernetes simplify complex tasks, enabling scalable, resilient microservices architectures by reducing manual intervention and ensuring consistent application performance across diverse environments.

Describe the role of a Master node in Kubernetes.h2

The Master node, or control plane node, in Kubernetes manages the entire cluster, orchestrating containerized applications. Its key roles include:

• Cluster Management: Hosts the API server (kube-apiserver), which processes RESTful requests from users and components, updating cluster state in etcd, a distributed key-value store for configuration and state data.
• Scheduling: Runs the kube-scheduler, which assigns pods to worker nodes based on resource needs, constraints, and policies like affinity or taints.
• State Reconciliation: Operates the controller manager (kube-controller-manager), running controllers (e.g., Deployment, ReplicaSet) to maintain the desired state, ensuring resources like pods and services align with user-defined configurations.
• Coordination: Facilitates communication between control plane components and worker nodes, ensuring cluster-wide consistency and reliability.

The Master node does not run application workloads but focuses on cluster coordination, scalability, and fault tolerance, enabling automated management of pods across worker nodes in the Kubernetes cluster.

What is the role of the kube-proxy in Kubernetes and how does it facilitate communication between Pods?h2

Kube-proxy runs on every Kubernetes node and manages network rules to enable communication between pods and services. Its key roles include:

• Service Discovery: Maintains stable endpoints for services (e.g., ClusterIP, NodePort) by mapping service names or IPs to pod IPs, abstracting dynamic pod changes.
• Load Balancing: Distributes traffic across pods matching a service’s selector, ensuring even workload distribution for scalability and reliability.
• Networking Modes: Operates in modes like iptables (default) or IPVS to configure network rules, routing traffic efficiently to the correct pods.
• Facilitating Pod Communication: For inter-pod communication, kube-proxy ensures pods can reach each other via service IPs or DNS names, handling intra-cluster traffic seamlessly. It also supports external access for NodePort or LoadBalancer services.

By updating network rules based on the cluster state from the API server, kube-proxy ensures reliable, scalable communication, abstracting pod IP volatility and enabling seamless connectivity for microservices within the Kubernetes cluster.

What is a ConfigMap?h2

A ConfigMap in Kubernetes is a resource that stores non-sensitive configuration data in key-value pairs, decoupling configuration from application code. It allows you to manage settings like environment variables, command-line arguments, or configuration files for pods without rebuilding container images.

• Usage: ConfigMaps can be mounted as volumes in pods, injected as environment variables, or used in command arguments, enabling dynamic configuration updates.
• Examples: Store database URLs, feature flags, or application settings (e.g., key: db_url, value: mysql://localhost:3306).
• Benefits: Enhances portability across environments (dev, prod) and simplifies updates by modifying ConfigMap data without redeploying containers.
• Creation: Defined in YAML, applied via kubectl apply, and referenced in pod specifications.

Unlike Secrets, ConfigMaps handle non-sensitive data, making them ideal for general application configuration, improving flexibility and maintainability in Kubernetes deployments.

Describe the role of etcd in Kubernetes.h2

etcd is a distributed key-value store that serves as the primary database for Kubernetes, storing all cluster data, including configuration, state, and metadata for resources like pods, services, and deployments.

• State Storage: Persists the cluster’s desired and current state, ensuring consistency across nodes.
• Consistency and Reliability: Uses the Raft consensus algorithm to provide high availability and fault tolerance, replicating data across multiple etcd instances.
• API Server Interaction: The kube-apiserver reads from and writes to etcd, handling all cluster operations and updates.
• Watch Functionality: Supports real-time event watching, allowing components like the scheduler and controller manager to react to state changes.
• Critical Role: Acts as the backbone for cluster coordination, enabling the control plane to maintain the desired state and recover from failures.

Typically deployed on control plane nodes, etcd ensures secure, scalable, and reliable management of Kubernetes cluster state, making it essential for orchestration and resource management.

What is a Namespace in Kubernetes?h2

A Namespace in Kubernetes is a virtual partition within a cluster that isolates resources like pods, services, and deployments. It organizes and separates workloads, preventing naming conflicts and enabling multi-tenancy for different teams or projects.

• Resource Isolation: Groups resources logically, allowing independent management within the same cluster.
• Access Control: Supports Role-Based Access Control (RBAC) to restrict permissions per namespace.
• Resource Quotas: Limits resource usage (CPU, memory) per namespace to ensure fair allocation.
• Default Namespaces: Includes “default” (general use), “kube-system” (system components), and “kube-public” (public resources).

Namespaces simplify resource management, enhance security, and support scalable, organized deployments in Kubernetes clusters.

Explain the use of Labels and Selectors in Kubernetes.h2

Labels and Selectors in Kubernetes are used to organize and manage resources efficiently.

• Labels: These are key-value pairs attached to resources like pods, services, or deployments (e.g., app=frontend, env=prod). They act as metadata to identify and categorize resources, enabling flexible grouping for management, querying, or operations.

• Selectors: Selectors query resources based on labels, allowing components like services or controllers to target specific pods. They come in two types:

  • Equality-based: Matches exact label values (e.g., app=frontend).
  • Set-based: Uses conditions like in, notin, or exists (e.g., env in (prod, dev)).

• Use Cases:

  • Service Routing: Services use selectors to route traffic to pods with matching labels.
  • Workload Management: Deployments and ReplicaSets use selectors to manage pod replicas.
  • Filtering: Tools like kubectl use labels to filter resources for inspection or updates.

Labels and selectors enable dynamic resource organization, load balancing, and scaling, making Kubernetes flexible and efficient for managing complex applications.

Describe the role of a Proxy in Kubernetes.h2

The proxy in Kubernetes, known as kube-proxy, runs on every node and manages network communication for services and pods. Its key responsibilities include:

• Service Discovery: Maintains stable endpoints for services (e.g., ClusterIP, NodePort, LoadBalancer) by mapping service IPs or DNS names to pod IPs, abstracting dynamic pod changes.
• Load Balancing: Distributes traffic across pods matching a service’s selector, ensuring even workload distribution for scalability and reliability.
• Network Rule Management: Operates in modes like iptables or IPVS to configure network rules, routing traffic to the correct pods based on service definitions.
• Pod Communication: Facilitates intra-cluster pod-to-pod communication and supports external access for services like NodePort or LoadBalancer.

By continuously updating network rules based on the cluster state from the API server, kube-proxy ensures seamless, reliable connectivity, enabling efficient service discovery and load balancing across the Kubernetes cluster.

What is a Persistent Volume (PV) in Kubernetes?h2

A Persistent Volume (PV) in Kubernetes is a cluster-wide storage resource that provides durable storage for applications, independent of pod lifecycles. It abstracts underlying storage systems (e.g., NFS, cloud storage like AWS EBS, or local disks) and defines properties like capacity, access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), and storage class.

• Purpose: Ensures data persistence for stateful applications, such as databases, even if pods are deleted or rescheduled.
• Management: PVs are provisioned statically by administrators or dynamically via StorageClasses and PersistentVolumeClaims (PVCs).
• Binding: A PV is bound to a PVC, which pods use to access storage, abstracting storage details for portability.
• Reclaim Policy: Determines what happens to the PV after release (e.g., Retain, Delete, or Recycle).

PVs enable reliable, scalable storage management, supporting stateful workloads by decoupling storage from ephemeral pods in Kubernetes clusters.

What advantages does Kubernetes have?h2

Kubernetes offers several advantages for managing containerized applications:

• Automation: Automates deployment, scaling, and updates of applications, reducing manual effort and errors through declarative configurations and controllers like Deployments.
• Scalability: Supports horizontal and vertical auto-scaling, dynamically adjusting pods or resources based on metrics like CPU or memory, ensuring performance under varying loads.
• Self-Healing: Automatically restarts failed pods, reschedules them on healthy nodes, and replaces crashed containers, ensuring high availability.
• Portability: Runs on any infrastructure (cloud, on-premises, hybrid), with consistent behavior across environments, thanks to container abstraction and tools like ConfigMaps.
• Resource Efficiency: Optimizes CPU, memory, and storage allocation via scheduling and resource quotas, maximizing cluster utilization.
• Service Discovery and Load Balancing: Provides built-in mechanisms for routing traffic and discovering services, simplifying microservices communication.
• Extensibility: Supports custom resources, plugins, and integrations, allowing tailored solutions for specific use cases.
• Community and Ecosystem: Backed by a large community and extensive tools (e.g., Helm, Prometheus), ensuring robust support and innovation.

These features make Kubernetes ideal for scalable, resilient, and portable application deployments.

What is the purpose of kubectl?h2

Kubectl is the command-line tool for interacting with Kubernetes clusters, enabling users to manage resources and operations efficiently. Its primary purposes include:

• Resource Management: Creates, updates, or deletes resources like pods, services, deployments, and namespaces using commands like kubectl apply, kubectl delete, or kubectl edit.
• Cluster Inspection: Retrieves information about cluster state, such as kubectl get pods or kubectl describe node, for monitoring and troubleshooting.
• Debugging: Accesses pod logs (kubectl logs), executes commands inside containers (kubectl exec), or port-forwards for testing.
• Configuration Application: Applies declarative YAML or JSON manifests to define desired cluster states, ensuring consistency.
• Scaling and Updates: Manages application scaling (kubectl scale) and rolling updates for deployments, minimizing downtime.

Kubectl communicates with the Kubernetes API server, providing a flexible interface for developers and administrators to control and monitor clusters, streamline workflows, and maintain application reliability.

How does Kubernetes make deployment in containers easier?h2

Kubernetes simplifies containerized deployment through automation and abstraction:

• Declarative Configuration: Uses YAML/JSON manifests to define desired states for pods, services, and deployments. Applying these with kubectl apply automates setup and updates, reducing manual scripting.
• Automated Scheduling: The kube-scheduler assigns pods to nodes based on resource needs, constraints, and policies, optimizing resource utilization without manual intervention.
• Self-Healing: Automatically restarts failed pods, reschedules them on healthy nodes, and replaces crashed containers, ensuring reliable deployments.
• Rolling Updates and Rollbacks: Manages seamless updates via Deployments, gradually replacing pods to avoid downtime, with automatic rollbacks if issues occur.
• Service Discovery and Load Balancing: Abstracts pod IP changes with services (e.g., ClusterIP), providing stable endpoints and distributing traffic across pods.
• Storage and Configuration Management: Integrates PersistentVolumes for storage and ConfigMaps/Secrets for settings, decoupling them from containers for flexibility.
• Scalability: Supports auto-scaling of pods or nodes based on metrics like CPU, enabling efficient handling of varying workloads.

These features streamline deployment, minimize errors, and ensure consistent, scalable, and resilient container management across diverse environments.

What is the difference between a Kubernetes namespace and a label?h2

• Namespaces: Virtual partitions within a Kubernetes cluster that isolate resources like pods, services, and deployments. They enable multi-tenancy, prevent naming conflicts, and support resource quotas and RBAC for access control. Namespaces are ideal for separating projects or teams (e.g., dev, prod).

• Labels: Key-value pairs attached to resources (e.g., app=frontend, env=dev) for identification and organization. They enable flexible grouping and filtering, used by selectors in services, deployments, or queries to target specific resources dynamically.

• Key Differences:

  • Scope: Namespaces provide resource isolation at the cluster level; labels are metadata for individual resources.
  • Purpose: Namespaces organize and segregate resources; labels categorize and select resources for operations like routing or scaling.
  • Usage: Namespaces define boundaries (e.g., separate environments); labels enable fine-grained management (e.g., load balancing to pods with app=web).

Namespaces structure the cluster logically, while labels offer granular control and flexibility in resource management.

What is a Kubernetes secret, and how is it different from a Kubernetes configuration map?h2

A Kubernetes Secret stores sensitive data, such as passwords, API keys, or certificates, in a secure, base64-encoded format. It ensures confidential information is managed separately from application code, enhancing security. Secrets can be mounted as volumes or injected as environment variables in pods.

A ConfigMap, in contrast, stores non-sensitive configuration data, like environment variables or config files, in plain text key-value pairs. It decouples configuration from container images, enabling dynamic updates without rebuilding.

• Key Differences:
  • Data Type: Secrets handle sensitive data with stricter access controls; ConfigMaps manage non-sensitive settings.
  • Encoding: Secrets are base64-encoded and can be encrypted at rest (if configured); ConfigMaps store plain text.
  • Security: Secrets integrate with RBAC and encryption for secure access; ConfigMaps lack these protections.
  • Use Cases: Secrets are used for credentials (e.g., database passwords); ConfigMaps store app settings (e.g., db_url=http://localhost).

Both improve portability and maintainability, but Secrets prioritize security for sensitive data, while ConfigMaps focus on flexible configuration management.

What is a Kubernetes Helm Chart, and how can it help with application deployment?h2

A Kubernetes Helm Chart is a package containing pre-configured Kubernetes resources, like YAML files for deployments, services, and ConfigMaps, bundled for easy application deployment. Helm, the package manager for Kubernetes, uses charts to simplify managing complex applications.

• Structure: Charts include a Chart.yaml file (metadata), templates (resource definitions), and values (customizable parameters) to define application configurations.
• Benefits for Deployment:
  • Simplification: Packages multiple resources into a single, reusable unit, reducing manual YAML creation.
  • Reusability: Allows parameterization via values files, enabling consistent deployments across environments (e.g., dev, prod).
  • Versioning: Supports versioned releases, facilitating updates and rollbacks with commands like helm upgrade or helm rollback.
  • Dependency Management: Manages dependencies between applications (e.g., a web app and its database).
  • Community Ecosystem: Provides access to pre-built charts in repositories like Helm Hub, speeding up setup for common tools (e.g., Nginx, MySQL).

Helm Charts streamline deployment, improve reproducibility, and reduce errors, making complex Kubernetes application management more efficient and scalable.

What are the main components of a Kubernetes cluster, and what are their functions?h2

A Kubernetes cluster comprises a control plane and worker nodes, each with key components to manage containerized applications.

• Control Plane Components:

  • API Server (kube-apiserver): Acts as the cluster’s front-end, handling RESTful API requests to manage resources like pods and services, updating state in etcd.
  • etcd: A distributed key-value store that persists cluster configuration, state, and metadata, ensuring consistency.
  • Scheduler (kube-scheduler): Assigns pods to nodes based on resource needs, constraints, and policies like affinity or taints.
  • Controller Manager (kube-controller-manager): Runs controllers (e.g., Deployment, ReplicaSet) to maintain desired resource states, reconciling discrepancies.
  • Cloud Controller Manager (optional): Integrates with cloud providers for resources like load balancers or storage.

• Worker Node Components:

  • Kubelet: Manages pods on each node, ensuring containers run as specified and reporting status to the API server.
  • Kube-proxy: Handles networking, enabling service discovery and load balancing by managing network rules for pod communication.
  • Container Runtime: Executes containers (e.g., Docker, containerd), handling their lifecycle on the node.

These components collectively enable automated deployment, scaling, and management of applications, ensuring reliability and scalability.

What are the Latest Features of Kubernetes?h2

Kubernetes v1.34, released in August 2025, introduces key enhancements for storage, resources, and observability.

• Pod Level Resources (Beta): Enables finer-grained resource allocation at the pod level for better flexibility.
• Recovery from Volume Expansion Failure (GA): Automates handling of storage expansion errors, improving reliability.
• Dynamic Resource Allocation (DRA) Consumable Capacity: Supports granular requests for specialized hardware like GPUs.
• Pods Report DRA Resource Health: Monitors health of allocated resources for AI/ML workloads.
• Decoupled Taint Manager (Stable): Separates node management from pod eviction for efficiency.
• Kubelet and API Server Tracing (Stable): Enhances debugging with stable tracing capabilities.

v1.35 is in development, focusing on further optimizations.

Explain the working of the master node in Kubernetes?h2

The master node, or control plane node, in Kubernetes orchestrates the cluster’s operations, managing resources and maintaining the desired state. Its key components work together as follows:

• API Server (kube-apiserver): Acts as the central interface, processing RESTful API requests from users, kubectl, or other components. It validates requests, updates cluster state in etcd, and coordinates with other control plane components.
• etcd: A distributed key-value store that persistently stores all cluster data, including configurations, pod states, and metadata, ensuring consistency and fault tolerance.
• Scheduler (kube-scheduler): Assigns pods to worker nodes based on resource requirements, constraints (e.g., taints, tolerations), and policies like affinity or resource availability, optimizing workload placement.
• Controller Manager (kube-controller-manager): Runs controllers (e.g., Deployment, ReplicaSet) that monitor the cluster’s current state via the API server and reconcile it with the desired state by creating, updating, or deleting resources.
• Cloud Controller Manager (optional): Integrates with cloud providers to manage cloud-specific resources like load balancers or storage.

The master node communicates with worker nodes’ kubelets and kube-proxy to manage pods and networking, ensuring automated, scalable, and reliable application orchestration across the cluster.

What is a node in Kubernetes?h2

A node in Kubernetes is a single machine (physical or virtual) in a cluster that runs containerized applications. It provides compute, memory, and storage resources for pods, which contain one or more containers. Nodes are categorized as:

• Worker Nodes: Execute application workloads, hosting pods managed by the kubelet, which communicates with the control plane, and kube-proxy, which handles networking and load balancing. A container runtime (e.g., Docker, containerd) runs the containers.
• Control Plane Nodes: Run control plane components like the API server, etcd, scheduler, and controller manager to manage the cluster.

Nodes report their status (e.g., Ready, DiskPressure) to the API server, enabling the scheduler to assign pods based on resource availability and constraints. Nodes ensure efficient workload execution and scalability across the cluster.

What are the different services within Kubernetes?h2

Kubernetes services enable communication between pods and external clients by defining a logical set of pods and access policies. The main service types are:

• ClusterIP: The default type, assigns an internal virtual IP for pod communication within the cluster. Ideal for internal microservices connectivity.
• NodePort: Exposes the service on a specific port (30000–32767) on each node, allowing external access via <NodeIP>:<NodePort>. Suitable for testing or limited external access.
• LoadBalancer: Integrates with cloud providers to provision an external load balancer with a public IP, routing traffic to pods. Best for production-grade external access.
• ExternalName: Maps a service to an external DNS name without creating a local proxy, redirecting traffic to external endpoints (e.g., external APIs).
• Headless Service: Defined with clusterIP: None, it bypasses load balancing, returning individual pod IPs via DNS. Used for stateful applications like databases with StatefulSets.

These services, managed via YAML and kube-proxy, provide flexible networking, load balancing, and service discovery, ensuring reliable and scalable communication for applications in Kubernetes clusters.

What do you understand from the Cloud controller manager?h2

The Cloud Controller Manager (CCM) in Kubernetes is a control plane component that integrates a cluster with cloud provider APIs, enabling seamless management of cloud-specific resources. It runs as part of the kube-controller-manager or as a separate process.

• Functionality: Manages cloud-dependent tasks, such as:
  • Node Management: Updates node metadata (e.g., availability zones) and handles node lifecycle events.
  • Load Balancing: Provisions and configures cloud load balancers for LoadBalancer-type services, ensuring external traffic routing.
  • Storage Integration: Manages cloud storage resources like volumes (e.g., AWS EBS, GCP Persistent Disk) for PersistentVolumes.
  • Route Management: Configures network routes for pod communication in cloud environments.
• Purpose: Offloads cloud-specific logic from the core Kubernetes components, improving portability across cloud providers (e.g., AWS, Google Cloud, Azure) and on-premises setups.
• Benefits: Enables better scalability, modularity, and provider-specific optimizations while keeping the Kubernetes core cloud-agnostic.

The CCM communicates with the API server and cloud provider APIs, ensuring resources align with the cluster’s desired state, enhancing flexibility for cloud-based deployments.

What is Kubectl?h2

Kubectl is the command-line tool for managing Kubernetes clusters. It interacts with the Kubernetes API server to perform tasks like:

• Resource Management: Creates, updates, or deletes resources (pods, services, deployments) using commands like kubectl apply, kubectl delete, or kubectl edit.
• Cluster Inspection: Retrieves cluster information with kubectl get or kubectl describe for resources like nodes or pods.
• Debugging: Accesses pod logs (kubectl logs), runs commands inside containers (kubectl exec), or sets up port-forwarding for testing.
• Scaling and Updates: Scales applications (kubectl scale) or manages rolling updates for deployments.
• Configuration: Applies YAML/JSON manifests to define and update cluster state declaratively.

Kubectl simplifies cluster administration, enabling developers and operators to efficiently control, monitor, and troubleshoot Kubernetes applications, ensuring streamlined workflows and consistent resource management.

What is a sidecar and when is it best to use one?h2

A sidecar in Kubernetes is a secondary container running alongside the main application container within the same pod, sharing its network and storage. It enhances or extends the primary container’s functionality without altering its code.

• Purpose: Sidecars handle auxiliary tasks like logging (e.g., Fluentd collecting logs), monitoring (e.g., Prometheus exporters), proxying (e.g., Envoy for service mesh), or data synchronization (e.g., syncing files with a database).
• How It Works: Both containers share the same localhost and volumes, enabling tight integration while keeping concerns separate.
• When to Use:
  • Modularity: When you need to add functionality (e.g., logging, security) without modifying the main application.
  • Cross-Cutting Concerns: For tasks like traffic management or observability in microservices, often in service meshes (e.g., Istio).
  • Legacy Applications: When updating an existing app isn’t feasible, a sidecar can add modern features like metrics or encryption.
  • Temporary Tasks: For initialization or preprocessing before the main container starts (e.g., config loaders).

Sidecars are best when separation of concerns, reusability, or non-invasive enhancements are needed, especially in complex, distributed systems.

What is the difference between a StatefulSet and a DaemonSet?h2

A StatefulSet and DaemonSet are Kubernetes controllers for managing pods, but they serve different purposes.

• StatefulSet: Manages stateful applications requiring stable identity, ordered deployment/scaling, and persistent storage. Pods get unique, predictable names (e.g., app-0, app-1) and stable network IDs (e.g., DNS). Scaling happens in order, preserving state across restarts. Ideal for databases like MySQL or Cassandra, where data persistence and sequencing matter.

• DaemonSet: Ensures one pod (identical across nodes) runs on every node (or subset via node selectors/taints). Pods are ephemeral and stateless, with generic names. Scaling is tied to node count—adds/removes pods as nodes join/leave. Suited for infrastructure services like logging (Fluentd), monitoring (Prometheus Node Exporter), or networking (Calico).

• Key Differences:

  • Workload Type: StatefulSet for ordered, stateful apps; DaemonSet for node-wide, stateless tasks.
  • Pod Management: StatefulSet provides ordering and identity; DaemonSet ensures per-node coverage.
  • Storage: StatefulSet integrates with PersistentVolumes; DaemonSet rarely does.

Choose StatefulSet for apps needing consistency, DaemonSet for cluster-level utilities.

How is host application deployment different from container application deployment?h2

Host application deployment (on VMs or bare metal) differs from container application deployment in several ways:

• Isolation: Host deployments run applications on full OS instances, providing strong isolation but high resource overhead. Containers share the host OS kernel, offering lightweight isolation with lower resource use, enabling denser deployments.

• Portability: Containers package applications and dependencies into portable images, ensuring consistent behavior across environments (dev, prod, cloud). Host deployments often require OS-specific configurations, reducing portability.

• Deployment Speed: Containers deploy quickly via immutable images, supporting rapid scaling and updates. Host deployments involve slower OS/application installations or patching, risking downtime.

• Management: Containers leverage orchestration tools like Kubernetes for automated scaling, load balancing, and self-healing. Host deployments rely on manual scripting or tools like Ansible, making management more complex.

• Resource Efficiency: Containers optimize resource use by sharing OS resources, while hosts consume more CPU/memory due to separate OS instances.

• Updates: Containerized apps use rolling updates for zero downtime; host updates can require service interruptions.

Containers suit microservices and cloud-native apps for agility, while hosts are better for monolithic or legacy systems needing full OS control.

How is Kubernetes related to Docker?h2

Kubernetes and Docker are complementary technologies for containerized applications:

• Docker: A platform for creating, running, and packaging containers, which are lightweight, portable units encapsulating applications and dependencies. It provides the container runtime to execute containers on nodes.

• Kubernetes: An orchestration system that automates deployment, scaling, and management of containers across a cluster. It schedules and manages pods (groups of containers) but relies on a container runtime like Docker to run them.

• Relationship:

  • Kubernetes uses Docker (or alternatives like containerd) as its container runtime to execute containers within pods.
  • Kubernetes manages higher-level tasks like scaling, load balancing, and self-healing, while Docker handles container creation and execution.
  • Historically, Kubernetes tightly integrated with Docker, but since Kubernetes 1.20, Docker support is deprecated in favor of containerd or CRI-compliant runtimes for better modularity.

• Workflow: Developers build container images with Docker, push them to registries, and Kubernetes pulls these images to deploy and orchestrate them across nodes.

Together, they enable scalable, portable, and automated containerized application deployment, with Kubernetes providing orchestration and Docker (or equivalent) enabling container execution.

What is the difference between a replica set and a replication controller?h2

Both ReplicaSet and Replication Controller in Kubernetes ensure a specified number of pod replicas run, but they differ in functionality and usage:

• Purpose:

  • Replication Controller is an older controller that maintains a set number of pod replicas, replacing failed pods to ensure availability.
  • ReplicaSet is a newer, more advanced controller, supporting richer pod selection and typically used by Deployments.

• Selector Support:

  • Replication Controller uses equality-based selectors (e.g., app=frontend), limiting pod targeting to exact label matches.
  • ReplicaSet supports set-based selectors (e.g., env in (prod, dev)), allowing more flexible and expressive pod matching.

• Usage:

  • Replication Controller is rarely used directly, as it’s considered legacy.
  • ReplicaSet is managed by Deployments for features like rolling updates and rollbacks, making it the preferred choice for modern applications.

• Functionality:

  • Both ensure pod replication and fault tolerance, but ReplicaSet integrates better with higher-level abstractions like Deployments for advanced update strategies.

In practice, ReplicaSet is favored for its flexibility and integration, while Replication Controller is maintained for backward compatibility in older clusters.

What are federated clusters?h2

Federated clusters in Kubernetes enable the management of multiple Kubernetes clusters as a single entity, coordinating resources across different regions, clouds, or on-premises environments.

• Purpose: Federation synchronizes configurations, workloads, and policies across clusters, ensuring consistency and enabling global scalability and high availability.
• Key Features:
  • Resource Synchronization: Propagates resources like Deployments, Services, or ConfigMaps across clusters using a federation control plane.
  • Cross-Cluster Scheduling: Distributes workloads across clusters based on policies, optimizing resource use or geographic proximity.
  • Service Discovery: Provides unified DNS for services across clusters, enabling seamless communication.
  • High Availability: Spreads applications across clusters to improve fault tolerance and reduce latency for users in different regions.
• Implementation: The Kubernetes Cluster Federation (KubeFed) project manages federation, using a central control plane to coordinate member clusters.
• Use Cases: Multi-region applications, hybrid cloud deployments, or disaster recovery setups requiring consistent management across diverse environments.

Federated clusters simplify administration of distributed systems, but they add complexity and are less commonly used since Kubernetes 1.20, with focus shifting to single-cluster optimizations.

What is Container resource monitoring?h2

Container resource monitoring in Kubernetes involves tracking the performance and health of containers and pods to ensure efficient resource utilization and application reliability. It focuses on collecting metrics like CPU, memory, disk, and network usage.

• Purpose: Identifies resource bottlenecks, detects performance issues, and supports scaling or troubleshooting decisions.
• Tools:
  • Metrics Server: Collects basic resource metrics (CPU, memory) from kubelets, exposing them via the Kubernetes API for tools like kubectl top.
  • Prometheus: A popular monitoring solution that scrapes detailed metrics from pods and nodes, often paired with Grafana for visualization.
  • Heapster (deprecated): Previously used for cluster-wide metric aggregation, now replaced by Metrics Server or Prometheus.
• Key Metrics: Tracks pod/container resource consumption, node capacity, and application-specific metrics (e.g., request latency).
• Benefits: Enables auto-scaling (via HorizontalPodAutoscaler), alerts on anomalies, and optimizes cluster performance by identifying over/under-provisioned resources.

Monitoring integrates with Kubernetes components like the API server and kubelet, providing real-time insights for maintaining scalable, healthy containerized applications in production environments.

What do you understand by Kube-proxy?h2

Kube-proxy is a network proxy running on every Kubernetes node, managing network communication for services and pods. It ensures seamless connectivity by handling service discovery and load balancing. Its key functions include:

• Service Discovery: Maps service names or IPs (e.g., ClusterIP, NodePort, LoadBalancer) to pod IPs, abstracting dynamic pod IP changes for consistent access.
• Load Balancing: Distributes traffic across pods matching a service’s selector, optimizing performance and reliability.
• Network Rules: Operates in modes like iptables or IPVS to configure routing rules, directing traffic to appropriate pods based on service definitions.
• Pod Communication: Facilitates intra-cluster pod-to-pod communication and supports external access for services like NodePort or LoadBalancer.

Kube-proxy continuously updates network rules based on cluster state from the API server, ensuring reliable, scalable networking for microservices and maintaining connectivity across the Kubernetes cluster.

Can you brief on the working of the master node in Kubernetes?h2

The master node, or control plane node, in Kubernetes orchestrates cluster operations to manage containerized applications. Its components work together to maintain the desired state:

• API Server (kube-apiserver): Processes RESTful API requests from users, kubectl, or components, validating and updating cluster state in etcd.
• etcd: Stores all cluster data (configuration, state, metadata) in a distributed key-value store, ensuring consistency and reliability.
• Scheduler (kube-scheduler): Assigns pods to worker nodes based on resource needs, constraints (e.g., taints, affinity), and policies, optimizing workload placement.
• Controller Manager (kube-controller-manager): Runs controllers (e.g., Deployment, ReplicaSet) to monitor and reconcile the cluster’s current state with the desired state, managing resources like pods and services.
• Cloud Controller Manager (optional): Integrates with cloud provider APIs for resources like load balancers or storage.

The master node communicates with worker nodes’ kubelets and kube-proxy to manage pods and networking, ensuring automated deployment, scaling, and fault tolerance across the cluster without running application workloads itself.

What is the role of kube-apiserver and kube-scheduler?h2

• Kube-apiserver: The primary interface for the Kubernetes control plane, it handles RESTful API requests from users, kubectl, or other components. It validates and processes these requests, updating the cluster state in etcd. It coordinates with the scheduler, controller manager, and nodes, serving as the central hub for managing resources like pods, services, and deployments, ensuring cluster consistency and accessibility.

• Kube-scheduler: Responsible for assigning pods to nodes based on resource requirements, constraints, and policies. It evaluates node capacity (CPU, memory), taints, tolerations, and affinity rules to optimize pod placement. The scheduler monitors the API server for new pods and ensures efficient workload distribution, enhancing cluster performance, scalability, and high availability by placing pods on suitable nodes.

Can you brief me about the Kubernetes controller manager?h2

The Kubernetes Controller Manager is a control plane component that runs multiple controllers to maintain the cluster’s desired state. It operates within the kube-controller-manager process and interacts with the API server to monitor and reconcile resources. Key functions include:

• Node Controller: Monitors node health, marks nodes as unreachable if they fail, and manages pod eviction or rescheduling.
• Replication Controller: Ensures the specified number of pod replicas run, replacing failed pods (legacy, mostly replaced by ReplicaSet).
• Deployment Controller: Manages stateless applications, handling rolling updates, rollbacks, and scaling via ReplicaSets.
• StatefulSet Controller: Oversees stateful applications, ensuring ordered pod creation and stable identities.
• DaemonSet Controller: Runs one pod per node for cluster-wide tasks like logging or monitoring.
• Job/CronJob Controllers: Manages finite or scheduled tasks, ensuring completion.
• Service Controller: Handles service endpoints and load balancing.

By continuously comparing the current cluster state with the desired state defined in the API server, the controller manager ensures resources like pods and services remain consistent, scalable, and resilient across the Kubernetes cluster.

What are the different types of services in Kubernetes?h2

Kubernetes services enable communication between pods and external clients by defining a logical set of pods and access policies. The main types are:

• ClusterIP: Default service type, assigns an internal virtual IP for pod communication within the cluster. Ideal for internal microservices.
• NodePort: Exposes the service on a specific port (30000–32767) on each node, enabling external access via <NodeIP>:<NodePort>. Suitable for testing or limited external access.
• LoadBalancer: Provisions a cloud provider’s load balancer with a public IP to route external traffic to pods. Best for production-grade external access.
• ExternalName: Maps a service to an external DNS name without a local proxy, redirecting traffic to external endpoints (e.g., external APIs).
• Headless Service: Set with clusterIP: None, bypasses load balancing, returning individual pod IPs via DNS. Used for stateful applications with StatefulSets.

These services, managed via YAML and kube-proxy, provide flexible networking, load balancing, and service discovery, ensuring reliable connectivity for applications in Kubernetes clusters.

What do you understand by load balancer in Kubernetes?h2

A LoadBalancer in Kubernetes is a service type that exposes an application to external traffic by provisioning a cloud provider’s load balancer, assigning a public IP address to route requests to a set of pods. It builds on ClusterIP, using selectors to target pods and kube-proxy for internal traffic management.

• Functionality: Integrates with cloud platforms (e.g., AWS ELB, Google Cloud Load Balancer) to distribute external traffic across pods, ensuring scalability and high availability.
• Configuration: Defined in a service YAML, specifying type: LoadBalancer, ports, and pod selectors. The cloud provider automatically configures the load balancer.
• Use Cases: Ideal for production applications like web servers or APIs requiring stable, external access with load distribution.
• Benefits: Simplifies external traffic routing, supports session affinity, and scales automatically with pod replicas.

It abstracts complex networking, providing a reliable, single entry point for external clients while leveraging cloud infrastructure for performance and fault tolerance.

What are the best security measures that you can take while using Kubernetes?h2

To secure a Kubernetes cluster, implement these best practices:

• RBAC (Role-Based Access Control): Define granular permissions using RBAC policies to restrict user and service account access to specific resources and namespaces, minimizing unauthorized actions.
• Pod Security Standards: Enforce Pod Security Policies or Admission Controllers to limit container privileges, prevent root access, and restrict risky configurations.
• Network Policies: Use NetworkPolicies to control pod-to-pod communication, limiting traffic to only necessary connections and reducing attack surfaces.
• Secrets Management: Store sensitive data in Secrets, encrypt them at rest, and restrict access. Use tools like Vault for dynamic secret injection.
• Image Security: Scan container images for vulnerabilities using tools like Trivy or Clair, and use trusted registries to avoid malicious images.
• API Server Security: Enable TLS for API server communication, use strong authentication (e.g., OIDC), and limit anonymous access.
• Node Hardening: Secure nodes by minimizing host OS attack surfaces, using minimal base images, and applying regular security patches.
• Audit Logging: Enable audit logs to monitor API server activity, helping detect and investigate suspicious actions.

These measures enhance cluster security, protect workloads, and ensure compliance in production environments.

What is the role of Load Balance in Kubernetes?h2

The LoadBalancer service type in Kubernetes exposes applications to external traffic by provisioning a cloud provider’s load balancer, assigning a public IP to route requests to a set of pods. Its key roles include:

• External Access: Provides a single, stable entry point (public IP) for external clients to access applications, like web servers or APIs, without needing to know pod IPs.
• Traffic Distribution: Distributes incoming traffic across pods matching the service’s selector, ensuring balanced workload and high availability.
• Integration with Cloud Providers: Works with platforms like AWS, Google Cloud, or Azure to configure cloud-native load balancers (e.g., ELB, GCP Load Balancer), leveraging their scalability and reliability.
• Dynamic Scaling: Automatically adjusts to pod replicas added or removed during scaling, maintaining consistent access.
• Network Management: Builds on ClusterIP, using kube-proxy to handle internal routing and load balancing within the cluster.

Defined in a service YAML with type: LoadBalancer, it simplifies external traffic management, enhances performance, and ensures fault tolerance for production-grade applications.

What’s the init container and when it can be used?h2

An init container in Kubernetes is a special container that runs and completes before the main application containers in a pod start. Defined in the pod’s YAML under initContainers, it performs initialization tasks.

• Purpose: Executes setup or preprocessing tasks, such as configuring dependencies, initializing databases, generating configuration files, or waiting for external services (e.g., a database) to be ready.
• Execution: Runs sequentially, each completing successfully before the next starts. If an init container fails, the pod fails to start.
• Use Cases:
  • Data Setup: Populates a volume with initial data or configurations (e.g., cloning a Git repository).
  • Service Dependency: Delays app container startup until a service is available (e.g., checking database connectivity).
  • Security Setup: Configures permissions or secrets before the main app runs.
  • Initialization Logic: Performs one-time setup tasks that the main container shouldn’t handle.

Init containers share the pod’s network and storage but are ephemeral, terminating after completion. They’re ideal when setup tasks need isolation or must complete fully before the application starts, ensuring proper initialization for reliable deployments.

What is PDB (Pod Disruption Budget)?h2

A Pod Disruption Budget (PDB) in Kubernetes is a resource that limits the number of pods from a specific application that can be voluntarily disrupted (e.g., during maintenance, upgrades, or node draining) to ensure application availability.

• Purpose: Protects workloads by specifying the minimum number of pods that must remain running (minAvailable) or the maximum number that can be unavailable (maxUnavailable) at any time.
• Configuration: Defined in a YAML file, a PDB uses selectors to target pods (e.g., those managed by a Deployment) and sets thresholds as absolute numbers or percentages.

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: my-app-pdb
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: my-app

• Use Cases: Ensures high availability for critical applications like web servers or databases during cluster operations, preventing too many pods from being evicted simultaneously.
• Behavior: Works with the Kubernetes eviction API, allowing controlled disruptions while respecting the budget.

PDBs are crucial for maintaining service reliability during planned maintenance, balancing operational needs with application uptime.

What are the various K8’s services running on nodes and describe the role of each service?h2

In Kubernetes (K8s), several key services run on nodes to manage the cluster and ensure containerized applications operate effectively. These services are primarily associated with worker nodes and the control plane. Below is an overview of the main services and their roles:

• Kubelet:

  • Role: Runs on every worker node and manages pod lifecycles. It communicates with the API server to receive pod specifications, ensures containers are running as defined, and executes health checks (liveness/readiness probes). Kubelet interacts with the container runtime (e.g., Docker, containerd) to start, stop, or restart containers and reports node and pod status to the control plane.

• Kube-proxy:

  • Role: Runs on every node to manage network communication. It maintains network rules for service discovery and load balancing, routing traffic to pods for ClusterIP, NodePort, or LoadBalancer services. Operating in modes like iptables or IPVS, kube-proxy ensures seamless pod-to-pod and external-to-pod connectivity, abstracting dynamic pod IP changes.

• Container Runtime:

  • Role: Runs on worker nodes to execute containers within pods. Examples include Docker, containerd, or CRI-O. It handles container creation, execution, and termination, working with kubelet to manage container lifecycles based on pod specifications.

• Control Plane Services (typically on master nodes, but relevant for cluster-wide context):

  • Kube-apiserver: Central management interface, processes RESTful API requests, validates them, and updates cluster state in etcd. It coordinates all cluster operations.
  • etcd: Distributed key-value store that persists cluster state, configuration, and metadata, ensuring consistency and reliability.
  • Kube-scheduler: Assigns pods to nodes based on resource needs, constraints, and policies, optimizing workload placement.
  • Kube-controller-manager: Runs controllers (e.g., Deployment, ReplicaSet) to maintain desired cluster state, reconciling discrepancies.
  • Cloud Controller Manager (optional): Integrates with cloud providers for resources like load balancers or storage.

These services collectively enable Kubernetes to automate deployment, scaling, networking, and management of containerized applications across nodes, ensuring reliability and efficiency.

How do we control the resource usage of POD?h2

To control resource usage of pods in Kubernetes, you define resource limits and requests in the pod’s YAML specification. This ensures efficient resource allocation and prevents overuse.

• Resource Requests and Limits:

  • Requests: Specify the minimum CPU (e.g., 100m for 0.1 core) and memory (e.g., 256Mi) a pod needs. The scheduler uses this to place pods on nodes with sufficient resources.
  • Limits: Set the maximum CPU and memory a pod can use (e.g., 500m, 512Mi). Pods exceeding limits may be throttled (CPU) or terminated (memory).

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-pod
  spec:
    containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          cpu: "100m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"

• ResourceQuotas: Apply at the namespace level to limit total resource usage (e.g., CPU, memory, pod count) for all pods, preventing overconsumption.

• LimitRange: Sets default, minimum, or maximum resource limits for pods or containers in a namespace.

• HorizontalPodAutoscaler (HPA): Scales pod replicas based on CPU/memory usage, optimizing resource allocation dynamically.

These mechanisms ensure efficient resource utilization, prevent pod monopolization, and maintain cluster stability.

How to monitor the Kubernetes cluster?h2

Monitoring a Kubernetes cluster involves tracking resource usage, application performance, and cluster health to ensure reliability and efficiency. Key approaches include:

• Metrics Server: Collects CPU and memory metrics from kubelets, accessible via kubectl top. It’s lightweight and ideal for basic resource monitoring.
• Prometheus and Grafana: Prometheus scrapes detailed metrics (e.g., pod, node, and application performance) from cluster components and endpoints. Grafana visualizes these metrics with dashboards, enabling real-time insights and alerts.
• Logging: Use tools like Fluentd or Loki to collect and aggregate pod logs. Access logs via kubectl logs or centralize them for analysis in systems like Elasticsearch.
• Health Checks: Implement liveness and readiness probes in pod specs to monitor container health, ensuring automatic restarts or traffic routing to healthy pods.
• Kubernetes Events: Monitor events with kubectl get events to track issues like pod failures or scheduling problems.
• Custom Metrics: Use tools like Prometheus Adapter to enable HorizontalPodAutoscaler for scaling based on application-specific metrics (e.g., request latency).
• Dashboards: Use Kubernetes Dashboard or third-party tools like Lens for a graphical overview of cluster state.

Combining these tools provides comprehensive visibility, enabling proactive issue resolution and optimized resource management.

What are the various things that can be done to increase Kubernetes security?h2

To enhance Kubernetes security, implement these key measures:

• Role-Based Access Control (RBAC): Use RBAC to define granular permissions, restricting users and service accounts to specific resources and actions within namespaces.
• Pod Security Standards: Apply Pod Security Policies or Admission Controllers to enforce least-privilege principles, preventing containers from running as root or accessing host resources.
• Network Policies: Implement NetworkPolicies to restrict pod-to-pod communication, allowing only necessary traffic to reduce the attack surface.
• Secrets Management: Store sensitive data in Secrets, enable encryption at rest, and use tools like Vault for dynamic secret injection. Limit Secret access via RBAC.
• Image Security: Scan container images for vulnerabilities using tools like Trivy or Clair. Use trusted registries and sign images to ensure integrity.
• API Server Security: Enable TLS for API server communication, use strong authentication (e.g., OIDC, certificates), and disable anonymous access.
• Node Hardening: Minimize node OS attack surfaces with minimal base images, apply security patches, and restrict SSH access.
• Audit Logging: Enable audit logs to monitor API server activity, aiding in detecting and investigating suspicious behavior.
• Service Mesh: Use tools like Istio for secure pod communication with mutual TLS and traffic encryption.

These practices protect the cluster, workloads, and data, ensuring a robust security posture.

How to get the central logs from POD?h2

To retrieve centralized logs from pods in Kubernetes, you can use logging tools and Kubernetes commands to aggregate and access logs efficiently.

• Using kubectl: For basic log retrieval, use kubectl logs <pod-name> -n <namespace> to fetch logs from a specific pod’s container. For multi-container pods, specify the container with -c <container-name>.
• Centralized Logging:
  • Deploy a Logging Agent: Use a logging solution like Fluentd, Fluent Bit, or Loki. Deploy a DaemonSet to run a logging agent on each node, collecting logs from all pods.
    • Example: Fluentd collects logs and forwards them to a backend like Elasticsearch or a cloud service.
  • Configuration: Configure the agent to read logs from the container runtime (e.g., /var/log/containers/*.log) and send them to a central store.
• Log Aggregation Tools:
  • ELK Stack: Combine Elasticsearch, Logstash, and Kibana for storing, processing, and visualizing logs.
  • Loki: A lightweight solution integrated with Grafana for log aggregation and querying.
• Accessing Logs: Use tools like Kibana or Grafana to query and analyze centralized logs, filtering by pod, namespace, or labels.
• Cluster-Level Monitoring: Enable Kubernetes audit logs or events (kubectl get events) for additional context on pod activities.

Centralized logging ensures scalable log management, simplifies troubleshooting, and supports monitoring across distributed applications.

What is GKE?h2

Google Kubernetes Engine (GKE) is Google Cloud’s managed service for running Kubernetes clusters. It automates the deployment, scaling, and management of containerized applications, simplifying cluster operations.

• Functionality: GKE handles control plane components (API server, etcd, scheduler) and worker nodes on Google Cloud infrastructure, using Compute Engine instances.
• Key Features:
  • Automation: Manages cluster upgrades, auto-scaling, and self-healing, reducing administrative overhead.
  • Integration: Seamlessly integrates with Google Cloud services like Cloud Logging, Monitoring, and Load Balancing.
  • Security: Provides features like workload identity, RBAC, and private clusters for enhanced security.
  • Scalability: Supports auto-scaling of nodes and pods, handling large-scale workloads efficiently.
• Use Cases: Ideal for deploying microservices, cloud-native apps, or hybrid workloads with minimal management effort.

GKE abstracts Kubernetes complexity, offering a production-ready environment with high availability and cloud-native integrations, making it suitable for developers and enterprises. For pricing details, refer to https://cloud.google.com/kubernetes-engine.

What is Ingress Default Backend?h2

The Ingress Default Backend in Kubernetes is a fallback service that handles requests when no Ingress rules match the incoming traffic. It’s specified in the Ingress controller configuration or the Ingress resource.

• Purpose: Ensures a response (e.g., 404 or a custom page) for unmatched requests, preventing errors when no specific rule applies to a URL path or host.
• Configuration: Defined in the Ingress resource under spec.defaultBackend, pointing to a service and port. Example:

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-ingress
  spec:
    defaultBackend:
      service:
        name: default-service
        port:
          number: 80

• Use Cases: Commonly used to serve a default webpage, error page, or redirect for unmatched routes, enhancing user experience and application reliability.
• Ingress Controller: The default backend depends on the Ingress controller (e.g., NGINX, Traefik), which processes the rules and routes traffic to the specified service.

This feature provides a catch-all mechanism, ensuring robust traffic handling for requests that don’t match defined Ingress rules in the cluster.

Why should namespaces be used? How does using the default namespace cause problems?h2

Namespaces in Kubernetes provide virtual isolation within a cluster, enabling better organization, security, and resource management. Here’s why they should be used and issues with relying on the default namespace:

• Why Use Namespaces:

  • Resource Isolation: Separate workloads (e.g., dev, prod, staging) to prevent naming conflicts and organize resources for different teams or projects.
  • Access Control: Apply Role-Based Access Control (RBAC) to restrict user permissions per namespace, enhancing security by limiting access to specific resources.
  • Resource Quotas: Enforce CPU, memory, or pod limits per namespace, ensuring fair resource allocation and preventing overuse.
  • Simplified Management: Group related resources, making it easier to manage and monitor complex applications in large clusters.
  • Multi-Tenancy: Support multiple teams or applications sharing a cluster while maintaining logical separation.

• Problems with Default Namespace:

  • Naming Conflicts: All resources in the default namespace share the same naming scope, risking collisions (e.g., two apps with the same service name).
  • Security Risks: Without isolation, users may access or modify unintended resources, as RBAC is harder to enforce in a single namespace.
  • Resource Contention: No quotas by default lead to resource overuse, impacting cluster performance.
  • Clutter and Confusion: Mixing all resources in one namespace complicates management, especially in large clusters with many teams or apps.

Using namespaces ensures better organization, security, and scalability, while overusing the default namespace leads to conflicts, security gaps, and management challenges.

What service and namespace are referred to in the following file?h2

To identify the service and namespace in a Kubernetes YAML file, I’d need to see the file’s content, as you haven’t shared it. Typically, a Kubernetes service is defined with kind: Service, and the namespace is specified in the metadata section as namespace: <name>. If no namespace is explicitly defined, it defaults to the default namespace.

Please share the YAML file or relevant details, and I’ll pinpoint the exact service name and namespace for you. For now, here’s how to check:

• Look for kind: Service to confirm it’s a service definition.
• Check metadata.name for the service name.
• Check metadata.namespace for the namespace; if absent, it’s default.

Provide the file, and I’ll give a precise answer!

What is the purpose of operators?h2

Operators in Kubernetes are software extensions that automate the management of complex applications, particularly stateful ones, by extending the Kubernetes API. They act as custom controllers, leveraging Custom Resource Definitions (CRDs) to manage application-specific resources and lifecycle tasks.

• Purpose:

  • Automation: Handle tasks like deployment, scaling, upgrades, backups, and recovery for complex apps (e.g., databases like MySQL or etcd) that require domain-specific logic beyond standard Kubernetes controllers.
  • Custom Resources: Define application-specific resources (e.g., a Database CRD) to simplify management with declarative configurations.
  • Stateful Management: Manage stateful applications by ensuring proper sequencing, stable networking, and persistent storage, unlike Deployments suited for stateless apps.
  • Operational Knowledge: Codify operational expertise (e.g., failover, upgrades) into automated workflows, reducing manual intervention.

• How They Work: Operators use a control loop to monitor custom resources, reconcile their state with the desired state, and execute tasks like provisioning resources or handling failures.

• Use Cases: Deploying and managing databases (e.g., PostgreSQL Operator), message queues, or cluster services like monitoring tools.

Operators enhance Kubernetes’ extensibility, making it easier to manage complex, stateful workloads with automation and consistency.

Conclusionh2

This series on “100 Basic Kubernetes Interview Questions” provides a comprehensive overview of key Kubernetes concepts, components, and best practices essential for backend developers. From understanding core objects like pods, services, and deployments to mastering advanced features like operators, namespaces, and security measures, the series equips you with concise, actionable answers for job interviews. It covers critical aspects such as cluster architecture, resource management, networking, and monitoring, ensuring a solid grasp of Kubernetes’ role in container orchestration. By preparing with these questions, you can confidently demonstrate expertise in deploying, scaling, and managing containerized applications, showcasing your readiness to tackle real-world challenges in modern cloud-native environments.