> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/networking/ip-addresses.md). # IP addresses When you create a cluster through Release, it will handle allocating IP addresses and defining IP address ranges for you. In most cases, you can use the defaults, but in more complicated cases it might be necessary to configure these manually. This information might be important if: * You are running software that spans multiple cloud accounts (for example, using VPC peering in AWS). * You are running hundreds or thousands of nodes and run out of IP addresses. ## How IP addresses work with Kubernetes The underlying Kubernetes cluster will have an assigned range of IP addresses that it can assign to **nodes** and **pods**. A node is a virtual compute server, which can run multiple pods. Each pod can run multiple containers. IP addresses are unique in a specific context. Global IP addresses, reachable on the public internet, are globally unique. In the context of your cluster, you will use internal IP addresses that are also used by other clusters and internal networks. This means that there is a chance you will have two services conflicting on the same IP address if your software spans multiple clusters running in different accounts. ## Choose a unique range for your cluster When you create a new cluster, you'll be given the option to choose which range of IP addresses to use. In most cases, you can choose any range. If you are integrating your software with services running in a different AWS account (for example, by using [AWS VPC peering](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/peer-with-vpc-in-another-account.html)), then you may have multiple services competing for the same internal IP address. In this case, it is important to choose an IP range that does not overlap with any ranges that are already in use. The example below shows two peered AWS accounts, each with unique (global) IP addresses for ingress to their respective clusters, but which use an overlapping IP range for subnets. This will only be a problem if the accounts are peered. ![Conflicting IP ranges](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-c56e93670f5a92edf52284012639bab2cebebd20%2Fnetworking-peer-conflict.png?alt=media\&token=c16879c9-4f21-4dd1-9e41-9f83a509568f) ## Running out of IP addresses (AWS) If you are running lots of microservices, you might exhaust the available IP addresses. You can fix this by spreading your services out over more separate Release clusters, or by optimizing IP allocation directly in your AWS account. For example, you can configure the `WARM_PREFIX_TARGET` and `WARM_IP_TARGET` parameters. See some examples [in this doc](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md). Release sets `WARM_PREFIX_TARGET=1` by default on clusters for v1.21 and above. You can find more details on how to optimize your IP address allocation directly in your cloud provider at the following links: * [Optimizing IP address allocation with GCP](https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr) * [Optimizing IP address allocation with AWS](https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/) --- # 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.release.com/reference-documentation/networking/ip-addresses.md?ask=&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.