Kubernetes Manifests: Difference between revisions
Jump to navigation
Jump to search
(→TODO) |
|||
| Line 5: | Line 5: | ||
=Overview= | =Overview= | ||
A manifest expresses the | 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: | ||
{{Internal|Kubernetes_Concepts#Declarative_versus_Imperative_Approach|Declarative versus Imperative Approach}} | |||
Manifest files can be generated with [[Kubectl kustomize|kubectl kustomize]]. | Manifest files can be generated with [[Kubectl kustomize|kubectl kustomize]]. | ||
Revision as of 22:47, 6 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.