mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
57 lines
3.0 KiB
Plaintext
57 lines
3.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * networking/ingress-operator.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="nw-http2-haproxy_{context}"]
|
|
= Enabling HTTP/2 Ingress connectivity
|
|
|
|
You can enable transparent end-to-end HTTP/2 connectivity in HAProxy. It allows application owners to make use of HTTP/2 protocol capabilities, including single connection, header compression, binary streams, and more.
|
|
|
|
You can enable HTTP/2 connectivity for an individual Ingress Controller or for the entire cluster.
|
|
|
|
To enable the use of HTTP/2 for the connection from the client to HAProxy, a route must specify a custom certificate. A route that uses the default certificate cannot use HTTP/2. This restriction is necessary to avoid problems from connection coalescing, where the client re-uses a connection for different routes that use the same certificate.
|
|
|
|
The connection from HAProxy to the application pod can use HTTP/2 only for re-encrypt routes and not for edge-terminated or insecure routes. This restriction is because HAProxy uses Application-Level Protocol Negotiation (ALPN), which is a TLS extension, to negotiate the use of HTTP/2 with the back-end. The implication is that end-to-end HTTP/2 is possible with passthrough and re-encrypt and not with insecure or edge-terminated routes.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
For non-passthrough routes, the Ingress Controller negotiates its connection to the application independently of the connection from the client. This means a client may connect to the Ingress Controller and negotiate HTTP/1.1, and the Ingress Controller may then connect to the application, negotiate HTTP/2, and forward the request from the client HTTP/1.1 connection using the HTTP/2 connection to the application. This poses a problem if the client subsequently tries to upgrade its connection from HTTP/1.1 to the WebSocket protocol, because the Ingress Controller cannot forward WebSocket to HTTP/2 and cannot upgrade its HTTP/2 connection to WebSocket. Consequently, if you have an application that is intended to accept WebSocket connections, it must not allow negotiating the HTTP/2 protocol or else clients will fail to upgrade to the WebSocket protocol.
|
|
====
|
|
|
|
.Procedure
|
|
|
|
Enable HTTP/2 on a single Ingress Controller.
|
|
|
|
* To enable HTTP/2 on an Ingress Controller, enter the `oc annotate` command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
|
|
----
|
|
+
|
|
Replace `<ingresscontroller_name>` with the name of the Ingress Controller to annotate.
|
|
|
|
Enable HTTP/2 on the entire cluster.
|
|
|
|
* To enable HTTP/2 for the entire cluster, enter the `oc annotate` command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
|
|
----
|
|
+
|
|
[TIP]
|
|
====
|
|
You can alternatively apply the following YAML to add the annotation:
|
|
[source,yaml]
|
|
----
|
|
apiVersion: config.openshift.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
name: cluster
|
|
annotations:
|
|
ingress.operator.openshift.io/default-enable-http2: "true"
|
|
----
|
|
====
|