GKE address management: Introduction and overview

Stay organized with collections Save and categorize content based on your preferences.

This document is part of a series intended for network architects. The series discusses the Google Kubernetes Engine (GKE) address-management options available to organizations that are IPv4-address constrained.

The series consists of the following parts:


Many companies want to expand their existing data center to the cloud to take advantage of managed services such as GKE. However, GKE requires a lot of IP addresses for its various components. For some large organizations, meeting this requirement is difficult or impossible due to an inability to assign appropriately sized,, and (RFC 1918) Classless Inter-domain Routing (CIDR) blocks.

Historically, the process of IPv4 address allocation has done the following:

  • Exhausted the three available private network blocks by assigning most of the address space to existing infrastructure.
  • Assigned IPv4 address blocks in such a way that finding contiguous CIDR ranges large enough to meet new demand is impossible.
  • Assigned IPv4 address blocks in such a way that expanding an already assigned address block is impossible.

This lack of available address space makes building or expanding GKE deployments problematic. When attempting to allocate or expand CIDR blocks for Pods, Nodes, or Services, organizations discover that they cannot meet the IPv4 addressing requirements, which holds up their GKE project and caps business growth.

Several solutions are available to alleviate this problem. The solution you choose depends on the number and size of required GKE CIDR blocks and the available IPv4 address space you have to meet these requirements.

Topics not covered in this series

This series does not cover the following topics.

Load balancing

Although this series discusses internal load balancing, it does not discuss the following:

You can implement these load-balancing features if they are required. However, they aren't relevant to the solutions proposed in this series.

Routes-based cluster

Moving forward, all newly created clusters will be VPC-native by default. We recommend that you use VPC-native clusters as opposed to routes-based clusters.


Throughout the series, the keywords "must", "must not", "require", "shall", "shall not", "should", "should not", "recommend", "may", and "optional" are to be interpreted as described in RFC 2119.

In addition, the terms CIDR range, CIDR block, address range, and address block are synonymous.

This series introduces the following terms:

allocated address
An RFC 1918 address that has been assigned by an organization for use within its routed domain. The address appears either on-premises or in any of the organization's virtual private clouds (VPCs) and in the global routing table.
isolated VPC
A VPC that is reusing IPv4 address space that is already assigned in the on-premises network. The term isolated is used because the VPC is reusing address space. It's not a good idea to advertise the reused routes back into the on-premises network.
isolated-VPC allocated address
An allocated address that represents a resource inside an isolated VPC to the routed domain.
isolated-VPC reused address
A reused address that resides on a resource inside of an isolated VPC.
reused address
An RFC 1918 address that is already assigned and in use in an organization and that is being reused by another resource. The address appears in one or several of an organization's isolated VPCs and is routable only within that VPC. The reused address must not be accessible from, nor be advertised to, the organization's routed domain.
routed domain
The collection of infrastructure locations whose routers insert routes into the organization's global routing table. An isolated VPC can be considered outside an organization's routed domain.
routed-domain allocated address
An allocated address that resides on a resource within an organization's routed domain.
routed-domain reused address
A reused address that represents a resource outside an isolated VPC to resources within the isolated VPC.

What's next