Challenge your understanding of Kubernetes with these practical interview-style questions, covering key orchestration concepts, deployment scenarios, and troubleshooting techniques. Ideal for preparing for technical assessments or deepening Kubernetes expertise.
Which Kubernetes resource is primarily responsible for ensuring a specified number of pod replicas are running at all times, even after node failures or restarts?
Explanation: A Deployment is designed to manage replicas of pods and ensures the desired number are running as specified by the user, automatically replacing pods in case of failures. ConfigMap is used for managing configuration data, not replicas. ClusterRole defines permissions and access but does not manage pods. ServiceAccount provides identity for processes in pods but is unrelated to pod replication.
In Kubernetes, what component is directly responsible for assigning unscheduled pods to nodes based on resource availability and scheduling policies?
Explanation: The Scheduler is the component that examines pending pods and assigns them to suitable nodes based on available resources and policies. Kubelet manages pods on each node after scheduling, but it does not decide the placement. Proxy handles network communication, not scheduling. Controller Manager runs controllers to ensure the desired state but isn't in charge of scheduling pods.
You want to expose your Kubernetes application to external traffic over the internet. Which type of Kubernetes Service should you use in this scenario?
Explanation: A LoadBalancer Service provides a way to expose an application externally by giving it a publicly accessible IP address. Headless Service is used for direct pod-to-pod communication and does not expose the application externally. ClusterIP is the default and limits access to within the cluster. ConfigController is not a standard Service type and does not manage exposure.
If a pod consistently exceeds its memory resource limits in Kubernetes, what will most likely happen to that pod?
Explanation: When a pod exceeds its memory limit, Kubernetes' system will kill the pod, and if managed by a controller like a Deployment, it may restart it. If the application runs without limits, problems like instability can occur, not indefinite operation. Automatic scaling to another node is triggered by scaling mechanisms, not individual memory excess. Exceeding CPU limits causes throttling, but exceeding memory usually leads to termination.
Which Kubernetes resource should you use to ensure data created by a pod persists across pod restarts or rescheduling events?
Explanation: A PersistentVolumeClaim allows pods to use persistent storage that survives beyond the lifecycle of a single pod, maintaining data across restarts. ReplicaSet is used for maintaining multiple pod replicas, not storage. PodPreset injects configuration into pods, but not storage. Ingress manages external HTTP or HTTPS access, not persistence of storage.