Kubernetes: resize, stack, security
Kubernetes is getting finer-grained operational tools—an in-place pod resize feature lets teams change CPU and memory for running pods without restarts, though it introduces production policy and VPA integration questions. Conversations are also converging on a streamlined DevOps stack (Docker/K8s, Terraform, ArgoCD, Prometheus/Grafana) and a focused cluster security checklist covering IAM, VPC isolation, encryption and observability. Together these posts signal practical trade-offs between runtime flexibility, stack simplicity and hardened production security. (x.com, x.com, x.com)
Kubernetes now lets operators change a running pod’s CPU and memory without restarting it, a feature that reached stable status in version 1.35 in December 2025. (kubernetes.io) A pod is Kubernetes’ basic workload unit, and in-place resize changes its resource requests and limits while the pod keeps running. Kubernetes says the feature was introduced as alpha in v1.27, moved to beta in v1.33 in May 2025, and became generally available in v1.35. (kubernetes.io) The practical appeal is straightforward: before this feature, changing CPU or memory usually meant deleting a pod and starting a replacement. The Kubernetes project says in-place resize reduces that disruption for stateful and latency-sensitive workloads that do not tolerate restarts well. (kubernetes.io) The feature does not remove scheduling constraints. Kubernetes still has to find room on the node for the larger request, and the project’s documentation says some resize operations can be deferred or rejected if the node cannot satisfy them. (kubernetes.io) That creates a new policy question for production teams: who is allowed to resize a live workload, by how much, and under what guardrails. The Kubernetes security checklist tells operators to lock down access, use least-privilege identity and access management, and audit cluster activity rather than rely on broad administrator permissions. (kubernetes.io) Autoscaling adds another layer. Kubernetes’ Vertical Pod Autoscaler adjusts resource requests from usage history and real-time events, and its upstream feature docs now include an `InPlaceOrRecreate` mode plus flags for when disruption-budget checks may be skipped for non-disruptive updates. (kubernetes.io, github.com) Around that runtime change, practitioners are still converging on a relatively small platform stack. Argo CD’s documentation describes Git-based continuous delivery for Kubernetes, while Terraform providers and stack guides commonly place Terraform underneath cluster provisioning and Argo CD on top for application sync. (argo-cd.readthedocs.io, registry.terraform.io, devops-stack.io) Observability stays in the same core bundle. DevOps Stack describes Prometheus as the time-series database for cluster metrics and Grafana as the dashboard layer, which mirrors the default monitoring setup used across many Kubernetes installations. (devops-stack.io) Security guidance is similarly narrowing to a checklist. Kubernetes’ own baseline document calls for hardened authentication and authorization, network segmentation, secret and data encryption, image controls, and logging and audit visibility across the cluster. (kubernetes.io) U.S. government hardening guidance goes in the same direction, pointing operators to isolate clusters, restrict administrative access, and monitor for abnormal behavior. In practice, the new resize feature gives teams a finer control at runtime, but it also makes those older controls more important, not less. (media.defense.gov, kubernetes.io)
