A Kubernetes manifest is a YAML or JSON file that declares one or more Kubernetes objects. Instead of choosing a machine and starting each part of an application yourself, you describe the objects the application needs and submit them to the Kubernetes API. The same application description can be used for local or cloud deployment; Kubernetes handles differences in the underlying infrastructure. section 1.2.4 section 1.1.1
Listing 5.1 A basic pod manifest file
apiVersion: v1 #1
kind: Pod #2
metadata:
name: kiada #3
spec:
containers:
- name: kiada #4
image: luksa/kiada:0.1 #5
ports:
- containerPort: 8080 #6
This small Pod manifest shows the starting shape: apiVersion and kind identify the object type, metadata names it, and spec declares one container, its image, and its port. It omits status, which appears after the object is created. section 5.2.1
Submitting a manifest does more than store a file. The API server records the declared objects; controllers create or update related objects, and other Kubernetes components arrange for application instances to run. Controllers watch for changes to an object's spec and report its current state in status. A manifest you write can therefore be much shorter than the YAML returned when you retrieve the resulting object. section 1.2.4 section 4.4 section 5.2.1
A practical manifest workflow is:
- Create a YAML file for an object. To get a starting Pod definition without creating it, run `kubectl run kiada --image=luksa/kiada:0.1 --dry-run=client -o yaml > mypod.yaml`; edit the file, using `kubectl explain pods` to look up fields. section 5.2.1
- Create the declared objects with `kubectl apply -f app.yaml`. A file may declare several object types for one application; manifests may also be spread across multiple files. section 5.6.2
- Check what ran with `kubectl get` or `kubectl describe`. To remove objects declared in a file, run `kubectl delete -f app.yaml`; you can also apply or delete a directory of manifest files. section 5.4.2 section 5.6.2
Manifests can configure an application as well as declare its workload. A Pod manifest can override a container image's default command, arguments, and environment variables. For configuration that differs between development, staging, and production, put values in a ConfigMap and reference it from the Pod rather than maintaining a separate Pod manifest for every environment. section 8.1 section 8.2
Take care when adding annotations: quote values that YAML might interpret as numbers or Booleans, such as `'3'` or `'yes'`. Also, do not rely on retrieved manifests having a reader-friendly field order; most objects group fields under spec and status, but Event objects do not. section 7.5.2 section 4.3.2
