Suggestions on gatewayapi

[zhshw]

At present, the design of gatewayapi still lacks sufficient production validation, so it is not necessary to wait for the design of gatewayapi. Just consider enough compatibility with it, Partially use it.

Keep observing the features in the gateway api design.

The go-controller-plane is also the definition of resources, Not all resource conversions are translations. It can also be an association.

For example, the association between K8S Service resource and Envoy Cluster resource, Get endpoints and container ports through K8s Service, The actual work is Envoy Cluster. If there is an EnvoyCluster CRD, the logic will be very simple.

cluster

apiVersion: config.gateway.envoyproxy.io/v1alpha1
kind: EnvoyCluster
metadata:
  name: demo
spec:  //use envoy cluster struct

Endpoints

apiVersion: config.gateway.envoyproxy.io/v1alpha1
kind: EnvoyEndpoints
metadata:
  name: demo
spec:  //use envoy endpoint struct

[youngnick]

Thanks for the issue @zhshw.

We actually discussed this approach early on in the design phase for Envoy Gateway, and decided not to go with it because it adds a bunch of additional complexity around handling extra clusters, endpoints etc. At the time, the maintainers didn't believe the benefits (making some translations easier to do) were worth the costs (we still need to translate the Kubernetes Service and Endpoints into these resources anyway, so we're really moving the complexity rather than reducing it).

I'm curious if you have any other reasons aside from those for proposing this? I don't think that the cost/benefit has changed very much, but I'd love to hear if you have some other ideas here.

[zhshw]

The user-oriented K8S service lacks the configuration of connect timeout #877 , slowstart #787 , lb policy, etc, The K8S endpoint is lacks the Locality and Weight fields. But they are all useful features. The translation process will lead to a large number of intermediate fields and resource definitions.

For example, the intermediate field warmupDurationSecs defined by istio and the envoy cluster resource are actually SlowStartConfig. The Istio translation process also lost the Aggregation and MinWeightPercent
There is reason to suspect that this is an artificial creation of demand (translation, document, intermediate field definition)

However, these intermediate resource fields are difficult to match with enough unit tests, documents, and design validation, which require a lot of time. Using the envoy-control-plane resource field will reduce the user's use cost, User can refer to the envoy document, The basic resources such as cluster and endpoint only need to add hundreds of lines of code to replace the K8S service and endpoint. Of course, K8S services can also be supported in a compatible way, but the implementation method will be different. For envoy-gateway, it has a lot of rich configurations that can be user-oriented.

Different scenarios and requirements, Support for new features will be very fast, not a lot of "Support *" issues And translation is not required in the startup phase. This is not to say that translation is useless, according to the actual situation. Need to consider more about the use cost and value

Another advantage is that users can configure EnvoyCluster(CRD) static IP or DNS There are always some services that are not running under K8S, In this way, traffic switching between multiple clusters will be very easy to implement

Are these reasons and ideas enough to persuade you? @youngnick

[arkodg]

@zhshw your comments reveal that you're well versed in Envoy APIs and can be classified as a advanced user for this project. For users like you we planning on supporting a direct xDS mode, more details here #24, we will try and prioritize this feature for the next release so users like you can leverage advanced Envoy knobs w/o waiting for it to be exposed in the Gateway API