Multi-Document YAML with Namespace Setup
Validate a multi-document YAML file containing a Namespace, Deployment, and Service. Learn how to structure complete application stacks in a single YAML file.
Detailed Explanation
Multi-Document Kubernetes YAML
Kubernetes supports YAML files with multiple documents separated by ---. This is commonly used to define an entire application stack — namespace, deployments, services, config maps — in a single file.
Example Multi-Document Manifest
apiVersion: v1
kind: Namespace
metadata:
name: production-app
labels:
environment: production
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
namespace: production-app
labels:
app: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
securityContext:
runAsNonRoot: true
containers:
- name: api
image: myregistry.io/api:2.5.0
ports:
- containerPort: 8080
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 1000m
memory: 512Mi
livenessProbe:
httpGet:
path: /health
port: 8080
---
apiVersion: v1
kind: Service
metadata:
name: api-service
namespace: production-app
spec:
selector:
app: api
ports:
- port: 80
targetPort: 8080
How the Validator Handles Multi-Doc
The validator splits the input on --- separators and validates each document independently:
- Document 1 (Namespace): Checks required fields
- Document 2 (Deployment): Checks required fields, resources, probes, security
- Document 3 (Service): Checks required fields, selector, ports
The Resources Found table shows all three resources, giving you a quick overview of the entire application stack.
Ordering Considerations
While Kubernetes accepts resources in any order, it is common to organize them as:
- Namespace (created first)
- ConfigMaps and Secrets (needed by Deployments)
- Deployments, StatefulSets, DaemonSets
- Services
- Ingress resources
This ordering makes the manifest more readable and helps when applying with kubectl apply -f.
Use Case
Validating complete application stacks defined in a single YAML file before deploying to a new namespace. Common in GitOps workflows where entire environments are defined declaratively.