interlock vip mode: improvements

content management:
- rename interlock-default-mode.{png,svg} to interlock-task...
- add frontmatter and TOC

copy:
- simplify canary service impact description
- wording improvements
This commit is contained in:
Trapier Marshall 2019-02-05 13:42:01 -05:00
parent d84d901bf2
commit 0a0f7ff6f4
3 changed files with 17 additions and 10 deletions

View File

Before

Width:  |  Height:  |  Size: 62 KiB

After

Width:  |  Height:  |  Size: 62 KiB

View File

Before

Width:  |  Height:  |  Size: 85 KiB

After

Width:  |  Height:  |  Size: 85 KiB

View File

@ -1,3 +1,9 @@
---
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 container IPs.
@ -8,43 +14,44 @@ Most kinds of application updates do not require a configuring backends in VIP m
#### Task Routing Mode
Task routing was the original Interlock behavior and remains the default 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.
![default mode](../../images/interlock-default-mode.png)
![task mode](../../images/interlock-task-mode.png)
#### VIP Routing Mode
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 UCP 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 on to service containers.
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.
![default mode](../../images/interlock-vip-mode.png)
![vip mode](../../images/interlock-vip-mode.png)
While VIP mode provides endpoint stability in the face of application churn, it cannot support sticky sessions since they depend on routing directly to container IPs.
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.
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.
In VIP mode a canary service with one task next to an existing service with four tasks represents one out of two total services. Despite the fact that has fewer tasks, the canary will receive 50% 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
Backend mode is applied on a per-service basis, which means that some applications can be deployed in task mode, while others are deployed in 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 value is `task` or the label does not exist then Interlock will use task 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 changes will not require proxy reconfiguration:
- Service replica increase/decrease
- New image deployment