Reading Kubernetes Manifests
5 exercises on reading Kubernetes Deployment YAML: API versioning, resource requests and limits, liveness probes, rolling update strategies, and Secrets vs ConfigMaps.
Kubernetes manifest structure
apiVersion+kind— which API handles it and what type of resourcemetadata— name, namespace, labels (used by selectors)spec— desired state: replicas, containers, volumes, strategyresources.requests— minimum guaranteed (used for scheduling)resources.limits— maximum allowed (CPU: throttle; memory: OOMKill)livenessProbe→ restart if unhealthy;readinessProbe→ stop traffic if not ready
0 / 5 completed
1 / 5
Read this Kubernetes Deployment manifest excerpt and answer the question:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: api-server
What do apiVersion: apps/v1 and kind: Deployment tell Kubernetes?apiVersion selects the API group and version; kind names the resource type.Every Kubernetes manifest has four top-level keys:
- apiVersion → tells
kubectlwhich API group and version to use.apps/v1means the apps API group, stable version 1. Core resources (Pod, Service) use justv1. - kind → the resource type.
Deploymentmanages a set of identical Pods and maintains N running replicas. Other common kinds:Service,ConfigMap,Ingress,StatefulSet. - metadata → name, namespace, labels, annotations
- spec → the desired state (what you want Kubernetes to create or maintain)
apps/v1 matters: resource types moved between API versions as Kubernetes matured. Using an older apiVersion (e.g. extensions/v1beta1) for Deployments will fail on modern clusters.Vocabulary:
- manifest → a YAML or JSON file describing the desired state of a Kubernetes resource
- namespace → a logical partition isolating resources between teams or environments
- selector → a label query that identifies which Pods belong to this Deployment