mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-9693: adds route config MicroShift
This commit is contained in:
“Shauna Diaz”
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
77e84c4876
commit
01c0ded6f6
@@ -430,6 +430,8 @@ Topics:
|
||||
File: microshift-cni-multus
|
||||
- Name: Configuring and using multiple networks
|
||||
File: microshift-cni-multus-using
|
||||
- Name: Configuring routes
|
||||
File: microshift-configuring-routes
|
||||
- Name: Firewall configuration
|
||||
File: microshift-firewall
|
||||
- Name: Networking settings for fully disconnected hosts
|
||||
|
||||
62
microshift_networking/microshift-configuring-routes.adoc
Normal file
62
microshift_networking/microshift-configuring-routes.adoc
Normal file
@@ -0,0 +1,62 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="microshift-configuring-routes"]
|
||||
= Configuring routes
|
||||
include::_attributes/attributes-microshift.adoc[]
|
||||
:context: microshift-configuring-routes
|
||||
|
||||
toc::[]
|
||||
|
||||
You can configure routes for {microshift-short} for clusters.
|
||||
|
||||
//OCP module, edit with care; Creating an insecure/http route
|
||||
include::modules/nw-creating-a-route.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care; HTTP Strict Transport Security
|
||||
include::modules/nw-enabling-hsts.adoc[leveloffset=+2]
|
||||
|
||||
//OCP module, edit with care; Enabling HTTP strict transport security per-route
|
||||
include::modules/nw-enabling-hsts-per-route.adoc[leveloffset=+2]
|
||||
|
||||
//OCP module, edit with care; Disabling HTTP strict transport security per-route
|
||||
include::modules/nw-disabling-hsts.adoc[leveloffset=+2]
|
||||
|
||||
//Enforcing HTTP strict transport security per-domain
|
||||
include::modules/microshift-nw-enforcing-hsts-per-domain.adoc[leveloffset=+2]
|
||||
|
||||
//OCP module, edit with care; Troubleshooting Throughput Issues
|
||||
include::modules/nw-throughput-troubleshoot.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care; Using cookies to keep route statefulness
|
||||
include::modules/nw-using-cookies-keep-route-statefulness.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care; Using cookies to keep route statefulness
|
||||
include::modules/nw-annotating-a-route-with-a-cookie-name.adoc[leveloffset=+2]
|
||||
|
||||
//OCP module, edit with care
|
||||
include::modules/nw-path-based-routes.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care; just use the `Route` CR
|
||||
include::modules/nw-http-header-configuration.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care
|
||||
include::modules/nw-route-set-or-delete-http-headers.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care
|
||||
include::modules/nw-ingress-creating-a-route-via-an-ingress.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care
|
||||
include::modules/nw-ingress-edge-route-default-certificate.adoc[leveloffset=+1]
|
||||
|
||||
//OCP module, edit with care
|
||||
include::modules/nw-ingress-reencrypt-route-custom-cert.adoc[leveloffset=+1]
|
||||
|
||||
[id="microshift-secured-routes_{context}"]
|
||||
== Secured routes
|
||||
|
||||
Secure routes provide the ability to use several types of TLS termination to serve certificates to the client. The following links to the {OCP} documentation describe how to create re-encrypt, edge, and passthrough routes with custom certificates.
|
||||
|
||||
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/networking/configuring-routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes[Creating a re-encrypt route with a custom certificate]
|
||||
|
||||
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/networking/configuring-routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes[Creating an edge route with a custom certificate]
|
||||
|
||||
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/networking/configuring-routes#nw-ingress-creating-a-passthrough-route_secured-routes[Creating a passthrough route]
|
||||
51
modules/microshift-nw-enforcing-hsts-per-domain.adoc
Normal file
51
modules/microshift-nw-enforcing-hsts-per-domain.adoc
Normal file
@@ -0,0 +1,51 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="microshift-nw-enforcing-hsts-per-domain_{context}"]
|
||||
= Enforcing HTTP Strict Transport Security per-domain
|
||||
|
||||
You can configure a route with a compliant HSTS policy annotation. To handle upgraded clusters with non-compliant HSTS routes, you can update the manifests at the source and apply the updates.
|
||||
|
||||
You cannot use `oc expose route` or `oc create route` commands to add a route in a domain that enforces HSTS because the API for these commands does not accept annotations.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
HSTS cannot be applied to insecure, or non-TLS, routes.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
* You have root access to the cluster.
|
||||
* You installed the {oc-first}.
|
||||
|
||||
.Procedure
|
||||
|
||||
* Apply HSTS to all routes in the cluster by running the following `oc annotate command`:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;preload;includeSubDomains"
|
||||
----
|
||||
+
|
||||
* Apply HSTS to all routes in a particular namespace by running the following `oc annotate command`:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc annotate route --all -n <my_namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;preload;includeSubDomains" <1>
|
||||
----
|
||||
<1> Replace _<my_namespace> with the namespace you want to use.
|
||||
|
||||
.Verification
|
||||
* Review the HSTS annotations on all routes by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
|
||||
----
|
||||
@@ -5,12 +5,13 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/configuring-routing.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-annotating-a-route-with-a-cookie-name_{context}"]
|
||||
= Annotating a route with a cookie
|
||||
|
||||
You can set a cookie name to overwrite the default, auto-generated one for the route. This allows the application receiving route traffic to know the cookie name. By deleting the cookie it can force the next request to re-choose an endpoint. So, if a server was overloaded it tries to remove the requests from the client and redistribute them.
|
||||
You can set a cookie name to overwrite the default, auto-generated one for the route. This allows the application receiving route traffic to know the cookie name. Deleting the cookie can force the next request to re-choose an endpoint. The result is that if a server is overloaded, that server tries to remove the requests from the client and redistribute them.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
// Module included in the following assemblies:
|
||||
// * networking/configuring-routing.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-disabling-hsts_{context}"]
|
||||
@@ -8,9 +9,13 @@
|
||||
To disable HTTP strict transport security (HSTS) per-route, you can set the `max-age` value in the route annotation to `0`.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
ifndef::microshift[]
|
||||
* You are logged in to the cluster with a user with administrator privileges for the project.
|
||||
* You installed the `oc` CLI.
|
||||
endif::microshift[]
|
||||
ifdef::microshift[]
|
||||
* You have root access to the cluster.
|
||||
endif::microshift[]
|
||||
* You installed the {oc-first}.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
// Module included in the following assemblies:
|
||||
// * networking/configuring-routing.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-enabling-hsts-per-route_{context}"]
|
||||
@@ -8,9 +9,13 @@
|
||||
HTTP strict transport security (HSTS) is implemented in the HAProxy template and applied to edge and re-encrypt routes that have the `haproxy.router.openshift.io/hsts_header` annotation.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
ifndef::microshift[]
|
||||
* You are logged in to the cluster with a user with administrator privileges for the project.
|
||||
* You installed the `oc` CLI.
|
||||
endif::microshift[]
|
||||
ifdef::microshift[]
|
||||
* You have root access to the cluster.
|
||||
endif::microshift[]
|
||||
* You installed the {oc-first}.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -21,7 +26,7 @@ HTTP strict transport security (HSTS) is implemented in the HAProxy template and
|
||||
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ <1>
|
||||
includeSubDomains;preload"
|
||||
----
|
||||
<1> In this example, the maximum age is set to `31536000` ms, which is approximately eight and a half hours.
|
||||
<1> In this example, the maximum age is set to `31536000` ms, which is approximately 8.5 hours.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
// Module filename: nw-enabling-hsts.adoc
|
||||
// Module included in the following assemblies:
|
||||
// * networking/configuring-routing.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
[id="nw-enabling-hsts_{context}"]
|
||||
= HTTP Strict Transport Security
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/configuring-routing.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
@@ -25,13 +26,12 @@ HSTS cannot be applied to insecure, or non-TLS routes, even if HSTS is requested
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You are logged in to the cluster with a user with administrator privileges for the project.
|
||||
* You installed the `oc` CLI.
|
||||
* You installed the {oc-first}.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Edit the Ingress config file:
|
||||
. Edit the Ingress configuration YAML by running the following command and updating fields as needed:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -47,19 +47,19 @@ metadata:
|
||||
name: cluster
|
||||
spec:
|
||||
domain: 'hello-openshift-default.apps.username.devcluster.openshift.com'
|
||||
requiredHSTSPolicies: <1>
|
||||
- domainPatterns: <2>
|
||||
requiredHSTSPolicies: # <1>
|
||||
- domainPatterns: # <2>
|
||||
- '*hello-openshift-default.apps.username.devcluster.openshift.com'
|
||||
- '*hello-openshift-default2.apps.username.devcluster.openshift.com'
|
||||
namespaceSelector: <3>
|
||||
namespaceSelector: # <3>
|
||||
matchLabels:
|
||||
myPolicy: strict
|
||||
maxAge: <4>
|
||||
maxAge: # <4>
|
||||
smallestMaxAge: 1
|
||||
largestMaxAge: 31536000
|
||||
preloadPolicy: RequirePreload <5>
|
||||
includeSubDomainsPolicy: RequireIncludeSubDomains <6>
|
||||
- domainPatterns: <2>
|
||||
preloadPolicy: RequirePreload # <5>
|
||||
includeSubDomainsPolicy: RequireIncludeSubDomains # <6>
|
||||
- domainPatterns:
|
||||
- 'abc.example.com'
|
||||
- '*xyz.example.com'
|
||||
namespaceSelector:
|
||||
|
||||
@@ -6,14 +6,29 @@
|
||||
:_mod-docs-content-type: CONCEPT
|
||||
[id="nw-http-header-configuration_{context}"]
|
||||
= HTTP header configuration
|
||||
|
||||
ifndef::microshift[]
|
||||
{product-title} provides different methods for working with HTTP headers. When setting or deleting headers, you can use specific fields in the Ingress Controller or an individual route to modify request and response headers. You can also set certain headers by using route annotations. The various ways of configuring headers can present challenges when working together.
|
||||
endif::microshift[]
|
||||
|
||||
ifdef::microshift[]
|
||||
When setting or deleting headers, you can use an individual route to modify request and response headers. You can also set certain headers by using route annotations. The various ways of configuring headers can present challenges when working together.
|
||||
endif::microshift[]
|
||||
|
||||
ifndef::microshift[]
|
||||
[NOTE]
|
||||
====
|
||||
You can only set or delete headers within an `IngressController` or `Route` CR, you cannot append them. If an HTTP header is set with a value, that value must be complete and not require appending in the future. In situations where it makes sense to append a header, such as the X-Forwarded-For header, use the `spec.httpHeaders.forwardedHeaderPolicy` field, instead of `spec.httpHeaders.actions`.
|
||||
====
|
||||
endif::microshift[]
|
||||
|
||||
ifdef::microshift[]
|
||||
[NOTE]
|
||||
====
|
||||
You can only set or delete headers within a `Route` CR. You cannot append headers. If an HTTP header is set with a value, that value must be complete and not require appending in the future. In situations where it makes sense to append a header, such as the X-Forwarded-For header, use the `spec.httpHeaders.forwardedHeaderPolicy` field, instead of `spec.httpHeaders.actions`.
|
||||
====
|
||||
endif::microshift[]
|
||||
|
||||
ifndef::microshift[]
|
||||
[id="nw-http-header-configuration-order_{context}"]
|
||||
== Order of precedence
|
||||
|
||||
@@ -43,6 +58,7 @@ spec:
|
||||
----
|
||||
|
||||
A route owner sets the same response header that the cluster administrator set in the Ingress Controller, but with the value `SAMEORIGIN` using the following configuration:
|
||||
endif::microshift[]
|
||||
|
||||
.Example `Route` spec
|
||||
[source,yaml]
|
||||
@@ -60,10 +76,10 @@ spec:
|
||||
set:
|
||||
value: SAMEORIGIN
|
||||
----
|
||||
ifndef::microshift[]
|
||||
When both the `IngressController` spec and `Route` spec are configuring the X-Frame-Options response header, then the value set for this header at the global level in the Ingress Controller takes precedence, even if a specific route allows frames. For a request header, the `Route` spec value overrides the `IngressController` spec value.
|
||||
|
||||
When both the `IngressController` spec and `Route` spec are configuring the X-Frame-Options header, then the value set for this header at the global level in the Ingress Controller will take precedence, even if a specific route allows frames.
|
||||
|
||||
This prioritzation occurs because the `haproxy.config` file uses the following logic, where the Ingress Controller is considered the front end and individual routes are considered the back end. The header value `DENY` applied to the front end configurations overrides the same header with the value `SAMEORIGIN` that is set in the back end:
|
||||
This prioritization occurs because the `haproxy.config` file uses the following logic, where the Ingress Controller is considered the front end and individual routes are considered the back end. The header value `DENY` applied to the front end configurations overrides the same header with the value `SAMEORIGIN` that is set in the back end:
|
||||
|
||||
[source,text]
|
||||
----
|
||||
@@ -81,12 +97,18 @@ backend be_secure:openshift-monitoring:alertmanager-main
|
||||
----
|
||||
|
||||
Additionally, any actions defined in either the Ingress Controller or a route override values set using route annotations.
|
||||
endif::microshift[]
|
||||
|
||||
ifdef::microshift[]
|
||||
Any actions defined in a route override values set using route annotations.
|
||||
endif::microshift[]
|
||||
|
||||
[id="nw-http-header-configuration-special-cases_{context}"]
|
||||
== Special case headers
|
||||
|
||||
The following headers are either prevented entirely from being set or deleted, or allowed under specific circumstances:
|
||||
|
||||
ifndef::microshift[]
|
||||
.Special case header configuration options
|
||||
[cols="5*a",options="header"]
|
||||
|===
|
||||
@@ -120,3 +142,34 @@ The following headers are either prevented entirely from being set or deleted, o
|
||||
* the `haproxy.router.openshift.io/cookie_name` route annotation
|
||||
|
||||
|===
|
||||
endif::microshift[]
|
||||
|
||||
ifdef::microshift[]
|
||||
|===
|
||||
|Header name |Configurable using `Route` spec |Reason for disallowment |Configurable using another method
|
||||
|
||||
|`proxy`
|
||||
|No
|
||||
|The `proxy` HTTP request header can be used to exploit vulnerable CGI applications by injecting the header value into the `HTTP_PROXY` environment variable. The `proxy` HTTP request header is also non-standard and prone to error during configuration.
|
||||
|No
|
||||
|
||||
|`host`
|
||||
|Yes
|
||||
|When the `host` HTTP request header is set using the `IngressController` CR, HAProxy can fail when looking up the correct route.
|
||||
|No
|
||||
|
||||
|`strict-transport-security`
|
||||
|No
|
||||
|The `strict-transport-security` HTTP response header is already handled using route annotations and does not need a separate implementation.
|
||||
|Yes: the `haproxy.router.openshift.io/hsts_header` route annotation
|
||||
|
||||
|`cookie` and `set-cookie`
|
||||
|No
|
||||
|The cookies that HAProxy sets are used for session tracking to map client connections to particular back-end servers. Allowing these headers to be set could interfere with HAProxy's session affinity and restrict HAProxy's ownership of a cookie.
|
||||
|Yes:
|
||||
|
||||
* the `haproxy.router.openshift.io/disable_cookie` route annotation
|
||||
* the `haproxy.router.openshift.io/cookie_name` route annotation
|
||||
|
||||
|===
|
||||
endif::microshift[]
|
||||
@@ -1,6 +1,7 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/routes/route-configuration.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-ingress-creating-a-route-via-an-ingress_{context}"]
|
||||
|
||||
@@ -1,9 +1,10 @@
|
||||
// This is included in the following assemblies:
|
||||
//
|
||||
// networking/routes/route-configuration.adoc
|
||||
// * networking/routes/route-configuration.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="creating-edge-route-with-default-certificate_{context}"]
|
||||
[id="nw-ingress-edge-route-default-certificate_{context}"]
|
||||
= Creating a route using the default certificate through an Ingress object
|
||||
|
||||
If you create an Ingress object without specifying any TLS configuration, {product-title} generates an insecure route. To create an Ingress object that generates a secure, edge-terminated route using the default ingress certificate, you can specify an empty TLS configuration as follows.
|
||||
@@ -42,6 +43,7 @@ $ oc create -f example-ingress.yaml
|
||||
----
|
||||
|
||||
.Verification
|
||||
|
||||
* Verify that {product-title} has created the expected route for the Ingress object by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
|
||||
@@ -1,9 +1,10 @@
|
||||
// This is included in the following assemblies:
|
||||
//
|
||||
// networking/routes/route-configuration.adoc
|
||||
// * networking/routes/route-configuration.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="creating-re-encrypt-route-with-custom-certificate_{context}"]
|
||||
[id="nw-ingress-re-encrypt-route-custom-cert_{context}"]
|
||||
= Creating a route using the destination CA certificate in the Ingress annotation
|
||||
|
||||
The `route.openshift.io/destination-ca-certificate-secret` annotation can be used on an Ingress object to define a route with a custom destination CA certificate.
|
||||
@@ -14,7 +15,6 @@ The `route.openshift.io/destination-ca-certificate-secret` annotation can be use
|
||||
* You must have a separate destination CA certificate in a PEM-encoded file.
|
||||
* You must have a service that you want to expose.
|
||||
|
||||
|
||||
.Procedure
|
||||
|
||||
. Add the `route.openshift.io/destination-ca-certificate-secret` to the Ingress annotations:
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
// Module filename: nw-throughput-troubleshoot.adoc
|
||||
// Module included in the following assemblies:
|
||||
// * networking/routes/route-configuration.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
:_mod-docs-content-type: CONCEPT
|
||||
[id="nw-throughput-troubleshoot_{context}"]
|
||||
@@ -33,7 +34,8 @@ $ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
|
||||
ifdef::openshift-enterprise,openshift-webscale[]
|
||||
** For information on installing and using `iperf`, see this link:https://access.redhat.com/solutions/33103[Red Hat Solution].
|
||||
endif::openshift-enterprise,openshift-webscale[]
|
||||
|
||||
* In some cases, the cluster may mark the node with the router pod as unhealthy due to latency issues. Use worker latency profiles to adjust the frequency that the cluster waits for a status update from the node before taking action.
|
||||
ifndef::microshift[]
|
||||
* In some cases, the cluster might mark the node with the router pod as unhealthy due to latency issues. Use worker latency profiles to adjust the frequency that the cluster waits for a status update from the node before taking action.
|
||||
|
||||
* If your cluster has designated lower-latency and higher-latency nodes, configure the `spec.nodePlacement` field in the Ingress Controller to control the placement of the router pod.
|
||||
endif::microshift[]
|
||||
|
||||
@@ -5,20 +5,14 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/configuring-routing.adoc
|
||||
// * microshift_networking/microshift-configuring-routes.adoc
|
||||
|
||||
[id="nw-using-cookies-keep-route-statefulness_{context}"]
|
||||
= Using cookies to keep route statefulness
|
||||
|
||||
{product-title} provides sticky sessions, which enables stateful application
|
||||
traffic by ensuring all traffic hits the same endpoint. However, if the endpoint
|
||||
pod terminates, whether through restart, scaling, or a change in configuration,
|
||||
this statefulness can disappear.
|
||||
{product-title} provides sticky sessions, which enables stateful application traffic by ensuring all traffic hits the same endpoint. However, if the endpoint pod terminates, whether through restart, scaling, or a change in configuration, this statefulness can disappear.
|
||||
|
||||
{product-title} can use cookies to configure session persistence. The Ingress
|
||||
controller selects an endpoint to handle any user requests, and creates a cookie
|
||||
for the session. The cookie is passed back in the response to the request and
|
||||
the user sends the cookie back with the next request in the session. The cookie
|
||||
tells the Ingress Controller which endpoint is handling the session, ensuring
|
||||
that client requests use the cookie so that they are routed to the same pod.
|
||||
{product-title} can use cookies to configure session persistence. The ingress controller selects an endpoint to handle any user requests, and creates a cookie for the session. The cookie is passed back in the response to the request and the user sends the cookie back with the next request in the session. The cookie tells the ingress controller which endpoint is handling the session, ensuring that client requests use the cookie so that they are routed to the same pod.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
Reference in New Issue
Block a user