From f482e358e7dd3584350b6832dcb0788456193207 Mon Sep 17 00:00:00 2001 From: vinay kulkarni Date: Mon, 20 Mar 2023 12:57:04 -0700 Subject: [PATCH] Initial draft of blog post for in-place pod resize feature --- .../2022-10-21-in-place-pod-resize-alpha.md | 35 ----- .../2023-04-04-in-place-pod-resize-alpha.md | 125 ++++++++++++++++++ 2 files changed, 125 insertions(+), 35 deletions(-) delete mode 100644 content/en/blog/_posts/2022-10-21-in-place-pod-resize-alpha.md create mode 100644 content/en/blog/_posts/2023-04-04-in-place-pod-resize-alpha.md diff --git a/content/en/blog/_posts/2022-10-21-in-place-pod-resize-alpha.md b/content/en/blog/_posts/2022-10-21-in-place-pod-resize-alpha.md deleted file mode 100644 index a9cccf41c1dff..0000000000000 --- a/content/en/blog/_posts/2022-10-21-in-place-pod-resize-alpha.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: blog -title: "Kubernetes 1.27: In-place Resource Resize for Kubernetes Pods lands as alpha" -date: 2022-10-21 -slug: in-place-pod-resize-alpha ---- - -**Author:** Vinay Kulkarni - -TBD-placeholder - -## What's new in 1.27? - -TBD-placeholder - -## When to use this feature - -TBD-placeholder - -## How to use this feature - -TBD-placeholder - -## Example Use Cases - -TBD-placeholder - -## Security Considerations - -TBD-placeholder - -## References - -TBD-placeholder - diff --git a/content/en/blog/_posts/2023-04-04-in-place-pod-resize-alpha.md b/content/en/blog/_posts/2023-04-04-in-place-pod-resize-alpha.md new file mode 100644 index 0000000000000..ae4f4dfd32ad6 --- /dev/null +++ b/content/en/blog/_posts/2023-04-04-in-place-pod-resize-alpha.md @@ -0,0 +1,125 @@ +--- +layout: blog +title: "Kubernetes 1.27: In-place Resource Resize for Kubernetes Pods (alpha)" +date: 2023-04-04 +slug: in-place-pod-resize-alpha +--- + +**Author:** Vinay Kulkarni + +Kubernetes v1.27 brings a new alpha feature that allows users to resize CPU +and memory resources allocated to their pod without restarting them. The +`resources` field in pod's containers are now mutable for `cpu` and `memory` +resources. Additionally, a new `restartPolicy` for resize gives users control +over how their containers are handled during resize. + +Kubernetes gets the actual CPU and memory requests and limits enforced on the +containers via an API call to the container runtime, and hence need support +from container runtimes. The CRI (Container Runtime Interface) API changes +for this feature were merged in v1.25 release. + +## What's new in 1.27? + +Besides the aforementioned resize policy in the pod's spec, a new field named +`allocatedResources` was added to `containerStatuses` in the pod's status. This +field reflects the resources allocated to the pod's containers by the node. + +In addition, a new field called `resources` was added to the container's status. +This field reflects the actual resource requests and limits that are configured +on the running containers as reported by the container runtime. + +Lastly, a new field named `resize` was added to the pod's status to show the +status of the last requested resize. A value of `Proposed` is an acknowledgement +of the requested resize and indicates that request was validated and recorded. A +value of `InProgress` indicates that the node has accepted the resize request +and is in the process of applying the resize request to the pod's containers. +A value of `Deferred` means that the requested resize cannot be granted at this +time, and the node will keep retrying. The resize may be granted when other pods +leave and free up node resources. A value of `InFeasible` is a signal that the +node cannot accommodate the requested resize. This can happen if the requested +resize exceeds the maximum resources the node can ever allocate for a pod. + + +## When to use this feature + +Below are a few examples where this feature may be useful: +- Pod is running on node but with either too much or too little resources. +- Pods are not being scheduled do to lack of sufficient CPU or memory in a +cluster that is under-utilized. +- Evicting certain pods that need more resources and scheduling them on +bigger nodes is an expensive or disruptive operation when other pods on +the nodes can be moved. + + +## How to use this feature + +In order to use this feature in v1.27, the `InPlacePodVerticalScaling` +feature gate needs to be enabled. + +```bash +root@vbuild:~/go/src/k8s.io/kubernetes# FEATURE_GATES=InPlacePodVerticalScaling=true ./hack/local-up-cluster.sh +go version go1.20.2 linux/arm64 ++++ [0320 13:52:02] Building go targets for linux/arm64 + k8s.io/kubernetes/cmd/kubectl (static) + k8s.io/kubernetes/cmd/kube-apiserver (static) + k8s.io/kubernetes/cmd/kube-controller-manager (static) + k8s.io/kubernetes/cmd/cloud-controller-manager (non-static) + k8s.io/kubernetes/cmd/kubelet (non-static) +... +... +Logs: + /tmp/etcd.log + /tmp/kube-apiserver.log + /tmp/kube-controller-manager.log + + /tmp/kube-proxy.log + /tmp/kube-scheduler.log + /tmp/kubelet.log + +To start using your cluster, you can open up another terminal/tab and run: + + export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig + cluster/kubectl.sh + +Alternatively, you can write to the default kubeconfig: + + export KUBERNETES_PROVIDER=local + + cluster/kubectl.sh config set-cluster local --server=https://localhost:6443 --certificate-authority=/var/run/kubernetes/server-ca.crt + cluster/kubectl.sh config set-credentials myself --client-key=/var/run/kubernetes/client-admin.key --client-certificate=/var/run/kubernetes/client-admin.crt + cluster/kubectl.sh config set-context local --cluster=local --user=myself + cluster/kubectl.sh config use-context local + cluster/kubectl.sh + +``` + + +## Example Use Cases + +### Cloud-based Development Environment + +In this scenario, a developer or development teams write their code locally +but build and test the code in Kubernetes pods that with consistent configs. +Such pods need minimal resources when the user is writing code, but need +significantly more CPU and memory when the user builds the code or runs a +battery of tests. This use case can leverage in-place pod resize feature +(with a help from eBPF) to quickly resize the pod's resources and avoid +kernel OOM (out of memory) killer from terminating the user's processes. + +This [KubeCon North America 2022 conference talk](https://www.youtube.com/watch?v=jjfa1cVJLwc) +illustrates the use case. + +### Java processes initialization CPU requirements + +Some Java applications may need significantly more CPU during initialization +than what is needed during normal process running times. If such +applications specify CPU requests and limits suited for normal operation, +they may suffer very long startup times. Such pods can request higher CPU +values at the time of pod creation, and can resize down to normal running +needs once the application has finished initializing. + + +## References + +TBD-placeholder +