AWS load balancer controller uses invalid (or deprecated) annotations

[sftim]

Describe the bug https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/ and https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/ingress/annotations/ both list annotations; however, the Service annotations use a deprecated form that includes .beta. (.alpha. is also deprecated).

For both kinds, the annotations are not yet registered - see https://kubernetes.io/docs/reference/labels-annotations-taints/

I'm not sure whether to class the Service annotations as unregistered or deprecated. Either way, I recommend fixing it.

Steps to reproduce Read https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/ or https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/ingress/annotations/

Recommendation

• Formally deprecate the service.beta.kubernetes.io domain name for AWS load balancer annotations.
• Introduce a new AWS domain name for all these annotations
  • and possibly update the in-tree cloud provider integration to also honor them
• Continue to support the deprecated annotations either indefinitely or for a lengthy period. There's no problem supporting them indefinitely. We (Kubernetes project) can also register the deprecated annotations.
• Document the AWS annotations in AWS' reference documentation. Make it clear which annotations apply to the AWS load balancer controller and which apply to the in-tree code.
  • There is no need to register the new annotations as they won't use the domain kubernetes.io

I'd prefer not to register the existing annotations without also deprecating them. Ideally, we don't end up having any registered annotations that are:

• specific to a cloud provider, and
• not deprecated

Additional Context: I'm also working on https://github.com/kubernetes/website/pull/38551 for the Kubernetes documentation; this issue relates to registering those annotations.

For an example of a cloud provider partly following recommended practice, see https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing

• service.kubernetes.io/firewall-rule-for-hc is unofficial
• networking.gke.io/load-balancer-type is thirdparty

There are other providers that also do it wrong; for example: https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer

Future plans:

Eventually, the Kubernetes project may return warnings when unregistered annotations are used. Right now there are no plans for such warnings, that I know of. Even if warnings are ever returned, I assume that you'd still be able to use unregistered annotations and labels, you'd just get a Warning: header in the API response.

[kishorj]

@sftim, thanks for raising the details. We have it in our roadmap for 2.5.0 release. Here is our current plan:

• Document service.beta.kubernetes.io as deprecate
• Introduce a new AWS specific prefix service.k8s.aws, continue to support legacy annotations for now
• Modify CCM. The in-tree controller (KCM) will remain as-is.

[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

[sftim]

/remove-lifecycle stale /triage accepted

Part of roadmap

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[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

[sftim]

We should fix this /remove-lifecycle rotten /triage accepted