Menu
Home » Host Tuning » Containers
Host Tuning

Containers

Container network options

Note: The following recommendations are presented for informational purposes only. Running containers with access to a host system's network namespace may break your local network isolation policy and/or expose your system to inadvertent misconfiguration. 

Docker

The Docker default "bridge" network should be avoided for performance testing purposes to avoid network address translation (NAT) overheads. The "host" network namespace can be selected instead using the following docker run syntax:

docker run --net host ...

Other Docker network types are also available that are suitable for high-performance network performance testing, such as macvlan and ipvlan. Note that these alternatives may require additional configuration to work correctly within your networking environment.

Kubernetes

Kubernetes networking is often more involved and the available configurations are defined by the container network interface(s) (CNI) plugins installed and made available in a given deployment. Similar guidance for avoiding container networks that perform NAT is advised, and in most deployments the ability to select "host" network namespace is also present. The relevant options in an example pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: my_container
spec:
  hostNetwork: true
  containers:
    ...

Apptainer (Singularity)

Apptainer deployments will typically run container images in a non-root configuration, which limits access to the "host" network namespace as a security feature. Other network attachments may be available including "ptp" and "macvlan" and it is advisable to understand the available options if high-performance networking is required beyond the scope of the local compute resource. Within the context of an HPC cluster, applications requiring access to a high-performance networking fabric will make use of the message passing libraries (e.g., MPI, MPICH) that are already compiled and optimized for the local interconnect, and these libraries may be included in existing images or available through bind mounts into a running container.

Application considerations

It is important to understand your application requirements to ensure a container environment is configured appropriately for performance. For example, Docker containers do not mount a tmpfs filesystem by default, which may cause issues with certain memory mapping expectations with files rooted in /tmp. iperf3 and its zero-copy mode (-Z) is a good example of when a tmpfs mount should be specified to avoid a performance regression. Example docker run syntax:

docker run --tmpfs /tmp ...

Available performance testing containers