RFE: Enable logging via service annotations for load balancer backends

[JoelSpeed]

GKE enables users to use a BackendConfig to enable logging of HTTP requests hitting the backend services when using the ingress objects.
For regular Kubernetes clusters on GCP that use the CCM to implement the service load balancer, there is, as far as I can tell no configuration that would allow a user to configure the load balancer backend service logging.

On other providers (eg AWS), you can enable equivalent logging using an annotation (eg service.beta.kubernetes.io/aws-load-balancer-access-log-enabled).

I would like to see support for this in the GCP CCM implementation as well.

Happy to work with maintainers to implement a solution if the idea is supported in general.

[k8s-ci-robot]

This issue is currently awaiting triage.

If the repository mantainers determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[aojea]

AFAIK the CCM only configures netLB loadbalancers that are pass through, so that capability is not available , but better @swetharepakula @bowei to confirm or explain

[DustinTrap]

Love to see this added. Feature is important to us. ty

[JoelSpeed]

@aojea Is correct, digging into this further, it appears that GKE uses ALBs, which do support backend logging as they are L7, but the CCM by default is using passthrough netLB with target pools as backends.

It appears that there is an option to use a regional backend service, and if that's the case, I believe the logging can be enabled on the RBS.

Looks like this was added in kubernetes/kubernetes#106683, so something external is handling this.

Edit: Handled by ingress-gce

[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

[DustinTrap]

/remove-lifecycle rotten

[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