> For the complete documentation index, see [llms.txt](https://platform9.com/kb/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://platform9.com/kb/pcd/kubernetes/how-to-modify-the-metrics-server-container-limits.md).

# How to Modify the Metrics-Server Container Limits?

## Problem

* A metrics-server container running inside the metrics-server pod is frequently restarting because it's being OOMKilled due to insufficient resources.
* Requests and Limits change applied to the `metrics-server` container reverts back.
* How to modify the `metrics-server` container limits?

## Environment

* Private Cloud Director Kubernetes – v2025.4 and Higher
* Self-Hosted Private Cloud Director Kubernetes - v2025.4 and Higher
* Component - Metric Server Add-on.

## Procedure

The `metrics-server` container running inside the metric-server pod retrieves its value from the `metrics-server-nanny-config` config map. This config map needs to be updated to push the latest configuration.

> Direct update to the requests and limits for the `metrics-server` container running inside the metric-server pod won't work.

> Updating the requests and limits for the `metrics-server-nanny` container running inside the metric-server pod will work without updating the Config Map.

1. Take a backup of the existing `metrics-server-nanny-config` config map using the command given below:

```bash
$ kubectl get cm -n kube-system metrics-server-nanny-config -o yaml > metrics-server-nanny-config.yaml.bk
```

2. Edit the Config Map.

```bash
$ kubectl edit cm -n kube-system metrics-server-nanny-config
```

3. Update the below fields with the desired value and save the config map.

```dart
baseCPU: 80m      # This is minimum CPU required for the container similar to pod request 
cpuPerNode: 1m
baseMemory: 80Mi  # This is minimum Memory required for the container similar to pod request
memoryPerNode: 2Mi
```

> CPU and Memory calculations are done by the `metrics-server-nanny` container for the `metrics-server` container is based on the number of nodes running on the cluster.> > CPU = baseCPU + extraCpu \* max(nodes, minClusterSize)> > Memory = baseMem + extraMemory \* max(nodes, minClusterSize)> > Here, `CPU` and `Memory` are the `Limits` that will be applied to the `metric-server` container. `baseCPU`, `baseMem` values can be retrieved from the existing `metrics-server-nanny-config` Config Map. However, values such as `extraCpu`(default is 1), `extraMemory` (default is 2) and `minClusterSize` (default is 10) can be retrieved from the `metric-server` cluster add-on, which are applicable only for Self-Hosted Private Cloud Director Kubernetes.

4. Save the Config Map.
5. Delete the `metrics-server` pod in the `kube-system` namespace and it should redeploy pod with new updated value as per updated config map.

## Validation

1. Validate the latest updated value in Config Map and Pod status.

```bash
$ kubectl get cm -n kube-system metrics-server-nanny-config -o yaml
$ kubectl get pods -n kube-system | grep -i "metrics-server"
```

2. Latest Limits set to the `metrics-server` container running inside the metric-server pod.
3. If these steps prove insufficient, reach out to the [Platform9 Support Team](https://support.platform9.com/hc/en-us) for additional assistance.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://platform9.com/kb/pcd/kubernetes/how-to-modify-the-metrics-server-container-limits.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.