All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
4330 bites
Page 37
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.
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%).
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.
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.
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.
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.
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).
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.
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.
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.
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…
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.
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.
ConfigMap vs Secret
ConfigMaps hold non-sensitive plain config; Secrets hold sensitive data, base64-encoded and treated specially (RBAC, optional encryption at rest).
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).
Are base64-encoded Kubernetes Secrets actually secure?
Base64 is reversible, not a protection; default guards against accidental shoulder-surfing only; real defenses are encryption-at-rest, RBAC, audit.
How do you let Pods pull from a private registry?
Create a dockerconfigjson Secret with registry creds; reference it via imagePullSecrets on the Pod or ServiceAccount.
How do you restrict a Pod's access to a Secret?
Pods read Secrets through their ServiceAccount and RBAC, scoped with resourceNames; mounted Secrets are governed by the Pod spec.
How do you inject secrets from an external store at runtime?
Use a sidecar injector or CSI driver that authenticates via the Pod's ServiceAccount token, fetches secrets at runtime, and mounts them on tmpfs.
What do immutable ConfigMaps and Secrets solve?
Setting immutable true blocks data edits, preventing accidental updates and letting the kubelet skip watches, reducing API server load.