Overview

With IP aliases, Kubernetes Engine clusters can allocate
Pod IP addresses from a CIDR block known to Google Cloud Platform. This allows
your cluster to interact with other Cloud Platform products and entities, and
also allows more scalable clusters.

Using IP aliases has several advantages:

Pod IPs are reserved within the network ahead of time, which prevents conflict
with other compute resources.

The networking layer can perform anti-spoofing checks to ensure that egress
traffic is not sent with arbitrary source IPs.

Pod IPs are natively routable within the Google Cloud Platform network
(including via VPC Network Peering), so clusters can scale to larger sizes
faster without using up route quota.

Aliased IPs can be announced through BGP by the cloud-router, enabling better
support for connecting to on-premises networks.

Firewall controls for Pods can be applied separately from their hosting node.

In this command, the new cluster is automatically configured with IP ranges
and a subnetwork. You can either provide a name for the subnetwork (in this
example, name=my-cluster-subnet) or provide an empty string ("") to have a
name automatically generated.

--create-subnetwork flag causes a subnetwork for the cluster to be
automatically created.

The optional --cluster-ipv4-cidr flag indicates the size and location of
the cluster's CIDR range. [RANGE] can be in the form of [IP]/[SIZE],
such as 10.0.0.0/18, or simply /[SIZE], which causes the IP address to
be automatically assigned. If this flag is omitted, a CIDR range is
automatically assigned with default sizes.

The optional --services-ipv4-cidr flag indicates the size and location of
the Service's CIDR range. The [RANGE] specifications are identical to
--cluster-ipv4-cidr. The range cannot overlap with --cluster-ip4-cidr
and vice-versa. If this flag is omitted, a CIDR range is automatically
assigned with default sizes.

API

To create a cluster with IP aliases, define a IPAllocationPolicy object in
your cluster resource:

createSubnetwork automatically creates and provisions a subnetwork for
the cluster. subnetworkName is optional; if left empty, a name is
automatically chosen for the subnetwork.

Using an existing subnetwork with IP aliases

You can manually create a Compute Engine subnetwork with a primary range
and two secondary ranges for your Kubernetes Engine cluster and use the
subnet in conjunction with Kubernetes Engine IP aliases. When you create
a new cluster with IP aliases, you can specify that the cluster should use the
existing Compute Engine subnetwork. IP addresses from this subnet will be
allocated as follows:

Node IPs are allocated from the primary range.

Pod IPs are allocated from a named secondary range specified during
cluster creation.

Service IPs are allocated from another named secondary range specified
during cluster creation.

Console

You must create a subnetwork with at least two secondary CIDR ranges for
Pod and Service addresses.

Node IP

Node IPs and internal load balancers are both allocated from the primary range
specified in a subnet. Kubernetes Engine requires a CIDR prefix length
between 19 and 28 bits, which corresponds to between 16 (=2^(32-28)=2^4) and
8192 (=2^(32-19)=2^13) addresses.

Note: Four addresses in each CIDR range are reserved and cannot be allocated to
nodes or Internal load balancer instances. For more information, refer to
VPC Network Overview in the Compute Engine documentation.

When you create the cluster, ensure that you choose a subnetwork range that is
large enough for the cluster's anticipated growth.

For example, to create a cluster with up to 60 nodes or Internal load balancers,
you need to allocate a contiguous block of 64 addresses (=2^6). In terms of CIDR
prefix length, this corresponds to a /26 network (=32-6).

Pod IP

Each node requires that 256 IP addresses, or a /24 block, be reserved for use
by Pods running on it. As with the node IP range, this range cannot be changed
after the cluster is created; therefore, it is important to size the Pod IP
block to accommodate for the number of nodes multiplied by 256.
Kubernetes Engine requires that the secondary prefix range for Pods have
between 11 and 19 bits, which corresponds to a contiguous block of between 8,192
and 2,097,152 addresses.

Building off of the above example, a cluster with 60 nodes requires a block
of 64 x 256 = 16,384 contiguous IP addresses be allocated for Pods. This would
amount to reserving 6 + 8 = 14 bits for addresses, which corresponds to a '/18'
network (=32-14).

Service IP

The Service IP range is immutable after the cluster is created; therefore, it is
important that you size the Service CIDR block to accommodate the maximum
number of Service objects you intend to deploy. Kubernetes Engine
requires that the secondary prefix range for Service IPs have between 18 and
22 bits, which corresponds to a contiguous block of between 1,024 and 16,384
addresses.

Restrictions

Additional subnetworks cannot be used in tandem with IP aliases.

You cannot currently migrate an existing cluster to a cluster that uses IP
aliases. This limitation will be removed in future releases.

Cluster IPs for internal services are only available from within the cluster.
If you want to access a Kubernetes service from within the VPC, but from
outside of the cluster (for example, from a Compute Engine instance), use an
internal load balancer.