Health check for backends.gateway.envoyproxy.io

[czczycz]

something like:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
  name: static-upstream
  namespace: default
spec:
  endpoints:
  - ip:
      address: 10.212.100.1
      port: 8080
  - ip:
      address: 10.212.100.2
      port: 8080
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: health-check-static-upstream
  namespace: default
spec:
  targetRefs:
    - group: gateway.envoyproxy.io
      kind: Backend
      name: static-upstream
  healthCheck:
    active:
      timeout: 3s
      interval: 5s
      unhealthyThreshold: 3
      healthyThreshold: 1
      type: HTTP
      http:
        path: "/healthz"
        expectedStatuses:
          - 200

[arkodg]

@czczycz can you elaborate on the issue ?
how are you trying to test this

[guydc]

Hi @czczycz !

BackendTrafficPolicy only applies to xRoutes, not backend objects. If you have a route with a ref to a backend, you can apply the policy to that route.

If your backend is not referenced by a route (e.g. ext-auth, observability sinks, ... ): there is currently an effort to support such capabilities for this as well: #3069, #3954 . I hope that this would enable your use case.

[czczycz]

Hey @guydc , thanks for attention!
From a semantic perspective, BackendTrafficPolicy refers to a policy for the backend. If it is intended for the BackendRef of xRoute, it may be confusing.
Another point is that if the BackendTrafficPolicy is applied to xRoute, will there be conflicting configurations if multiple xRoutes refer to the same Backend?

#3954 looks really nice. Will targetRefs in PolicyTargetReferences support backends.gateway.envoyproxy.io resource?

[guydc]

From a semantic perspective, BackendTrafficPolicy refers to a policy for the backend. If it is intended for the BackendRef of xRoute, it may be confusing.

You can read the high-level design and some naming discussion for this policy here: #1821.

Another point is that if the BackendTrafficPolicy is applied to xRoute, will there be conflicting configurations if multiple xRoutes refer to the same Backend?

There shouldn't be a conflict. In Envoy Gateway, each route produces a separate envoy cluster. As a result, different policies would be isolated to different clusters.

#3954 looks really nice. Will targetRefs in PolicyTargetReferences support backends.gateway.envoyproxy.io resource?

Depends on the policy. For example, BackendTLSPolicy attaches to a backend-like resources, such as service, serviceImport and backends.gateway.envoyproxy.io (already). However, most policies (BackendTrafficPolicy, ClientTrafficPolicy, SecurityPolicy, EnvoyExtensionPolicy) support attachment to a subset of [Gateway, Listener and Route]. These are not likely to support attachment to backends.gateway.envoyproxy.io.

[arkodg]

the diagram in https://gateway.envoyproxy.io/docs/concepts/concepts_overview/ should help understand which policies can target which resource

[czczycz]

Hi @guydc !

Thank you very much for your patient response.

Besides configuration conflicts, duplicate configurations might also be an issue. If multiple HTTPRoutes are configured with the same Backend, you need to configure a BackendTrafficPolicy for each HTTPRoute. However, the health check configurations are the same (for the same backend).

[czczycz]

@arkodg Thanks!

This diagram is very helpful.

[arkodg]

closing this one, attaching BTP to the route should resolve this issue