Cannot separately define health checks for HTTP and gRPC when combined on one Ingress

[erhudy]

Describe the bug

When using conditions cleverness to combine both regular HTTP and gRPC services on a single Ingress (i.e., write a condition that steers traffic to a service offering gRPC if Content-Type: application/grpc), it is not possible to define separate health checks for the two target groups that are generated by the controller. If both services are able to use the default health checks, great, but this is probably not the case.

Steps to reproduce

Write an Ingress with conditions annotations that route traffic to a gRPC service if the Content-Type is application/grpc.

Expected outcome

I know the controller doesn't support defining separate health checks for HTTP vs gRPC target groups on the same ingress, so this outcome is actually expected.

What I would like to be possible is to be able to define separate health check parameters for gRPC services, with all the existing health check annotations duplicated to gRPC-specific ones:

alb.ingress.kubernetes.io/grpc-healthcheck-protocol: HTTP
alb.ingress.kubernetes.io/grpc-healthcheck-port: '12345'
alb.ingress.kubernetes.io/grpc-healthcheck-path: hello.HelloService/SayHello
alb.ingress.kubernetes.io/grpc-healthcheck-interval-seconds: '15'
alb.ingress.kubernetes.io/grpc-healthcheck-timeout-seconds: '15'
alb.ingress.kubernetes.io/grpc-success-codes: '0,1,2,3'
alb.ingress.kubernetes.io/grpc-healthy-threshold-count: '5'
alb.ingress.kubernetes.io/grpc-unhealthy-threshold-count: '3'

For full backwards compatibility, the existing behavior would be maintained. If any of these annotations is present, it would configure health check behavior for a gRPC service only.

Environment

• AWS Load Balancer controller version: 2.4.x
• Kubernetes version: 1.26.x
• Using EKS (yes/no), if so version? yes, 1.26.x

Additional Context:

Maybe you think this is an insane use case. Maybe it is! But if the LB controller allows this kind of orthogonality through defining all sorts of crazy conditions, it should probably also allow it for health checks.

[oliviassss]

@erhudy, sorry for the late reply. I think your request is kind of similar to this issue: #3346
I think probably we don't need to have a set of annotations to specify the health check for gPRC separately, but to improve the current annotations to support multiple health checks per service/ingress.
For example, we can have
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: portA,portB
service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: protocolA,protocolB
If there are multiple values specified in the annotation, we expect it's a 1:1 mapping.

[hanpeter]

👍 on this. I have a similar use case for HTTP and HTTPS. I would very much like this feature.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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/test-infra repository.