GKE - Ingress "Unmeshed"

[sonicSW]

Dear community,

I am struggling to update the GKE ingress controller to include traffic from external IPs.
The full ingress route is Cloudflare-->GCP-LB-->GKE in my case and the result remains for external request:
Unmeshed
ip/130.211.3.76
ip/130.211.1.53
ip/130.211.3.62

I followed the guide https://linkerd.io/2.11/tasks/using-ingress/#gce.
I removed the line for the cert-manager as I use a secret file, is this supported?
What I do not understand, is it "suggests" I would have a web-svc in namespace XYZ, but nothing is installed with linked or shall this be a service pointing to my deployments? In this case, what to do with multiple services I have mapped in the ingress controller.
Probably the answer is so obvious and I just lost the plot.

thank you already to the person for taking the time to read my QA post.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Values.global.project }}-ingress
  namespace: {{ .Values.global.nameSpace }}
  
  annotations:
    kubernetes.io/ingress.global-static-ip-name: {{ .Values.ingress.staticIpName }}
    kubernetes.io/ingress.allow-http: "false"

    # WebSockets Support
    cloud.google.com/backend-config: '{"ports": {"80":"{{ .Values.webSocket.instanceShort }}-backend"}}'
    cloud.google.com/neg: '{"ingress": true}'

    #Linkerd 2.11.1
    ingress.kubernetes.io/custom-request-headers: "l5d-dst-override: web-svc.{{ .Values.global.nameSpace }}.svc.cluster.local:80"

[ercalote]

Facing the same issue.. Have you ever made it work?

I understood from the docs that we need to add linkerd.io/inject: ingress annotation to GCE ingress controller, however GKE ships with a managed GCE ingress. Is it possible to mesh it?

[mateiidavid]

If your ingress controller does not have a pod, then it cannot be injected. Linkerd handles re-direction at the pod's network namespace level. Without a pod (and thus without a proxy) there's no way to intercept the traffic, or to secure it. The workaround here would be to have a pod at the edge of your cluster that accepts incoming requests, e.g a gateway or something else similar to that.

[revero-doug]

@mateiidavid does this mean the linkerd documentation is wrong to include GCE Ingress as a compatible ingress controller?

[etlock]

Facing the same issue..

[kflynn]

I think that what we're talking about as "GCE Ingress" here is https://cloud.google.com/kubernetes-engine/docs/concepts/ingress (if anyone cares to confirm, this would be lovely). There are two different ways to use this:

1. You can let GKE manage it for you, or
2. You can deploy it directly in your cluster.

Most folks, I'm told, take option 1 and let GKE worry about it. However, you can't mesh the ingress controller in that mode since there's nothing running in your cluster to put our proxy next to.

I'll clarify, in the docs, that you need to be deploying this ingress directly in your cluster in order to mesh it. It's definitely compatible in that mode.

[adrian-gierakowski]

Doesn’t look like the docs for this have been improved

[adrian-gierakowski]

What about if I don’t use GKE ingress but API Gateway?

It doesn’t crate any load balancer pods in the cluster and sends traffic directly to pods.

[adrian-gierakowski]

Can I let the external traffic from Load Balancer hit the pods directly and only use Linkerd for managing internal traffic between services in the cluster?

[kflynn]

Yes, you can do that. Obviously Linkerd won't be able to protect the traffic from the ingress to the first pods, but everything after that can take advantage of Linkerd.

[adrian-gierakowski]

Thank you for your answer! I gather I’d do it with config.linkerd.io/skip-inbound-ports annotation? I saw it mention mentioned in one of your workshops on YouTube I watched after I wrote the above message. Thanks!