Kubernetes Engineer interview questions

Kubernetes is a platform that manages containerized workloads by keeping declared application state running across a cluster.

• It schedules workloads onto available nodes instead of requiring manual placement.
• Controllers replace failed instances and reconcile actual state with desired state.
• Services provide stable access while Pods can be created and removed.
• Kubernetes supplies orchestration primitives, but application code and container images still remain the user's responsibility.

A Kubernetes cluster is a group of control-plane and worker-node components that run and manage workloads together.

• The control plane stores desired state and makes cluster-wide decisions.
• Worker nodes provide CPU, memory, networking, and storage for Pods.
• Components communicate through the Kubernetes API rather than sharing one process.
• A cluster can contain one or many nodes depending on its purpose and availability needs.

Containers isolate processes while sharing the host kernel, whereas virtual machines include a guest operating system on virtualized hardware.

• Container images package an application and its user-space dependencies without a separate kernel.
• Virtual machines generally provide a stronger isolation boundary but consume more resources and start more slowly.
• Multiple containers can run on one node through a container runtime.
• Kubernetes schedules containers inside Pods and does not replace the underlying node operating system.

A Pod is the smallest deployable Kubernetes workload unit and contains one or more tightly coupled containers.

• Containers in a Pod are scheduled together onto the same node.
• They share the Pod network namespace, IP address, and localhost.
• They can share volumes declared in the Pod specification.
• Pods are disposable, so higher-level controllers usually create and replace them.

A Pod can group containers that must share lifecycle, networking, and storage as one application unit.

• The main container may run the application while a helper provides a closely related supporting function.
• Containers communicate over localhost because they share one network namespace.
• Shared volumes allow one container to produce files that another consumes.
• Unrelated services should usually use separate Pods so they can scale and update independently.

Each Pod normally receives its own cluster IP address that is shared by all containers in that Pod.

• Containers inside the Pod use localhost and different ports to communicate with one another.
• Other Pods address it through the Pod IP when cluster networking permits.
• The Pod IP is not stable across replacement, so clients should normally use a Service.
• The Kubernetes network model expects Pod IPs to be routable across nodes without application-level port mapping.

A Pod phase is a high-level summary of where the Pod is in its lifecycle: Pending, Running, Succeeded, Failed, or Unknown.

• Pending means Kubernetes accepted the Pod but one or more containers are not ready to run yet.
• Running means the Pod is bound to a node and at least one container is running, starting, or restarting.
• Succeeded and Failed mean all containers terminated, with success or at least one failure respectively.
• Phase is broader than container state and should not be confused with the Ready condition.

restartPolicy tells the kubelet when to restart terminated application containers in the same Pod.

• Always restarts a terminated container regardless of its exit result.
• OnFailure restarts only containers that exit unsuccessfully.
• Never leaves a terminated container stopped.
• The policy applies to application containers in the Pod and does not recreate the Pod on another node.

An init container runs to completion before the Pod's regular application containers start.

• Multiple init containers run sequentially in the order listed.
• Each must succeed before Kubernetes starts the next init container or an application container.
• Init containers can use separate images, commands, security settings, and shared volumes.
• They suit prerequisite setup without placing that setup logic in the main application image.

A sidecar is a supporting container that runs alongside the main application container in the same Pod.

• It shares the Pod's network and can share declared volumes with the application.
• Common roles include proxying, telemetry collection, or adapting files for the main process.
• The sidecar is tightly coupled to the Pod lifecycle rather than deployed and scaled as an independent service.
• Adding a sidecar increases the Pod's resource use and operational surface, so the coupling should be intentional.

A Deployment declaratively manages a set of replicated application Pods and their updates.

• Its Pod template describes the containers and metadata used for new Pods.
• The replicas field states how many matching Pods should exist.
• The Deployment creates and manages ReplicaSets rather than owning Pods directly.
• It is intended for stateless workloads whose Pods can be replaced from the same template.

A ReplicaSet is a controller that keeps a specified number of matching Pod replicas running.

• It uses a label selector to identify the Pods it manages.
• If too few matching Pods exist, it creates more from its Pod template.
• If too many matching Pods exist, it removes extras.
• Users normally manage ReplicaSets through Deployments, which add update and revision behavior.

A Deployment manages ReplicaSets, and each ReplicaSet maintains Pods created from one template revision.

• Changing the Deployment Pod template causes it to create a new ReplicaSet.
• The new and old ReplicaSets adjust replica counts according to the update strategy.
• Pods receive owner references that connect them to their ReplicaSet.
• This layered ownership lets Kubernetes preserve desired replica count while replacing a workload version.

The replicas field declares the desired number of available Pod instances for the Deployment's workload.

• The Deployment and its ReplicaSet continually compare desired and observed counts.
• A missing Pod is replaced so the count can return to the declared value.
• Multiple replicas can spread application traffic across separate Pod instances.
• Replicas duplicate the Pod template but do not automatically partition application data.

Reconciliation is the repeated process of moving actual cluster state toward the desired state stored in the API.

• A controller watches resources relevant to the state it manages.
• It compares the declared specification with current objects or conditions.
• It creates, updates, or removes resources when the two states differ.
• The loop repeats, so Kubernetes can correct later drift rather than run a one-time script.

Labels are key-value metadata attached to objects for identifying and grouping them.

• They can describe properties such as application, component, environment, or version.
• Selectors use labels to find sets of objects without relying on object names.
• Services and workload controllers depend on accurate labels to connect related resources.
• Labels are intended for identifying data, while larger descriptive text belongs in annotations.

A label selector is a query that matches Kubernetes objects by their labels.

• Equality selectors match expressions such as app=web or tier!=frontend.
• Set-based selectors express membership with operators such as In, NotIn, and Exists.
• A Service selector determines which Pods become its backends.
• A controller selector must match the labels in its Pod template so it can manage the intended Pods.

Annotations store non-identifying metadata, while labels are designed for selecting and grouping objects.

• Annotations may contain tool configuration, ownership links, checksums, or descriptive details.
• Selectors cannot query annotations.
• Annotation values can hold larger and less structured text than label values.
• Metadata used to decide membership in a Service or controller belongs in labels, not annotations.

A Namespace creates a logical scope for many namespaced resources inside one cluster.

• Pods, Deployments, Services, ConfigMaps, and Secrets commonly belong to a Namespace.
• The same resource name can exist in different Namespaces.
• RBAC rules, quotas, and policies can be applied by Namespace.
• Namespaces organize and scope resources but are not automatically a complete security boundary.

Namespaced resources belong to one Namespace, while cluster-scoped resources exist for the whole cluster.

• Pods, Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims are namespaced.
• Nodes, Namespaces, PersistentVolumes, and many cluster-level RBAC objects are cluster-scoped.
• A namespaced resource name must be unique only inside its Namespace.
• kubectl uses the selected Namespace for namespaced resources but does not add one to cluster-scoped resources.