Fixing Cluster Crashes: Reduce kube-apiserver CPU Request

Problem Statement

In my Kubernetes setup, the API server was shutting down immediately after startup. Logs from crictl revealed the kube-apiserver would start, initialize components, and then shut down within seconds. This happened repeatedly, resulting in:

• kubectl get nodes failing with connection refused errors
• kube-apiserver container status marked as Exited
• Cluster becoming unreachable and unstable

This behavior is typically due to CPU resource starvation, where the default 250m CPU request could not be satisfied on a low-spec system (like a 1–2 vCPU, 4GB RAM VM).

Why is this necessary?

On low-resource machines (e.g., virtual machines with only 1–2 vCPUs and ~4GB RAM), the default CPU resource requests (like 250m for kube-apiserver) may cause resource exhaustion. This can lead to:

• kubelet crash loops
• API server restarts or failure to start
• Cluster becoming unstable or inaccessible

If your Kubernetes control plane is crashing, pods are stuck in CrashLoopBackOff, or the API server fails to respond, this CPU reduction may stabilize your setup.

Objective

Reduce the CPU request for the Kubernetes API server container from 250m to 100m to reduce its reserved CPU footprint and allow smoother operation in limited environments.

Step-by-Step Instructions

Step 1: Open the kube-apiserver static pod manifest

sudo nano /etc/kubernetes/manifests/kube-apiserver.yaml

Step 2: Locate the resources: section

Look for this block inside the first container:

resources:

requests:

cpu: 250m

Step 3: Modify the CPU request

Change it to:

resources:

requests:

cpu: 100m

This reduces the requested CPU to a more conservative value.

Step 4: Save and exit

For nano:

• Ctrl+O to save
• Enter to confirm
• Ctrl+X to exit

Step 5: Let kubelet auto-reload the manifest

The kubelet automatically detects changes in /etc/kubernetes/manifests and will restart the API server with updated settings.

Step 6: (Optional) Manually restart kubelet if needed

sudo systemctl restart kubelet Step 7: Reconfigure kubectl to use admin config

After a node reset or config change, kubectl may not work due to missing credentials.

Run the following to set up your kubectl config using admin.conf:

mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

This step:

• Creates the .kube directory if it doesn’t exist
• Copies the Kubernetes admin config to your user’s config location
• Sets the correct ownership so you can use kubectl without sudo

If prompted to overwrite the config, answer yes.

Step 8: Verify new CPU request is applied

kubectl -n kube-system get pod kube-apiserver-master -o jsonpath="{.spec.containers[0].resources.requests.cpu}"

Expected output:

100m

Step 8: Verify Nodes

kubectl get nodes

Additional Notes

• This does not limit CPU usage — it only informs Kubernetes about the expected CPU usage for scheduling.
• You can apply the same principle to other components like kube-controller-manager, kube-scheduler, etc., if needed.
• Always monitor cluster stability after making such changes.