☁️ DevOps &amp; Cloud

Two ways to consume a ConfigMap in a Pod

Inject keys as environment variables (good for a few simple settings), or mount the ConfigMap as a volume of files (good for config files and live updates).

ConfigMap vs Secret

ConfigMaps hold non-sensitive plain config; Secrets hold sensitive data, base64-encoded and treated specially (RBAC, optional encryption at rest).

Ingress resource vs Ingress controller

The Ingress resource is declarative routing rules; the controller is the running proxy (NGINX, etc.) that reads them and serves traffic.

Restricting Pod ingress with a NetworkPolicy

Create a NetworkPolicy with podSelector app=frontend, policyTypes Ingress, and one ingress from-rule matching podSelector role=api-gateway; requires a CNI that enforces policies.

advanced2 min read

kube-proxy and iptables vs IPVS modes

Kube-proxy watches Services/endpoints and programs node rules so ClusterIP traffic is DNAT'd to a backend Pod; iptables uses sequential rule chains, IPVS uses a hash table with real…

Debugging Service connectivity between Pods

Kubectl get endpoints to check the Service has Pod IPs (selector match); kubectl describe service to verify selector and ports; exec into the frontend to curl the Service DNS name.

Headless Services and direct Pod DNS

Set clusterIP: None so no virtual IP or proxy load balancing; DNS returns individual Pod IPs (A records). Primary use: StatefulSets needing stable per-Pod addressing.

Ingress for host and path routing

Use an Ingress with an Ingress controller for layer-7 host/path routing behind one external IP, instead of one cloud LoadBalancer per service.

Cross-namespace Service DNS resolution

CoreDNS gives each Service a name; cross-namespace you must qualify it as my-service.B.svc.cluster.local (or my-service.B).

ClusterIP vs NodePort vs LoadBalancer

ClusterIP for internal-only access; NodePort opens a port on every node for basic external reach; LoadBalancer provisions a cloud load balancer for production external traffic.

Why Kubernetes Services exist

Pod IPs are ephemeral and change on reschedule; a Service gives a stable virtual IP and DNS name plus load balancing across healthy Pods via label selectors.

Spreading Pods one-per-node for availability

Use required podAntiAffinity with topologyKey kubernetes.io/hostname matching the Deployment's own pod labels, so the scheduler refuses to co-locate two Pods on a node.

Stalled rollouts and progressDeadlineSeconds

With maxUnavailable respected, the rollout pauses partway and old Pods keep serving; progressDeadlineSeconds marks the Deployment as failed after no progress for that window.

Tuning maxSurge and maxUnavailable

MaxSurge allows Pods above desired; maxUnavailable allows Pods below desired during update. For zero downtime and speed, set maxUnavailable 0 and maxSurge high (e.g. 100%).

Sharing ephemeral cache between containers in a Pod

Use an emptyDir volume defined in the Pod spec and mounted into each container at the cache path; it is created with the Pod and deleted when the Pod is removed.

Liveness vs readiness probes

Liveness restarts a stuck container; readiness gates traffic by controlling Service endpoint membership. Readiness-only fits an app that pauses to reload a large cache but is still healthy.

Rolling back a bad Deployment

Kubectl rollout undo deployment/NAME reverts to the prior revision by scaling the old ReplicaSet back up and the bad one down.

How a Deployment rolling update works

New image creates a new ReplicaSet; Deployment scales it up while scaling the old one down per maxSurge/maxUnavailable; old ReplicaSet is retained at zero for rollback.

Debugging a Pod in CrashLoopBackOff

Kubectl describe pod for events, restarts, and last state; kubectl logs (with --previous) for the crashed container's output.