Kubernetes · Beginner interview

Kubernetes is a container orchestration platform that automates deploying, scaling, networking, and healing containerized apps across a cluster of machines. It solves the operational problems of running many containers in production: it keeps the desired number of replicas running, restarts failed ones, rolls out updates, load-balances traffic, and schedules workloads onto nodes. You declare the desired state and Kubernetes works to maintain it.

A cluster has a control plane and worker nodes. The control plane includes the API server (the front door), etcd (the cluster's state store), the scheduler (places Pods on nodes), and controller manager (runs control loops). Each worker node runs a kubelet (manages Pods on that node), a container runtime, and kube-proxy (networking). You interact with the API server, usually via kubectl.

A Pod is the smallest deployable unit in Kubernetes — one or more containers that share a network namespace (same IP and ports) and storage, scheduled together on a node. Usually a Pod runs a single main container, with extra 'sidecar' containers for helper tasks. Pods are ephemeral and disposable; you almost never create them directly but through controllers like Deployments.

A Deployment is a controller that manages a set of identical Pods via a ReplicaSet, ensuring a declared number of replicas run and handling rolling updates and rollbacks. You describe the desired state (image, replicas, config) and the Deployment reconciles toward it — replacing Pods on update, recreating failed ones. It's the standard way to run stateless applications.

kubectl scale deployment web --replicas=5
kubectl rollout undo deployment web

You set a replica count and Kubernetes keeps exactly that many Pods running — if one crashes or its node dies, a controller schedules a replacement (self-healing). Scaling is changing the replica count (manually or via autoscaling), and the scheduler places the new Pods on available nodes. This desired-state reconciliation is the core of how Kubernetes keeps apps available.

A rolling update replaces old Pods with new ones gradually — starting new Pods and terminating old ones a few at a time — so the app stays available with no downtime. Kubernetes keeps the previous ReplicaSet, so if the new version is bad you run kubectl rollout undo to revert. You control the pace with maxSurge and maxUnavailable.

Pods are ephemeral and get new IPs when recreated, so you can't rely on their addresses. A Service provides a stable virtual IP and DNS name that load-balances across the healthy Pods matching its selector. It decouples clients from individual Pods — they talk to the Service, which routes to whatever Pods currently exist.

ClusterIP (default) exposes the Service on an internal IP reachable only inside the cluster — for service-to-service traffic. NodePort opens a static port on every node for external access. LoadBalancer provisions an external cloud load balancer pointing to the Service. ExternalName maps to a DNS name. You usually use ClusterIP internally and a LoadBalancer or Ingress for outside traffic.

An Ingress manages external HTTP/HTTPS access to Services, providing host- and path-based routing, TLS termination, and a single entry point — so multiple services share one load balancer with rules like api.example.com → api service. It needs an Ingress controller (nginx, Traefik) running to implement the rules. It's how you expose many web services without a load balancer each.

Both inject configuration into Pods as environment variables or mounted files, decoupling config from the image. A ConfigMap holds non-sensitive config (URLs, feature flags); a Secret holds sensitive data (passwords, tokens, keys) and is treated more carefully — base64-encoded and ideally encrypted at rest with restricted access. Use ConfigMaps for plain config and Secrets for anything sensitive.

kubectl is the CLI to talk to the cluster's API server — to create, inspect, update, and delete resources. The recommended approach is declarative: you write YAML manifests describing the desired state and run kubectl apply, and Kubernetes reconciles to match. This is preferable to imperative commands because the manifests are version-controllable and reproducible (GitOps).

kubectl get pods shows status; kubectl describe pod <name> shows events and why something failed; kubectl logs <pod> shows container output; and kubectl exec -it <pod> -- sh opens a shell inside it. These cover most first-line debugging — for example, describe reveals scheduling failures or image pull errors, and logs reveal crashes.