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:
- Introduction and overview (this document)
- IPv4 address optimization
- Network address translation (NAT) for a GKE Pod CIDR block
- Configuring NAT for a GKE Pod CIDR block
- NAT for all GKE CIDR blocks
- Configuring NAT for all GKE CIDR blocks
- Configuring ULOGD2 and Cloud SQL for NAT logging
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
192.168.0.0/16 (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.
Although this series discusses internal load balancing, it does not discuss the following:
- HTTP(S) Load Balancing or Network Load Balancing. Both HTTP(S) and network load balancing use public IPv4 addressing for external access to GKE Services.
- Container-native load balancing. Container-native load balancing is available only with HTTP(S) load balancing.
- GKE Service load balancing. Intra-Pod communication through Service load balancing is localized to a cluster.
You can implement these load-balancing features if they are required. However, they aren't relevant to the solutions proposed in this series.
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.
- Read the next document in the series: IPv4 address optimization.
- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.