Your pods restart, fail their health checks, or will not come up at all, and you
need to know whether that is something you can fix from your Component
configuration. This article has two parts: a reference on how workloads are
configured, and a troubleshooting section for the common failure states.

Part 1 — Configuration reference

Resource requests and limits

Your Component's resource configuration tells the platform how much CPU and
memory to reserve for each pod. It drives scheduling, autoscaling, and eviction
behaviour.

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

The request is what is reserved for the pod and what the scheduler plans
around. The limit is the ceiling the pod is not allowed to exceed. Pods with
no request set are the first to be evicted when a node comes under memory
pressure, so always set requests on production Components.

Health checks

Kubernetes uses probes to decide whether your pod is healthy.

Probe	What it does
Liveness	Restarts the pod if it fails
Readiness	Removes the pod from the load balancer until it passes
Startup	Delays liveness checks, to give a slow-starting application time to initialise

The platform configures default probes for the standard Component types. Override
them in your Component's configuration if your application exposes a
non-standard health check endpoint.

Right-sizing with VPA recommendations

If you are unsure what requests and limits to set, enable the Vertical Pod
Autoscaler in recommender mode. It observes your Component's real CPU and
memory usage over time and produces sizing recommendations without changing
anything automatically.

vpa:
  enabled: true

The recommendations appear in the VPA Recommender dashboard, under
Dashboards → Application, if you have a dedicated Grafana instance — see
Observability.
A Component configured with a small request and a very large limit often turns
out to need something in between: that is the signal to raise the request and
lower the limit.

Stateful workloads

Components that must keep data across pod restarts should run as a
StatefulSet rather than a standard Deployment. StatefulSets give each pod a
stable identity and its own persistent volume claim. Raise a request if you want
help choosing the right type for a workload.

Part 2 — Troubleshooting

Diagnosing from SVIEW first

For any pod problem, start on the Component's Logs tab in SVIEW. Recent
output is there without any additional access, and for a crash on startup the
reason is usually in the last few lines.

Only when you need more than that — the exit reason, cluster events, or the logs
of a container that has already been replaced — do you need kubectl. That
requires Kubernetes namespace access, requested through SVIEW and described
in Namespace Access.

Still having issues?

Raise a request with the namespace, the Component name, the pod status, and what
you have already tried.

Workload Management