We have a central Apigee instance, with various northbound XLB’s in application projects routing to Apigee and then Southbound, various PSC attachments to Internal Load Balancers.
If we use target servers which point to the Apigee Endpoint Attachment private IP e.g. 7.8.9.1, it routes successfully if the southbound service runs on HTTP.
If however the backend service runs on HTTPS we hit an SSL handshake error (which we would expect), as the IP isn’t a SAN in the certificate..
The routes are
NB = XLB > NEG > Apigee SA
SB = Target Server > Endpoint Attachment > Service Attachment > ILB (GKE Gateway).
Apigee sits in a different project to the Northbound and Southbound application/networking. We’ve attempted to use CloudDNS to route to the Target Server to the Apigee endpoint IP (using an A record in CloudDNS), but it fails to resolve.
Any suggestions please?
Due to the centralised instance of Apigee with multiple projects, we were advised to use PSC for Southbound, and its OK if we terminate SSL at the XLB, but pushing it through to the southbound service we’re hitting issues.
Thanks, it seems the issue was DNS peering, but it seems there is DNS peering and then DNS peering.
We are not using VPC peering Southbound between the Apigee VPC and the application GKE clusters in application projects, so DNS peering wasn’t going to work..
What we were actually trying to achieve was to get Apigee to communicate via DNS to the Apigee PSC endpoint attachment IP, the part I found via trial and error, was the
“google_service_networking_peered_dns_domain” documented here:
https://cloud.google.com/vpc/docs/configure-private-services-access
Apigee required that being enabled, to allow the GCP service provider network (Apigee) access to the private zone hosted in the Apigee project..
So whilst it was DNS peering, it was to peer it internally with GCP it seems…
1 Like
@mr_mann Im pretty much in the same boat.
Do you mind explaining what exactly is that when you say “Apigee required that being enabled, to allow the GCP service provider network (Apigee) access to the private zone hosted in the Apigee project..” please?
Kind Regards,
Raks
@mr_mann Have you go this working?
Im in the same boat. The above solution does work except for GKE cluster where the backend endpoint is exposed through Istio Ingress gateway.
It seems apigee is not sending the SNI and hence Ingress gateway proxy cannot process the request.
Do you think I’m missing something here please?
@mr_mann - can you please mark the solution as answered if it helped resolve your issue
@n_raks - your issue is different from the main post. Can you please open a new post so that we can discuss there
Hi @n_raks - We are using the GKE Gateway, not ingress
@n_raks - Apigee could not access the private DNS zone in the Apigee GCP project, which resolved to the Endpoint attachment IP address e.g 7.3.2.1, which in turn routes to the service attachment of the GKE gateway.
Enabling the above, allowed Apigee to see, and resolve the records in the private DNS zone, to resolve the endpoints correctly.
E.g
Southbound
Apigee > Target Server (set with DNS name) > Private DNS Zone Record > Apigee endpoint attachment > PSC Service Attachment > GKE Gateway