You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Docker machines acting as routed gateways use clusterf-ipvs --filter-routes=file:// --ipvs-elide to only configure IPVS services for local backends (using a local masq route for the local container network, and a default drop route). This is done in order to avoid routing loops, where connections forwaded by the gateway would be forwarded to a different docker machine. This causes issues when a container accesses a service using the same frontend network address as a locally configured service, but with no local backends, as there will be no IPVS configuration for that service.
Instead, the local route matching the etcd route used to advertise gateway access to local containers could have a higher priority. A service having a backend matching a high-priority route would omit any lower-priority backends.
Other services without local backends could then be configured using the normal droute dests for remote backends. This could be used to optimize cross-network access to clusterf services between Docker containers, forming a direct mesh of connections bypassing the Gateway machines.
The same mechanism would also act to avoid any routing loops, since any Docker machine acting as the gateway for some service backend would only use local backends for that service frontend.
This requires that the high-priority local routes used by clusterf-ipvs must match those advertised by clusterf-docker into etcd.
Perhaps it would be better to integrate those local routes more closely into clusterf-ipvs, probably by pulling them directly from the same Docker Engine API used by clusterf-docker...?
The text was updated successfully, but these errors were encountered:
SpComb
changed the title
Optimize intra-cluster service access by implementing High-Priority Routes for the exclusive use of local backends
Implement High-Priority Routes to replace --filter-routes for the exclusive use of local backends
Aug 29, 2016
SpComb
changed the title
Implement High-Priority Routes to replace --filter-routes for the exclusive use of local backends
Implement High-Priority Routes to replace --filter-routes for the exclusive use of local backends
Aug 29, 2016
Currently Docker machines acting as routed gateways use
clusterf-ipvs --filter-routes=file:// --ipvs-elide
to only configure IPVS services for local backends (using a local masq route for the local container network, and a default drop route). This is done in order to avoid routing loops, where connections forwaded by the gateway would be forwarded to a different docker machine. This causes issues when a container accesses a service using the same frontend network address as a locally configured service, but with no local backends, as there will be no IPVS configuration for that service.Instead, the local route matching the etcd route used to advertise gateway access to local containers could have a higher priority. A service having a backend matching a high-priority route would omit any lower-priority backends.
Other services without local backends could then be configured using the normal droute dests for remote backends. This could be used to optimize cross-network access to clusterf services between Docker containers, forming a direct mesh of connections bypassing the Gateway machines.
The same mechanism would also act to avoid any routing loops, since any Docker machine acting as the gateway for some service backend would only use local backends for that service frontend.
This requires that the high-priority local routes used by
clusterf-ipvs
must match those advertised byclusterf-docker
into etcd.Perhaps it would be better to integrate those local routes more closely into
clusterf-ipvs
, probably by pulling them directly from the same Docker Engine API used byclusterf-docker
...?The text was updated successfully, but these errors were encountered: