Allow user to define proxy service name

[liyangau]

Problem Statement

KGO generates proxy service name as dataplane-ingress-<Gateway_Name>-s2vb6-lhz28 which is difficult to predict the real service name to use.

Proposed Solution

Add support for nameOverride or something similar to allow user define their proxy service name so they have a predictable name to send requests to. It can be as simple as dataplane-ingress-<Gateway_Name>_<user_defined_name>

Additional Information

This feature is also valuable for Kong mesh users to select their gateway dataplanes.

[pmalek]

You can look up the Service name by looking at the (owned by Gateway) DataPlane's .status.service`:

kubectl get dataplane -n default kong-dgw79   -o jsonpath-as-json='{.status.service}' | jq -r '.[0]'
dataplane-ingress-kong-dgw79-5cgqt

---

Apparently we do not provide the Gateway -> DataPlane relationship in the Gateway. The owner relationship is only available in the owned DataPlane. We could consider putting that information in Gateway's status for easier discoverability.

[mlavacca]

Since the service name is inferred by the Gateway name, how is the service name difficult to predict? there is always a 1:1 relationship between the Gateway and the service, hence the random suffix should not be a problem in figuring out which service belongs to which Gateway 🤔 Is there anything I'm missing, @liyangau?

[liyangau]

How do I make sure my ci/cd process is idempotent if the service name is randomly generated? By saying it is randomly generated, I am referring to -s2vb6-lhz28.

The same set up, applying it twice on the same cluster. We got two different proxy service names.

➜ kubectl get svc -n kong -o name
service/dataplane-ingress-kong-gw-demo-cljpp-p5h8k

➜ kubectl get svc -n kong -o name
service/dataplane-ingress-kong-gw-demo-8nrt9-s5jct

Imagine all my Zone Mesh Policies selects the Gateway Dataplanes using this service name and it changes every time I need to reapply it. (Let's say in a DR or migration situation)

[pmalek]

@liyangau Are you selecting DataPlanes or their Pods?

For the latter you can use pod labels:

apiVersion: gateway-operator.konghq.com/v1beta1
kind: DataPlane
metadata:
  name: sidecar-example
spec:
  deployment:
    podTemplateSpec:
      metadata:
        labels:
          dataplane-pod-label: example

(that can also be embedded in GatewayConfiguration)

kind: GatewayConfiguration
apiVersion: gateway-operator.konghq.com/v1beta1
metadata:
  name: kong
  namespace: default
spec:
  dataPlaneOptions:
    deployment:
      podTemplateSpec:
        metadata:
          labels:
            dataplane-pod-label: example

For the latter we don't have a solution right now but we could definitely provide one: add custom labels to Gateway managed DataPlanes.

---

Names are problematic because they can cause conflicts which then have to be handled and communicated to the user (prefferably through object status).

[programmer04]

It's reasonable to have the ability to specify the name of that service for an even simpler use case.

Consider a situation when Kong Gateway is used to route traffic inside the cluster for some services, so the name of the ClusterIP service (there is no need for LB in such cases) can be used as an address by others to make calls