I am trying to implement such solution proposed in the article Modernize Apigee-GKE Connectivity with Private Service Connect and GKE Gateway , and realized that the doc ( Southbound networking patterns | Apigee | Google Cloud ) is proposing to use a deprecated item : producerForwardingRule (not able to add more than 2 links )
Would you be able to help me find a new alternative?
My proposal will be to use serviceAttachment backendservice , then creating a service without app-selector and manually creating an EndpointSlice to target my Gateway ILB.
This works but I am not convinced I am creating the best architecture in term of network and resiliency.
Thanks for your support.
Thank you for the question, I am going to make a couple of assumptions not knowing your exact architecture. I am assuming that you are currently using Apigee OPDK and not Apigee X?
One way that you could address this use case is using the following flow:
Apigee OPDK Message Processor → GKE Gateway ILB IP Address → GKE Gateway → Backend Service
Hello @rabustamante ,
Thanks for your response. I am not using Apigee at all.
I won’t connect Apigee as a consumer of my PSC endpoints.
So I am actually more interested in the “PSC (endpoint) → GKE Gateway ILB IP Address → GKE Gateway → Backend Service” part of the setup proposed in this article.
Thanks for your update.
I posted this question in here for 2 reasons, first it’s related to a document called [Southbound networking patterns | Apigee | Google Cloud] and my question is related to one specific step, and second, I found an old post similar to my question on this forum so I decided I will continue in here. I apologize if it’s incorrectly tagged but I was thinking I could get support from the people writing these guides.
I already read the references you added and in there ServiceAttachment is bound to a service, not a producerForwardingRule as described in the [Southbound networking patterns | Apigee | Google Cloud] , so what I am asking is for a potential version 2 of this document that will consider the “non-deprecated” ServiceAttachment item.
I’m happy to give you my point of view. While I initially suggested other forums because you might find networking specialists there, my research confirms a better approach.
The recommended way to accomplish your goal is to use the cloud.google.com/psc-connect annotation on a GKE Service. This method automates the entire Private Service Connect (PSC) setup for you. The best practice is to let GKE manage the ServiceAttachment lifecycle declaratively by creating a standard Kubernetes Service of type InternalLoadBalancer and adding the annotation to it.
Your proposed solution with a manual EndpointSlice is not the most resilient architecture, but it would likely work.
Thanks for the udpate @rabustamante , I investigated and unfortunately I am missing a piece of information here as an annotation is key:value and you only gave the key cloud.google.com/psc-connect
By curiousity I tried using value “Endpoint” but it didn’t work
And there is no reference of this annotation in any doc, so could you please provide the full annotation so I can test and mark the post as solutioned ?
Thank you !
Thank you for your patience. I apologies I seem to have been looking at some internal documentation.
The official, publicly documented, and declarative GKE-native method is to use a ServiceAttachment Custom Resource (CRD).This is more akin to the original solution that you proposed but not using an endpointSlice
This CRD achieves the exact same goal as the annotation: it lets you declaratively create and manage a ServiceAttachment from within Kubernetes.
Instead of annotating the Service itself, you create two separate Kubernetes objects:
A standard GKE Service: (e.g., my-ilb-service) This creates the Internal Load Balancer, just as you would normally.
A ServiceAttachment CRD: This is a new GKE-specific manifest. In this file, you explicitly link it to the Service you just created.
Example:
This is the manifest for the ServiceAttachment CRD. Notice how the spec.resourceRef points directly to your Service:
YAML
apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
name: my-psc-service-attachment
namespace: default
spec:
# This points to the GKE Service (ILB) you want to expose
resourceRef:
kind: Service
name: my-ilb-service
# This points to the PSC NAT subnet you created
natSubnets:
- "my-psc-nat-subnet"
connectionPreference: ACCEPT_AUTOMATIC
Hello @rabustamante ,
Thanks for your reply and confirming your previous post was referring to internal documents, I wished it would have worked for me.
I am afraid your proposal is not solving my problem… so let me rephrase the pbm statement.
Like stated in the doc, we need to target the Gateway from the ServiceAttachment, and the problem is that a Gateway creates an Ingress and a ServiceAttachment requires a Service.
What we want to achieve:
ServiceAttachment (Service) → ??? → Gateway (Ingress + ILB + backend + HTTPRoutes ) → producer services.
How do you connect your standard GKE service (my-ilb-service) to your Gateway ?
FYI, a standard GKE Service requires an App Selector that can target a Deployment, ReplicateSet, Job or DaemonSet but not a Gateway (AFAIK) .
Unless you create a “Manual” Service, without App Selector but then you need to manually create an EndPoint or EndPointslice … which is actually what I am proposing.
Thank you for rephrasing the problem statement. After looking it at it again I believe that using the endpointslice is your best option for accomplishing the connectivity that you need. You were absolutely on the right track.
)