Troubleshooting

Start with the deployment. When a deploy fails, its summary starts with a Why block: each reason a pod is not ready, then the latest warnings from Kubernetes. Most of the time that is the answer.

Where	Command	Console
Last deploys and their Why block	platform service deployments <id>	Deployments tab
Pods and why one is not ready	platform service pods <id>	Monitoring tab
What Kubernetes reported	platform service events <id> --warnings	Monitoring tab, Events
A container’s output	platform service logs <id> --container <name>	Logs tab
The run before a crash	platform service logs <id> --container <name> --previous	Logs tab, Previous container

You only see your own app. Events and pods come from its namespace and nothing else.

Pending: no room on the cluster

Why:
- server-7c9d…: The cluster has no room for this pod: 0/1 nodes are available: 1 Insufficient memory.

The scheduler found no node with enough free memory or CPU for what the pod reserves, or the node already runs as many pods as it may (Too many pods). Apps share the cluster, so this depends on what else runs there.

• Lower deploy.resources.reservations in the Compose file to what the container really needs. A reservation is held even when the container is idle.
• Run fewer services. A help site and a developer site can often be one container, or be served by the main server.
• If the app really needs more, ask the platform team for capacity.

ImagePullBackOff or ErrImagePull

The cluster could not download an image. platform service events shows the registry’s answer.

• not found or manifest unknown: the image or tag does not exist. Check that the build pushed it under the name in the Compose file.
• unauthorized: a private image on registry.m12p.net needs the registry login on the service.
• A public image written without a registry host, such as minio/minio, is looked up on registry.m12p.net. Write docker.io/minio/minio. See Compose.

CrashLoopBackOff

The container starts and exits again. The pod line says which container and the exit code, for example server exited with code 1 (Error).

platform service logs <id> --container server --previous

--previous prints the output of the run that crashed. The current run is often too young to have said anything. Common causes are a missing environment value, a database that is not ready yet, or a command that replaced an entrypoint the image needs.

A volume stays Pending

The pod waits for its storage claim. platform service events shows the claim’s events. A claim that names a storage class the cluster does not have never binds. Use plain name:/path volumes from the Compose file.

The domain answers 404 or 503

The pods may be fine while the domain is not.

• 503: the domain points at a service with no ready pod, or at a port the container does not listen on. Check the domain’s service and port on the Domains tab against ports in the Compose file.
• 404: no domain on the app has that hostname. Add it on the Domains tab, then deploy.
• A TLS error or ERR_QUIC_PROTOCOL_ERROR: the name has two labels under the platform domain, such as help.shop.m12p.com. The certificate covers one label. Use shop-help.m12p.com.

Deployed, but still the old version

A deploy restarts every container whose image is :latest or has no tag, one after another, so each new pod pulls the image again. An image with any other tag is pulled only when the tag changes. New content pushed under the same tag, such as :v2, is not fetched, because the node keeps the copy it has. Push a new tag for each release, or use :latest.

platform service deploy <id> --restart <container> restarts only that container, without applying anything else.