Skip to content

Commit

Permalink
Initial draft of blog post for in-place pod resize feature
Browse files Browse the repository at this point in the history
  • Loading branch information
vinaykul committed Mar 21, 2023
1 parent 27a0af9 commit a4fed14
Show file tree
Hide file tree
Showing 2 changed files with 125 additions and 35 deletions.
35 changes: 0 additions & 35 deletions content/en/blog/_posts/2022-10-21-in-place-pod-resize-alpha.md

This file was deleted.

125 changes: 125 additions & 0 deletions content/en/blog/_posts/2023-04-04-in-place-pod-resize-alpha.md
Original file line number Diff line number Diff line change
@@ -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 pods without restarting them. The `resources`
field in a 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
running containers via a CRI (Container Runtime Interface) API call that queries
the running container's status. The CRI API changes needed to support this
feature were merged in v1.25 release.

## What's new in v1.27?

Besides the aforementioned resize policy in the pod's spec, a new field named
`allocatedResources` has been added to `containerStatuses` in the pod's status.
This field reflects the node resources allocated to the pod's containers.

In addition, a new field called `resources` has been 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` has been 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

0 comments on commit a4fed14

Please sign in to comment.