> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/home/containers/managed-kubernetes/overview/limitations.md).

# Limitations

Managed Kubernetes limitations: technical constraints, resource quotas, and known constraints.

Following are a few limitations that you can encounter while using both **Public** and **Private Node Pools**:

* The maximum number of pods supported per node is **110**. It is a Kubernetes default value.
* The recommended maximum number of nodes per node pool is **20**.
* The maximum number of nodes in a node pool is **100**.
* A total of **500** node pools per cluster is supported.
* The recommended maximum number of node pools per cluster are **50**.
* The maximum number of supported nodes per cluster is **5000**.
* While a node can theoretically support a maximum of **20** volumes, the practical limit can be lower because each node has only 24 Peripheral Component Interconnect (PCI) slots shared among all peripherals.
* Managed Kubernetes clusters use [<mark style="color:blue;">**Block Storage**</mark>](/cloud/home/backup-and-storage/block-storage.md) as the underlying storage system. As a result, Block Storage volume limits and performance thresholds apply to your cluster nodes. Before provisioning persistent volumes, see [<mark style="color:blue;">Limitations</mark>](/cloud/home/backup-and-storage/block-storage/overview/limitations.md).

## Control plane

The control plane is subject to the following resource limits:

* Each `kube-apiserver` replica is limited to **8 GiB** of memory.
* Each cluster runs two `kube-apiserver` replicas, resulting in a maximum of 16 GiB of memory for the API server across the cluster. This memory is not shared between replicas; a single replica cannot exceed 8 GiB.

If the API server's memory consumption reaches this limit, the affected replica is restarted. This can cause temporary interruptions in API availability, for example, failing `kubectl` commands or delayed reconciliation. Workloads running on your nodes are not directly affected, but controllers and operators that depend on the Kubernetes API may be.

To stay within the limit, avoid patterns that increase API server memory consumption:

* A very high number of objects in the cluster.
* Frequent full `LIST` requests without pagination or field selectors.
* A large number of concurrent watch clients.

## Worker node memory management

Worker nodes include a safeguard that protects a node from running out of memory. When the available memory of a node gets very low (roughly 10% or less), it can stop containers before the kubelet starts evicting pods. This affects larger nodes: on small nodes, for example with 3 GB of RAM, the kubelet evicts pods first. This is a limitation of the current node configuration. You cannot change the thresholds per cluster or node pool.

Containers of pods with a lower Kubernetes Quality of Service (QoS) class are affected first, and containers of `Guaranteed` pods last.

When a node reaches the threshold, you can observe the following behavior:

* Containers stop after a `SIGTERM` signal that does not come from Kubernetes. If the application shuts down in an orderly way, Kubernetes reports the containers as completed with exit code `0`. If the application runs as the container's main process and does not handle `SIGTERM`, it is stopped with `SIGKILL` instead, and Kubernetes reports exit code `137`. The pod events only show backoffs and restarts.
* Kubernetes does not create eviction events, does not report `OOMKilled`, and does not set the `MemoryPressure` condition of the node.
* Containers restart on the same node, which can result in a crash loop.
* No pod becomes `Pending`. As a result, the cluster autoscaler does not receive a signal to add nodes.

To reduce the impact on your workloads, use the following recommendations:

* **Use Guaranteed QoS for critical workloads:** Set memory requests equal to memory limits.
* **Reduce the difference between memory limits and requests:** A large difference lets containers use more memory than the scheduler and the cluster autoscaler account for.
* **Choose node sizes with headroom:** Leave free memory on each node beyond the memory limits of your workloads.

For more information about requests and limits, see [<mark style="color:blue;">Resource Management for Pods and Containers</mark>](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits).

## Private Node Pools

Following are a few limitations that you can encounter while using **Private Node Pools**:

* Managed Kubernetes clusters for Private Node Pools are bound to **one region**. When you create a node pool, you need to provide a data center, which has to be in the same location as defined in the **cluster**. You can create Private Node Pools only in a [<mark style="color:blue;">Virtual Data Center (VDC)</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#virtual-data-center-vdc) that shares the region with the managed Kubernetes cluster.
* Kubernetes services of type **LoadBalancer** are currently not supported.
* The **static node Internet Protocol (IP)** addresses are not supported.


---

# 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://docs.ionos.com/cloud/home/containers/managed-kubernetes/overview/limitations.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.