mirror of https://github.com/docker/docs.git
interlock vip mode improvements
content management:
- rename interlock-default-mode.{png,svg} to interlock-task...
- add frontmatter and TOC
formatting:
- newline sentences for reviewability
content:
- replace default mode with task mode
- note introduced-in UCP versions
- remove websockets from unsupported. websocket upgrade routes fine
through Swarm VIP. applications that use web sockets tend to want
sticky sessions, but sticky sessions must be configured separately.
don't conflate the two.
- clarify effect on canary deployments
- general wording improvements
This commit is contained in:
Trapier Marshall
parent
c0185c8c09
commit
29c004e909
|
|
@ -1335,6 +1335,8 @@ manuals:
|
|||
path: /ee/ucp/interlock/usage/service-clusters/
|
||||
- title: Context/Path based routing
|
||||
path: /ee/ucp/interlock/usage/context/
|
||||
- title: VIP backend mode
|
||||
path: /ee/ucp/interlock/usage/interlock-vip-mode/
|
||||
- title: Service labels reference
|
||||
path: /ee/ucp/interlock/usage/labels-reference/
|
||||
- title: Layer 7 routing upgrade
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 62 KiB |
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
|
@ -1,47 +1,67 @@
|
|||
---
|
||||
title: VIP Mode
|
||||
description: Learn about the VIP backend mode for Layer 7 routing
|
||||
keywords: routing, proxy
|
||||
---
|
||||
|
||||
## VIP Mode
|
||||
VIP mode is an alternative mode of routing in which Interlock uses the Swarm service VIP as the backend IP instead of the container IPs. Traffic to the frontend route is L7 load balanced to the Swarm service VIP which L4 load balances to the backend tasks.
|
||||
|
||||
VIP mode can be useful to reduce the amount of churn in the proxy configuration, which can be advantageous in very dynamic environments. It optimizes for fewer updates to the proxy as a tradeoff for a limited feature set. Most kinds of application updates do not require a proxy configuration in VIP mode.
|
||||
VIP mode is an alternative mode of routing in which Interlock uses the Swarm service VIP as the backend IP instead of container IPs.
|
||||
Traffic to the frontend route is L7 load balanced to the Swarm service VIP which L4 load balances to backend tasks.
|
||||
VIP mode can be useful to reduce the amount of churn in Interlock proxy service configuration, which may be an advantage in highly dynamic environments.
|
||||
It optimizes for fewer proxy updates in a tradeoff for a reduced feature set.
|
||||
Most kinds of application updates do not require a configuring backends in VIP mode.
|
||||
|
||||
#### Default Routing Mode
|
||||
In the default routing mode, Interlock uses the backend container IPs to route traffic from the proxy to the container. Traffic to the frontend route is L7 load balanced directly to the service tasks. This allows for per-container routing functionality like sticky sessions. The default routing mode applies L7 routing and then sends packets directly to the container.
|
||||
#### Task Routing Mode
|
||||
|
||||
Task routing is the default Interlock behavior and the default backend mode if one is not specified.
|
||||
In task routing mode, Interlock uses backend task IPs to route traffic from the proxy to each container.
|
||||
Traffic to the frontend route is L7 load balanced directly to service tasks.
|
||||
This allows for per-container routing functionality such as sticky sessions.
|
||||
Task routing mode applies L7 routing and then sends packets directly to a container.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### VIP Routing Mode
|
||||
In VIP routing mode Interlock uses the service VIP (a persistent endpoint that exists from service creation to service deletion) for the proxy backend. VIP routing mode applies L7 routing and then sends packets to the Swarm L4 load balancer which routes traffic to service containers.
|
||||
|
||||
In VIP routing mode Interlock uses the service VIP (a persistent endpoint that exists from service creation to service deletion) as the proxy backend.
|
||||
VIP routing mode was introduced in Universal Control Plane (UCP) 3.0 version 3.0.3 and 3.1 version 3.1.2.
|
||||
VIP routing mode applies L7 routing and then sends packets to the Swarm L4 load balancer which routes traffic service containers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
While VIP mode provides endpoint stability in the face of application churn, it cannot support sticky sessions because sticky sessions depend on routing directly to container IPs.
|
||||
Sticky sessions are therefore not supported in VIP mode.
|
||||
|
||||
While VIP mode guarantees a more stable endpoint despite application churn, it does not support some features which require routing directly to the container IPs to function. The following Interlock functionality is **not** supported in VIP mode:
|
||||
|
||||
- Sticky sessions
|
||||
- Web sockets
|
||||
- Canary deployments
|
||||
Because VIP mode routes by service IP rather than by task IP it also affects the behavior of canary deployments.
|
||||
In task mode a canary service with one task next to an existing service with four tasks represents one out of five total tasks, so the canary will receive 20% of incoming requests.
|
||||
By contrast the same canary service in VIP mode will receive 50% of incoming requests, because it represents one out of two total services.
|
||||
|
||||
#### Usage
|
||||
|
||||
VIP mode can be used on a per-service basis, which means that some applications can be deployed in VIP mode, while others are deployed in default. The following label must be applied to services that use Interlock VIP mode:
|
||||
You can set the backend mode on a per-service basis, which means that some applications can be deployed in task mode, while others are deployed in VIP mode.
|
||||
The following label must be applied to services to use Interlock VIP mode:
|
||||
|
||||
```
|
||||
com.docker.lb.backend_mode=vip
|
||||
```
|
||||
|
||||
If the label is `default` or does not exist then Interlock will use the default routing mode.
|
||||
The default backend mode is `task`.
|
||||
If the label is set to `task` or the label does not exist then Interlock will use `task` routing mode.
|
||||
|
||||
In VIP mode the following non-exhaustive list of application changes will not require any proxy reconfiguration:
|
||||
In VIP mode the following non-exhaustive list of application events will not require proxy reconfiguration:
|
||||
|
||||
- Service replica increase/decrease
|
||||
- New image deployment
|
||||
- Config or secret updates
|
||||
- Add/Remove labels
|
||||
- Add/Remove environment variables
|
||||
- Rescheduling a failed application task
|
||||
- ...
|
||||
|
||||
The following two updates still require a proxy reconfiguration (because these actions will create or destroy a service VIP):
|
||||
|
||||
- Add/Remove a network to the service
|
||||
- Add/Remove a network on a service
|
||||
- Deployment/Deletion of a service
|
||||
|
|
|
|||
Loading…
Reference in New Issue