This blog is second in the series on VPC native GKE clusters. In this blog, I will cover overview of IP aliasing, IP alias creation options and creating VPC native clusters using alias IPs. For the first blog on GKE ip addressing, please refer here.

Overview
IP aliases allows a single VM to have multiple internal IP addresses. These addresses are not the same as having multiple interfaces with each interface having a different IP address. Each of the multiple internal IP address can be used to allocate it for different services running in the VM. When the node is running containers, alias IPs can be used to allocate it to Container pods. GCP VPC network is aware of alias IPs, so the routing is taken care by VPC. Alias IP has significant advantages with GKE Containers since Containers have pod and service IP to manage in addition to the node IP and IP aliasing makes sure that these addresses are native to VPC allowing a tight integration with GCP services.

Alias IP Advantages

Alias IPs provides many advantages in the Container space as having VPC aware separate address ranges carved for pods and services gives better flexibility.

• Alias IP addresses are VPC aware and routing is taken care by VPC. Without IP aliasing, pod routing was responsibility of the container orchestrator and orchestrator adds these routes manually. With IP aliasing, pod routing is taken care by VPC itself and there is no need to add manual routes to reach pod IP.
• Without IP aliases, anti-spoofing checks had to be disabled in nodes that are part of GKE cluster. Traffic from the pods will have the source IP as pod IP and since VPC is not aware of pod IP, anti-spoofing checks needs to be disabled to allow this traffic to pass-thru. With IP aliases, VPC is aware of pod IPs so we can enable the anti-spoofing check. This prevents traffic with arbitrary source IPs to originate from the node.
• IP aliasing prevents IP address conflicts between node IP address and cluster IP address since VPC is aware of both these addresses.
• IP aliases helps in scenarios where its needed to reach the pod but not the node from external world. Since VPC is aware of alias address, we can setup different BGP and firewall rules between node and pod ip addresses.

Creating Alias IP

There are 3 ways to create Alias IP.

1. When creating VM, specify alias IP address that will be used by VM.
2. When creating subnet, create primary and secondary range or more ranges. During VM creation, use the alias IP ranges to create alias IP. Alias IP can be created for the subnets in either “auto” or “custom” network.
3. When GKE cluster is created with ip aliasing enabled, 2 subnet secondary ranges are created implicitly, 1 for pod IP and another for service IP. Containers pod and services gets ip allocated from this range. This approach is used by GKE.

Creating Alias IP – Approach 1:

In this approach, we will specify alias IP address when creating VM. The steps are mentioned below.

Create network:

gcloud compute networks create aliasnet \
    --subnet-mode=auto

Create instance with alias ip address from the subnet:

 
 gcloud compute instances create vm5     --zone us-central1-b     --network-interface "subnet=s1,aliases=10.65.61.128/28" 

Instance network detail:

Below output shows internal IP, external IP and alias IP.

Creating Alias IP – Approach 2:

In this approach, we will first create primary and secondary range in the subnet and specify IP alias within the primary and secondary range when creating the VM.

Create network:

gcloud compute networks create aliasnet \
    --subnet-mode=auto

Create subnets with primary and secondary range:

gcloud compute networks subnets create s1 \
    --network  aliasnet \
    --region us-central1 \
    --range 10.65.61.0/24 \
    --secondary-range range1=172.16.0.0/16, range2=10.0.0.0/16

Create instance with ip address from primary and secondary range:
For some reason, I could not get the CLI command to work and I was able to do this only from console. Following is the VM created with the 2 alias IPs(172.16.1.0/24, 10.0.0.1/32). These alias IPs are within the primary and secondary range specified in previous command.

Creating Alias IP – Approach 3:

In this approach, we will create alias IP for Containers.

Create cluster with IP aliasing enabled:

 gcloud container clusters create cluster-vpc --zone us-central1-b --enable-ip-alias 

Because we had enabled IP alias and we have used the default network, the above command automatically creates 2 secondary ranges as shown below. “10.64.0.0/14” is the first secondary range and “10.0.0.0/20” is the second secondary range. These ranges will be used for cluster IP range and service IP range.

We also have the option of manually specifying cluster IP range and service IP range like below:

 gcloud container clusters create cluster-vpc --zone us-central1-b --enable-ip-alias --cluster-ipv4-cidr=<clusteriprange> --services-ipv4-cidr=<serviceiprange>

The above command will create secondary ranges on the subnet using the addresses specified and use them as alias IP address for cluster and service IPs.

Following command shows the ip ranges for “default” network after creating a cluster with IP aliasing enabled. “10.128.0.0/20” is the subnet range for internal ip, “10.64.0.0./14” is the cluster ip range, “10.0.0.0/20” is the service IP range.

 gcloud compute networks subnets describe default | grep -i ipcidrrange
 ipCidrRange: 10.128.0.0/20
 - ipCidrRange: 10.64.0.0/14
 - ipCidrRange: 10.0.0.0/20 

From the cluster, let’s check the cluster IP range and service IP range. This will match the default ranges.

 gcloud container clusters describe cluster-vpc | grep -e servicesIpv4Cidr -e clusterIpv4Cidr
 clusterIpv4Cidr: 10.64.0.0/14
   servicesIpv4Cidr: 10.0.0.0/20 

Let’s deploy a sample application:

kubectl run web --image=gcr.io/google-samples/hello-app:1.0 --replicas=3 --port=8080
kubectl expose deployment web --target-port=8080 --type=NodePort

Let’s look at pod and service IP addresses:

 kubectl get pods -o wide
 NAME                   READY     STATUS    RESTARTS   AGE       IP          NODE
 web-6d695d4565-g7lbb   1/1       Running   0          1h        10.64.1.6   gke-cluster-vpc-default-pool-db114d00-2mz8
 web-6d695d4565-nzdnx   1/1       Running   0          1h        10.64.0.4   gke-cluster-vpc-default-pool-db114d00-1l9m
 web-6d695d4565-ttkr8   1/1       Running   0          1h        10.64.1.5   gke-cluster-vpc-default-pool-db114d00-2mz8 

 
 kubectl get services
 NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
 kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP          1h
 web          NodePort    10.0.0.253   <none>        8080:30017/TCP   1h 

As we can see from above output, pod IP address(10.64.0.x, 10.64.1.x) comes out of the cluster IP range and service IP address(10.0.0.253) comes out of the service IP address range. If we look at the routing table, we do not see routes specific to pod IP address as VPC is already aware of it.

In the next blog, I will talk about Network endpoint group and Container native load balancing.

References:

• Alias IP ranges overview
• Network endpoint groups
• Using Container native load balancing