Kubernetes YAML Resource Summarizer
Inventory Kubernetes resources, namespaces, workload images, replicas, ports, hosts, and configuration signals from manifests.
Paste one or more Kubernetes YAML documents; multi-document streams and kind: List are supported.
Summary Settings
Looks for
Checks
Parsing stays in this browser. No resource is applied and no Kubernetes API discovery or schema lookup is performed.
Output
Kubernetes YAML summary output will appear here.
Treat a manifest summary as an inventory
A Kubernetes YAML stream can mix workloads, Services, Ingresses, configuration, RBAC, storage, and custom resources. The inventory keeps the object identity first—apiVersion, kind, name, and namespace—then adds fields that are meaningful for that resource family.
That is intentionally different from pretending every object has replicas, images, or ports. A Secret and a Deployment answer different review questions, so their summary signals should differ too.
Secrets deserve a separate handling path
Secret values are deliberately not copied into the inventory. Kubernetes Secret data is commonly base64-encoded, which is not encryption; repository, access-control, and encryption-at-rest decisions still matter.
Namespace is not universal
Deployments and Services are namespaced, while objects such as Namespace, Node, PersistentVolume, StorageClass, and ClusterRole are cluster-scoped. Missing namespace is only flagged where the resource family is known to be namespaced.
What changes by resource family
- Pod-template workloads: container, init-container, and ephemeral-container images plus declared container ports and scaling hints.
- Services: type, Service port, targetPort, nodePort, app protocol, and headless or ExternalName signals.
- Ingress: rule and TLS hosts plus Service backend references.
- ConfigMaps and Secrets: key counts without echoing Secret values.
- RBAC and cluster-scoped objects: identity and scope rather than invented workload fields.
- Custom resources: object identity and metadata are kept, while domain-specific spec fields remain outside the generic summary.
Replica text is a declaration, not live capacity
Deployments, StatefulSets, and ReplicaSets expose spec.replicas and default to one when it is omitted. DaemonSets scale with eligible nodes; Jobs describe parallelism and completions; CronJobs create Jobs according to schedule. The summary preserves those distinctions instead of forcing every workload into one replica number.
Static YAML stops before API-server truth
The parser validates YAML structure and duplicate keys, but it does not perform Kubernetes OpenAPI validation, default every API field, resolve CRD schemas, run admission, check RBAC, or compare against live cluster state. Use server-side dry-run, policy checks, and the target cluster when those answers matter.
Kubernetes' object documentation explains the object model, while the namespace documentation distinguishes namespaced and cluster-scoped resources.
What the inventory can and cannot answer
Can a valid YAML document still be invalid Kubernetes configuration?
Yes. YAML syntax and Kubernetes API schema validity are separate layers. Unknown fields, removed API versions, admission rules, or CRD validation can still reject a syntactically valid document.
Why are Secret values not displayed?
The resource identity and key count are usually enough for an inventory. Reprinting credentials adds exposure without improving the structural summary.
Does an omitted Deployment replica count mean zero?
No. Kubernetes defaults a Deployment replica count to one when the field is omitted. The inventory labels that as a default rather than showing a misleading blank or zero.
Can custom resources still appear?
Yes. Their apiVersion, kind, metadata, labels, and scope hint can be listed, but domain-specific fields require the CRD schema or controller knowledge.