In today's cloud-native landscape, organizations demand both agile API management and the flexibility of microservices running on Kubernetes. Google Cloud offers powerful solutions for comprehensive API management capabilities with Apigee and Google Kubernetes Engine (GKE) for orchestration of containerized applications. But bridging these environments for streamlined API traffic to your Kubernetes-based microservices can present hurdles. Fortunately, there’s Private Service Connect (PSC), which you can use to create private and secure connections from your VPCs to Google, third parties, or your own services. In this scenario, PSC provides a secure, efficient, and elegant solution for the southbound communication from Apigee to your backend targets.

The connectivity challenge

The traditional methods of bridging Apigee and GKE introduce a series of networking complications. Some of the typical challenges hindering streamlined connectivity between Apigee and GKE include:

• Public exposure: Routing API traffic from Apigee to GKE often necessitates exposing GKE services publicly. This introduces security risks by opening potential attack vectors.

• Traffic bottlenecks and cost: Relying exclusively on public internet connectivity can result in unpredictable latency, affecting performance and driving up egress costs.

• Management complexity: Configuring network and VPC Peering connections, ensuring CIDR ranges do not overlap, and managing access permissions across platforms like Apigee and GKE can create a complex administrative burden.

The Private Service Connect approach 

PSC fundamentally transforms the way your Apigee deployment interacts with GKE services, unlocking a new level of security and simplicity using:

• Private, internal networking: PSC exposes services from one VPC to another directly via a service attachment and endpoint without the need for complex VPC Peering or exposing clusters to the public internet. PSC facilitates the establishment of private endpoints within your Google Cloud VPC for your GKE Gateway. This enables Apigee to communicate with your Kubernetes service directly via Google Cloud’s internal network, bypassing the public internet entirely or requiring complex VPC Peering implementations.

• Granular security controls: PSC allows you to expose only the specific services within your GKE cluster that Apigee is authorized to access. This granular approach minimizes risk.

• Performance improvement: Private connectivity over Google Cloud's high-performance network fosters reduced latency and greater reliability, enhancing overall API response times.

Key components in the mix

1. Apigee: Google Cloud's robust API management platform simplifies creating, managing, securing, and monitoring APIs, providing policy enforcement, analytics, and monetization capabilities.

2. GKE Gateway: GKE’s implementation of the Kubernetes Gateway API (a newer, more flexible API specification) is an advanced networking resource that improves upon the Ingress object and provides expanded routing and load balancing features for internal and external traffic within your GKE cluster.

3. Private Service Connect: The cornerstone of this integration, PSC sets up a private connection and manages the routing between your Apigee VPC and the VPC hosting your GKE cluster. 

Setting up the secure bridge

To establish this connectivity, you must complete the following steps. Here, we  focus on the details of GKE Gateway creation, as the other steps are very straightforward and well documented.

1. Deploy the Internal GKE Gateway: 

This is a very detailed process but at a high level, the following steps must be completed:

• Create a VPC-native cluster. A VPC-native cluster is a cluster whose Pods and Services directly use IP addresses from your Google Cloud VPC network.

• Enable the Gateway API and HTTP Load Balancing Addon. You can achieve this during cluster creation or update, as needed.

• Configure a Proxy-only Subnet. This is a different subnet from the subnet your GKE cluster runs in. Ensure it is created with the REGIONAL_MANAGED_PROXY purpose

• Create a named IP address: Named IP addresses let you reserve a static IP to be used by your Gateway resource. If you do not specify an IP address on the Gateway, then the Gateway controller automatically provides an IP address.
  
  NOTE: At the time of this publication, PSC Service Attachments do not support forwarding rules that use a shared IP address (SHARED_LOADBALANCER_VIP). This is the default purpose of the IP address used by the Gateways if a named IP address is not reserved or a named IP address is created without an explicitly defined purpose. To work around this, we create a named IP address of purpose GCE_ENDPOINT using the gcloud command below instead. The implications of using the GCP_ENDPOINT IP address are:

• • The Gateway cannot use the same IP address for both HTTP and HTTPS traffic from Apigee to the Gateway or perform HTTP-to-HTTPS redirects on traffic to the Gateway on the same address. 

  • If the communication from Apigee to the Gateway is using either only HTTP or HTTPS, this implication is not as significant. If you need both from Apigee to the Gateway, you will need to handle this with two separate Gateways (one for HTTP and the other for HTTPS) therefore requiring two named IP addresses. 

  • This is not referring to initial traffic from the origin client into Apigee. The external L7 Load balancer that handles this initial traffic still uses the SHARED_LOADBALANCER_VIP purpose and can handle both HTTP/HTTPS traffic and perform HTTP-to-HTTPS redirect.

  • This step can be ignored once PSC Service Attachments support forwarding rules using shared IP addresses of purpose SHARED_LOADBALANCER_VIP. Verify this is still a limitation before completing this step.