Deploy a Sample Application with Sticky Sessions (Experimental)

Estimated reading time: 4 minutes

This topic applies to Docker Enterprise.

The Docker Enterprise platform business, including products, customers, and employees, has been acquired by Mirantis, inc., effective 13-November-2019. For more information on the acquisition and how it may affect you and your business, refer to the Docker Enterprise Customer FAQ.

Experimental features provide early access to future product functionality. These features are intended for testing and feedback only as they may change between releases without warning or can be removed entirely from a future release. Experimental features must not be used in production environments. Docker does not offer support for experimental features.


With persistent sessions, the Ingress controller can use a predetermined header or dynamically generate a HTTP header cookie for a client session to use, so that a clients requests are sent to the same back end.


This guide assumes the Deploy Sample Application tutorial was followed, with the artifacts still running on the cluster. If they are not, please go back and follow this guide.

This is specified within the Istio Object DestinationRule via a TrafficPolicy for a given host. In the following example configuration, consistentHash is chosen as the load balancing method and a cookie named “session” is used to determine the consistent hash. If incoming requests do not have the “session” cookie set, the Ingress proxy sets it for use in future requests.


A Kubernetes manifest file with an updated DestinationRule can be found here.

  1. Source a UCP Client Bundle attached to a cluster with Cluster Ingress installed.
  2. Download the sample Kubernetes manifest file.
    $ wget
  3. Deploy the Kubernetes manifest file with the new DestinationRule. This file includes the consistentHash loadBalancer policy.
    $ kubectl apply -f ingress-sticky.yaml
  4. Curl the service to view how requests are load balanced without using cookies. In this example, requests are bounced between different v1 services.
  # Public IP Address of a Worker or Manager VM in the Cluster

  # Node Port
  $ PORT=$(kubectl get service demo-service --output jsonpath='{.spec.ports[?("http")].nodePort}')

  $ for i in {1..5}; do curl -H "Host:" http://$IPADDR:$PORT/ping; done

Now curl again and inspect the headers returned from the proxy.

  $ curl -i -H "Host:" http://$IPADDR:$PORT/ping
  HTTP/1.1 200 OK
  set-cookie: session=1555389679134464956; Path=/; Expires=Wed, 17 Apr 2019 04:41:19 GMT; Max-Age=86400
  date: Tue, 16 Apr 2019 04:41:18 GMT
  content-length: 131
  content-type: text/plain; charset=utf-8
  x-envoy-upstream-service-time: 0
  set-cookie: session="d7227d32eeb0524b"; Max-Age=60; HttpOnly
  server: istio-envoy


The Ingress proxy sets a 60 second TTL cookie named session on this HTTP request. A browser or other client application can use that value in future requests.

Now curl the service again using the flags that save cookies persistently across sessions. The header information shows the session is being set, persisted across requests, and that for a given session header, the responses are coming from the same back end.

  $ for i in {1..5}; do curl -c cookie.txt -b cookie.txt -H "Host:" http://$IPADDR:$PORT/ping; done

When the HTTP uses the cookie that is set by the Ingress proxy, all requests are sent to the same back end, demo-v1-7797b7c7c8-kw6gp.

Where to to go next

ucp, cluster, ingress, kubernetes