Kubernetes Manifest Reading
replicas, selectors, Service types, resource limits, ConfigMaps — reading K8s YAML manifests in plain English
Kubernetes manifest vocabulary
- replicas: N — desired number of Pods; Kubernetes self-heals to maintain this count
- selector.matchLabels — links a Deployment/Service to the Pods it manages or routes to
- ClusterIP = internal only; LoadBalancer = public cloud load balancer
- resources.requests = scheduling reservation; resources.limits = hard cap (OOMKill if exceeded)
- ConfigMap volume mount — each key becomes a file at mountPath inside the container
Question 0 of 5
In this Kubernetes Deployment manifest, what does replicas: 3 mean?apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
replicas: 3
selector:
matchLabels:
app: api-server
template:
spec:
containers:
- name: api
image: myapp:v1.2.0
- Deployment — a controller that manages a set of identical Pods and ensures the desired replica count is always maintained
- replicas — the desired number of Pod instances (the "desired state"); the controller continuously reconciles actual vs desired
- Pod — the smallest deployable unit; contains one or more containers
- Self-healing — if a Pod crashes, the Deployment controller notices and creates a replacement
replicas to scale up or down. Set replicas: 0 to stop all Pods while keeping the Deployment definition.What is the purpose of selector.matchLabels in this Deployment?spec:
selector:
matchLabels:
app: api-server
tier: backend
template:
metadata:
labels:
app: api-server
tier: backend
spec:
containers:
- name: api
image: myapp:latest
- labels — key-value metadata attached to Kubernetes objects; used for grouping and selection
- selector.matchLabels — the Deployment watches all Pods with these exact labels; it manages them (restarts, scales, etc.)
- template.metadata.labels — labels applied to each Pod created from this template; must match the selector
- Why it matters — Services also use label selectors to route traffic to matching Pods; the selector pattern is the core of Kubernetes wiring
Read this Kubernetes Service manifest. What is the difference between ClusterIP and LoadBalancer service types?# Service A
apiVersion: v1
kind: Service
spec:
type: ClusterIP
selector:
app: api-server
ports:
- port: 80
targetPort: 3000
# Service B
apiVersion: v1
kind: Service
spec:
type: LoadBalancer
selector:
app: api-server
ports:
- port: 80
targetPort: 3000
- ClusterIP (default) — creates an internal IP reachable only within the cluster; used for service-to-service communication
- NodePort — exposes the service on a port on every cluster node; accessible externally but on a high port number
- LoadBalancer — provisions a cloud load balancer (AWS ELB, GCP Cloud Load Balancer, etc.) with a public IP; suitable for production ingress
- ExternalName — maps the service to a DNS name outside the cluster
What does resources.limits.memory: "256Mi" mean in this Pod spec?containers:
- name: api
image: myapp:latest
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
- requests — the amount of resource guaranteed and reserved for this container; used by the scheduler to find a node with enough available capacity
- limits — the maximum the container can consume; enforced by the kernel cgroup
- OOMKilled — "Out Of Memory Killed": if a container exceeds its memory limit, the kernel kills it; Kubernetes then restarts it
- Mi vs M —
256Mi= 268,435,456 bytes (mebibytes, base-2);256M= 256,000,000 bytes (megabytes, base-10) - CPU: 250m = 250 millicores = 0.25 CPU cores
Read this ConfigMap and Deployment snippet. How is the ConfigMap mounted into the container?apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
config.yaml: |
server:
port: 8080
log_level: info
---
spec:
containers:
- name: app
image: myapp:latest
volumeMounts:
- name: config-volume
mountPath: /etc/app
volumes:
- name: config-volume
configMap:
name: app-config
- ConfigMap — stores non-sensitive configuration data as key-value pairs; each key can be a filename with multi-line content
- volumes: configMap — creates a volume backed by the ConfigMap; each key in
data:becomes a file in the volume - volumeMounts: mountPath — the directory inside the container where the volume is mounted;
/etc/app/config.yamlwill exist as a file - Alternative: env vars — ConfigMap values can also be injected as environment variables using
envFrom: configMapRef