AKO
in GCP

This topic explains the pod routing support in GCP for
AKO
.
The network configuration modes supported by
AKO
in GCP Full Access IaaS cloud are:
  • Inband Management
  • Two-arm mode with the Same Backend Subnet
In both the deployments there is a one-to-one mapping between virtual private cloud (VPC) and a Kubernetes cluster. So, in case of inband management, each cluster must have a dedicated cloud created in
NSX Advanced Load Balancer
.
In the two-arm-mode, multiple clusters can sync to the same cloud.
For more information on the network configuration modes supported for GCP IaaS cloud, see GCP Cloud Network Configuration topic in the
VMware NSX Advanced Load Balancer
Installation Guide
.

Types of Networks

The types of networks used are as follows:
  • Frontend Data Network: This network connects the VIP to the Service Engines. All the VIP traffic reaches Service Engines through this network.
  • Backend Data Network: This network connects the Service Engines to the application servers. All the traffic between the Service Engines and application servers flows through this network.
  • Management Network: This network connects the Service Engines with the Controller for all management operations.

Inband Management

The Service Engines will be connected to only one VPC subnet.
There is no network isolation between frontend and backend data and management traffic as both will go through same VPC subnet.

Two-Arm Mode with the same Backend Subnet

In the two-arm mode, the Service Engines are connected to three VPC subnets, one each for the frontend data traffic, management traffic, and backend data traffic.
  • The two-arm mode provides isolation between the management, the frontend data, and the backend data networks.
  • The first interface of the SE will be connected to the frontend data network. GCP supports shared VPC only on first NIC, therefore the data VPC can be a shared VPC.
  • The second interface of the SE will be connected to the management network. This interface cannot be connected to a shared VPC because GCP allows shared VPC only on first NIC.
  • The third interface of the SE will be connected to the Kubernetes cluster where
    AKO
    is running.
  • In this mode, the backend network of the SE is the same as the one where the Kubernetes or OpenShift nodes are connected.

Routing in GCP Two-Arm Mode with the same Backend Subnet

When multiple clusters are syncing to the same cloud the pod CIDRs can overlap.Currently, in
AKO
for each cluster, SE Group is created. In addition to Service Engine Group, each cluster must be in unique VPC in GCP cloud. This config is supplied in the Service Engine Group during the cloud setup by the admin.
AKO
configures the routes for
cluster1
and
cluster2
in the GCP routing tables for
vpc1
and
vpc2
respectively. Since there is unique mapping for cluster and SE Group, the overlapping pod CIDR’s routes will be in their respective VPC’s.

AKO
in Azure (Day 0 Preparation)

The Day 0 preparation checklist required to set up
AKO
in GCP is as listed below:
  1. Operations on GCP Side
    1. Ensure that the Kubernetes / OpenShift clusters running in their own dedicated VPC.
    2. Ensure that the Kubernetes and OpenShift cluster node virtual machines must have IP forwarding enabled in the GCP’s virtual machines.
    3. Create a dedicated backend VPC for each of the clusters.
  2. Operations on
    NSX Advanced Load Balancer
    Side
    1. Create a GCP cloud in
      NSX Advanced Load Balancer
      .
      Skip this step if the IaaS cloud is already created.
    2. Create a Service Engine group for each cluster.
    3. Override the backend VPC subnet in each of the Service Engine group.
      1. If there are two clusters,
        cluster1
        and
        cluster2
        ,
        1. Run
          configure serviceenginegroup cluster1-seg
        2. Override the
          gcp_config
          in the SE Group
          configure serviceenginegroup Default-Group [admin:10-152-0-30]: serviceenginegroup> gcp_config [admin:10-152-0-30]: serviceenginegroup:gcp_config> backend_data_vpc_network_name dev-multivnet-1 [admin:10-152-0-30]: serviceenginegroup:gcp_config> backend_data_vpc_subnet_name mv-subnet-1 [admin:10-152-0-30]: serviceenginegroup:gcp_config> save [admin:10-152-0-30]: serviceenginegroup> save |-----------------------------------------------|---------------| |gcp_config | | | backend_data_vpc_network_name dev-multivnet-1|dev-multivnet-1| | backend_data_vpc_subnet_name |mv-subnet-1 | |-----------------------------------------------|---------------|