A manifest expresses the desired state of a specific component of the application, and it is POSTed to the API server to instruct the cluster to adjust the corresponding current state. The steps involved by processing a manifest are described here:
Note that only a small subset of manifest fields for an object is actually required. The optional fields that are not set are automatically expanded with default values by Kubernetes.
Manifest files can be generated with kubectl kustomize.
Commonality. There are common elements with the same semantics for all manifests (e.g. metadata.name). Address them here in a common section, and link from individual "kinds" to here.
The .apiVersion field contains the API group and the API version of the resource's specification. Normally, the format is:
However, some of the most common resources are defined in a special API group called the core group. For those resources, we can omit the <group> part when specifying apiVersion. While a StorageClass object should be specified as
apiVersion: storage.k8s.io/v1, a pod, whose corresponding type is defined in the core group, should be specified as
There are situations when an object is declared with an apiVersion, but after deployment, when the object is introspected, the return values shows a different version. For example, the object may be deployed as
apiVersion: v1, but introspection after deployment may show
apiVersion: v1beta1. This is normal behavior.
The API group a specific resource type belongs to is shown by the kubectl api-resources command.
The .kind field specifies the type of resource being deployed.
The .spec section contains the specification of the object to be deployed. The structure varies with the type of the object.