Software containers are a convenient way to run your applications in multiple isolated user-space instances. You can run containers on either Linux or Windows Server 2016 public VM images. Containers allow your applications to run with fewer dependencies on the host virtual machine and run independently from other containerized applications that you deploy to the same virtual machine instance. These characteristics make containerized applications more portable, easier to deploy, and easier to maintain at scale.
This document describes some of the more common container technologies that you can use to run containers on Compute Engine instances. You can use these technologies on most of the public VM images that Google Compute Engine provides.
Run containers on Compute Engine when you need complete control over your container environment and your container orchestration tools. Alternatively, you can use Google Container Engine to simplify cluster management and container orchestration tasks so that you do not need to manage the underlying virtual machine instances.
Container technologies that run on Compute Engine
In general, Compute Engine instances can run almost any container technology or tool. You can run several different types of containers on modern Linux operating systems and you can also run Docker on Windows Server 2016. The following list includes several common tools that you can use to run and manage containerized applications:
- Docker and rkt are two popular container technologies that allow you to easily run containerized applications.
- Kubernetes is a container orchestration platform that you can use to manage and scale your running containers across multiple instances or within a hybrid-cloud environment.
- You can convert your existing systems into LXD images and run them within Compute Engine virtual machine instances for a simple lift-and-shift migration solution. LXD runs on Ubuntu images.
Additionally, you can use Container Registry, to manage container image versions. Container Registry serves as a central location to store and manage your container images before you deploy those images to Kubernetes on Compute Engine or to Google Container Engine clusters.
Container-optimized VM images
Compute Engine provides several public VM images that you can use to create instances and run your container workloads. Some of these public VM images have a minimalistic container-optimized operating system that includes newer versions of Docker, rkt, or Kubernetes preinstalled. The following public image families are designed specifically to run containers:
- Container-Optimized OS from Google
- Includes: Docker, Kubernetes
- Image project:
- Image family:
- Includes: Docker, rkt, Kubernetes
- Image project:
- Image family:
- Includes: LXD
- Image project:
- Image family:
If you need to run specific container tools and technologies on images that do not include them by default, install those technologies manually.
Installing container technologies on your instances
When you run container workloads on Compute Engine, you have the freedom to employ whatever container technologies and orchestration tools that you need. Create an instance from a public VM image and then install the container technologies that you want. For example:
- Install Docker on Compute Engine instances so that you can run your Docker container images on those instances.
- Install rkt on Compute Engine instances as an alternative to the Docker container runtime.
- Install Kubernetes on your instances to provide container orchestration for both Docker and rkt containers.
In some situations, you might require specific versions of these technologies to ensure that they operate together correctly. For example, Kubernetes usually runs best with specific versions of Docker. Typically, you can install the latest versions of these technologies for the best result.
Installing Docker on Windows Server 2016 images
You can install Docker on Windows Server 2016 images and run containerized applications in a Windows environment. If you do not have a Windows Server 2016 instance, you can create a Windows Server instance using a Windows Server 2016 public image.
Open a PowerShell terminal as an administrator.
Install Docker from the Microsoft repositories:
PS C:> Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
PS C:> Install-Package -Name docker -ProviderName DockerMsftProvider
Run the following commands to work around known issues with Windows containers on Compute Engine:
Disable Receive Segment Coalescing:
PS C:> netsh netkvm setparam 0 *RscIPv4 0
PS C:> reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters ` /v DisabledComponents /t REG_DWORD /d 0x0 /f
Restart the instance:
PS C:> Restart-Computer -Force
Additional setup steps
At this point you can use Docker to run containers in the instance. For example,
the following command downloads the Windows
nanoserver container image and
runs PowerShell inside a
PS C:\> docker run -it microsoft/nanoserver powershell
However, there is a known issue with Docker's default network
MTU that affects connectivity to the instance and connectivity from containers
to the Internet. To work around this issue, run the following commands in a
PowerShell terminal on the instance to see the interface names and set the
vEthernet MTU to
PS C:\> netsh interface ipv4 show subinterfaces MTU MediaSenseState Bytes In Bytes Out Interface ------ --------------- --------- --------- ------------- 4294967295 1 0 5720 Loopback Pseudo-Interface 1 1500 1 76091 292077 vEthernet (HNS Internal NIC)
PS C:\> netsh interface ipv4 set subinterface ` "vEthernet (HNS Internal NIC)" mtu=1460 store=persistent
Even after repairing the instance's MTU, connectivity from containers to the
Internet may be unstable because the container's network interface will also use
an MTU of
1500 by default. To establish full connectivity, repeat these MTU
commands (the interface name will be different) inside the container itself.
Remember to fix the MTU in this manner when generating new container images.
You may need to periodically re-execute these MTU commands as you configure Docker networking. Read the known issues section for full details.
Known issues with Windows containers
MTU incompatibilities affect instance and container connectivity
When you create a container network on a Windows instance using the
network create or
New-VMSwitch commands, the MTU of the instance's network
interface is typically forced to
1500. The default network interface inside of
a new Docker container also typically uses an MTU of
1500. Google Cloud
Platform supports an MTU of only
1460, so when the MTU is forced to
may experience the following issues:
The RDP session can stop and you might be unable to reconnect. This is known to happen when creating a transparent container network.
DNS resolution inside the container might fail.
DNS resolution is successful, but establishing an HTTP connection from the container to the Internet might fail.
To recover from this situation, run the following commands in a PowerShell terminal on the instance or in the container to see the interface names and reset the MTU:
PS C:\> netsh interface ipv4 show subinterfaces MTU MediaSenseState Bytes In Bytes Out Interface ------ --------------- --------- --------- ------------- 4294967295 1 0 5720 Loopback Pseudo-Interface 1 1500 1 76091 292077 vEthernet (HNSTransparent)
PS C:\> netsh interface ipv4 set subinterface ` "vEthernet (HNSTransparent)" mtu=1460 store=persistent
If you are unable to run these commands because you can no longer connect to
an instance via RDP, you can can connect to the instance through the serial
console, start a
prompt and run the
netsh commands there to repair the MTU. To avoid having to
do this you can execute the
docker network ... or
New-VMSwitch commands as
part of a script that also executes the MTU repair commands.
Docker containers fail to start
Starting a container with
docker run can fail with the following error:
C:\Program Files\Docker\docker.exe: Error response from daemon: container ... encountered an error during CreateContainer: failure in a Windows system call: Element not found. (0x490)
This issue occurs on Windows Server 2016 instances with Windows Update KB4015217 installed. To work around the problem, enable IPv6 on the instance using the following PowerShell command:
PS C:\> reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters ` /v DisabledComponents /t REG_DWORD /d 0x0 /f
After you enable IPv6, restart the instance:
PS C:\> Restart-Computer -Force
If this issue is corrected in future operating system updates, you can restore the original IPv6 setting:
PS C:\> reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters ` /v DisabledComponents /t REG_DWORD /d 0xff /f
- Create and start an instance that you can use to run container applications.
- Learn about Compute Engine instances.
- Learn more about Google Container Engine, which you can use to easily run your containers on Google Cloud Platform without managing Compute Engine instances yourself.
- Learn more about Kubernetes.
- Learn how to use Container Registry to store your container images privately within Google Cloud Platform.