What should a Kubernetes deployment diagram show?

Show the desired workload, pod-template inputs, rollout controller, ReplicaSet and pods, distinct readiness and liveness checks, Service endpoint selection, Ingress traffic, and the decision taken when the new version never becomes ready.

Why keep readiness and liveness separate?

Readiness controls whether a pod is eligible for Service traffic. Liveness tells the kubelet when to restart a stuck container. Combining them hides two different failure and recovery paths.

Does this diagram describe Excaliwow production?

No. It is generated from a small illustrative fixture committed for this marketing proof. It demonstrates the review method, not Excaliwow’s hosting topology or operational configuration.

Can the diagram be updated after the manifests change?

Yes. Keep stable element ids, re-read the changed YAML, and ask the agent for a targeted update to the same persistent diagram. Review selectors, ports, probe paths, and rollout settings again rather than assuming the old map still applies.

Kubernetes deployment diagram · manifest review

Turn Kubernetes YAML into a rollout review

Read the Deployment, Service, and Ingress together. Trace pod-template inputs, separate readiness from liveness, show which endpoints receive traffic, and make the rollback decision visible before a reviewer trusts the picture.

YAML

Three manifests

Workload

Rolling ReplicaSet

Probes

Ready vs live

Traffic

Ready endpoints

Rollback

Stop or restore

Editable Kubernetes deployment diagram tracing configuration, rolling pods, readiness and liveness probes, Service endpoints, Ingress traffic, and rollback — Faithful SVG render from the editable v2 spec. The human review connects readiness to Service eligibility, and the same-canvas follow-up adds the rollback decision.Open full-size SVG

A useful Kubernetes diagram does more than place objects on a canvas. It shows why a pod becomes eligible for Service traffic, what restarts it, and where an unhealthy rollout should stop or restore the prior ReplicaSet.

Product boundary: The three manifests are an illustrative local fixture, not Excaliwow production infrastructure. The diagram uses standard Kubernetes ownership only and does not invent a CI provider, cloud load balancer, service mesh, database, or secret values.

Reproduce it

Copy setup

Scope the manifest set

Provide the Deployment, Service, and Ingress together so selectors, ports, probes, and traffic can be checked as one system. Exclude Secret values and unrelated cluster configuration.

Connect a scoped agent

Mint a read + write Personal Access Token and add @excaliwow/mcp to your existing coding agent. Keep publish and delete disabled for the review.

MCP client config

{
  "mcpServers": {
    "excaliwow": {
      "command": "npx",
      "args": ["-y", "@excaliwow/mcp"],
      "env": {
        "EXCALIWOW_TOKEN": "excw_pat_…"
      }
    }
  }
}

Review eligibility before layout

Ask for the bounded prompt below, then verify selectors, target ports, readiness behavior, liveness behavior, and rollback meaning before adjusting spacing or color.

Human review

Change what the agent misunderstood

Add the missing readiness-to-Service dependency and label it ‘only Ready pods receive traffic’.
Move ConfigMap and Secret into a pre-rollout input stage so reviewers do not confuse configuration with request traffic.

Same-canvas follow-up

Send the correction back

Update the same diagram in place: add the failed-readiness rollback decision while preserving the human-positioned input stage and readiness edge.

Review the critical path, not the pixels

ConfigMap and Secret feed the pod template without exposing their values.
Readiness gates Service endpoint eligibility; liveness remains a separate restart signal.
Ingress routes through the Service to Ready pod endpoints on the declared ports.
Repeated readiness failure reaches an explicit stop-and-rollback decision.

Common questions

What should a Kubernetes deployment diagram show?: Show the desired workload, pod-template inputs, rollout controller, ReplicaSet and pods, distinct readiness and liveness checks, Service endpoint selection, Ingress traffic, and the decision taken when the new version never becomes ready.
Why keep readiness and liveness separate?: Readiness controls whether a pod is eligible for Service traffic. Liveness tells the kubelet when to restart a stuck container. Combining them hides two different failure and recovery paths.
Does this diagram describe Excaliwow production?: No. It is generated from a small illustrative fixture committed for this marketing proof. It demonstrates the review method, not Excaliwow’s hosting topology or operational configuration.
Can the diagram be updated after the manifests change?: Yes. Keep stable element ids, re-read the changed YAML, and ask the agent for a targeted update to the same persistent diagram. Review selectors, ports, probe paths, and rollout settings again rather than assuming the old map still applies.

Review one rollout from source

Start free—no credit card. First 10,000 verified accounts keep the core workspace free; 3 diagrams to start and earn more capacity.

Start free