Release Channels and Schedule

Understanding Image Names

Container-Optimized OS is available on three different release channels which are explained below. Since channel names are included in the image names, it’s important to understand Container-Optimized OS names before discussing the channels and release schedule.

A Container-Optimized OS name has the following format:


where CHANNEL is the channel name that the image was released on, RELEASE_MILESTONE is a numeric string, and RELEASE_VERSION is a string containing numbers, letters and delimiters such as '-'. A release milestone is analogous to a major software version, whereas a release version is analogous to a minor version. For example, the image name cos-dev-52-8300-0-0 implies the image is available on the dev channel at release milestone 52 and release version 8300-0-0.

Release Channels

The cos node image uses three release channels for delivering releases to users:

  • The dev channel has all the latest changes the cos node image team is working on and is updated frequently.

  • The beta channel is a qualified image in Beta. Images on the beta channel are updated less frequently than images on the dev channel.

  • The stable channel offers a longer tested and supported release with only rare and critical updates (if needed).

The rule of thumb for choosing a release channel is:

  • For testing and prototyping, select the latest image from the dev or beta channels.
  • For production deployments, select an image from the stable channel.

Refer to the Support Policy for the release duration and cadence for each channel.

How do I choose which channel to use?

You choose which release channel an instance runs when creating the instance. It is not possible to change which channel an instance uses after creation.

It is strongly recommended that users set up tiered testing along with their production environment to utilize the release channels. For example, a light-weight “nightly” test environment can pick up the latest releases on the dev channel to test new features as well as to catch any potential breakage as early as possible, and a more involved “staging” or “canary” test environment that mimics the production environment can pick up latest releases on the beta channel. This kind of setup will minimize surprises when switching the production environment to a newer version on the stable channel.

Release and Deprecation Schedule

On all of the channels, a major version update is released once every six weeks. On each of the dev and beta channels, a minor version update is released typically once per week. On the stable channel, minor version updates are rare and infrequent.

Images on Google Compute Engine have a notion of "deprecation status". A new image on a channel is always created in ACTIVE state, and older images on that channel are marked as DEPRECATED. On each of the dev and beta channels, there is usually one ACTIVE image, which is the latest released version on that channel. On the stable channel, there may be more than one ACTIVE major versions.

Auto Updates

Container-Optimized OS uses an active-passive root partition scheme. The OS image is updated in its entirety, including the kernel, as opposed to package-by-package updates on traditional Linux operating systems. The image ships with the auto-update feature enabled, which means that an instance running a version of Container-Optimized OS on a channel downloads a newer version on the same channel and installs it on the passive partition soon after it's released. Note that the update does not take effect until the instance is rebooted, and the auto-updater does not force reboot when an update is installed. After an updated version has been installed, the instance must be rebooted before it can update to a newer version.

Users can check the status of auto-update using the following command on a running instance:

sudo update_engine_client --status

Users can trigger an auto-update using the following command on a running instance:

sudo update_engine_client --update

Disable auto-updates by setting the cos-update-strategy metadata when creating a new instance:

gcloud compute instances create ... --metadata cos-update-strategy=update_disabled

Or use add-metadata on an existing instance:

gcloud compute instances add-metadata ... --metadata cos-update-strategy=update_disabled
Was this page helpful? Let us know how we did:

Send feedback about...

Container-Optimized OS