IP addresses

When you create a cluster through ReleaseHub, 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), 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

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 ReleaseHub 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. ReleaseHub 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: