Feature #11255

[Crunchv2] Option to use host networking for containers

Added by Peter Amstutz about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
03/21/2017
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
0.5

Description

Docker bridge networking has bugs on certain kernels. Add a flag to crunch-run to instruct containers to use host networking instead of the default bridge network.

Intend to support the following use case: the entire cluster is running compute nodes which will use host networking instead of bridge networking.

Sysadmin will specify the option via command line (which can be configured in crunch-dispatch-slurm).

We will provide two options:

  • Use host networking when networking is enabled, and "none" when it is disabled.
    When a container is created with --net=none, the container is given an "empty" network namespace (only the loopback device is available.) If kernel bugs are associated with Docker's bridge networking, this option would use host networking for those containers that need it, while maintaining isolation for containers that don't need networking.
  • Use host networking for all containers.
    If kernel bugs make network namespaces totally unusable, always use --net=host, so that network namespaces are not used at all. This should sidestep the issue, at the expense of reduced isolation from the host system.

Subtasks

Task #11312: Review 11255-docker-host-networkingResolvedPeter Amstutz

Associated revisions

Revision ae970cb1
Added by Peter Amstutz about 1 year ago

Merge branch '11255-docker-host-networking' closes #11255

History

#1 Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)

#2 Updated by Tom Morris about 1 year ago

  • Target version set to 2017-03-29 sprint

#3 Updated by Tom Morris about 1 year ago

  • Story points set to 0.5

#4 Updated by Tom Clegg about 1 year ago

  • Assigned To set to Nico César
  • Target version changed from 2017-03-29 sprint to 2017-04-12 sprint

#5 Updated by Nico César about 1 year ago

summon Nico before discussing implementing

#6 Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)

#8 Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)

#9 Updated by Peter Amstutz about 1 year ago

  • Target version changed from 2017-04-12 sprint to 2017-03-29 sprint

#10 Updated by Peter Amstutz about 1 year ago

  • Status changed from New to In Progress
  • Assigned To changed from Nico César to Peter Amstutz

#11 Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)
  • Status changed from In Progress to New
  • Assigned To changed from Peter Amstutz to Nico César
  • Target version changed from 2017-03-29 sprint to 2017-04-12 sprint

#12 Updated by Peter Amstutz about 1 year ago

  • Target version changed from 2017-04-12 sprint to 2017-03-29 sprint

#13 Updated by Peter Amstutz about 1 year ago

  • Status changed from New to In Progress
  • Assigned To changed from Nico César to Peter Amstutz

#14 Updated by Tom Clegg about 1 year ago

11255-docker-host-networking @ bfd73917834d89e9e8c55b6bb4e05912741fbf8a

I think the flag docs should say "for containers with networking enabled" instead of "when API: true". Even though that happens to be the only case where we enable networking right now, the flag really makes sense in terms of networking, not API access.

(from chat) (10:59:03 AM) tom: Still seems to me we might as well offer that option in a way that isn't necessarily bundled with the "lose ability to turn off networking" sacrifice... we can make two options that do separate meaningful things, and document the kernel bug workaround as "use both of these options at once and you should be OK"

Specifically how about the following orthogonal options
  1. Use specified network mode when enabling network access (default "default")
  2. Enable network access for all containers regardless of what's specified in runtime constraints
I think this would make it easier to see what each flag does, and make it possible to do things like
  • always enable networking, but use default networking mode
  • use "bridge" networking mode regardless of what the docker default is (in case this can change)
  • use some other docker networking mode we don't know about yet

The combination of flags needed for the old-kernel workaround should be documented at http://doc.arvados.org/install/crunch2-slurm/install-dispatch.html

#15 Updated by Peter Amstutz about 1 year ago

11255-docker-host-networking updated:

-container-enable-networking=[default, always]

-container-network-mode=[any valid docker network mode, passed through to container creation]

Didn't update documentation yet, will do.

#16 Updated by Tom Clegg about 1 year ago

flag help messages should probably just indent with tabs instead of a combination of spaces and tabs. The rest LGTM, thanks.

#17 Updated by Peter Amstutz about 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:ae970cb115251915c0a8e1052b23acdd2ab70fee.

Also available in: Atom PDF