thebushidocollective Kubernetes Manifests
Understanding and writing Kubernetes manifest files.
Basic Structure
apiVersion: v1
kind: Pod
metadata:
name: my-app
namespace: default
labels:
app: my-app
spec:
containers:
- name: app
image: nginx:latest
ports:
- containerPort: 80
Common Resource Types
Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: myapp:1.0.0
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Service
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: LoadBalancer
ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
database.url: "postgres://db:5432"
log.level: "info"
Secret
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
data:
password: cGFzc3dvcmQxMjM= # base64 encoded
Best Practices
Resource Requests and Limits
Always define resource requests and limits:
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Liveness and Readiness Probes
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
Labels and Selectors
Use consistent labeling:
metadata:
labels:
app: my-app
version: v1
environment: production
Validation
# Validate manifest syntax
kubectl apply --dry-run=client -f manifest.yaml
# Validate with kubeconform
kubeconform manifest.yaml
# Validate against live cluster
kubectl apply --dry-run=server -f manifest.yaml