-
Notifications
You must be signed in to change notification settings - Fork 95
Add support for HTTP/2 listener protocol in OCI Load Balancer #505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add support for HTTP/2 listener protocol in OCI Load Balancer #505
Conversation
Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application. When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated. If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public. |
67d17c6
to
25b9ce1
Compare
25b9ce1
to
e7d91e4
Compare
Thank you for signing the OCA. |
f588dcf
to
609b223
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Adds independent listener protocol configuration to OCI Load Balancer resources, introducing HTTP/2 support via a new annotation and updating listener naming and timeout logic.
- New
oci.oraclecloud.com/oci-load-balancer-protocol
annotation for listener protocol getListenersOciLoadBalancer
split intobackendProtocol
andlistenerProtocol
, with HTTP2 validation- Listener naming and default idle timeouts updated to include HTTP/2
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
pkg/cloudprovider/providers/oci/load_balancer_util.go | Normalize listener names to use the "HTTP" prefix for HTTP/2 |
pkg/cloudprovider/providers/oci/load_balancer_spec.go | Added listenerProtocol override, HTTP2 support, and idle timeout map |
pkg/cloudprovider/providers/oci/load_balancer_spec_test.go | Added test cases covering HTTP2 and HTTP listener protocols |
Comments suppressed due to low confidence (1)
pkg/cloudprovider/providers/oci/load_balancer_spec.go:1163
- The comment is outdated now that HTTP/2 (and gRPC) are supported; please update it to reflect all currently supported protocols.
// At that point LB only supports HTTP and TCP
Up |
Problem
When using Layer 7 load balancers with
service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "HTTP"
, the HTTPS listener on port 443 was defaulting to HTTP/1.1 instead of respecting theoci.oraclecloud.com/oci-load-balancer-protocol: "HTTP2"
annotation.This prevented users from configuring HTTP/2 on the listener while maintaining HTTP communication with backends, which is a common configuration pattern for performance optimization.
Solution
Added support for the
oci.oraclecloud.com/oci-load-balancer-protocol
annotation to allow independent configuration of listener and backend protocols.Key Changes
ServiceAnnotationLoadBalancerProtocol = "oci.oraclecloud.com/oci-load-balancer-protocol"
getListenersOciLoadBalancer()
to handle listener and backend protocols independentlyHTTP2
to the list of supported listener protocolsUsage Example
Supported Protocols
Backend Protocol (
service.beta.kubernetes.io/oci-load-balancer-backend-protocol
):TCP
(default)HTTP
GRPC
Listener Protocol (
oci.oraclecloud.com/oci-load-balancer-protocol
):TCP
(default, matches backend protocol)HTTP
HTTP2
NEWGRPC
Testing
Before/After
Before: HTTP-443 listener defaulted to HTTP/1.1 regardless of the protocol annotation
After: HTTP-443 listener correctly uses HTTP/2 when
oci.oraclecloud.com/oci-load-balancer-protocol: "HTTP2"
is specifiedThis change resolves issue #449 and enables users to optimize their load balancer configurations for modern HTTP/2 performance while maintaining flexibility in backend communication protocols.