Kubernetes Manifest Metadata: Difference between revisions
(→name) |
(→labels) |
||
(21 intermediate revisions by the same user not shown) | |||
Line 5: | Line 5: | ||
=Internal= | =Internal= | ||
* [[Kubernetes_Manifests#metadata| | * [[Kubernetes_Manifests#metadata|Kubernetes Manifests]] | ||
=Overview= | =Overview= | ||
The manifest metadata section is where things like the resource name and [[Kubernetes Labels and Annotations#Label|labels]] are specified. | |||
=Elements= | =Elements= | ||
Line 13: | Line 15: | ||
==name== | ==name== | ||
{{ | The <tt>.metadata.name</tt> field specifies the [[Kubernetes_API_Resources_Concepts#Names|name of the resource]]. The presence of this field is in general mandatory when creating the resource specified by this manifest, thought in some cases, some resources may allow a client to request the generation of an appropriate name automatically. Once a resource is create, the name cannot be updated. More details: {{Internal|Kubernetes_API_Resources_Concepts#Names|Resource Names}} | ||
==namespace== | |||
The <tt>.metadata.namespace</tt> field specifies the Kubernetes [[Kubernetes_Namespace_Concepts#Overview|namespace]] the corresponding object belongs to. When the object is created, it will be created in the specified namespace - which has to exist at the time of the creation. If no namespace field is specified, the [[Kubernetes_Namespace_Concepts#The_Default_Namespace|default namespace]] is implied. A missing namespace field is equivalent with a namespace field with the value "default". | |||
==labels== | |||
== | The <tt>.metadata.labels</tt> field contains a map of string keys and values representing labels. More about labels: {{Internal|Kubernetes Labels and Annotations#Labels|Kubernetes Labels}} | ||
Also see: | |||
{{Internal|Kubernetes_Pod_Manifest#labels|Pod Labels}} | |||
==annotations== | |||
The <tt>.metdata.annotations</tt> filed contains an unstructured key/value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More about annotations: {{Internal|Kubernetes Labels and Annotations#Annotations|Kubernetes Annotations}} |
Latest revision as of 08:11, 2 January 2021
External
Internal
Overview
The manifest metadata section is where things like the resource name and labels are specified.
Elements
name
The .metadata.name field specifies the name of the resource. The presence of this field is in general mandatory when creating the resource specified by this manifest, thought in some cases, some resources may allow a client to request the generation of an appropriate name automatically. Once a resource is create, the name cannot be updated. More details:
namespace
The .metadata.namespace field specifies the Kubernetes namespace the corresponding object belongs to. When the object is created, it will be created in the specified namespace - which has to exist at the time of the creation. If no namespace field is specified, the default namespace is implied. A missing namespace field is equivalent with a namespace field with the value "default".
labels
The .metadata.labels field contains a map of string keys and values representing labels. More about labels:
Also see:
annotations
The .metdata.annotations filed contains an unstructured key/value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More about annotations: