Kubernetes Engineer interview questions

A controller continuously compares observed cluster state with the declared desired state and acts to reduce the difference.

• Users submit intent through API objects rather than issuing a fixed sequence of commands to nodes.
• Controllers watch resources and use labels, selectors, and owner references to manage dependent objects.
• Reconciliation is repeated and must be idempotent because events can be duplicated or state can change between observations.
• Status records observed results, while spec remains the requested state that the controller works toward.

A Deployment manages stateless replicated Pods through ReplicaSets and provides declarative rollout and rollback behavior.

• Its selector identifies the Pods it owns, while the Pod template defines the desired revision.
• Changing the template creates a new ReplicaSet and shifts replicas according to the update strategy.
• The controller replaces failed or deleted Pods to maintain the declared replica count.
• Pod names and identities are disposable, so durable identity or storage should not depend on a particular replica.

maxSurge limits extra Pods above the desired replica count, while maxUnavailable limits how many desired replicas may be unavailable during rollout.

• Higher surge can speed replacement but requires spare cluster capacity.
• Lower unavailability protects serving capacity but can slow progress when new Pods start gradually.
• Both accept absolute numbers or percentages, with rounding behavior applied by the Deployment controller.
• Readiness determines whether a new Pod counts as available, so rollout safety depends on a meaningful readiness probe.

StatefulSet is appropriate when replicas need stable identity, ordered lifecycle, or individually associated persistent storage.

• Pods receive predictable ordinal names and stable network identities across rescheduling.
• volumeClaimTemplates create a distinct PVC for each ordinal rather than one disposable shared volume.
• OrderedReady behavior controls default creation, scaling, and update order, while Parallel pod management relaxes some ordering.
• StatefulSet does not make an application distributed or replicate its data; the workload must still implement those semantics.

A headless Service provides stable DNS records for individual StatefulSet Pods without placing a virtual Service IP in front of them.

• Setting clusterIP to None lets DNS return Pod addresses rather than one load-balanced address.
• Each ordinal can receive a predictable name such as pod-0.service.namespace.svc.
• Peer-aware systems can use those records for discovery, membership, or leader coordination.
• Readiness and publishNotReadyAddresses must be chosen deliberately when peers need discovery before becoming ready.

A DaemonSet runs a Pod on every eligible node or on every node matching its scheduling constraints.

• Typical uses include log collectors, node monitoring agents, CNI components, and storage node plugins.
• New eligible nodes receive the Pod automatically, and Pods disappear when their nodes leave the cluster.
• Node selectors, affinity, and taints determine which classes of nodes actually run the daemon.
• Application replicas that scale with traffic usually belong in a Deployment rather than a DaemonSet.

A Job creates Pods until it reaches the required number of successful completions or its failure policy stops further attempts.

• completions defines the required successes, while parallelism limits concurrently running Pods.
• backoffLimit bounds retries, and activeDeadlineSeconds bounds total execution time.
• restartPolicy must be Never or OnFailure because successful Job Pods should not restart forever.
• Indexed Jobs give parallel workers stable completion indexes when input can be partitioned deterministically.

A CronJob creates Jobs on a schedule and needs explicit rules for missed runs, overlap, time zones, and history.

• concurrencyPolicy decides whether overlapping runs are allowed, skipped, or replaced.
• startingDeadlineSeconds limits how late a missed schedule may still create a Job.
• The timeZone field makes schedule interpretation explicit instead of relying on controller defaults.
• Successful and failed history limits prevent old Job objects from accumulating without bounds.

OnFailure can restart a failed container inside the same Pod, while Never leaves the Pod terminal and lets the Job create another one.

• Pod-level restarts preserve Pod identity but make attempts less visible as separate objects.
• Never represents each failed attempt as a separate Pod, which simplifies inspection at the cost of more objects.
• backoffLimit still governs Job retries, while per-index policies can refine indexed workloads.
• The task must tolerate retries because Kubernetes cannot guarantee that a failed attempt produced no external side effect.

A controller's selector defines ownership of matching Pods, so it must align with template labels and avoid overlap with other controllers.

• A selector that does not match the Pod template is rejected for controllers such as Deployment.
• Overlapping selectors can make controllers compete over similar Pods and produce unsafe ownership assumptions.
• Deployment selectors are immutable in the stable API, so changing identity usually requires a new Deployment.
• Labels used only for release or observability should be separated from the stable labels that define controller identity.

The Service type determines how a stable virtual endpoint is exposed beyond its selected Pods.

• ClusterIP is reachable inside the cluster and is the default for internal service discovery.
• NodePort opens the same port on eligible nodes and forwards traffic to the Service, often as a building block rather than a final public interface.
• LoadBalancer asks a supported cloud or implementation controller to provision an external load balancer, usually backed by Service networking.
• All three still depend on selectors or explicit EndpointSlices that identify ready backends.

Ingress declares HTTP routing intent, while an Ingress Controller watches that intent and configures a concrete proxy or load balancer.

• Creating an Ingress without a matching controller produces no data-plane implementation.
• ingressClassName selects the controller class when a cluster hosts more than one implementation.
• Host and path rules route requests to Kubernetes Services, not directly to arbitrary Pods.
• Controller-specific annotations add features but reduce portability beyond the standard Ingress API.

Ingress matches request hosts and paths to Service backends, and its TLS section associates hosts with certificate Secrets.

• Exact matches one path precisely, while Prefix matches path segments according to Kubernetes path rules.
• ImplementationSpecific delegates matching behavior to the selected controller and is less portable.
• A TLS Secret normally contains tls.crt and tls.key in the same namespace as the Ingress.
• Termination at the controller protects the client connection, while backend encryption requires separate controller and service configuration.

Gateway API separates infrastructure attachment from application routes and provides richer typed routing resources.

• GatewayClass identifies an implementation, Gateway defines listeners, and HTTPRoute or other routes attach traffic rules.
• allowedRoutes controls which namespaces may attach Routes to a Gateway, while ReferenceGrant authorizes cross-namespace object references such as backends.
• Status conditions make route acceptance and attachment visible in a standardized way.
• Ingress remains valid for simpler HTTP routing, while Gateway API fits shared and multi-team traffic infrastructure more cleanly.

A default-deny policy selects Pods and isolates them so only traffic allowed by other applicable policies is accepted.

• Ingress and egress isolation are independent and must be declared for the directions that need denial.
• An empty ingress or egress rule list allows no traffic in that direction for selected Pods.
• Policies are additive, so a later policy adds allowed traffic rather than overriding the default-deny object.
• Enforcement requires a network plugin that implements NetworkPolicy semantics.

Selectors in the same peer entry are ANDed, while separate peer entries represent alternative allowed sources or destinations.

• podSelector alone selects matching Pods in the policy's namespace.
• namespaceSelector alone selects all qualifying Pods in matching namespaces.
• Combining both in one entry selects matching Pods only inside matching namespaces.
• YAML list indentation matters because splitting them into two entries broadens access instead of narrowing it.

Egress isolation normally needs an explicit allowance for Pods to reach the cluster DNS service before name-based application traffic can work.

• A policy can select the DNS Pods and permit UDP and TCP on the configured DNS port.
• The actual namespace and labels depend on the cluster DNS deployment and should not be guessed from examples.
• Standard NetworkPolicy controls IP and port traffic, not arbitrary DNS names after resolution.
• DNS access alone does not permit the resolved destination, which still needs its own egress rule.

Standard NetworkPolicy provides namespaced L3 and L4 allow rules but does not define every network-security feature.

• It has no native deny-rule priority because applicable allow policies are additive.
• HTTP paths, methods, and other L7 attributes require CNI-specific policy or another proxy layer.
• Policy behavior for host networking and some node traffic depends on the network implementation.
• Products such as Cilium extend the model, but those resources are not portable Kubernetes NetworkPolicy.

Ephemeral storage follows the Pod or container lifecycle, while persistent storage is represented independently so data can survive Pod replacement.

• emptyDir is created for a Pod and removed when that Pod leaves its node permanently.
• A PVC references durable storage whose lifecycle is controlled by claims, volumes, and reclaim policy rather than one container restart.
• ConfigMap, Secret, and projected volumes provide configuration data, not general durable application storage.
• Choosing a volume starts from durability, sharing, access mode, and storage-provider requirements.

A PVC requests storage properties, and Kubernetes binds it to one compatible PV or dynamically provisions a matching volume.

• Compatibility includes requested capacity, access modes, storageClassName, and selector constraints.
• Binding is one-to-one even when the underlying storage can support access from several Pods.
• The PVC is namespaced, while the PV is a cluster-scoped representation of storage.
• A Pod references the PVC, not the provider-specific PV details, which separates workload intent from infrastructure.