Kubernetes Manifests: Difference between revisions
| Line 23: | Line 23: | ||
apiVersion: <''group''>/<''version''> | apiVersion: <''group''>/<''version''> | ||
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 | 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 <code>apiVersion: storage.k8s.io/v1</code>, a pod, whose corresponding type is defined in the core group, should be specified as <code>apiVersion: v1</code>. | ||
a pod, whose corresponding type is defined in the core group, should be specified as | |||
==kind== | ==kind== | ||
Revision as of 00:40, 7 September 2019
Internal
Overview
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:
Manifest files can be generated with kubectl kustomize.
TODO
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.
Common Elements
apiVersion
The apiVersion field contains the API group and the API version of the resource's specification. Normally, the format is:
apiVersion: <group>/<version>
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 apiVersion: v1.