Question 1

What is a Pod in Kubernetes?

Accepted Answer

A Pod is the smallest deployable unit in Kubernetes. It encapsulates one or more containers that share the same network namespace, storage space, and IP address. Containers within a Pod can communicate via localhost and share the same lifecycle. In most cases, a Pod contains a single main container, but sidecar containers can be added for features like logging or monitoring.

Question 2

What are the two main components of the Kubernetes control plane?

Accepted Answer

The Kubernetes control plane mainly comprises the API Server (kube-apiserver) which exposes the Kubernetes API and serves as the entry point for all operations, and etcd which is the distributed key-value database storing cluster state. Other components include the scheduler (kube-scheduler) that assigns Pods to nodes, and the controller manager (kube-controller-manager) that runs control loops. The API Server is the central component that all other components communicate with.

Question 3

What is the role of kubelet in a Kubernetes node?

Accepted Answer

The kubelet is an agent running on each worker node of the cluster. It is responsible for managing Pods on its node: it monitors Pod specifications assigned by the API Server, starts and stops containers via the container runtime, monitors their health via probes (liveness, readiness), and reports status to the control plane. The kubelet ensures that containers defined in PodSpecs are running and healthy.

Question 4

What is the difference between a liveness probe and a readiness probe?

Accepted Answer

The liveness probe checks if the container is alive and functioning correctly. If it fails, Kubernetes restarts the container. It detects deadlocks or unrecoverable blockages. The readiness probe checks if the container is ready to receive traffic. If it fails, the Pod is temporarily removed from the Service without being restarted. Use readiness for external dependencies (database unavailable) and liveness for internal blockages.

Question 5

What are labels used for in Kubernetes?

Accepted Answer

Labels are key-value pairs attached to Kubernetes objects (Pods, Services, Deployments) to organize and identify them. They allow selecting groups of objects via selectors, particularly to connect Services to Pods, target Pods in a Deployment, or filter resources with kubectl. Labels are flexible and can represent the environment (prod, staging), application version, or owning team. They are essential to Kubernetes internal functioning.

Question 6

Which kubectl command shows events for a specific Pod?

Accepted Answer

The kubectl describe pod command displays detailed information about a Pod, including recent events. These events show actions from the scheduler, kubelet and controller manager: Pod assignment, image pulling, container startup, probe failures, etc. Events are essential for troubleshooting as they reveal scheduling issues, image pulls, or container health problems. Alternatively, kubectl get events --field-selector involvedObject.name=podname filters global events.

Question 7

What is a namespace in Kubernetes?

Accepted Answer

A namespace is a logical partitioning mechanism of the Kubernetes cluster allowing isolation of resource groups. It facilitates multi-team, multi-environment (dev, staging, prod) or multi-project organization within the same cluster. Namespaces enable applying resource quotas, specific RBAC policies, and avoiding name conflicts. By default, Kubernetes creates the namespaces default, kube-system (system components) and kube-public. Resources like Pods, Services and Deployments are namespaced.

Question 8

How does Kubernetes ensure high availability of applications?

Accepted Answer

Kubernetes ensures high availability through multiple mechanisms. Deployments maintain the desired number of replicas by automatically creating new Pods if some fail. The scheduler distributes Pods across different nodes to avoid single point of failure. Health probes (liveness/readiness) detect and restart failing containers. Services with load balancing distribute traffic among available Pods. Rolling update strategies enable zero-downtime deployments. Together, these mechanisms ensure resilience and service continuity.

Question 9

What is a Deployment in Kubernetes?

Accepted Answer

A Deployment is a Kubernetes object that manages the declarative deployment and update of Pods via ReplicaSets. It automatically maintains the desired number of running replicas and facilitates rolling updates without downtime. The Deployment creates and supervises a ReplicaSet which manages the Pods. It allows defining deployment strategy (RollingUpdate, Recreate), replica count, and container image. During updates, it progressively creates new Pods while removing old ones, enabling easy rollback.

Question 10

What is the difference between a ReplicaSet and a Deployment?

Accepted Answer

A ReplicaSet ensures a specified number of Pod replicas are running at all times, creating or deleting Pods as needed. A Deployment is a higher-level abstraction that manages ReplicaSets and adds declarative update features, rolling updates, rollback and version history. In practice, it's recommended to use Deployments rather than ReplicaSets directly, as Deployment offers more control over application lifecycle.

Question 11

What is a Service in Kubernetes and why is it necessary?

Accepted Answer

A Service is an abstraction defining a logical set of Pods and an access policy. It's necessary because Pods are ephemeral with changing IP addresses. The Service provides a stable IP address and DNS name to access Pods via label selectors. It distributes traffic among available Pods (internal load balancing). Types include ClusterIP (internal only), NodePort (exposed on node port), and LoadBalancer (external cloud load balancer). The Service decouples consumers from underlying Pods.

Question 12

What is the difference between ClusterIP, NodePort and LoadBalancer?

Accepted Answer

ClusterIP (default) exposes the Service only internally on a virtual cluster IP, accessible only from Pods. NodePort exposes the Service on a static port of each node (30000-32767), accessible externally via NodeIP:NodePort. LoadBalancer (cloud only) provisions an external cloud provider load balancer that routes traffic to NodePorts. ClusterIP for internal communications, NodePort for testing or small exposure, LoadBalancer for production with supported cloud provider.

Question 13

How does a Service select which Pods to route traffic to?

Accepted Answer

A Service uses a label-based selector to identify target Pods. The Service defines a set of key-value pairs in its selector field, and all Pods with matching labels automatically become Service endpoints. For example, a selector app: backend will select all Pods with label app=backend. Kubernetes continuously monitors Pods and automatically updates the endpoints list when Pods are created or deleted, ensuring dynamic routing without manual reconfiguration.

Question 14

Which deployment strategy enables updating an application without downtime?

Accepted Answer

The RollingUpdate strategy enables progressively updating an application without downtime. It gradually replaces old Pods with new Pods, ensuring a minimum number of Pods remains available during the update. The maxUnavailable (max unavailable Pods) and maxSurge (max additional Pods temporarily created) parameters control rolling update speed and safety. The Service continues routing traffic to available Pods throughout the entire update duration.

Question 15

How to rollback a Deployment to a previous version?

Accepted Answer

The kubectl rollout undo deployment deployment-name command reverts to the previous revision. Kubernetes maintains history of previous deployment ReplicaSets. To view history, use kubectl rollout history deployment deployment-name. To revert to specific revision, add --to-revision=N. Rollback is fast because old ReplicaSets are kept with their complete configuration. Number of kept revisions is controlled by revisionHistoryLimit (10 by default). Rollback follows same RollingUpdate strategy to avoid downtime.

Question 16

What is a ConfigMap used for in Kubernetes?

Accepted Answer

A ConfigMap stores non-confidential configuration data as key-value pairs. It allows decoupling configuration from application code, facilitating changes without image rebuild. Pods can consume ConfigMaps via environment variables, command arguments, or files mounted as volumes. ConfigMaps are ideal for configuration files, application parameters, or scripts. Note that data is not encrypted, so for sensitive information like passwords or tokens, use Secrets instead.

Question 17

What is the difference between a ConfigMap and a Secret?

Accepted Answer

A ConfigMap stores non-sensitive configuration data in plain text, while a Secret stores sensitive data (passwords, tokens, SSH keys) encoded in base64. Secrets benefit from additional security measures: encryption at rest in etcd (optional but recommended), secure transmission to Pods, and stricter RBAC access restrictions. Secrets are not displayed in kubectl logs by default. Although base64 is not encryption, it prevents accidental exposure. For enhanced security, use solutions like External Secrets Operator with Vault.

Question 18

How to inject a ConfigMap into a Pod as environment variable?

Accepted Answer

To inject a ConfigMap as environment variable, use the env or envFrom field in container specification. With env, define valueFrom.configMapKeyRef to map specific ConfigMap key to a variable. With envFrom.configMapRef, all ConfigMap keys automatically become environment variables. The first method offers granular control, the second is faster for loading multiple variables. The Pod must reference an existing ConfigMap, otherwise it will remain in Pending state until ConfigMap creation.

Question 19

How to mount a Secret as a volume in a Pod?

Accepted Answer

To mount a Secret as volume, define a secret type volume in Pod spec with secretName, then mount this volume in container via volumeMounts with mountPath. Each Secret key becomes a file in mounted directory, with decoded value as content. This method is preferable to environment variables for sensitive configuration files (TLS certificates, SSH keys). Secrets mounted as volumes benefit from automatic updates if Secret is modified, unlike environment variables which require Pod restart.

Question 20

What happens if a Pod references a ConfigMap that doesn't exist yet?

Accepted Answer

If a Pod references a non-existent ConfigMap, it will remain stuck in Pending state and won't start. The kubelet will wait for the ConfigMap to be created before launching containers. Pod events will indicate a configmap not found error. This strict dependency ensures Pods never start with missing or incomplete configuration. To avoid this issue, create ConfigMaps and Secrets before deploying Pods, or use optional: true option in ConfigMap reference to allow startup even without the ConfigMap.

Question 21

Which kubectl command retrieves logs from a Pod with multiple containers?

Accepted Answer

For a Pod with multiple containers, use kubectl logs pod-name -c container-name to specify target container. Without -c option, kubectl will return error asking to specify container. To follow logs in real-time, add -f (follow). To view previous container logs after crash, use --previous. The --all-containers=true option displays logs from all containers simultaneously, useful for debugging. Logs are limited in size and duration, for permanent storage use log aggregation solution like ELK or Loki.

Question 22

What does the CrashLoopBackOff status of a Pod mean?

Accepted Answer

CrashLoopBackOff indicates the container starts then immediately crashes repeatedly. Kubernetes applies exponential delay (backoff) between restart attempts to avoid system overload. Common causes include: application code error, incorrect entrypoint command, missing dependencies, configuration issue, or too aggressive liveness probe failure. To diagnose, check logs with kubectl logs, verify events with kubectl describe pod, and examine container configuration. The restart counter increases with each crash.

Question 23

How to debug a Pod that remains in Pending status?

Accepted Answer

A Pod in Pending status has not yet been scheduled on a node. Use kubectl describe pod to examine events revealing the cause: insufficient resources (CPU/memory), no nodes matching nodeSelector or affinity rules, unsatisfied PersistentVolumeClaim, taints on nodes without corresponding tolerations, or inaccessible image registry. Also check kubectl get nodes for node status. Event messages like FailedScheduling or Insufficient cpu precisely indicate the problem. Resolve by adjusting resources, scheduling constraints, or cluster capacity.

Question 24

Which command allows executing an interactive command in a running container?

Accepted Answer

The kubectl exec -it pod-name -- command allows executing interactive command in a container. The -i (stdin) option keeps stdin open, -t allocates pseudo-TTY for interactive session. For interactive shell, use kubectl exec -it pod-name -- /bin/bash or /bin/sh. With multiple containers, specify -c container-name. This command is essential for debugging: inspecting filesystem, testing network connectivity, checking environment variables, or diagnosing application issues. Avoid using exec to modify container state in production.

Question 25

How to define resource limits (CPU and memory) for a container?

Accepted Answer

Resource limits are defined in container spec via resources.requests (guaranteed minimum) and resources.limits (maximum allowed). Requests influence scheduling (scheduler chooses node with sufficient capacity), limits control execution (container cannot exceed). For CPU, use millicores (500m = 0.5 CPU) or whole units (1, 2). For memory, use Mi (Mebibytes) or Gi (Gibibytes). If container exceeds memory limit, it's killed (OOMKilled). Exceeding CPU causes throttling. Setting appropriate requests and limits improves cluster resource stability and utilization.

Question 26

What is the best practice for managing sensitive secrets in Kubernetes?

Accepted Answer

Best practice is using external secrets management solution like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, coupled with External Secrets Operator that automatically synchronizes secrets in Kubernetes. Enable at-rest encryption in etcd via EncryptionConfiguration. Use strict RBAC to limit Secret access. Avoid committing Secrets to Git (use sealed-secrets for GitOps). Prefer volume mounts over environment variables. Use cloud-native identities (IRSA, Workload Identity) rather than static credentials. Regularly audit secret access and implement automatic rotation.

Kubernetes Basics

What is a Pod in Kubernetes?

Answer

What are the two main components of the Kubernetes control plane?

Answer

What is the role of kubelet in a Kubernetes node?

Answer

What is the difference between a liveness probe and a readiness probe?

What are labels used for in Kubernetes?

Which kubectl command shows events for a specific Pod?

Master DevOps for your next interview