aws-load-balancer-controller
aws-load-balancer-controller copied to clipboard
[Feature Request] Add Support for k8s gateway APIs (formerly Service APIs)
SIG-NETWORK created the Service APIs project to evolve service-related APIs for Kubernetes. This issue is a request for aws-alb-ingress-controller to add support for Service APIs.
/kind feature-request Thanks for creating this issue. It's already planned :D. We are going to release a new version and rename this controller to aws-load-balancer-controller. The new version will contain the functionalities in a single controller.
- ALB Ingress Controller(v2)
- NLB Service with direct pod targeting support(IP mode) After the initial release(Q3), we'll add support for service-API into it as well.
@M00nF1sh: The label(s) kind/feature-request cannot be applied, because the repository doesn't have them
In response to this:
/kind feature-request Thanks for creating this issue. It's already planned :D. We are going to release a new version and rename this controller to aws-load-balancer-controller. The new version will contain the functionalities in a single controller.
- ALB Ingress Controller(v2)
- NLB Service with direct pod targeting support(IP mode) After the initial release(Q3), we'll add support for service-API into it as well.
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.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-contributor-experience at kubernetes/community. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-contributor-experience at kubernetes/community. /close
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.
/reopen
@kishorj: Reopened this issue.
In response to this:
/reopen
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.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR 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 contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR 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 contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR 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 and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The correct link is https://gateway-api.sigs.k8s.io/ @kishorj - what is needed to add it to the roadmap ?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Is this not on the roadmap yet? This should be a very important feature to implement. This will make it much easier to configure microservices where each microservice is in a different namespace.
This controller should be listed on this page along with the rest of the industry, but there doesn't seem to be any interest from this project. https://gateway-api.sigs.k8s.io/implementations/
/remove-lifecycle stale
k8s ingress spec will get deprecation notice soon. https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/
@geowalrus4gh The link you posted doesn't say anything about deprecation. In fact, the FAQ page says:
Q: Will Gateway API replace the Ingress API? A: No. The Ingress API is GA since Kubernetes 1.19. There are no plans to deprecate this API and we expect most Ingress controllers to support it indefinitely.
I need this feature.
this is available here https://github.com/aws/aws-application-networking-k8s
@bryantbiggs vpc lattice is a great service. But, WAF is not available on vpc lattice, and if you want to use WAF, you need to set ALB as a listener for vpc lattice, which is not available on aws-application-networking-k8s. Even if it becomes possible to specify an ALB as a backend for vpc lattice, it will probably not be supported in the future, although it may be possible if you let aws-application-networking-k8s do the ALB configuration. Also, vpc lattice is still only available in Oregon.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
Keep
/remove-lifecycle stale
Some comments on requirements, from looking over #3146:
The Gateway code shouldn't support annotations for things that can be expressed in GatewayClassParams or within the various *Route specs. Don't reimplement legacy ways of doing things.
We will probably need to implement two GatewayController values, one supporting TCPRoute, TLSRoute, and UDPRoute backed by NLB and another supporting HTTPRoute and GRPCRoute backed by ALB.
Is PR #3146 still being actively developed? Any updates are appreciated!
Support for controlling ALBs via Gateway API and HTTPRoute, rather than just via Ingress, would be really beneficial to our apps. In our Kubernetes clusters on other providers, we are adopting Gateway API for specifying ingress into the cluster, based on its improved persona-based model and its promotion by the Kubernetes community as a successor to Ingress resources. It would be good to have a uniform approach where apps can rely on Gateway API in both EKS and other K8s providers, rather than asking developers to use Gateway in one place and Ingress in another.
+1
As per kubernetes documentation, Ingress is frozen and new features are being added to the Gateway API. So it would be very beneficial to add Gateway API support in ALBC, and It would make it easier to switch our deployments to Gateway API and simplify development especially for our developers. Any updates on when this might be added?