Kubernetes Fundamentals

1. What is the primary scheduling unit in Kubernetes?

Node Deployment Pod Service

2. What is the role of the kubelet on a Kubernetes node?

It stores the desired state of all Deployments in the cluster It communicates with the control plane and manages the container lifecycle on the node It provides the external IP address for LoadBalancer Services It acts as the container registry for the cluster

3. Why should you use a Deployment rather than scheduling Pods directly?

Pods cannot specify container images without a Deployment Pods scheduled directly cannot have more than one container A Deployment manages Pod lifecycle including rescheduling Pods lost due to node failure or eviction Direct Pods cannot be exposed via a Service

4. How does a Kubernetes Service know which Pods to route traffic to?

It uses the Deployment's name field to find its Pods It references the Pods directly using a label selector that matches a label on the Pod template It queries the control plane for a list of all running Pods and picks the least loaded ones It is automatically linked to the most recently created Deployment

5. When you run kubectl apply with a new container image version, what does Kubernetes do by default?

It deletes all existing Pods immediately and creates new ones with the updated image It creates a completely new Deployment alongside the old one and switches traffic after all new Pods are ready It replaces Pods one or a few at a time using a rolling update strategy, maintaining availability It does nothing until all existing Pods are manually deleted

6. What does the CrashLoopBackOff status on a Pod indicate?

The Pod is waiting for sufficient cluster resources; Kubernetes retries scheduling every 30 seconds The container is crashing repeatedly; Kubernetes uses exponential backoff between restart attempts The container image cannot be pulled; Kubernetes retries the image pull indefinitely The Pod has been intentionally stopped by an administrator

7. What two changes are required to use a locally built Docker image with a local Kubernetes cluster?

Set imagePullPolicy: Always and use the full registry URL prefix Set imagePullPolicy: Never and reference the image by its local name without a registry URL prefix Set replicas: 1 and add hostNetwork: true to the PodSpec Use kubectl create instead of kubectl apply and specify the image ID

8. Why usually we prefer the declarative approach over the imperative approach for managing Kubernetes objects?

Imperative commands require root access to the cluster nodes Declarative YAML files support more Kubernetes features than imperative commands Declarative configuration is reproducible across environments and easier to update, enabling GitOps workflows Imperative commands are only available on GKE and not on other Kubernetes platforms

9. What is the purpose of the port vs. targetPort fields in a Kubernetes Service definition?

port is the internal cluster port and targetPort is the external internet-facing port port is the port exposed by the Service to its clients, and targetPort is the port on the container that traffic will be forwarded to port specifies the protocol (TCP/UDP) and targetPort specifies the port number Both fields must always be set to the same value or Kubernetes will reject the Service

10. What is a key difference between running Kubernetes locally vs. on a cloud provider, regarding Services?

Local clusters do not support the Deployment object Local clusters cannot run more than one Pod replica Local clusters do not provision an external IP for LoadBalancer-type Services; you must use kubectl port-forward instead Local clusters require all container images to be rebuilt from scratch without caching

11. What is the default state of a readiness probe when a container first starts?

Passing — the container is assumed ready until proven otherwise Failing — the container is assumed unready until it proves it can serve traffic Unknown — Kubernetes waits for the first probe result before assigning a state Passing — because liveness is already passing at boot

12. What does Kubernetes do when a liveness probe fails past its threshold?

Removes the Pod from the load-balancer rotation temporarily Scales down the Deployment by one replica permanently Terminates and replaces the Pod Sends an alert but takes no automated action

13. Which two probe settings together determine how long a liveness probe must keep failing before Kubernetes restarts the Pod?

initialDelaySeconds and timeoutSeconds periodSeconds and failureThreshold successThreshold and initialDelaySeconds timeoutSeconds and successThreshold

14. Which probe type is recommended for a non-HTTP TCP service such as an SMTP server?

httpGet exec (bash script) tcpSocket grpc

15. Why should external dependencies like a database generally not be checked inside a liveness probe?

Liveness probes do not support SQL or network calls It would make the liveness endpoint too slow to respond within timeoutSeconds It could cause unnecessary restarts and cascading failures Kubernetes ignores liveness failures if the readiness probe is passing

16. What is the main prerequisite for achieving zero downtime during a rolling update?

Setting maxUnavailable to 0 Using at least 3 replicas Having a correctly implemented readiness probe Using an external load balancer

17. If maxUnavailable is set to 0 during a rolling update, what must be true of maxSurge?

maxSurge must also be 0 maxSurge must be at least 1 maxSurge must equal the replica count maxSurge has no constraint in this case

18. Which rollout strategy is not natively supported by Kubernetes Deployments?

RollingUpdate Recreate Blue/Green All of the above are natively supported

19. What is the trade-off of setting a high maxSurge value during a rolling update?

The rollout slows down to protect availability Fewer Pods are created during the update The rollout completes faster but temporarily uses more resources The Service stops routing traffic during the rollout

20. How does the Recreate rollout strategy behave?

It replaces Pods incrementally to avoid downtime It terminates all old Pods before creating new ones, causing downtime It runs two Deployments in parallel and switches traffic via a Service selector It requires maxSurge to be set to a non-zero value