A Kubernetes manifest is a YAML file that describes a resource’s desired state. Rather than scripting each step, submit the file to the Kubernetes API and let the control plane reconcile the current state toward that goal. The file also documents the configuration and can be kept in version control for change tracking. section 1.9
apiVersion: v1
kind: Pod
metadata:
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
Inspect the Pod manifest’s apiVersion, kind, metadata, and spec. Its spec names an nginx container and image. section 1.9
Choose a submission command based on what already exists:
- Use kubectl create -f my-pod-manifest.yaml when the resource does not yet exist; it errors if one already exists. section 1.9
- Use kubectl apply -f my-pod-manifest.yaml to create or update the resource. section 1.9
Schedule a Pod using a manifest
Generate a starting file with kubectl run ssd-pod --image=nginx --dry-run=client -o yaml > ssd-pod.yaml. Check node labels with kubectl get no --show-labels, then label the intended worker with kubectl label no kind-worker disktype=ssd. In the Pod YAML, add nodeSelector under spec, alongside containers, with disktype: ssd beneath it. After submitting the edited YAML, use kubectl get po -o wide to verify that the Pod is Running on kind-worker. section 4.1
A manifest also gives you a starting point for diagnosis. The kubelet follows a Pod’s specified restart behavior when a container fails; inspect kubectl get po and kubectl describe po nginx for status and events. For a multi-container Pod, inspect a particular container with kubectl logs busybox -c sidecar. section 1.6 section 8.1.1
One operational exception is /etc/kubernetes/manifests: the kubelet picks up YAML files there and creates the control-plane components automatically, rather than relying on the scheduler to detect those files. section 2.4
