All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
8668 bites
Page 84
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.
Create a Deployment with 3 replicas via kubectl
Kubectl create deployment webapp --image=my-app:1.0, then kubectl scale to 3 replicas, or use --replicas if supported.
Deployment, ReplicaSet, and Pod hierarchy
A Deployment manages ReplicaSets, each ReplicaSet keeps a set of identical Pods, and Deployments add rolling updates, rollback, and self-healing.
CRDs and the Operator pattern
CRDs add new API object types, an Operator pairs a CRD with a controller that runs a reconciliation loop encoding domain operational knowledge.
Scheduler filtering and scoring phases
Filtering eliminates infeasible Nodes via resources, taints, and affinity, then scoring ranks the survivors to pick the best, after which the Pod is bound.
Deployment versus StatefulSet
Deployments suit interchangeable stateless replicas, StatefulSets give stable identities, ordered rollout, and per-Pod persistent storage for stateful systems.
The Kubernetes reconciliation loop
A controller continuously observes actual state, compares to desired state in the spec, and acts to close the gap, level-triggered not edge-triggered.
etcd as the cluster source of truth
Etcd is the consistent key-value store holding all cluster state, accessed only via the apiserver, and uses Raft needing a quorum.
What happens after kubectl apply
Apiserver validates and persists to etcd, scheduler binds the Pod to a Node, kubelet pulls the image and starts the container via the runtime, status flows back.
Minimal objects to expose a stateless app
A Deployment to run and self-heal replicas plus a Service to give a stable endpoint, exposed externally via type LoadBalancer or NodePort, or an Ingress.
Core control plane components
Api-server as the front door, etcd as state store, scheduler placing pods, and controller-manager running reconciliation loops, plus cloud-controller-manager.
Node, Pod, and Container relationship
A Node is a machine, a Pod is the smallest deployable unit wrapping one or more containers that share network and storage, and the Pod abstraction enables co-location and lifecycle management.
Reducing cross-region image pull costs
A per-region pull-through cache or geo-replicated registry serves pulls locally, cutting latency and egress, traded against consistency lag, storage cost, and cache management.