Kubernetes

Historical article example: a node reports 10 allocatable CPUs. A Pod requesting 10m with limit 11 CPU was placed; one requesting 11 CPU with the same limit remained Pending. Other constraints still apply.

The scheduler accounts for requests, not momentary utilization

Kubernetes scheduling answers whether a Pod can fit a node under the applicable resource requests and placement constraints. It does not simply look at a current CPU utilization chart and place work wherever the line is low. Requests provide accounting inputs for future demand; actual usage is a separate observation. Diagnose both before deciding that an idle-looking cluster has capacity for a particular Pod. ...

Default CronJob history keeps up to three successful Jobs and one failed Job; Job TTL is an independent age control. Either mechanism can remove a finished Job.

Kubernetes CronJobs need a history policy

A CronJob creates Jobs on a schedule, and each Job manages the Pods that perform the work. Finished objects can preserve useful status, but retention is bounded by several independent mechanisms. In particular, CronJobs already have default history limits. Omitting explicit history settings does not make ordinary completed runs accumulate forever. ...

An ancestor-constraint box branches to two separate container groups, each with its own cap. Unused sibling quota is not automatically transferred.

cgroups enforce container budgets within a hierarchy

Kubernetes resource fields become useful constraints only when the node’s execution stack applies them. On Linux, kubelet and the container runtime use cgroups to organize processes and configure resource controllers. The result is a hierarchy, not merely one number attached to a Pod. Check the relevant container group and its inherited constraints before deciding what budget a process can actually consume. ...

Ordinary new scheduling stops at a cordoned node; existing Pods run. Drain uses budget-aware eviction when supported and waits for termination.

Cordon and drain coordinate node maintenance

Cordon changes scheduling eligibility; drain coordinates eviction and waits for Pod termination. Neither command guarantees that work survives maintenance. Application shutdown, replacement capacity, storage and disruption budgets determine that outcome. Treat a drained node as an observed state with documented exceptions, rather than a promise inferred from one command name. ...

Two metric recommendations merge into the larger count: seven from CPU and twelve from average queue backlog, in the article’s arithmetic model.

The Horizontal Pod Autoscaler depends on metric semantics

A HorizontalPodAutoscaler turns configured metrics into replica recommendations. Choosing the metric and its aggregation is therefore part of application design. Increasing replicas should reduce the measured pressure or increase useful throughput; otherwise the controller may spend more money without relieving the bottleneck. Set explicit minimum and maximum counts, but do not confuse a cost bound with a performance guarantee. ...

A CronJob turns a schedule into Jobs

A CronJob combines a Job template with a recurring schedule. The CronJob controller creates Jobs; each Job manages the Pods that perform the work. A run can involve retries, replacement Pods, or parallel workers, depending on the Job specification. There need not be a dedicated application process waiting between runs, although completed Jobs and Pods may remain for inspection. ...

For a storage=nvme label rule, required affinity excludes a nonmatching node; preferred affinity favors a match while a nonmatch may remain a candidate. Other constraints must still pass.

Node affinity places workloads on matching nodes

Node affinity matches workload requirements to node labels. It can require NVMe storage or prefer a newer instance family, but it does not replace the scheduler’s other checks. Even without affinity, scheduling filters resource requests, taints and volume constraints before scoring feasible nodes. It is not simply a comparison of idle capacity. ...

RollingUpdate lifelines overlap old and new versions. Recreate lifelines place a zero-serving gap between the old version ending and the new version starting during a Deployment upgrade.

Kubernetes rolling updates replace pods gradually

Choose the release shape before its speed. Can old and new versions process requests together? Can they share storage and ownership safely? What happens if the new version cannot start? Those answers determine whether a Deployment should overlap versions with RollingUpdate or stop the old version before replacement with Recreate. The companion article handles rollout pacing and live observation. ...