[cilium] ExternalName Service Causes Unintended External Traffic

[kahirokunn]

Issue: ExternalName Service Causes Unintended External Traffic in helloworld-go Sample

Version Affected: 1.14.0

Description:
After applying the helloworld-go sample provided in the latest release (version 1.14.0) of Knative Serving, an ExternalName service was generated as described below. This service setup leads to internal application requests being routed externally via the NAT Gateway, instead of being contained within the cluster. This behavior might not be intended as it causes cluster-internal communications to be sent over the internet.

Generated Service YAML:

apiVersion: v1
kind: Service
metadata:
  annotations:
    serving.knative.dev/creator: system:admin
    serving.knative.dev/lastModifier: system:admin
  creationTimestamp: "2024-04-25T07:51:10Z"
  labels:
    serving.knative.dev/route: helloworld-go
    serving.knative.dev/service: helloworld-go
  name: helloworld-go
  namespace: default
  ownerReferences:
  - apiVersion: serving.knative.dev/v1
    blockOwnerDeletion: true
    controller: true
    kind: Route
    name: helloworld-go
    uid: d4bd7725-d0ec-4c60-9e1d-5fc0a9f0e4e5
  resourceVersion: "1883"
  uid: 8321e1c1-5850-4dfb-b78b-687d717a9083
spec:
  externalName: helloworld-go.default.example.com
  ports:
  - appProtocol: kubernetes.io/h2c
    name: http2
    port: 80
    protocol: TCP
    targetPort: 80
  sessionAffinity: None
  type: ExternalName
status:
  loadBalancer: {}

Expected Behavior:
Internal requests to the service should remain within the cluster, avoiding unnecessary use of external network resources.

Actual Behavior:
Traffic intended for internal services is routed externally, causing potential latency and cost implications.

Steps to Reproduce:

1. Deploy the helloworld-go sample from Knative Serving 1.14.0.
2. Observe the routing behavior of requests to the helloworld-go service.

[dprotaso]

The externalName: helloworld-go.default.example.com is a temporary placeholder until the underlying networking layer provides an alternate hostname or IP.

Are you not seeing the service being updated with the cluster local host or cluster ip?

[dprotaso]

@kahirokunn just following up here

[kahirokunn]

This also occurred when using Cilium's GatewayAPI.
We have not had time to re-verify this one.
I will share the results and the scripts etc. I used when I tested it next time!
thx 🙏

[dprotaso]

We don't test with Cillium - so it's probably specific to that implementation.

[kahirokunn]

I understand.
Please let me share any more information when I get it.
Thx

[CheyenneForbes]

@dprotaso for me with cilium, my test deployment's generated ExternalName service stay as externalName: http-bin.thenamespace.svc.cluster.local

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[kahirokunn]

/reopen

[knative-prow]

@kahirokunn: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.