The status of container groups and recipe deployments, as well as individual instances attached to a node change over the lifecycle of a deployment. This page clarifies the associated terminology and statuses.
Container Groups and Recipe Deployments: Container groups and recipe deployments are groups of one or more instances of your container image or selected recipe. These are similar to a Kubernetes ReplicaSet.
- Preparing: A Preparing (or pending) deployment is undergoing initial processing that needs to occur before the deployment can be started. The required processing depends on if the container image has been previously stored and whether or not it is from a private registry. Depending on the size of the container image, this preparation can take some time. The stages are:
- Pulling the image from the repository.
- Compressing the image for faster transmission.
- Storing the result for distribution.
- Stopped: The container group or recipe deployment is prepared, but is either not yet running or has been stopped. Note that presently, individual instances can still be running even after the container group is stopped while the stop message propagates through the network.
- Deploying: The deployment has been started, but no instances are currently running.
- Running: The container has been started and at least one instance is running.
- Failed: A container group or recipe deployment can only fail if there was a problem in the Preparing process, either:
- Failed to pull if we were not able to pull the image from the repository. This could indicate an issue with the provided image name, or a transient issue with the registry. Check the provided image and try again.
- Failed to authenticate if we could not authenticate to the registry. Check and correct the authentication details and try again.
- Failed to store or compress indicate a rare problem preparing at the state.
Instances: Instances are an assignment of your container to a SaladCloud node. Instances have separate status from the container group or recipe deployment they are a part of.
- Allocating: Instances are allocating when we are looking for a node to assign your deployment. If all instances show allocating for an extended time it indicates that either that instances are failing to create or that there are not currently nodes available with the requested properties.
- Downloading: Downloading indicates that a node has been assigned to your workload and is downloading the container image.
- Creating: The assigned node is preparing your deployment. This includes downloading, unpacking, and starting the container image. If an instance is stuck creating you can reallocate your workload to another node.
- Running: Running indicates the container has been started. Depending on your container, additional time may be needed before it is ready for inbound networking requests, e.g. to run startup scripts or download models. Health Probes can be configured to account for this. Note that Billing is usage-based on usage and only starts once a container is running. Running containers can be reallocated, recreated, or restarted.
- Stopping: Indicates that a stop signal has been sent to your container instance. It can take up to several minutes for your container to stop while the signal propagates through the network.
Replicas: Replicas are the desired number of instances for your container group or recipe deployment. While running, you can edit the desired replica count for your deployment.
Downloading and Creating instance statuses are estimated based on average download and setup times. If your instance is taking longer than expected to get set up, it will appear to hang at 99% creating. In this case, it is likely downloading or unpacking more slowly than expected. If the node continues to underperform, it will automatically be reallocated - there's nothing you need to do in this case but wait. You may attempt a manual reallocation, but note that this will cause the process to start over from the allocating step.
No. You are only charged for instances that are in a running state. If you had a container group that reached a running state, then you reallocate the instances, the container group would still show as running, even though no instances are running at the moment. In that case, you would not be charged until an instance began running again.
Updated about 2 months ago