There are many techies who would like to start their journey on Kubernetes, but they are not sure from where they should begin. So I have made an attempt to jot down all the common questions and their answers related to Kubernetes.

This article is vendor neutral and focuses purely on raw Kubernetes and its core concepts — without tying it to any specific cloud provider or platform.

Whether you are a Kubernetes beginner, preparing for an interview, or just trying to refresh your Kubernetes knowledge, this article is for you.

Q1: What is the architecture of a Kubernetes cluster?

Kubernetes follows a master-worker architecture. It consists of a Control Plane (or Master Plane) that manages the overall cluster, and multiple Worker Nodes where application workloads run. This architecture supports scale, high availability, and decoupled control logic.

Q2: What components are part of the Kubernetes Control Plane?

The Control Plane consists of several critical components:

• • kube-apiserver: The front-end API server that validates and processes REST requests.
  • etcd: A highly available, distributed key-value store used for all cluster data and state.
  • kube-scheduler: watches for unscheduled Pods and makes placement decisions based on resource availability and scheduling policies. It selects an appropriate Node and records this decision by updating the Pod specification, but it does not execute the assignment itself.
  • kube-controller-manager: Runs controllers to maintain cluster state (e.g., Deployment, Node, Endpoint).
  • cloud-controller-manager: Integrates with cloud provider APIs to manage resources like load balancers and volumes.

Q3: What is the role of the kube-apiserver?

The kube-apiserver is the only component that interacts with the Kubernetes cluster via REST. It authenticates, validates, and serves all API calls from `kubectl`, controllers, and operators. It’s stateless and typically runs behind a load balancer in HA setups.

Q4: What is etcd, and why is it important?

etcd is a distributed key-value store that stores all cluster configuration and state. It is the single source of truth for Kubernetes. Without etcd, the Control Plane cannot function. Backing up etcd is critical for disaster recovery.

Q5: What is the kube-scheduler responsible for?

The kube-scheduler monitors for unscheduled Pods and decides the best node for placement. It evaluates node resource availability, taints/tolerations, affinity/anti-affinity rules, and custom scheduling constraints.

Q6: What does the kube-controller-manager do?

This component runs various controllers such as:

• • Deployment Controller: Ensures desired replicas are running.
  • Node Controller: Tracks node health and availability.
  • Job Controller: Tracks completion of batch jobs.

Each controller is a loop that compares desired state with actual state and performs actions to reconcile them.

Controllers like the Deployment or ReplicaSet controller are part of kube-controller-manager.

Q7: What is the cloud-controller-manager?

The cloud-controller-manager abstracts cloud-provider-specific logic (e.g., for node provisioning, persistent disks, load balancers). It enables Kubernetes to work seamlessly across different IaaS platforms like Azure, AWS, and GCP.

Cloud-controller-manager is only required if the Kubernetes Cluster is running in a Cloud environment.

Q8: What are the components of a Kubernetes Worker Node?

Each Worker Node includes:

• • kubelet: Node agent that ensures Pods are running as expected based on PodSpecs.
  • container runtime: Responsible for running containers (e.g., containerd, CRI-O, Docker – deprecated).
  • kube-proxy: Handles networking rules and load balances traffic to Pods based on Service rules.

Q9: What is the kubelet and how does it work?

kubelet runs on each node and ensures the containers in assigned Pods are running. It talks to the container runtime, reads the PodSpecs, monitors liveness/readiness probes, and reports back to the API server.

Q10: What is kube-proxy and what is its role?

kube-proxy manages network rules on nodes using iptables or IPVS. It enables communication between services and their backend Pods by load-balancing traffic at the IP level.

Q11: How do Control Plane and Worker Nodes interact?

The Control Plane schedules workloads onto Worker Nodes and monitors their health. Worker Nodes execute the workloads, report status, and react to commands (e.g., scale up/down). Communication is via the API server.

Q12: Is it possible to run a Kubernetes cluster on a single machine?

Yes, this is commonly done in local dev environments using tools like minikube, kind, or k3s. In these setups, control plane and worker components run on a single node.

Q13: How is high availability (HA) achieved in Kubernetes?

HA is achieved by deploying multiple Control Plane nodes with etcd in a quorum. Load balancers are used in front of kube-apiservers. Worker Nodes also run across availability zones to tolerate infrastructure failures.

Q14: What is the platform layer in Kubernetes?

This layer seats outside the Kubernetes Cluster.

The platform layer refers to the underlying infrastructure and cloud-native services that support the cluster. This includes:

• • Compute (VMs or Bare Metal)
  • Networking (VPC, IPAM, Load Balancers)
  • Storage (disks, file shares, CSI)
  • Security (IAM, policies, secrets)

When Kubernetes is deployed in the cloud, this platform layer is often managed by the cloud provider (e.g., AKS, EKS, GKE), simplifying operations and maintenance.

🔸 Horizontal Pod Autoscaler (HPA)

Q1: What is Horizontal Pod Autoscaler (HPA) in Kubernetes?

HPA automatically adjusts the number of Pods in a Deployment, ReplicaSet, or StatefulSet based on observed CPU/memory usage or custom metrics. It helps applications scale out under high load and scale in when demand drops.

Q2: How does HPA decide when to scale?

HPA compares the current resource usage (e.g., CPU) with the target utilization defined in its spec. If the actual usage is above the threshold, it increases the number of replicas. If it’s below, it scales down, respecting cooldown timers.

Q3: What metrics does HPA use by default?

By default, HPA uses CPU utilization (and optionally memory) collected from the metrics-server. These metrics are aggregated and averaged across all Pods controlled by the HPA.

Q4: How to enable custom metrics in HPA?

To use custom metrics, you need to deploy the custom metrics API adapter (like Prometheus Adapter). Then, HPA can scale based on application-specific metrics such as queue length, HTTP requests, or latency.

Q5: What is the role of metrics-server in HPA?

The metrics-server collects resource usage data (like CPU and memory) from kubelets and makes it available to the Kubernetes API. HPA queries this data to decide whether to scale up or down.

Q6: Does HPA average the metrics across all Pods?

Yes. HPA computes the average resource usage across all targeted Pods. If the average exceeds the threshold, HPA increases the replica count. This ensures balanced scaling and avoids reacting to outliers.

Q7: What are target utilization and thresholds in HPA?

Target utilization is the desired average usage (e.g., 70% CPU). If the actual usage goes beyond this, HPA scales out. If it drops well below, HPA may scale in depending on cooldown periods and policies.

Q8: What are the minReplicas and maxReplicas settings?

minReplicas and maxReplicas define the lower and upper bounds for HPA to maintain. Kubernetes ensures the replica count stays within this range, even under heavy or minimal load.

Q9: Can HPA scale to zero replicas?

No. HPA cannot scale below minReplicas, which must be at least 1. If you need scale-to-zero behavior (e.g., for event-driven workloads), you should use KEDA.

Q10: How does HPA behave during startup or sudden spikes?

During startup, Pods may take time to generate metrics, causing delayed reactions. HPA also uses a cooldown period to avoid thrashing. Sudden spikes may not be immediately addressed unless aggressive thresholds and short cooldowns are set.

Q11: What is the difference between scaleUp and scaleDown behavior in HPA?

Scale-up usually happens faster to handle demand. Scale-down is more conservative to avoid flapping (rapid changes). You can configure these behaviors using stabilization windows and policies introduced in newer Kubernetes versions.

🔸 Vertical Pod Autoscaler (VPA)

Q12: What is Vertical Pod Autoscaler (VPA) and when should you use it?

VPA adjusts the resource requests (CPU/memory) of running Pods based on historical usage. It is useful for workloads with unpredictable usage patterns but does not change replica count. VPA is better for batch jobs or workloads that don’t scale horizontally well.

Q13: Can VPA and HPA work together?

Yes, but with limitations. HPA scales the number of replicas, while VPA adjusts the resource requests. They can conflict if not configured carefully. Kubernetes now supports both via updateMode: Auto with safety constraints, but best used with custom tuning.

🔸 Cluster Autoscaler

Q14: What is Cluster Autoscaler in Kubernetes?

Cluster Autoscaler automatically adjusts the number of nodes in your cluster. If there are unschedulable Pods due to lack of resources, it adds nodes. If nodes are underutilized and Pods can be rescheduled elsewhere, it removes them.

🔹 Important: Cluster Autoscaler is primarily designed for cloud-managed Kubernetes environments (like AKS, EKS, or GKE), where it integrates with the cloud provider’s APIs to add or remove virtual machines. On on-premises or bare-metal clusters, autoscaling is not available by default and requires custom implementation (e.g., integration with virtualization or provisioning tools).

Q15: How does Cluster Autoscaler decide which node pool to scale?

It prefers node pools where Pods are pending and can be scheduled. It also evaluates node groups based on cost-efficiency, taints, and existing workloads. Integration with cloud autoscaling APIs is essential (like in AKS, EKS, GKE).

Q16: How to set resource limits and requests to support autoscaling properly?

Always define resource requests and limits in your Pod specs. Autoscalers (both HPA and Cluster Autoscaler) use these to schedule workloads and make scaling decisions. Without them, scaling can be unpredictable and inefficient.

🔸 KEDA (Kubernetes Event-Driven Autoscaler)

Q17: What is KEDA in Kubernetes?

KEDA is a Kubernetes-based Event Driven Autoscaler. It allows you to scale applications based on external event sources like message queues, databases, or cloud services — beyond just CPU and memory.

Q18: Why use KEDA — where does HPA fall short?

HPA is limited to CPU, memory, and custom metrics. KEDA supports dozens of event sources like Kafka, Azure Queue, RabbitMQ, Prometheus, etc., and can scale based on queue length, message count, etc. It also supports scale-to-zero, which HPA doesn’t.

Q19: How does KEDA work at a high level?

KEDA installs a custom controller and a scaler per resource. It monitors the external event source, generates custom metrics, and creates an HPA behind the scenes to drive scaling. It’s seamless and runs natively in Kubernetes.

Q20: Can KEDA and HPA work together?

Yes. In fact, KEDA uses HPA under the hood. You can combine both to scale on multiple triggers (e.g., CPU + message queue length). KEDA lets you define multiple triggers per ScaledObject for fine-grained control.

🔹 ConfigMaps

Q64: What is a ConfigMap in Kubernetes?

A ConfigMap is a Kubernetes object used to store non-sensitive key-value pairs like configuration files, environment variables, command-line arguments, or app settings that your Pods can consume at runtime.

Q65: What are common use cases for ConfigMaps?

Typical use cases include injecting application configuration data, toggling features via flags, passing external URLs or service names, and setting runtime parameters.

Q66: How to mount a ConfigMap as environment variables?

You can define environment variables from a ConfigMap using the envFrom or env fields in the Pod spec. Each key in the ConfigMap becomes a variable.

Q67: How to mount a ConfigMap as files?

You can mount a ConfigMap as a volume. Each key becomes a file name and the value becomes the file content. Useful for mounting config files or templates.

Q68: Can you update a ConfigMap without restarting the Pod?

If the ConfigMap is mounted as a volume, the updated value appears in the file. But the app must reread the file. Environment variable injection does not support dynamic updates—restarting is needed.

Q69: What happens if a ConfigMap is missing at Pod startup?

If the ConfigMap is required and not found, the Pod fails to start. You can use the optional: true setting to make it non-fatal.

🔹 Secrets

Q70: What is a Secret in Kubernetes?

A Secret is similar to a ConfigMap but intended for storing sensitive data like passwords, tokens, certificates, and keys. Kubernetes encodes them in base64 and offers stricter access controls.

Q71: How is a Secret different from a ConfigMap?

Secrets are used for sensitive data and are base64-encoded by default. They can also be encrypted at rest and are RBAC-protected. ConfigMaps are meant for non-sensitive configuration data.

Q72: Are Secrets encrypted in Kubernetes?

By default, Secrets are stored in etcd as base64-encoded values. For actual encryption, you must enable encryption at rest via a Kubernetes EncryptionConfiguration resource.

Q73: How to mount Secrets as env variables and volumes?

Secrets can be mounted the same way as ConfigMaps: as environment variables using env or envFrom, or as volumes where each key becomes a file.

Q74: What is the recommended way to handle sensitive data in Pods?

Use Secrets and mount them as volumes, not environment variables. Avoid logging secrets, apply RBAC to limit access, and use external secret managers like Azure Key Vault with CSI drivers for production use.

🔹 Environment Injection

Q75: How do you inject environment variables in Pods using ConfigMaps and Secrets?

Use envFrom to inject all keys from a ConfigMap or Secret as environment variables. Use env for fine-grained injection where you map keys to specific variables.

Q76: How can downward API be used to inject metadata like Pod name, namespace, etc.?

The Downward API allows you to expose Pod and container fields (like name, UID, labels, annotations) as environment variables or volume files. Useful for logging, traceability, and telemetry.

Q77: What is the difference between env and envFrom fields?

env lets you define individual environment variables and sources. envFrom automatically pulls all key-value pairs from a Secret or ConfigMap. Use env for precision and envFrom for simplicity.

Section 8: Kubernetes Networking

Section 9 : Network Policies

Q1: What is a Network Policy in Kubernetes?

A Network Policy is a Kubernetes resource that defines how groups of Pods are allowed to communicate with each other and with other network endpoints. It provides fine-grained control over traffic flow at the IP address or port level.

Q2: Why do we need Network Policies?

By default, all Pods can communicate with each other in a Kubernetes cluster. Network Policies let you implement “deny by default” behavior, segment traffic, and enforce security between microservices.

Q3: Are all Pods allowed to talk to each other by default?

Yes. In the absence of any Network Policies, all Pods can send and receive traffic freely across namespaces. Network Policies must be explicitly defined to restrict this behavior.

Q4: What are ingress and egress rules in a Network Policy?

Ingress rules control incoming traffic to Pods. Egress rules control outgoing traffic from Pods. Each can be defined independently in a Network Policy to control the allowed sources and destinations.

Q5: What happens when a Network Policy is applied to a Pod?

Once a Pod is selected by a Network Policy, it is subject to the rules defined in that policy. If no ingress or egress rules are defined, the default behavior is to deny all traffic in that direction.

Q6: Can Network Policies explicitly deny traffic?

No. Network Policies are additive and only define what is allowed. There is no way to write a policy that explicitly denies traffic — traffic is denied by default once a Pod is selected by a policy, and not explicitly allowed.

Q7: What is the difference between namespaceSelector, podSelector, and IPBlock?

• • podSelector: Selects Pods in the same namespace.
  • namespaceSelector: Selects namespaces whose Pods are allowed.
  • ipBlock: Allows or blocks traffic based on IP CIDR ranges.

Q8: How to restrict traffic between two apps in the same namespace?

Create a Network Policy with a podSelector targeting one app, and ingress rules allowing only traffic from the second app’s label. This ensures only the allowed app can talk to the target.

Q9: How to allow ingress from a specific namespace only?

Use a namespaceSelector in the ingress rule to allow traffic only from that namespace. You can optionally combine it with a podSelector to allow only specific Pods from that namespace.

Q10: How to allow egress to a specific IP CIDR range?

Use the egress section in the Network Policy and specify the destination IP range using ipBlock. This restricts Pods to only access specific external services or addresses.

Q11: Can I use podSelector within a namespaceSelector?

Yes. You can nest podSelector within namespaceSelector to allow traffic from specific Pods in specific namespaces. This provides very granular access control between microservices across namespaces.

Q12: What happens if multiple Network Policies apply to the same Pod?

All applicable policies are evaluated together. If any policy allows a specific traffic direction and source, that traffic is permitted. Kubernetes evaluates them as additive — it’s not a first-match-wins model.

Q13: How does label matching work between a Pod and a Deployment?

A Deployment uses selector.matchLabels to match the labels it assigns to Pods. A Network Policy uses podSelector to select these Pods based on those labels. Matching is purely based on label keys and values — label consistency is key.

Q14: Do Network Policies work without a compatible CNI plugin?

No. Network Policies are only enforced if the CNI plugin (like Calico, Cilium, etc.) supports them. If your CNI doesn’t support them, the policies will be ignored silently.

Q15: Are Network Policies stateful or stateless?

They are connection-aware in the sense that once a connection is established, return traffic is allowed. This makes them effectively stateful — replies to allowed ingress traffic are permitted.

Q16: How do you troubleshoot Network Policy issues?

Use network policy visualizers, verbose logging from CNI, tools like netshoot or kubectl exec into Pods to test connectivity, and systematically disable/enable policies to isolate behavior.

🔐 Authentication & Authorization

Q1: How does Kubernetes handle authentication?

Kubernetes supports multiple authentication mechanisms such as certificates, bearer tokens, OpenID Connect (OIDC), and external identity providers. For managed clusters like AKS or EKS, it’s highly recommended to integrate with cloud-native identity platforms such as Azure AD (for AKS) or AWS IAM (for EKS). This enables centralized identity management, MFA, audit logging, and integration with corporate SSO, which is critical for enterprise security and compliance.

Q2: What is RBAC in Kubernetes?

RBAC (Role-Based Access Control) governs access to Kubernetes resources based on user roles. It defines what actions a user or application can perform (verbs) on which resources. RBAC helps enforce least privilege and secure cluster operations.

Q3: What is the difference between Role and ClusterRole?

Role is namespace-scoped — it grants access to resources within a specific namespace. ClusterRole is cluster-scoped — it can grant access to cluster-wide resources or be used across all namespaces.

Q4: What are RoleBinding and ClusterRoleBinding?

RoleBinding assigns a Role to users or service accounts within a namespace. ClusterRoleBinding assigns a ClusterRole to users or service accounts across the entire cluster. They connect subjects (users, groups) to roles.

🔐 Secrets & Encryption

Q5: How are Kubernetes Secrets stored?

By default, Secrets are stored in etcd, base64-encoded — not encrypted. This provides only obfuscation, not security. It’s important to enable encryption at rest for real protection.

Q6: Is it safe to store sensitive data in Kubernetes Secrets?

Only if encryption at rest is enabled and access to etcd and the API server is tightly controlled. Consider using external secret management systems like HashiCorp Vault or Azure Key Vault for highly sensitive data.

Q7: How can you encrypt Secrets at rest in Kubernetes?

Use the --encryption-provider-config flag to configure an encryption provider. This allows etcd data to be encrypted using AES-CBC, AES-GCM, or envelope encryption with KMS providers.

🔐 Pod Security

Q8: What is PodSecurityPolicy and what replaced it?

PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and removed in 1.25. It was replaced by Pod Security Admission (PSA), which uses built-in profiles (privileged, baseline, restricted) to enforce security controls without complex policy objects.

Q9: What is Pod Security Admission (PSA)?

PSA is a built-in admission controller that checks Pods against pre-defined security standards. It can operate in three modes — enforce, audit, and warn — making it easier to secure workloads with consistent policies.

Q10: What are Security Contexts in Kubernetes?

Security Context defines privilege and access controls for a Pod or container, such as user IDs, group IDs, capabilities, and file system settings. It is used to harden workloads and reduce the risk of privilege escalation.

Q11: What is the use of runAsUser, fsGroup, and readOnlyRootFilesystem?

• • runAsUser: Forces the container to run as a specific user ID.
  • fsGroup: Assigns a group ID to mounted volumes to control file permissions.
  • readOnlyRootFilesystem: Prevents the container from writing to the root filesystem, adding a layer of immutability and security.

🔐 Service Accounts & Token Management

Q12: What is a ServiceAccount in Kubernetes?

A ServiceAccount is used by Pods to interact with the Kubernetes API server. It replaces user credentials for in-cluster communication and automation.

Q13: How does a Pod use a ServiceAccount?

By default, each Pod is assigned a ServiceAccount, and a token is automatically mounted inside the container at /var/run/secrets/kubernetes.io/serviceaccount. This token is used to authenticate API calls.

Q14: How to restrict or scope a ServiceAccount?

Use RBAC to limit what the ServiceAccount can access. For example, bind it to a Role with only read permissions in a specific namespace.

Q15: What is automountServiceAccountToken?

This is a boolean field in the Pod or ServiceAccount spec. If set to false, it prevents automatic mounting of the token into Pods. This is useful for non-API-consuming workloads to avoid unnecessary token exposure.

📦 Volumes, Persistent Volumes (PVs), and Persistent Volume Claims (PVCs)

Q1: What is a Volume in Kubernetes?

A Volume in Kubernetes is a storage abstraction used to persist data across container restarts within a Pod. Unlike container-local storage, a Volume’s lifecycle is tied to the Pod and not the individual container, which means data can be shared across containers in the same Pod.

Q2: What is the difference between Volume and PersistentVolume?

A basic Volume exists only as long as the Pod exists. A PersistentVolume (PV), however, is a cluster-level resource that exists independent of Pods. PVs provide durable storage that can be reused across Pod restarts or even Pod replacements.

Q3: What is a PersistentVolumeClaim and how does it work?

A PersistentVolumeClaim (PVC) is a request for storage by a user. PVCs abstract the details of the underlying storage, allowing users to request storage without knowing the implementation. The control plane matches PVCs to available PVs based on size, access mode, and StorageClass.

Note: PVCs are namespaced, while PVs are cluster-scoped.

Q4: What is the lifecycle relationship between PV, PVC, and Pod?

A user creates a PVC, which gets bound to a suitable PV. The Pod then mounts the PVC to use that storage. The Pod is dependent on the PVC, and the PVC is dependent on the PV. Deleting a PVC may or may not delete the PV, depending on the reclaim policy.

Q5: What volume plugins are supported in Kubernetes?

Kubernetes supports multiple volume plugins, including:

• hostPath – Mounts a directory from the host node
• AzureDisk / AzureFile – Azure-specific managed disks and SMB shares
• NFS – Network File System mounts
• CSI – Container Storage Interface standard, which enables third-party storage drivers

🔄 Storage Classes and Dynamic Provisioning

Q6: What is a StorageClass in Kubernetes?

A StorageClass defines a “class” of storage and is used during dynamic provisioning. It specifies the provisioner, parameters like disk type, and reclaim policy. PVCs can request a specific StorageClass to get dynamically provisioned PVs.

Q7: How does dynamic provisioning work in Kubernetes?

When a PVC requests storage with a specified StorageClass, Kubernetes automatically creates a PersistentVolume for it using the configured provisioner. This eliminates the need for cluster admins to manually pre-create PVs.

Q8: What is reclaimPolicy and what are its types?

The reclaimPolicy of a PersistentVolume defines what happens to the PV when the associated PVC is deleted. Types include:

• • Retain: Keeps the PV for manual reuse or cleanup.
  • Delete: Deletes the PV and the associated backend storage.
  • Recycle: (Deprecated) Empties the volume for reuse — no longer recommended.

🔒 Access Modes and Binding

Q9: What are the access modes for PV/PVC?

Access modes determine how a volume can be mounted. They include:

• • • ReadWriteOnce (RWO): Mounted as read-write by a single node
    • ReadOnlyMany (ROX): Mounted as read-only by many nodes
    • ReadWriteMany (RWX): Mounted as read-write by many nodes

Q10: Can multiple Pods mount the same PVC?

Yes, but only if the PVC and the backing PV support an access mode like ReadWriteMany. This is typically supported by networked storage systems like Azure Files or NFS, but not by block storage like Azure Disk.

Q11: What is the difference between ReadWriteOnce, ReadOnlyMany, and ReadWriteMany?

ReadWriteOnce means only one node can mount the volume as read-write. ReadOnlyMany allows multiple nodes to mount the volume in read-only mode. ReadWriteMany permits multiple nodes to mount the volume as read-write, which is ideal for shared storage scenarios.

⏱️ Understanding the Kubernetes Scheduler

Q1: What is the Kubernetes scheduler?

The Kubernetes scheduler is a control plane component responsible for assigning newly created Pods to suitable nodes in the cluster. It considers various factors such as resource availability (CPU, memory), affinity rules, taints/tolerations, and custom constraints when making scheduling decisions.

Q2: Are there multiple types of schedulers in Kubernetes?

Yes. By default, Kubernetes uses the built-in “default-scheduler”, but you can run multiple custom schedulers. Pods can specify which scheduler to use via the schedulerName field in the spec. This is helpful in multi-tenant environments or for custom placement strategies.

📍 nodeSelector and Node Affinity

Q3: What is a nodeSelector in Kubernetes?

nodeSelector is the simplest form of node selection, allowing you to schedule Pods only onto nodes with a specific label. For example, you can assign a Pod only to nodes labeled with tier=backend.

Q4: What is node affinity and how is it different from nodeSelector?

nodeAffinity is a more expressive way to define rules for scheduling Pods onto nodes. It supports logical operators (like In, NotIn, Exists), and conditions like preferred vs required. Unlike nodeSelector, it allows soft rules that Kubernetes will try to honor but may ignore if necessary.

Q5: What is the difference between nodeSelector and nodeAffinity in Kubernetes?

• nodeSelector is a simple, hard requirement that schedules Pods onto nodes with specific labels. If no matching node exists, the Pod remains unscheduled.
• nodeAffinity is a more flexible and expressive way to define scheduling rules. It supports:
  • • Hard rules with requiredDuringSchedulingIgnoredDuringExecution
    • Soft preferences with preferredDuringSchedulingIgnoredDuringExecution

Recommendation: Prefer nodeAffinity over nodeSelector for complex scheduling logic or when soft placement rules are desirable.

Q6: What is a node pool in cloud-managed Kubernetes services?

In platforms like AKS or EKS, a node pool is a group of nodes with the same configuration (VM size, OS, etc.). Node pools can be used to separate workloads — for example, GPU workloads vs general compute, or system workloads vs application workloads. Each pool can have its own taints, labels, and scaling policies.

🤝 Affinity and Anti-Affinity

Q7: What is Pod Affinity and Anti-Affinity?

• Pod Affinity lets you co-locate Pods on the same node or topology (like same AZ) based on labels of other Pods.
• Pod Anti-Affinity does the opposite — it spreads Pods across nodes or zones to increase availability.

These are useful for high availability or performance optimizations, like ensuring replicas of the same app do not land on the same node.

🚫 Taints and Tolerations

Q8: What are taints and tolerations in Kubernetes?

Taints are applied to nodes to repel Pods that do not explicitly tolerate them. A toleration allows a Pod to be scheduled onto a tainted node.

This mechanism is used to keep certain nodes (e.g., GPU, system-critical nodes) reserved for specific workloads unless the workload explicitly tolerates the taint.

Q9: How do taints differ from affinity rules?

• Taints = hard constraint: prevent scheduling unless tolerated.
• Affinity = soft preference or rule: guide scheduling, but may be ignored depending on priority and type.

In short, taints are about exclusion and affinity is about preference/inclusion.

📌 Real-World Use Cases

Q10: What are some real-world use cases for affinity and taints?

• Ensure workloads that depend on each other (e.g., app and cache) land on the same node (pod affinity).
• Spread replicas of the same service across zones (anti-affinity).
• Isolate GPU-intensive jobs to GPU nodes using taints/tolerations.
• Reserve nodes for critical system components by tainting and only tolerating system Pods.

📍 Priority Class

Q1: What is a PriorityClass in Kubernetes?

A PriorityClass is a cluster-wide object that defines the scheduling priority of Pods. It helps Kubernetes determine which Pods should be scheduled or evicted first when resources are constrained. Higher values indicate higher priority.

Q2: What are the real-world use cases of PriorityClass?

PriorityClass is used to ensure critical workloads (like system agents, logging, monitoring, or high-value business apps) get scheduled ahead of lower-priority jobs (like batch processing or dev workloads). It’s especially useful during resource pressure and preemption scenarios.

Q3: How does PriorityClass affect Pod scheduling and eviction?

Kubernetes uses PriorityClass to sort Pods during scheduling. If resources are limited, lower-priority Pods may be preempted (evicted) to make room for higher-priority ones. Priority also influences Pod disruption budgets and graceful eviction handling.

🗂️ Namespaces

Q1: What is a Namespace in Kubernetes?

A Namespace provides logical separation within a physical Kubernetes cluster. It allows you to divide and isolate resources, enabling multi-tenant usage, cleaner organization, and scoped access control.

Q2: Why and when should you use Namespaces?

Namespaces are ideal for separating environments (dev/test/prod), teams, projects, or workloads that require isolated access control. They are especially useful in large clusters to avoid naming collisions and apply different resource quotas or network policies.

Q3: Are Kubernetes objects namespaced by default?

Most Kubernetes objects like Pods, Services, ConfigMaps, Secrets, and Deployments are namespaced. However, some resources such as Nodes, PersistentVolumes, and Namespaces themselves are cluster-scoped and not tied to any namespace.

Q4: What are some of the non-namespace objects in Kubernetes?
Kubernetes has several cluster-scoped (non-namespaced) objects that exist independently of namespaces. These include:

• • • Nodes – Represent worker machines in the cluster.
    • PersistentVolumes (PV) – Provide cluster-wide storage that can be claimed by PVCs.
    • ClusterRoles – Define permissions across all namespaces.
    • ClusterRoleBindings – Bind ClusterRoles to users or service accounts at the cluster level.
    • StorageClasses – Define storage provisioning behavior across the cluster.
    • CustomResourceDefinitions (CRDs) – Extend Kubernetes by defining new resource types.
    • Namespaces – Interestingly, while used to create logical boundaries, the Namespace object itself is cluster-scoped.

These resources apply across the entire cluster and are not confined to any specific namespace.

Q5: How can you enforce resource limits at the namespace level in Kubernetes?
You can enforce resource limits at the namespace level using a LimitRange object. It sets default and maximum values for CPU and memory requests/limits for Pods or containers in a namespace.

Additionally, you can use a ResourceQuota to control the total amount of resources that can be consumed by all Pods in the namespace. These two work together to prevent resource overconsumption and enforce governance.

🔐 RBAC (Role-Based Access Control)

Q4: What is RBAC in Kubernetes?

RBAC defines who can perform what actions on which resources. It uses Kubernetes objects like Role, ClusterRole, RoleBinding, and ClusterRoleBinding to assign permissions to users, groups, or service accounts.

Q5: What is the difference between Role and ClusterRole?

Role grants permissions within a specific namespace. ClusterRole grants permissions cluster-wide or to multiple namespaces, and can also access non-namespaced resources like nodes or persistent volumes.

Q6: What is the difference between RoleBinding and ClusterRoleBinding?

RoleBinding binds a Role to users/service accounts in a specific namespace. ClusterRoleBinding binds a ClusterRole to users/service accounts across the entire cluster or across namespaces.

📌 Real Use Cases for Role/Binding Combinations

Q7: When should you use Role with RoleBinding?

Use Role + RoleBinding to grant permissions within a single namespace. Example: Allow a developer to create and manage Pods only within the dev namespace.

Q8: When should you use ClusterRole with ClusterRoleBinding?

Use ClusterRole + ClusterRoleBinding for cluster-wide access. Example: Grant cluster administrators the ability to view all nodes, volumes, and system-level resources across all namespaces.

Q9: When should you use ClusterRole with RoleBinding?

Use ClusterRole + RoleBinding to grant namespaced access to a shared ClusterRole. Example: Grant read-only access to all resources in the qa namespace using a reusable view ClusterRole.

Section 14 : Ingress & Gateway

🌐 Ingress

Q1: What is an Ingress in Kubernetes?

An Ingress is a Kubernetes API object that defines rules for routing external HTTP(S) traffic to internal Services in the cluster. Instead of exposing each Service individually using LoadBalancer or NodePort, you can use a single Ingress controller to manage access based on hostnames, paths, and TLS settings.
It acts as a smart entry point for your cluster, enabling features like:

• • Path-based or host-based routing (e.g., /api goes to one service, /web to another)
  • Centralized TLS/SSL termination
  • Virtual hosting (multiple domains served from the same IP)

To function, Ingress requires an Ingress Controller (like NGINX, Traefik, or cloud-native options like Azure Application Gateway Ingress Controller or AWS ALB Ingress Controller) running in the cluster to interpret and enforce the Ingress rules.

Q2: What are the advantages of using Ingress?

Ingress consolidates routing rules in a single place, supports advanced traffic routing (host/path based), TLS configuration, and reduces the need for exposing each service via NodePort or LoadBalancer.

Q3: What is an Ingress Controller?

An Ingress Controller is the actual implementation that watches Ingress resources and configures the underlying proxy/load balancer (e.g., NGINX, Traefik, Istio) to route traffic accordingly.

Q4: Can you expose TCP/UDP traffic using Ingress?

Not directly. Ingress is designed for HTTP/HTTPS traffic. For TCP/UDP exposure, you typically use Services of type LoadBalancer or configure the Ingress Controller (if it supports TCP/UDP proxying).

Q5: How does TLS termination work with Ingress?

TLS certificates are specified in the Ingress resource, and the Ingress Controller terminates the SSL connection before forwarding traffic to backend services. Secrets are used to store certificates.

🚪 Gateway API (Next-Gen Ingress)

Q6: What is the Gateway API in Kubernetes?

The Gateway API is an evolution of Ingress. It provides a more extensible, role-oriented, and expressive way to manage traffic routing into a Kubernetes cluster, supporting use cases beyond HTTP/S (like TCP/UDP/GRPC).

Q7: How is Gateway API different from Ingress?

Gateway API breaks down configuration into multiple objects: GatewayClass, Gateway, HTTPRoute, TCPRoute, etc. This separation allows better delegation, modularity, and multi-tenant support compared to the flat Ingress resource.

Q8: What are the components of the Gateway API?

• • GatewayClass – Defines the type of gateway (like an Ingress controller class).
  • Gateway – Represents an actual network endpoint (e.g., IP, port).
  • Route (HTTPRoute, TCPRoute, etc.) – Defines how traffic is routed to Services.

Q9: Can you use both Ingress and Gateway API in the same cluster?

Yes. They can coexist, though it’s recommended to migrate toward Gateway API over time, especially for advanced use cases. Not all Ingress Controllers support Gateway API yet.

Q10: What are some common Ingress Controllers that support Gateway API?

Controllers like NGINX Gateway, Contour, Istio, and Traefik are adding support for Gateway API. Adoption is increasing across the ecosystem.

Section 15 : Logging & Monitoring in Kubernetes

📄 Logging

Q1: Where are application logs stored in Kubernetes?

Logs from containers are written to /var/log/containers or stored in container runtime-managed locations. By default, logs are ephemeral and stored on the node’s filesystem unless centralized logging is set up.

Q2: How can you view logs of a specific Pod?

Use the command kubectl logs <pod-name>. For multi-container Pods, specify the container name using -c. For example: kubectl logs mypod -c app.

Q3: What are popular tools for centralized logging in Kubernetes?

• • EFK (Elasticsearch + Fluentd + Kibana)
  • Loki + Promtail + Grafana
  • Datadog / New Relic / Splunk / Azure Monitor

Q4: How do sidecar log shippers work?

A log shipper like Fluent Bit or Filebeat runs as a sidecar container in the same Pod, reading log files or streams from the main container and forwarding them to external log storage systems like Elasticsearch or cloud log analytics.

Q5: Are logs preserved when a Pod restarts?

No. Unless a centralized logging solution is in place or the logs are written to persistent volumes, logs are lost when Pods restart or are rescheduled.

📊 Monitoring

Q6: What metrics are important to monitor in Kubernetes?

• • Node-level: CPU, memory, disk, network usage
  • Pod-level: CPU/memory limits vs usage, restarts, readiness/liveness
  • Cluster-level: Pod scheduling failures, autoscaler behavior, etc.

Q7: What are the core components for monitoring in Kubernetes?

• • Metrics Server – Collects CPU/memory metrics for autoscaling
  • Prometheus – Full-fledged monitoring and alerting toolkit
  • Grafana – Visualization and dashboarding

Q8: How does Prometheus collect metrics?

Prometheus uses a pull model to scrape metrics from targets (nodes, apps, exporters) at regular intervals. It can also scrape metrics exposed by Kubernetes objects annotated with specific labels.

Q9: What is a service monitor in Prometheus Operator?

A ServiceMonitor is a custom resource that tells Prometheus which services to scrape metrics from. It uses label selectors to match services and fetch metrics from their endpoints.

Q10: How can you set up alerting in Kubernetes?

Using Prometheus Alertmanager along with Prometheus. You define alert rules (e.g., CPU > 80% for 5 mins), and Alertmanager handles notification routing (email, Slack, PagerDuty, etc.).

When Kubernetes is hosted as a managed service (like AKS, EKS, or GKE), you can also leverage the cloud provider’s native monitoring and alerting tools — such as Azure Monitor, AWS CloudWatch, or Google Cloud Monitoring. These platforms offer built-in integration with Kubernetes metrics and logs, with customizable alert rules and dashboards.

Section 16 : Kubernetes API & Custom Resources

🧩 Kubernetes API

Q1: What is the Kubernetes API server?

The API server is the front end of the Kubernetes control plane. It exposes REST endpoints to interact with all Kubernetes objects, such as Pods, Deployments, Services, etc. All kubectl commands, controllers, and integrations talk to the cluster via the API server.

Q2: What are Kubernetes API resources?

API resources are the types of objects managed through the Kubernetes API — such as Pods, Services, Deployments, ConfigMaps, etc. These are organized into API groups and versions like apps/v1 or core/v1.

Q3: How can you interact with the Kubernetes API?

You can interact using:

• • kubectl — CLI tool that talks to the API server
  • Client libraries — SDKs available in Go, Python, JavaScript, etc.
  • Raw HTTP calls — For custom integrations or direct REST access

⚙️ Custom Resources & Operators

Q4: What is a Custom Resource (CR) in Kubernetes?

A Custom Resource is an extension of the Kubernetes API that lets you define your own object types. CRs can store and manage custom application-specific data the same way built-in resources do.

Q5: What is a Custom Resource Definition (CRD)?

A CRD is a Kubernetes object used to define a new API resource type. Once registered, you can create and manage instances of the custom resource using kubectl and the Kubernetes API.

Q6: What is a Kubernetes Operator?

An Operator is a method of packaging, deploying, and managing a Kubernetes application using custom resources and controllers. Operators watch CRs and implement business logic to act on changes — essentially automating complex application management.

Q7: What are real-world use cases for Custom Resources and Operators?

• • Managing database clusters like PostgreSQL or MongoDB
  • Automating certificate lifecycle (e.g., cert-manager)
  • Running infrastructure components like Prometheus or ArgoCD

Section 17 : Jobs & CronJobs

📌 Kubernetes Jobs

Q1: What is a Job in Kubernetes?

A Job is a Kubernetes resource that ensures a specified number of Pods successfully complete a task. It’s used for short-lived, one-time tasks like batch processing or data transformation.

Q2: How does a Job ensure completion?

The Job controller monitors the status of Pods and creates new ones if failures occur. It tracks completions and considers the job finished once the specified number of successful completions is reached.

Q3: What are backoffLimit and completions in a Job?

• backoffLimit: Number of retries before considering the Job as failed.
• completions: Number of times the job must be successfully completed.

Q4: What happens when a Job fails?

If Pods fail and the backoffLimit is reached, the Job is marked as failed. You can view the status using kubectl describe job <name>.

⏰ Kubernetes CronJobs

Q5: What is a CronJob in Kubernetes?

A CronJob creates Jobs on a time-based schedule using Cron format. It’s used for periodic tasks like backups, report generation, or cleanup scripts.

Q6: What is the Cron schedule format?

It follows standard cron format: minute hour day month day-of-week. For example, 0 0 * * * runs the Job every day at midnight.

Q7: How does Kubernetes prevent overlapping CronJobs?

Use concurrencyPolicy:

• • Allow: Jobs can run concurrently
  • Forbid: Skips the next run if the previous hasn’t finished
  • Replace: Replaces the currently running Job with a new one

Q8: How do you manage failed or successful Jobs in CronJobs?

Use successfulJobsHistoryLimit and failedJobsHistoryLimit to retain a specific number of completed or failed Jobs. Older ones are cleaned up automatically.

Section 18 : Provisioning and Upgrading a Kubernetes Cluster

🚀 Deploying Kubernetes Clusters

Q1: What are the common ways to deploy Kubernetes?

Kubernetes can be deployed in multiple ways:

• kubeadm: A CLI tool provided by the Kubernetes project to set up clusters manually. It is widely used for on-prem or custom-managed clusters.
• Cloud-managed services: Platforms like AKS (Azure Kubernetes Service), EKS (Elastic Kubernetes Service), and GKE (Google Kubernetes Engine) offer managed control planes and reduce operational overhead.

Most enterprises today prefer cloud-managed Kubernetes to offload complexities such as control plane management, high availability, and monitoring.

🔧 Upgrading Kubernetes

Q2: How are Kubernetes upgrades handled in on-prem clusters?

In on-prem environments, upgrades are typically performed using kubeadm upgrade which follows a step-by-step process: upgrading the control plane nodes first, then the worker nodes. It requires careful planning and backup to avoid disruptions.

Q3: How are upgrades handled in managed Kubernetes services?

Managed services provide built-in upgrade capabilities via portal, CLI, or API. The control plane is upgraded by the cloud provider, while node upgrades are either manual or automated (e.g., node pool upgrade in AKS). Maintenance windows and version skew policies help minimize impact.

Q4: What is a PodDisruptionBudget (PDB) in Kubernetes?
A PDB is a policy that specifies the minimum number or percentage of Pods in a deployment or StatefulSet that must remain available during voluntary disruptions, such as node drains or upgrades. It helps maintain application availability during maintenance events.

Q5: What is the purpose of using a PDB?
PDBs are used to prevent too many Pods from being evicted at once during cluster maintenance or scaling operations. This ensures service continuity for critical applications, especially in high-availability or production environments.

Q6: What types of disruptions does a PDB protect against?
PDBs only protect against voluntary disruptions, such as:

• • Node drains (e.g., during upgrades)
  • Evictions triggered by cluster autoscaler
  • Administrative operations
    They do not protect against involuntary disruptions like node failures or OOM kills.

🛠️ Maintenance Best Practices

Q4: What are best practices for maintaining a Kubernetes cluster?

• • Keep Kubernetes versions and critical add-ons up to date
  • Regularly apply security patches to nodes
  • Use health probes and liveness checks for better availability
  • Enable audit logging and RBAC
  • Take etcd backups periodically (for self-managed clusters)
  • Use auto-scaling and node replacement strategies for lifecycle management

Maintenance in cloud-managed Kubernetes clusters is significantly simplified, as the provider handles many of these responsibilities.

🔧 Tools & Methods for Managing Kubernetes

Q1: What is a kubeconfig file and how does it work?

The kubeconfig file contains cluster access information such as API server endpoints, user credentials, and namespaces. It allows kubectl and other tools to interact with the Kubernetes cluster. You can manage multiple contexts for different clusters and users within the same file.

Q2: What is the file extension of a kubeconfig file?

A kubeconfig file has no mandatory extension, but it is usually named simply config. However, for multiple contexts or custom naming, files like my-kubeconfig.yaml or dev-cluster-config.yml are also common.

Q3: Where is the kubeconfig file stored on Linux and Windows?

• • Linux/macOS: ~/.kube/config
  • Windows: %USERPROFILE%\.kube\config

You can also override this location using the KUBECONFIG environment variable.

Q4: What is the difference between imperative and declarative management in Kubernetes?

Imperative management involves using direct kubectl commands like kubectl run, kubectl expose, or kubectl create. This is quick for testing but hard to maintain long-term.

Declarative management uses YAML manifests to define the desired state of resources. These files can be version-controlled and reapplied as needed, making them ideal for repeatable and consistent deployments.

Recommendation: Use declarative YAML-based management for production, and keep everything version-controlled in a Git repository.

🔁 Managing Cloud-Hosted Kubernetes Clusters

Q5: What are the best practices for managing Kubernetes in cloud environments (AKS, EKS, GKE)?

• • Use the cloud provider’s CLI or portal to download the kubeconfig for authentication and access.
  • Avoid manual intervention. Adopt Git-based workflows (CI/CD or GitOps) for consistent and auditable deployments.
  • Integrate the cluster with a DevOps platform (like Azure DevOps, GitHub Actions, ArgoCD, or FluxCD).
  • Secure the cluster using managed identities (e.g., Azure Workload Identity) and apply RBAC to limit access.
  • Apply governance using native tools (Azure Policy, AWS OPA/Gatekeeper, etc.) and monitor drift.

Cloud-managed Kubernetes clusters simplify lifecycle operations and benefit from automation, built-in security, and seamless DevOps integration. GitOps and CI/CD are now standard for robust, scalable Kubernetes management.

Section 20 : Helm in Kubernetes

🎯 Introduction to Helm

Q1: What is Helm in Kubernetes?

Helm is a package manager for Kubernetes that helps you define, install, and upgrade even the most complex Kubernetes applications using a packaging format called “charts”. It simplifies deployment and version control for Kubernetes manifests.

Q2: What are Helm Charts?

A Helm Chart is a collection of YAML templates and metadata that define a set of Kubernetes resources. It allows you to package your app and infrastructure as a versioned artifact that can be reused and shared.

📦 Helm Operations

Q3: How do you install a Helm chart?

You can install a chart using the command: helm install <release-name> <chart-name>. You can also override default values using --values or --set flags.

Q4: How do you upgrade a Helm release?

Use helm upgrade <release-name> <chart-name> to apply updated configurations or versions. Helm will perform a rolling update of the underlying Kubernetes resources.

Q5: How do you roll back a Helm release?

Helm maintains a revision history. Use helm rollback <release-name> [revision] to revert to a previous state of the deployment.

🔍 Helm Internals & Benefits

Q6: What is the structure of a Helm chart?

A typical chart contains:

• • Chart.yaml – Metadata about the chart
  • values.yaml – Default configuration values
  • templates/ – Templated Kubernetes manifests
  • charts/ – Dependencies (other charts)

Q7: What are the benefits of using Helm?

• • Repeatable deployments and better DR strategies
  • Parameterization of Kubernetes manifests
  • Version control and rollback support
  • Helps manage complexity in large applications
  • Wide availability of public charts (e.g., Bitnami, Prometheus)

🔐 Security Considerations

Q8: What are some security concerns with Helm?

Older versions (v2) had a server-side component called Tiller, which had broad access to the cluster and was a security risk. Helm v3 removed Tiller and is now client-only, using your kubeconfig permissions. Always review chart sources and values to avoid security misconfigurations.

🌐 Real-World Usage

Q9: Where is Helm typically used in CI/CD pipelines?

In GitOps or CI/CD pipelines, Helm is used to templatize and deploy manifests via tools like Argo CD, Flux, or Azure DevOps. It enables versioned, auditable, and repeatable deployments across environments.

Section 21 : Service Mesh & GitOps 

🧭 Service Mesh Basics

Q1: What is a Service Mesh in Kubernetes?

A Service Mesh is a dedicated infrastructure layer that handles service-to-service communication in a secure, observable, and controlled manner. It typically uses a data plane of sidecar proxies and a control plane to manage them.

Q2: What are some popular Service Mesh options?

Istio, Linkerd, Consul Connect, and Kuma are commonly used service mesh solutions. Istio is the most feature-rich, supporting mTLS, traffic shifting, telemetry, retries, circuit breaking, and more.

Q3: What are the key features of a Service Mesh?

• • Zero-trust security with mTLS
  • Advanced traffic routing and A/B testing
  • Observability with metrics and tracing
  • Policy enforcement and rate limiting
  • Load Balancing
  • Rate Limiting

🚀 GitOps Basics

Q4: What is GitOps?

GitOps is a modern way of managing Kubernetes clusters and applications using Git as the single source of truth. It ensures that your desired state is version-controlled and applied to the cluster via automated reconcilers.

Q5: What are the benefits of GitOps?

• • Version-controlled infrastructure and app configs
  • Auditable change history through Git commits
  • Automated sync between Git and cluster
  • Reduced manual intervention and improved reliability

Q6: What are some popular GitOps tools?

Argo CD and Flux CD are the most widely used GitOps tools for Kubernetes. They continuously monitor your Git repo and sync changes to the cluster.

Section 22 : Miscellaneous Topics in Kubernetes