Container instancesUsers

Container instances

Run prebuilt container images as a managed service — one or more components, each its own pod, reachable from outside only through the endpoints you add.

A container instance runs container images that are already built — from a public registry or a private one — as a managed service. There is no build step: you name an image and a tag, and the platform runs it, keeps it running and gives it an address. When the platform should build your code from a repository, use an app instead.

Components and containers

An instance is made of one or more components. A component is one pod: its containers share a network address, volumes and lifecycle, and it is sized, scaled and restarted as a unit.
A component runs one or more containers, and optionally init containers, which run to completion, one after the other, before the main containers start.
The create wizard makes an instance with one component, main, running one container. More components and containers can be added on the instance's Components tab. An instance deployed from a blueprint usually has several.

Changing one component replaces only that component's pods; the others keep running.

Startup waves

Every component has a startup wave, a number from 1 up. The platform starts the components wave by wave, lowest first, and starts a wave only when every component of the waves before it is ready — so a gateway is not started before the database it talks to accepts connections. A component that has failed in a way that waiting will not fix — a crash loop, an image that cannot be pulled, no room to schedule it, storage that will not attach — does not hold the later waves back. A component whose pods run but never become ready does: the later waves wait for as long as it stays unready.

While a wave is pending, the instance's Overview shows its number as Starting wave, and components in later waves report that they are starting even when their pods already run. Endpoints are updated only once every wave is up.

Images and updates

When a component is deployed, the platform looks up the content digest behind each image tag and runs exactly that image. Pushing a new image under the same tag — latest, for example — therefore changes nothing by itself. Re-deploy the component, or Restart the instance, and the tag is looked up again. When the registry cannot be reached at deploy time, the component runs the tag as it is and the platform keeps asking; once the registry answers, the pods are replaced with the image the tag names then. Images in a private registry are pulled with the credentials of a deployment source; see Image.

Readiness

A component is ready when its pods are. A main container that declares exactly one port, a TCP one, and no readiness probe of its own is checked on that port: it counts as ready once the port accepts connections. Probes of your own are set through the API or a blueprint template; the portal does not edit them.

How an instance is reached

Inside the boundary. A component that declares ports gets the in-cluster name <instance>-<component>, answering on every port it declares. Other workloads in the same resource group reach it by that name. The boundary's network rules decide what may connect: every workload in the boundary, in any of its resource groups, and the cluster's ingress controller, on any port.
From outside the cluster. Only through an endpoint: an HTTPS hostname, or a load balancer address for raw TCP or UDP. An instance without endpoints is internal only. See Endpoints.
Through a load balancer endpoint. Its port is exempt from the boundary's rules: it admits every source, workloads in other boundaries included, with no allowlist of addresses — see Load balancer endpoints.

Outbound, a workload can open TCP 443 to any address and TCP 6443, the Kubernetes API port; other ports to addresses outside the cluster are blocked — see What the rules allow.

Storage

A component can declare volumes and mount them into its containers:

Persistent — a disk that survives restarts. A component with one runs at most one replica. By default the disk is kept when the instance is deleted.
Ephemeral — scratch space the component's containers share, discarded with the pod.
Files — files whose content is part of the instance's configuration, such as a configuration file or an init script. Content marked sensitive is stored as a secret and hidden when read.

Volumes are declared through the API, the CLI or a blueprint template — see Add volumes and files. Persistent volumes can be browsed on the Files tab and backed up with snapshots.

Identity and secrets

Every instance gets a managed identity, shared by all its components. The platform uses it to fetch the vault secrets the containers reference, and your code can use it to get tokens — see Use a managed identity in code. How a container receives a vault secret as an environment variable is described in Secrets in container instances.

Warning

Vault secrets are delivered per component, not per container. As soon as one container of a component references a vault secret, every container of that component — init containers included — can read all of the component's secret values from the file /secrets/env.json, and every container that declares a command or arguments also receives all of them as environment variables. Put a container that must not see those secrets in a component of its own.

Statuses

An instance is Creating, Updating, Running, Degraded, Error or Stopped; the worst component decides. What each status means is listed in Statuses.