All templates
Sequence template
Kubernetes container lifecycle
Startup, liveness checks, readiness gates, and termination.
Kubernetes orchestrates containers through a precise lifecycle: start, check readiness, serve traffic, monitor liveness, then gracefully shut down. Most outages happen not at runtime but at the boundaries— a readiness probe that never passes, a liveness probe that is too strict, or a graceful shutdown that is too short.
This sequence diagram is the Kubernetes contract: the kubelet (the node agent) owns the lifecycle, your application owns the health checks. The readiness probe gates inbound traffic; the liveness probe restarts stuck containers. Together, they keep your service healthy through rolling updates.
When to use this template
- Onboarding DevOps engineers — show them the full lifecycle so they understand why their readiness probe keeps failing and what SIGTERM actually means.
- Debugging CrashLoopBackOff — replay the actual sequence against your manifest. Is the probe path correct? Is the app responding? Does the app handle SIGTERM?
- Capacity planning during rolling updates — visualize what happens when a new pod starts (it waits for readiness before taking traffic) and an old pod terminates (it drains requests gracefully). Adjust timeouts and grace periods based on your app's real shutdown time.
How to adapt it
Map the probes and timeouts to your actual application:
- Change probe endpoints (GET /health, GET /alive) to match your app's real endpoints.
- Set initialDelaySeconds to the time your app needs to initialize before it can respond.
- Add a startup probe section if initialization takes longer than readiness can account for.
- Adjust the terminationGracePeriodSeconds to match how long your app needs to drain requests (default 30 seconds often is not enough for database-heavy workloads).
Visual edits regenerate clean Mermaid code, so probe strategy changes stay reviewable in your Kubernetes manifest alongside the diagram.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
sequenceDiagram
participant Kubelet
participant Container
participant App as Application
Kubelet->>Container: Pull image + start
Container->>App: Initialize
App->>Container: Ready to serve
Kubelet->>App: Readiness probe (GET /health)
App-->>Kubelet: 200 OK
Kubelet->>Kubelet: Add to load balancer
Note over Kubelet,App: Running & healthy
par Periodic checks
Kubelet->>App: Liveness probe (GET /alive)
App-->>Kubelet: 200 OK
end
Kubelet->>Container: SIGTERM (rolling update)
App->>App: Graceful shutdown (drain requests)
Container->>Kubelet: Exit cleanly
Frequently asked questions
- What is a Kubernetes container lifecycle diagram?
- It shows the journey of a container from startup through healthy serving to graceful termination. Key milestones are initialization, readiness (is the app ready to receive traffic?), liveness (is the app still alive and responsive?), and graceful shutdown (how does the app drain requests before exiting?). Most outages trace back to misconfigured probes at one of these stages.
- What is the difference between a readiness and liveness probe?
- Readiness tells Kubernetes 'I am ready to serve traffic now' — a new container waits for this before receiving requests. Liveness tells Kubernetes 'I am still alive' — if liveness fails repeatedly, Kubernetes restarts the container. Readiness gates traffic; liveness repairs stuck containers. Both are necessary.
- Why does the container send SIGTERM instead of just being killed?
- Because in-flight requests matter. SIGTERM gives your application a grace period (default 30 seconds) to finish processing current requests and close connections cleanly before Kubernetes forcibly kills the container with SIGKILL. Applications that ignore SIGTERM and run until SIGKILL drop in-flight requests and can corrupt databases.
- How do I set readiness and liveness probes in my Kubernetes manifest?
- Define readinesProbe and livenessProbe in the container spec with path (e.g., /health), port, and failureThreshold. For the example, a httpGet probe with path=/health, port=8080, initialDelaySeconds=10, periodSeconds=5. Pair the probe endpoints with your app's actual health-check logic — they must agree on what 'healthy' means.