cloud-provider-gcp
cloud-provider-gcp copied to clipboard
RFE: Enable logging via service annotations for load balancer backends
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.
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.
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
Love to see this added. Feature is important to us. ty
@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 https://github.com/kubernetes/kubernetes/pull/106683, so something external is handling this.
Edit: Handled by ingress-gce
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
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
/remove-lifecycle rotten