UpstreamSettingsPolicy
@@ -125,8 +123,8 @@ ClientKeepAlive
targetRef
-
-sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
+
+sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
|
@@ -143,8 +141,8 @@ Support: Gateway, HTTPRoute, GRPCRoute.
status
-
-sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus
+
+sigs.k8s.io/gateway-api/apis/v1.PolicyStatus
|
@@ -245,114 +243,6 @@ NginxGatewayStatus
-ObservabilityPolicy
-
-
-
-
ObservabilityPolicy is a Direct Attached Policy. It provides a way to configure observability settings for
-the NGINX Gateway Fabric data plane. Used in conjunction with the NginxProxy CRD that is attached to the
-GatewayClass parametersRef.
-
-
SnippetsFilter
@@ -540,10 +430,41 @@ UpstreamKeepAlive
+loadBalancingMethod
+
+
+LoadBalancingType
+
+
+ |
+
+(Optional)
+ LoadBalancingMethod specifies the load balancing algorithm to be used for the upstream.
+If not specified, NGINX Gateway Fabric defaults to random two least_conn,
+which differs from the standard NGINX default round-robin.
+ |
+
+
+
+hashMethodKey
+
+
+HashMethodKey
+
+
+ |
+
+(Optional)
+ HashMethodKey defines the key used for hash-based load balancing methods.
+This field is required when LoadBalancingMethod is set to hash or hash consistent.
+ |
+
+
+
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
|
@@ -561,8 +482,8 @@ Support: Service
status
-
-sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus
+
+sigs.k8s.io/gateway-api/apis/v1.PolicyStatus
|
@@ -794,8 +715,8 @@ ClientKeepAlive
targetRef
-
-sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
+
+sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
|
@@ -908,6 +829,105 @@ Duration can be specified in milliseconds (ms), seconds (s), minutes (m), hours
A value without a suffix is seconds.
Examples: 120s, 50ms, 5m, 1h.
+HashMethodKey
+(string alias)
+
+
+(Appears on:
+UpstreamSettingsPolicySpec)
+
+
+
HashMethodKey defines the key used for hash-based load balancing methods.
+The key must be a valid NGINX variable name starting with ‘$’ followed by lowercase
+letters and underscores only.
+For a full list of NGINX variables,
+refer to: https://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables
+
+LoadBalancingType
+(string alias)
+
+
+(Appears on:
+UpstreamSettingsPolicySpec)
+
+
+
LoadBalancingType defines the supported load balancing methods.
+
+
+
+
+| Value |
+Description |
+
+
+"hash" |
+LoadBalancingTypeHash enables generic hash-based load balancing,
+routing requests to upstream servers based on a hash of a specified key
+HashMethodKey field must be set when this method is selected.
+Example configuration: hash $binary_remote_addr;.
+ |
+
"hash consistent" |
+LoadBalancingTypeHashConsistent enables consistent hash-based load balancing,
+which minimizes the number of keys remapped when a server is added or removed.
+HashMethodKey field must be set when this method is selected.
+Example configuration: hash $binary_remote_addr consistent;.
+ |
+
"ip_hash" |
+LoadBalancingTypeIPHash enables IP hash-based load balancing,
+ensuring requests from the same client IP are routed to the same upstream server.
+ |
+
"least_conn" |
+LoadBalancingTypeLeastConnection enables least-connections load balancing,
+routing requests to the upstream server with the fewest active connections.
+ |
+
"least_time header" |
+LoadBalancingTypeLeastTimeHeader enables least-time load balancing,
+routing requests to the upstream server with the least time to receive the response header.
+ |
+
"least_time header inflight" |
+LoadBalancingTypeLeastTimeHeaderInflight enables least-time load balancing,
+routing requests to the upstream server with the least time to receive the response header,
+considering the incomplete requests.
+ |
+
"least_time last_byte" |
+LoadBalancingTypeLeastTimeLastByte enables least-time load balancing,
+routing requests to the upstream server with the least time to receive the full response.
+ |
+
"least_time last_byte inflight" |
+LoadBalancingTypeLeastTimeLastByteInflight enables least-time load balancing,
+routing requests to the upstream server with the least time to receive the full response,
+considering the incomplete requests.
+ |
+
"random" |
+LoadBalancingTypeRandom enables random load balancing,
+routing requests to upstream servers in a random manner.
+ |
+
"random two" |
+LoadBalancingTypeRandomTwo enables a variation of random load balancing
+that randomly selects two servers and forwards traffic to one of them.
+The default method is least_conn which passes a request to a server with the least number of active connections.
+ |
+
"random two least_conn" |
+LoadBalancingTypeRandomTwoLeastConnection enables a variation of least-connections
+balancing that randomly selects two servers and forwards traffic to the one with
+fewer active connections.
+ |
+
"random two least_time=header" |
+LoadBalancingTypeRandomTwoLeastTimeHeader enables a variation of least-time load balancing
+that randomly selects two servers and forwards traffic to the one with the least
+time to receive the response header.
+ |
+
"random two least_time=last_byte" |
+LoadBalancingTypeRandomTwoLeastTimeLastByte enables a variation of least-time load balancing
+that randomly selects two servers and forwards traffic to the one with the least time
+to receive the full response.
+ |
+
"round_robin" |
+LoadBalancingTypeRoundRobin enables round-robin load balancing,
+distributing requests evenly across all upstream servers.
+ |
+
+
Logging
@@ -1085,55 +1105,6 @@ Logging
-ObservabilityPolicySpec
-
-
-
-(Appears on:
-ObservabilityPolicy)
-
-
-
ObservabilityPolicySpec defines the desired state of the ObservabilityPolicy.
-
-
Size
(string alias)
@@ -1314,7 +1285,6 @@ and the status of the SnippetsFilter with respect to each controller.
(Appears on:
-Tracing,
Telemetry,
Tracing)
@@ -1355,154 +1325,6 @@ Format: must have all ‘“’ escaped and must not contain any &ls
-TraceContext
-(string alias)
-
-
-(Appears on:
-Tracing)
-
-
-
TraceContext specifies how to propagate traceparent/tracestate headers.
-
-
-
-
-| Value |
-Description |
-
-
-"extract" |
-TraceContextExtract uses an existing trace context from the request, so that the identifiers
-of a trace and the parent span are inherited from the incoming request.
- |
-
"ignore" |
-TraceContextIgnore skips context headers processing.
- |
-
"inject" |
-TraceContextInject adds a new context to the request, overwriting existing headers, if any.
- |
-
"propagate" |
-TraceContextPropagate updates the existing context (combines extract and inject).
- |
-
-
-TraceStrategy
-(string alias)
-
-
-(Appears on:
-Tracing)
-
-
-
TraceStrategy defines the tracing strategy.
-
-
-
-
-| Value |
-Description |
-
-
-"parent" |
-TraceStrategyParent enables tracing and only records spans if the parent span was sampled.
- |
-
"ratio" |
-TraceStrategyRatio enables ratio-based tracing, defaulting to 100% sampling rate.
- |
-
-
-Tracing
-
-
-
-(Appears on:
-ObservabilityPolicySpec)
-
-
-
Tracing allows for enabling and configuring OpenTelemetry tracing.
-
-
-
-
-| Field |
-Description |
-
-
-
-
-
-strategy
-
-
-TraceStrategy
-
-
- |
-
- Strategy defines if tracing is ratio-based or parent-based.
- |
-
-
-
-ratio
-
-int32
-
- |
-
-(Optional)
- Ratio is the percentage of traffic that should be sampled. Integer from 0 to 100.
-By default, 100% of http requests are traced. Not applicable for parent-based tracing.
-If ratio is set to 0, tracing is disabled.
- |
-
-
-
-context
-
-
-TraceContext
-
-
- |
-
-(Optional)
- Context specifies how to propagate traceparent/tracestate headers.
-Default: https://nginx.org/en/docs/ngx_otel_module.html#otel_trace_context
- |
-
-
-
-spanName
-
-string
-
- |
-
-(Optional)
- SpanName defines the name of the Otel span. By default is the name of the location for a request.
-If specified, applies to all locations that are created for a route.
-Format: must have all ‘“’ escaped and must not contain any ‘$’ or end with an unescaped ‘\’
-Examples of invalid names: some-$value, quoted-“value”-name, unescaped
- |
-
-
-
-spanAttributes
-
-
-[]SpanAttribute
-
-
- |
-
-(Optional)
- SpanAttributes are custom key/value attributes that are added to each span.
- |
-
-
-
UpstreamKeepAlive
@@ -1635,10 +1457,41 @@ UpstreamKeepAlive
+loadBalancingMethod
+
+
+LoadBalancingType
+
+
+ |
+
+(Optional)
+ LoadBalancingMethod specifies the load balancing algorithm to be used for the upstream.
+If not specified, NGINX Gateway Fabric defaults to random two least_conn,
+which differs from the standard NGINX default round-robin.
+ |
+
+
+
+hashMethodKey
+
+
+HashMethodKey
+
+
+ |
+
+(Optional)
+ HashMethodKey defines the key used for hash-based load balancing methods.
+This field is required when LoadBalancingMethod is set to hash or hash consistent.
+ |
+
+
+
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
|
@@ -1969,8 +1822,8 @@ Tracing
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
|
@@ -1989,8 +1842,8 @@ be unique across all targetRef entries in the ObservabilityPolicy.
status
-
-sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus
+
+sigs.k8s.io/gateway-api/apis/v1.PolicyStatus
|
@@ -2847,6 +2700,53 @@ bool
+NginxAccessLog
+
+
+
+(Appears on:
+NginxLogging)
+
+
+
NginxAccessLog defines the configuration for an NGINX access log.
+
+
+
+
+| Field |
+Description |
+
+
+
+
+
+disable
+
+bool
+
+ |
+
+(Optional)
+ Disable turns off access logging when set to true.
+ |
+
+
+
+format
+
+string
+
+ |
+
+(Optional)
+ Format specifies the custom log format string.
+If not specified, NGINX default ‘combined’ format is used.
+For now only path /dev/stdout can be used.
+See https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
+ |
+
+
+
NginxErrorLogLevel
(string alias)
@@ -2940,6 +2840,21 @@ AgentLogLevel
re-roll of the NGINX deployment.
+
+
+accessLog
+
+
+NginxAccessLog
+
+
+ |
+
+(Optional)
+ AccessLog defines the access log settings, including format itself and disabling option.
+For now only path /dev/stdout can be used.
+ |
+
NginxPlus
@@ -3303,8 +3218,8 @@ Tracing
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
|
diff --git a/content/ngf/traffic-management/session-persistence.md b/content/ngf/traffic-management/session-persistence.md
new file mode 100644
index 000000000..940fb553b
--- /dev/null
+++ b/content/ngf/traffic-management/session-persistence.md
@@ -0,0 +1,549 @@
+---
+title: Session Persistence
+weight: 1000
+toc: true
+nd-content-type: how-to
+nd-product: FABRIC
+nd-docs:
+---
+
+Learn how to configure session persistence using NGINX Gateway Fabric.
+
+## Overview
+
+In this guide, you’ll learn how to configure session persistence for your application. Session persistence ensures that multiple requests from the same client are consistently routed to the same backend Pod. This is useful when your application maintains in-memory state (for example, shopping carts or user sessions). NGINX Gateway Fabric supports configuring session persistence via `UpstreamSettingsPolicy` resource or directly on `HTTPRoute` and `GRPCRoute` resources. For NGINX OSS users, using the `ip_hash` load-balancing method provides basic session affinity by routing requests from the same client IP to the same backend Pod. For NGINX Plus users, the `sticky cookie` directive can be used to provide true session persistence based on a generated session cookie.
+In this guide, you will deploy three applications:
+
+- An application configured with `ip_hash` load-balancing method.
+- An application configured with cookie–based session persistence.
+- A regular application with default load-balancing.
+
+These applications will showcase the benefits of session persistence for stateful workloads.
+
+The NGINX directives discussed in this guide are:
+
+- [`ip_hash`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash)
+- [`sticky cookie`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#sticky)
+
+## Note
+
+{{< call-out "important" >}}`SessionPersistence` is only available for [NGINX Plus]({{< ref "/ngf/install/nginx-plus.md" >}}) users, with alternatives provided for NGINX OSS users. It is a Gateway API field from the experimental release channel and is subject to change. {{< /call-out >}}
+
+{{< include "/ngf/installation/install-gateway-api-experimental-features.md" >}}
+
+## Before you begin
+
+- [Install]({{< ref "/ngf/install/" >}}) NGINX Gateway Fabric with experimental features enabled.
+
+## Setup
+
+Create the `coffee`, `tea` and `latte` applications:
+
+```yaml
+kubectl apply -f - <
+pod/coffee-5b9c74f9d9-7gfwn 1/1 Running 0 3h19m 10.244.0.94 kind-control-plane
+pod/gateway-nginx-5c9f576669-tc258 1/1 Running 0 3h19m 10.244.0.99 kind-control-plane
+pod/latte-d5f64f67f-9t2j5 1/1 Running 0 3h19m 10.244.0.96 kind-control-plane
+pod/latte-d5f64f67f-drwc6 1/1 Running 0 3h19m 10.244.0.98 kind-control-plane
+pod/tea-859766c68c-cnb8n 1/1 Running 0 3h19m 10.244.0.93 kind-control-plane
+pod/tea-859766c68c-kttkb 1/1 Running 0 3h19m 10.244.0.97 kind-control-plane
+
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
+service/coffee ClusterIP 10.96.169.1 80/TCP 3h19m app=coffee
+service/gateway-nginx ClusterIP 10.96.15.149 80/TCP 3h19m app.kubernetes.io/instance=nginx-gateway,app.kubernetes.io/managed-by=nginx-gateway-nginx,app.kubernetes.io/name=gateway-nginx,gateway.networking.k8s.io/gateway-name=gateway
+service/latte ClusterIP 10.96.42.39 80/TCP 3h19m app=latte
+service/tea ClusterIP 10.96.81.103 80/TCP 3h19m app=tea
+```
+
+Create a Gateway:
+
+```yaml
+kubectl apply -f - <
+```
+
+Lookup the name of the NGINX pod and save into shell variable:
+
+```text
+NGINX_POD_NAME=
+```
+
+{{< call-out "note" >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /call-out >}}
+
+## Session Persistence Methods
+
+### Session Persistence with NGINX OSS
+
+In this section, you’ll configure a basic `coffee` HTTPRoute that routes traffic to the `coffee` Service. You’ll then attach an `UpstreamSettingsPolicy` to change the load-balancing method for that upstream to showcase session affinity behavior. NGINX hashes the client IP to select an upstream server, so requests from the same IP are routed to the same upstream as long as it is available. Session affinity quality with `ip_hash` depends on NGINX seeing the real client IP. In environments with external load balancers or proxies, operators must ensure appropriate `real_ip_header/set_real_ip_from` configuration so that `$remote_addr` reflects the end-user address otherwise, stickiness will be determined by the address of the front-end proxy rather than the actual client. Refer to this [guide]({{< ref "/ngf/how-to/data-plane-configuration/#configure-proxy-protocol-and-rewriteclientip-settings" >}}) for more information on configuring these fields.
+
+To create an HTTPRoute for the `coffee` service, copy and paste the following into your terminal:
+
+```yaml
+kubectl apply -f - < $NGINX_POD_NAME -- nginx -T
+```
+
+You should see the `ip_hash` directive on the `coffee` upstreams:
+
+```text
+upstream default_coffee_80 {
+ ip_hash;
+ zone default_coffee_80 1m;
+ state /var/lib/nginx/state/default_coffee_80.conf;
+}
+```
+
+In this example, the `coffee` Service currently has two backend Pods with IPs `10.244.0.95` and `10.244.0.94`. We’ll send five requests to the `/coffee` endpoint and observe that the responses consistently come from the same backend Pod, demonstrating session affinity.
+
+```bash
+for i in $(seq 5); do
+ echo "Request #$i"
+ curl -s -H "Host: cafe.example.com" \
+ http://localhost:8080/coffee \
+ | grep -E 'Server (address|name)'
+ echo
+done
+```
+
+You will observe that all responses are served by the Pod `coffee-5b9c74f9d9-7gfwn` with IP `10.244.0.94:8080`:
+
+```text
+Request #1
+Server address: 10.244.0.94:8080
+Server name: coffee-5b9c74f9d9-7gfwn
+
+Request #2
+Server address: 10.244.0.94:8080
+Server name: coffee-5b9c74f9d9-7gfwn
+
+Request #3
+Server address: 10.244.0.94:8080
+Server name: coffee-5b9c74f9d9-7gfwn
+
+Request #4
+Server address: 10.244.0.94:8080
+Server name: coffee-5b9c74f9d9-7gfwn
+
+Request #5
+Server address: 10.244.0.94:8080
+Server name: coffee-5b9c74f9d9-7gfwn
+```
+
+### Session Persistence with NGINX Plus
+
+You can configure session persistence by specifying the `sessionPersistence` field on an `HTTPRouteRule` or `GRPCRouteRule`. This configuration is translated to the `sticky cookie` directive on the NGINX data plane. In this guide, you’ll create a `tea` HTTPRoute with `sessionPersistence` configured at the rule level and then verify how traffic behaves when the route has multiple backend Pods.
+
+```yaml
+kubectl apply -f - < $NGINX_POD_NAME -- nginx -T
+```
+
+```text
+upstream default_tea_80_tea_default_0 {
+ random two least_conn;
+ zone default_tea_80_tea_default_0 1m;
+ sticky cookie cookie-tea expires=24h path=/tea;
+ state /var/lib/nginx/state/default_tea_80.conf;
+}
+```
+
+In this example, the `tea` `Service` has two backend Pods with IPs `10.244.0.93` and `10.244.0.97`. We’ll send five requests to the `/tea` endpoint and observe that all responses are served by the same backend Pod, demonstrating cookie-based session persistence.
+
+First, send a request to `/tea` and store the session cookie:
+
+```bash
+curl -v -c /tmp/tea-cookies.txt \
+ -H "Host: cafe.example.com" \
+ http://localhost:8080/tea
+```
+
+You’ll see a cookie being set, for example:
+
+```text
+* Added cookie cookie-tea="2878e97a4c7a8406b791aa0bd0b2f145" for domain cafe.example.com, path /tea, expire 1765417195
+< Set-Cookie: cookie-tea=2878e97a4c7a8406b791aa0bd0b2f145; expires=Thu, 11-Dec-25 01:39:55 GMT; max-age=86400; path=/tea
+```
+
+Next, send five requests using the stored cookie:
+
+```bash
+for i in $(seq 5); do
+ echo "Request #$i"
+ curl -s -b /tmp/tea-cookies.txt \
+ -H "Host: cafe.example.com" \
+ http://localhost:8080/tea \
+ | grep -E 'Server (address|name)'
+ echo
+done
+```
+
+All responses are served by the same backend Pod, `tea-859766c68c-cnb8n` with IP `10.244.0.93:8080`, confirming session persistence:
+
+```text
+Request #1
+Server address: 10.244.0.93:8080
+Server name: tea-859766c68c-cnb8n
+
+Request #2
+Server address: 10.244.0.93:8080
+Server name: tea-859766c68c-cnb8n
+
+Request #3
+Server address: 10.244.0.93:8080
+Server name: tea-859766c68c-cnb8n
+
+Request #4
+Server address: 10.244.0.93:8080
+Server name: tea-859766c68c-cnb8n
+
+Request #5
+Server address: 10.244.0.93:8080
+Server name: tea-859766c68c-cnb8n
+```
+
+### Regular Application
+
+We’ll create routing rules for `latte` application without any session affinity or persistence settings and then verify how the traffic behaves.
+
+Let’s create the `latte` HTTPRoute:
+
+```yaml
+kubectl apply -f - < $NGINX_POD_NAME -- nginx -T
+```
+
+```text
+upstream default_latte_80 {
+ random two least_conn;
+ zone default_latte_80 1m;
+ state /var/lib/nginx/state/default_latte_80.conf;
+}
+```
+
+In this example, the `latte` Service currently has two backend Pods with IPs `10.244.0.96` and `10.244.0.98`. We’ll send five requests to the `/latte` endpoint and observe which backend Pod serves each response to understand how a regular backend behaves without any session affinity or persistence configured.
+
+```bash
+for i in $(seq 5); do
+ echo "Request #$i"
+ curl -s -H "Host: cafe.example.com" \
+ http://localhost:8080/latte \
+ | grep -E 'Server (address|name)'
+ echo
+done
+```
+
+You will see responses coming from both backend Pods, for example:
+
+```text
+Request #1
+Server address: 10.244.0.98:8080
+Server name: latte-d5f64f67f-drwc6
+
+Request #2
+Server address: 10.244.0.96:8080
+Server name: latte-d5f64f67f-9t2j5
+
+Request #3
+Server address: 10.244.0.98:8080
+Server name: latte-d5f64f67f-drwc6
+
+Request #4
+Server address: 10.244.0.98:8080
+Server name: latte-d5f64f67f-drwc6
+
+Request #5
+Server address: 10.244.0.96:8080
+Server name: latte-d5f64f67f-9t2j5
+```
+
+Because there is no session persistence configured for `latte`, traffic is distributed across both backend Pods according to the default load-balancing method, and requests from the same client are not guaranteed to hit the same Pod.
+
+## Further reading
+
+- [Session Persistence](https://gateway-api.sigs.k8s.io/reference/spec/?h=sessionpersistence#sessionpersistence).
+- [API reference]({{< ref "/ngf/reference/api.md" >}}): all configuration fields for the `UpstreamSettingsPolicy` API.
\ No newline at end of file
diff --git a/content/ngf/traffic-management/upstream-settings.md b/content/ngf/traffic-management/upstream-settings.md
index b27fe738d..f7772ad62 100644
--- a/content/ngf/traffic-management/upstream-settings.md
+++ b/content/ngf/traffic-management/upstream-settings.md
@@ -19,14 +19,21 @@ The settings in `UpstreamSettingsPolicy` correspond to the following NGINX direc
- [`keepalive`]()
- [`keepalive_requests`]()
- [`keepalive_time`]()
-- [`keepalive_timeout`]()
+- [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout)
+- [`random`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#random)
+- [`least_conn`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#least_conn)
+- [`least_time`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#least_time)
+- [`upstream`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream)
+- [`ip_hash`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash)
+- [`hash`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash)
+- [`variables`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables)
`UpstreamSettingsPolicy` is a [Direct Policy Attachment](https://gateway-api.sigs.k8s.io/reference/policy-attachment/) that can be applied to one or more services in the same namespace as the policy.
`UpstreamSettingsPolicies` can only be applied to HTTP or gRPC services, in other words, services that are referenced by an HTTPRoute or GRPCRoute.
See the [custom policies]({{< ref "/ngf/overview/custom-policies.md" >}}) document for more information on policies.
-This guide will show you how to use the `UpstreamSettingsPolicy` API to configure the upstream zone size and keepalives for your applications.
+This guide will show you how to use the `UpstreamSettingsPolicy` API to configure the load balancing method, upstream zone size and keepalives for your applications.
For all the possible configuration options for `UpstreamSettingsPolicy`, see the [API reference]({{< ref "/ngf/reference/api.md" >}}).
@@ -237,6 +244,100 @@ Server name: tea-76c7c85bbd-cf8nz
---
+## Configure load balancing methods
+
+You can use `UpstreamSettingsPolicy` to configure the load balancing method for the `coffee` and `tea` applications. In this example, the `coffee` service uses the `random two least_time=header` method, and the `tea` service uses the `hash consistent` method with `$upstream_addr` as the hash key.
+
+{{< call-out "note" >}} You need to specify an NGINX [variable](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables) as `hashMethodKey` when using load balancing methods `hash` and `hash consistent` .{{< /call-out >}}
+
+Create the following `UpstreamSettingsPolicy` resources:
+
+```yaml
+kubectl apply -f - < $NGINX_POD_NAME -- nginx -T
+```
+
+You should see the `random two least_time=header` directive on the `coffee` upstreams and `hash $upstream_addr consistent` in the `tea` upstream:
+
+```text
+upstream default_coffee_80 {
+ random two least_time=header;
+ zone default_coffee_80 1m;
+ state /var/lib/nginx/state/default_coffee_80.conf;
+}
+
+upstream default_tea_80 {
+ hash $upstream_addr consistent;
+ zone default_tea_80 1m;
+ state /var/lib/nginx/state/default_tea_80.conf;
+}
+```
+
+{{< call-out "note" >}}
+NGINX Open Source supports the following load-balancing methods: `round_robin`, `least_conn`, `ip_hash`, `hash`, `hash consistent`, `random`, `random two`, and `random two least_conn`.
+NGINX Plus supports all of the methods available in NGINX Open Source, and adds the following methods: `random two least_time=header`, `random two least_time=last_byte`, `least_time header`, `least_time last_byte`, `least_time header inflight`, and `least_time last_byte inflight`.
+{{< /call-out >}}
+
## Configure upstream zone size
To set the upstream zone size to 1 megabyte for both the `coffee` and `tea` services, create the following `UpstreamSettingsPolicy`:
From 946cf7fe0bf9a3f90fc5e79ca7b594b51f792344 Mon Sep 17 00:00:00 2001
From: salonichf5 <146118978+salonichf5@users.noreply.github.com>
Date: Wed, 10 Dec 2025 14:24:53 -0700
Subject: [PATCH 2/4] update based on reviews
---
.../ngf/overview/gateway-api-compatibility.md | 4 +--
.../traffic-management/session-persistence.md | 25 +++++++++++++------
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/content/ngf/overview/gateway-api-compatibility.md b/content/ngf/overview/gateway-api-compatibility.md
index 29131ab8e..33e2dd260 100644
--- a/content/ngf/overview/gateway-api-compatibility.md
+++ b/content/ngf/overview/gateway-api-compatibility.md
@@ -176,7 +176,7 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
- `name`: Not supported.
- `timeouts`: Not supported.
- `retry`: Not supported.
- - `sessionPersistence`: Supported.
+ - `sessionPersistence`: Supported (NGINX Plus).
- `status`
- `parents`
- `parentRef`: Supported.
@@ -226,7 +226,7 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
- `extensionRef`: Supported for SnippetsFilters.
- `backendRefs`: Partially supported. Backend ref `filters` are not supported.
- `name`: Not supported.
- - `sessionPersistence`: Supported.
+ - `sessionPersistence`: Supported (NGINX Plus).
- `status`
- `parents`
- `parentRef`: Supported.
diff --git a/content/ngf/traffic-management/session-persistence.md b/content/ngf/traffic-management/session-persistence.md
index 940fb553b..46abe7b45 100644
--- a/content/ngf/traffic-management/session-persistence.md
+++ b/content/ngf/traffic-management/session-persistence.md
@@ -11,11 +11,11 @@ Learn how to configure session persistence using NGINX Gateway Fabric.
## Overview
-In this guide, you’ll learn how to configure session persistence for your application. Session persistence ensures that multiple requests from the same client are consistently routed to the same backend Pod. This is useful when your application maintains in-memory state (for example, shopping carts or user sessions). NGINX Gateway Fabric supports configuring session persistence via `UpstreamSettingsPolicy` resource or directly on `HTTPRoute` and `GRPCRoute` resources. For NGINX OSS users, using the `ip_hash` load-balancing method provides basic session affinity by routing requests from the same client IP to the same backend Pod. For NGINX Plus users, the `sticky cookie` directive can be used to provide true session persistence based on a generated session cookie.
+In this guide, you’ll learn how to configure session persistence for your application. Session persistence ensures that multiple requests from the same client are consistently routed to the same backend Pod. This is useful when your application maintains in-memory state (for example, shopping carts or user sessions). NGINX Gateway Fabric supports configuring session persistence via `UpstreamSettingsPolicy` resource or directly on `HTTPRoute` and `GRPCRoute` resources. For NGINX OSS users, using the `ip_hash` load-balancing method provides basic session affinity by routing requests from the same client IP to the same backend Pod. For NGINX Plus users, cookie-based session persistence can be configured using the `sessionPersistence` field in a Route.
In this guide, you will deploy three applications:
- An application configured with `ip_hash` load-balancing method.
-- An application configured with cookie–based session persistence.
+- An application configured with cookie–based session persistence (if you have access to NGINX Plus).
- A regular application with default load-balancing.
These applications will showcase the benefits of session persistence for stateful workloads.
@@ -152,7 +152,6 @@ kubectl get all -o wide -n default
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/coffee-5b9c74f9d9-2zlqq 1/1 Running 0 3h19m 10.244.0.95 kind-control-plane
pod/coffee-5b9c74f9d9-7gfwn 1/1 Running 0 3h19m 10.244.0.94 kind-control-plane
-pod/gateway-nginx-5c9f576669-tc258 1/1 Running 0 3h19m 10.244.0.99 kind-control-plane
pod/latte-d5f64f67f-9t2j5 1/1 Running 0 3h19m 10.244.0.96 kind-control-plane
pod/latte-d5f64f67f-drwc6 1/1 Running 0 3h19m 10.244.0.98 kind-control-plane
pod/tea-859766c68c-cnb8n 1/1 Running 0 3h19m 10.244.0.93 kind-control-plane
@@ -160,7 +159,6 @@ pod/tea-859766c68c-kttkb 1/1 Running 0 3h19m 10.244
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/coffee ClusterIP 10.96.169.1 80/TCP 3h19m app=coffee
-service/gateway-nginx ClusterIP 10.96.15.149 80/TCP 3h19m app.kubernetes.io/instance=nginx-gateway,app.kubernetes.io/managed-by=nginx-gateway-nginx,app.kubernetes.io/name=gateway-nginx,gateway.networking.k8s.io/gateway-name=gateway
service/latte ClusterIP 10.96.42.39 80/TCP 3h19m app=latte
service/tea ClusterIP 10.96.81.103 80/TCP 3h19m app=tea
```
@@ -183,7 +181,18 @@ spec:
EOF
```
-After creating the Gateway resource, NGINX Gateway Fabric will provision an NGINX Pod and Service fronting it to route traffic. Save the public IP address and port of the NGINX Service into shell variables:
+After creating the Gateway resource, NGINX Gateway Fabric will provision an NGINX Pod and Service fronting it to route traffic. Verify the gateway is created:
+
+```bash
+kubectl get gateways.gateway.networking.k8s.io gateway
+```
+
+```text
+NAME CLASS ADDRESS PROGRAMMED AGE
+gateway nginx 10.96.15.149 True 23h
+```
+
+Save the public IP address and port of the NGINX Service into shell variables:
```text
GW_IP=XXX.YYY.ZZZ.III
@@ -202,7 +211,7 @@ NGINX_POD_NAME=
### Session Persistence with NGINX OSS
-In this section, you’ll configure a basic `coffee` HTTPRoute that routes traffic to the `coffee` Service. You’ll then attach an `UpstreamSettingsPolicy` to change the load-balancing method for that upstream to showcase session affinity behavior. NGINX hashes the client IP to select an upstream server, so requests from the same IP are routed to the same upstream as long as it is available. Session affinity quality with `ip_hash` depends on NGINX seeing the real client IP. In environments with external load balancers or proxies, operators must ensure appropriate `real_ip_header/set_real_ip_from` configuration so that `$remote_addr` reflects the end-user address otherwise, stickiness will be determined by the address of the front-end proxy rather than the actual client. Refer to this [guide]({{< ref "/ngf/how-to/data-plane-configuration/#configure-proxy-protocol-and-rewriteclientip-settings" >}}) for more information on configuring these fields.
+In this section, you’ll configure a basic `coffee` HTTPRoute that routes traffic to the `coffee` Service. You’ll then attach an `UpstreamSettingsPolicy` to change the load-balancing method for that upstream to showcase session affinity behavior. NGINX hashes the client IP to select an upstream server, so requests from the same IP are routed to the same upstream as long as it is available. Session affinity quality with `ip_hash` depends on NGINX seeing the real client IP. In environments with external load balancers or proxies, operators must ensure appropriate `real_ip_header/set_real_ip_from` configuration so that `$remote_addr` reflects the end-user address otherwise, stickiness will be determined by the address of the front-end proxy rather than the actual client.
To create an HTTPRoute for the `coffee` service, copy and paste the following into your terminal:
@@ -250,7 +259,7 @@ Status:
Controller Name: gateway.nginx.org/nginx-gateway-controller
```
-Now, let’s create an `UpstreamSettingsPolicy` targeting the `coffee` Service to change the load-balancing method for its upstreams:
+Now, let’s create an `UpstreamSettingsPolicy` targeting the `coffee` Service to change the load-balancing method for its upstream:
```yaml
kubectl apply -f - < $NGINX_POD_NAME -- nginx -T
```
-You should see the `ip_hash` directive on the `coffee` upstreams:
+You should see the `ip_hash` directive on the `coffee` upstream:
```text
upstream default_coffee_80 {
From c4e40e96eb179f1cb5ca7d4f825ae6f0dcfa7050 Mon Sep 17 00:00:00 2001
From: salonichf5 <146118978+salonichf5@users.noreply.github.com>
Date: Wed, 10 Dec 2025 19:57:14 -0700
Subject: [PATCH 3/4] remove api.md changes
---
content/ngf/reference/api.md | 569 ++++++++++++++++++++---------------
1 file changed, 327 insertions(+), 242 deletions(-)
diff --git a/content/ngf/reference/api.md b/content/ngf/reference/api.md
index ea994b670..565577009 100644
--- a/content/ngf/reference/api.md
+++ b/content/ngf/reference/api.md
@@ -27,6 +27,8 @@ Resource Types:
UpstreamSettingsPolicy
@@ -123,8 +125,8 @@ ClientKeepAlive
targetRef
-
-sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
+
+sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
|
@@ -141,8 +143,8 @@ Support: Gateway, HTTPRoute, GRPCRoute.
status
-
-sigs.k8s.io/gateway-api/apis/v1.PolicyStatus
+
+sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus
|
@@ -243,6 +245,114 @@ NginxGatewayStatus
+ObservabilityPolicy
+
+
+
+
ObservabilityPolicy is a Direct Attached Policy. It provides a way to configure observability settings for
+the NGINX Gateway Fabric data plane. Used in conjunction with the NginxProxy CRD that is attached to the
+GatewayClass parametersRef.
+
+
SnippetsFilter
@@ -430,41 +540,10 @@ UpstreamKeepAlive
-loadBalancingMethod
-
-
-LoadBalancingType
-
-
- |
-
-(Optional)
- LoadBalancingMethod specifies the load balancing algorithm to be used for the upstream.
-If not specified, NGINX Gateway Fabric defaults to random two least_conn,
-which differs from the standard NGINX default round-robin.
- |
-
-
-
-hashMethodKey
-
-
-HashMethodKey
-
-
- |
-
-(Optional)
- HashMethodKey defines the key used for hash-based load balancing methods.
-This field is required when LoadBalancingMethod is set to hash or hash consistent.
- |
-
-
-
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
|
@@ -482,8 +561,8 @@ Support: Service
status
-
-sigs.k8s.io/gateway-api/apis/v1.PolicyStatus
+
+sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus
|
@@ -715,8 +794,8 @@ ClientKeepAlive
targetRef
-
-sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
+
+sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
|
@@ -829,105 +908,6 @@ Duration can be specified in milliseconds (ms), seconds (s), minutes (m), hours
A value without a suffix is seconds.
Examples: 120s, 50ms, 5m, 1h.
-HashMethodKey
-(string alias)
-
-
-(Appears on:
-UpstreamSettingsPolicySpec)
-
-
-
HashMethodKey defines the key used for hash-based load balancing methods.
-The key must be a valid NGINX variable name starting with ‘$’ followed by lowercase
-letters and underscores only.
-For a full list of NGINX variables,
-refer to: https://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables
-
-LoadBalancingType
-(string alias)
-
-
-(Appears on:
-UpstreamSettingsPolicySpec)
-
-
-
LoadBalancingType defines the supported load balancing methods.
-
-
-
-
-| Value |
-Description |
-
-
-"hash" |
-LoadBalancingTypeHash enables generic hash-based load balancing,
-routing requests to upstream servers based on a hash of a specified key
-HashMethodKey field must be set when this method is selected.
-Example configuration: hash $binary_remote_addr;.
- |
-
"hash consistent" |
-LoadBalancingTypeHashConsistent enables consistent hash-based load balancing,
-which minimizes the number of keys remapped when a server is added or removed.
-HashMethodKey field must be set when this method is selected.
-Example configuration: hash $binary_remote_addr consistent;.
- |
-
"ip_hash" |
-LoadBalancingTypeIPHash enables IP hash-based load balancing,
-ensuring requests from the same client IP are routed to the same upstream server.
- |
-
"least_conn" |
-LoadBalancingTypeLeastConnection enables least-connections load balancing,
-routing requests to the upstream server with the fewest active connections.
- |
-
"least_time header" |
-LoadBalancingTypeLeastTimeHeader enables least-time load balancing,
-routing requests to the upstream server with the least time to receive the response header.
- |
-
"least_time header inflight" |
-LoadBalancingTypeLeastTimeHeaderInflight enables least-time load balancing,
-routing requests to the upstream server with the least time to receive the response header,
-considering the incomplete requests.
- |
-
"least_time last_byte" |
-LoadBalancingTypeLeastTimeLastByte enables least-time load balancing,
-routing requests to the upstream server with the least time to receive the full response.
- |
-
"least_time last_byte inflight" |
-LoadBalancingTypeLeastTimeLastByteInflight enables least-time load balancing,
-routing requests to the upstream server with the least time to receive the full response,
-considering the incomplete requests.
- |
-
"random" |
-LoadBalancingTypeRandom enables random load balancing,
-routing requests to upstream servers in a random manner.
- |
-
"random two" |
-LoadBalancingTypeRandomTwo enables a variation of random load balancing
-that randomly selects two servers and forwards traffic to one of them.
-The default method is least_conn which passes a request to a server with the least number of active connections.
- |
-
"random two least_conn" |
-LoadBalancingTypeRandomTwoLeastConnection enables a variation of least-connections
-balancing that randomly selects two servers and forwards traffic to the one with
-fewer active connections.
- |
-
"random two least_time=header" |
-LoadBalancingTypeRandomTwoLeastTimeHeader enables a variation of least-time load balancing
-that randomly selects two servers and forwards traffic to the one with the least
-time to receive the response header.
- |
-
"random two least_time=last_byte" |
-LoadBalancingTypeRandomTwoLeastTimeLastByte enables a variation of least-time load balancing
-that randomly selects two servers and forwards traffic to the one with the least time
-to receive the full response.
- |
-
"round_robin" |
-LoadBalancingTypeRoundRobin enables round-robin load balancing,
-distributing requests evenly across all upstream servers.
- |
-
-
Logging
@@ -1105,6 +1085,55 @@ Logging
+ObservabilityPolicySpec
+
+
+
+(Appears on:
+ObservabilityPolicy)
+
+
+
ObservabilityPolicySpec defines the desired state of the ObservabilityPolicy.
+
+
Size
(string alias)
@@ -1285,6 +1314,7 @@ and the status of the SnippetsFilter with respect to each controller.
(Appears on:
+Tracing,
Telemetry,
Tracing)
@@ -1325,6 +1355,154 @@ Format: must have all ‘“’ escaped and must not contain any &ls
+TraceContext
+(string alias)
+
+
+(Appears on:
+Tracing)
+
+
+
TraceContext specifies how to propagate traceparent/tracestate headers.
+
+
+
+
+| Value |
+Description |
+
+
+"extract" |
+TraceContextExtract uses an existing trace context from the request, so that the identifiers
+of a trace and the parent span are inherited from the incoming request.
+ |
+
"ignore" |
+TraceContextIgnore skips context headers processing.
+ |
+
"inject" |
+TraceContextInject adds a new context to the request, overwriting existing headers, if any.
+ |
+
"propagate" |
+TraceContextPropagate updates the existing context (combines extract and inject).
+ |
+
+
+TraceStrategy
+(string alias)
+
+
+(Appears on:
+Tracing)
+
+
+
TraceStrategy defines the tracing strategy.
+
+
+
+
+| Value |
+Description |
+
+
+"parent" |
+TraceStrategyParent enables tracing and only records spans if the parent span was sampled.
+ |
+
"ratio" |
+TraceStrategyRatio enables ratio-based tracing, defaulting to 100% sampling rate.
+ |
+
+
+Tracing
+
+
+
+(Appears on:
+ObservabilityPolicySpec)
+
+
+
Tracing allows for enabling and configuring OpenTelemetry tracing.
+
+
+
+
+| Field |
+Description |
+
+
+
+
+
+strategy
+
+
+TraceStrategy
+
+
+ |
+
+ Strategy defines if tracing is ratio-based or parent-based.
+ |
+
+
+
+ratio
+
+int32
+
+ |
+
+(Optional)
+ Ratio is the percentage of traffic that should be sampled. Integer from 0 to 100.
+By default, 100% of http requests are traced. Not applicable for parent-based tracing.
+If ratio is set to 0, tracing is disabled.
+ |
+
+
+
+context
+
+
+TraceContext
+
+
+ |
+
+(Optional)
+ Context specifies how to propagate traceparent/tracestate headers.
+Default: https://nginx.org/en/docs/ngx_otel_module.html#otel_trace_context
+ |
+
+
+
+spanName
+
+string
+
+ |
+
+(Optional)
+ SpanName defines the name of the Otel span. By default is the name of the location for a request.
+If specified, applies to all locations that are created for a route.
+Format: must have all ‘“’ escaped and must not contain any ‘$’ or end with an unescaped ‘\’
+Examples of invalid names: some-$value, quoted-“value”-name, unescaped
+ |
+
+
+
+spanAttributes
+
+
+[]SpanAttribute
+
+
+ |
+
+(Optional)
+ SpanAttributes are custom key/value attributes that are added to each span.
+ |
+
+
+
UpstreamKeepAlive
@@ -1457,41 +1635,10 @@ UpstreamKeepAlive
-loadBalancingMethod
-
-
-LoadBalancingType
-
-
- |
-
-(Optional)
- LoadBalancingMethod specifies the load balancing algorithm to be used for the upstream.
-If not specified, NGINX Gateway Fabric defaults to random two least_conn,
-which differs from the standard NGINX default round-robin.
- |
-
-
-
-hashMethodKey
-
-
-HashMethodKey
-
-
- |
-
-(Optional)
- HashMethodKey defines the key used for hash-based load balancing methods.
-This field is required when LoadBalancingMethod is set to hash or hash consistent.
- |
-
-
-
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
|
@@ -1822,8 +1969,8 @@ Tracing
targetRefs
-
-[]sigs.k8s.io/gateway-api/apis/v1.LocalPolicyTargetReference
+
+[]sigs.k8s.io/gateway-api/apis/v1alpha2.LocalPolicyTargetReference
|
@@ -1842,8 +1989,8 @@ be unique across all targetRef entries in the ObservabilityPolicy.
status
-
-sigs.k8s.io/gateway-api/apis/v1.PolicyStatus
+
+sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus
|
@@ -2700,53 +2847,6 @@ bool
-NginxAccessLog
-
-
-
-(Appears on:
-NginxLogging)
-
-
-
NginxAccessLog defines the configuration for an NGINX access log.
-
-
-
-
-| Field |
-Description |
-
-
-
-
-
-disable
-
-bool
-
- |
-
-(Optional)
- Disable turns off access logging when set to true.
- |
-
-
-
-format
-
-string
-
- |
-
-(Optional)
- Format specifies the custom log format string.
-If not specified, NGINX default ‘combined’ format is used.
-For now only path /dev/stdout can be used.
-See https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
- |
-
-
-
NginxErrorLogLevel
(string alias)
@@ -2840,21 +2940,6 @@ AgentLogLevel
re-roll of the NGINX deployment.
-
-
-accessLog
-
-
-NginxAccessLog
-
-
- |
-
-(Optional)
- AccessLog defines the access log settings, including format itself and disabling option.
-For now only path /dev/stdout can be used.
- |
-
Generated with gen-crd-api-reference-docs
-
+
\ No newline at end of file
From 763bd63489039f8ad5ad772f259cd705973a3b92 Mon Sep 17 00:00:00 2001
From: salonichf5 <146118978+salonichf5@users.noreply.github.com>
Date: Thu, 11 Dec 2025 10:06:36 -0700
Subject: [PATCH 4/4] update the code snippets to shell type
---
content/ngf/traffic-management/session-persistence.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/content/ngf/traffic-management/session-persistence.md b/content/ngf/traffic-management/session-persistence.md
index 46abe7b45..aaeb00aa3 100644
--- a/content/ngf/traffic-management/session-persistence.md
+++ b/content/ngf/traffic-management/session-persistence.md
@@ -183,7 +183,7 @@ EOF
After creating the Gateway resource, NGINX Gateway Fabric will provision an NGINX Pod and Service fronting it to route traffic. Verify the gateway is created:
-```bash
+```shell
kubectl get gateways.gateway.networking.k8s.io gateway
```
@@ -314,7 +314,7 @@ upstream default_coffee_80 {
In this example, the `coffee` Service currently has two backend Pods with IPs `10.244.0.95` and `10.244.0.94`. We’ll send five requests to the `/coffee` endpoint and observe that the responses consistently come from the same backend Pod, demonstrating session affinity.
-```bash
+```shell
for i in $(seq 5); do
echo "Request #$i"
curl -s -H "Host: cafe.example.com" \
@@ -421,7 +421,7 @@ In this example, the `tea` `Service` has two backend Pods with IPs `10.244.0.93`
First, send a request to `/tea` and store the session cookie:
-```bash
+```shell
curl -v -c /tmp/tea-cookies.txt \
-H "Host: cafe.example.com" \
http://localhost:8080/tea
@@ -436,7 +436,7 @@ You’ll see a cookie being set, for example:
Next, send five requests using the stored cookie:
-```bash
+```shell
for i in $(seq 5); do
echo "Request #$i"
curl -s -b /tmp/tea-cookies.txt \
@@ -516,7 +516,7 @@ upstream default_latte_80 {
In this example, the `latte` Service currently has two backend Pods with IPs `10.244.0.96` and `10.244.0.98`. We’ll send five requests to the `/latte` endpoint and observe which backend Pod serves each response to understand how a regular backend behaves without any session affinity or persistence configured.
-```bash
+```shell
for i in $(seq 5); do
echo "Request #$i"
curl -s -H "Host: cafe.example.com" \