Version: 0.7

Configuring IP address range assignments

In order to control the IP address ranges used to build team clusters, you can configure Network Assignments which allow Kore to allocate non-overlapping network address ranges to each cluster built.

This is required for any of the following scenarios:

  • Your team's clusters may need to be peered directly with each other
  • You may want to peer team clusters to shared management networks (including the network which hosts Kore itself)
  • You may want to peer team clusters to VPNs or direct connections to on-premise networks.
CIDR Notation

Kore uses CIDR (Classless Inter-Domain Routing) notation to describe networks.

This uses the format w.x.y.z/a (e.g. to describe a network and size, where w.x.y.z defines the start address of the network range, and a describes how many significant bits are in that address.

A few examples:

  • - available IPs: 16,777,216
  • - available IPs: 65,536
  • - available IPs: 512
  • - available IPs: 256
  • - available IPs: 128
  • - available IPs: 128

Deciding network range(s) to allocate#

Firstly, you should consider how large each cluster network should be - the smallest supported is /24, and you should consider how many workloads and how much auto-scaling is likely to be needed by your teams to determine if this size is large enough.

AWS Worked Example

On AWS, Kore will split the allocated range for a cluster into subnets for each availability zone and into public and private ranges, thus a /24 gives:

  • 3 x /28 public subnets (11 usable IP addresses per AZ)
  • 3 x /26 private subnets (59 usable IP addresses per AZ)

The next consideration is how many teams, and how many clusters you are likely to want. You should choose a network size to allocate which allows for this growth. Remember, you can always add further network ranges to Kore should an existing range be fully allocated.

A /16 network assignment allows for 256 /24 clusters or 128 /23 clusters so is a good starting point.

If you are likely to want to peer your Kore-managed infrastructure with existing networks (on cloud or on premise), you should ensure that the range you select is compatible with those existing networks - i.e. delegated by your organization's network team for Kore to use. This will ensure these networks can be peered in future.

Adding a network allocation to Kore#

To add a range from the UI, choose Admin > Configure > Cloud > AWS, GCP or Azure > Network Assignments.

Network range list

Here you can review any existing assignments, and add a new one. When adding a range, you specify the base address and size, as well as minimum, default and maximum network sizes which teams can request:

Dialog to add a network range

NetworkStart address of the network range
SizeTotal size of the range to allocate from
MinimumSmallest network size that can be chosen for a team cluster (counter-intuitively, this will have the highest number, e.g. /24)
DefaultNetwork size that team clusters will use unless they manually request a specific range, must be equal to or larger than the minimum, and equal to or smaller than the maximum, e.g. /23
MaximumLargest network size that can be chosen for a team cluster (counter-intuitively, this will have the lowest number, e.g. /22)

To specify this through the CLI, you must prepare a YAML file for an AssignableNetwork such as the following:

kind: AssignableNetwork
name: eks
namespace: kore-admin
- defaultMask: 23
max: 22
min: 24
type: node
provider: eks

This can then be applied using kore apply -f. You can use kore get assignablenetwork -t kore-admin to see existing network assignments, and kore edit assignablenetwork -t kore-admin [name] to edit it inline.

Changing network allocations#

Note that once a cluster has been built, its network allocation is fixed, so changes made in the Network Assignments section or by applying new network assignments via the CLI will only affect clusters built after the change is made.

Removing network allocations#

If you remove all network allocations from a cloud provider, Kore will no longer allocate networks when creating clusters, thus any future clusters created will go back to using the default IP ranges assigned in the cluster plan.