Kubernetes Manifests: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 8: Line 8:
{{Internal|Kubernetes_Concepts#Declarative_versus_Imperative_Approach|Declarative versus Imperative Approach}}
{{Internal|Kubernetes_Concepts#Declarative_versus_Imperative_Approach|Declarative versus Imperative Approach}}


Manifest files can be generated with [[Kubectl kustomize|kubectl kustomize]].
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|kubectl kustomize]] and they are usually applied with [[kubectl apply]]. Note that [[kubectl apply]] can be used to both create or update a resource.


=TODO=
=TODO=


<font color=darkgray>'''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.
<font color=darkkhaki>'''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.
</font>
</font>


=<span id='Elements'></span>Common Elements=
=<span id='Elements'></span>Common Elements=


==apiVersion==
==<tt>apiVersion</tt>==


The .apiVersion field contains the API group and the API version of the resource's specification. Normally, the format is:
The <tt>.apiVersion</tt> field contains the API group and the API version of the resource's specification. Normally, the format is:


  apiVersion: <''group''>/<''version''>
  apiVersion: <''group''>/<''version''>
Line 27: Line 29:
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 <code>apiVersion: v1</code>, but introspection after deployment may show  <code>apiVersion: v1beta1</code>. This is normal behavior.
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 <code>apiVersion: v1</code>, but introspection after deployment may show  <code>apiVersion: v1beta1</code>. This is normal behavior.


==kind==
The API group a specific resource type belongs to is shown by the [[Kubernetes_API_Resources_Concepts#API_Resources|kubectl api-resources]] command.


The .kind field specifies the type of resource being deployed.
==<tt>kind</tt>==
The <tt>.kind</tt> field specifies the [[Kubernetes API Resources Concepts#Kind|type of resource]] being deployed.


==metadata==
==<tt>metadata</tt>==
{{Internal|Kubernetes Manifest Metadata|Manifest Metadata}}
{{Internal|Kubernetes Manifest Metadata|Manifest Metadata}}


==spec==
==<tt>spec</tt>==
The <code>.spec</code> section contains the specification of the object to be deployed. The structure varies with the type of the object.
 
=Dependent Variables=
{{External|https://kubernetes.io/docs/tasks/inject-data-application/define-interdependent-environment-variables/}}
 
Kubernetes manifests support '''dependent variables''', which allow you to reference previously defined variables in the value definition of other entries, with the <code>$(...)</code> notation. The values will be resolved during the startup of the container. Order matters, if you reference a variable defined later in the list, it will not be resolved and <code>$(...)</code> reference will be taken over literally.
 
<syntaxhighlight lang='yaml'>
[...]
spec:
  containers:
  - [...]
    env:
    - name: PORT
      value: "8181"
    - name: IP                        1
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: MY_URL
      value: "https://$(IP):$(PORT)"
</syntaxhighlight>


=Manifest Operations=
=Manifest Operations=
* [[Kubectl#POSTing_a_Manifest|POSTing a Manifest]]
* [[Kubectl#POSTing_a_Manifest|POSTing a Manifest]]
* [[Kubectl#Get_the_Manifest_for_an_Existing_Object|Get the Manifest for an Existing Object]]
* [[Kubectl#Get_the_Manifest_for_an_Existing_Object|Get the Manifest for an Existing Object]]

Latest revision as of 20:21, 28 February 2024

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:

Declarative versus Imperative Approach

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 and they are usually applied with kubectl apply. Note that kubectl apply can be used to both create or update a resource.

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.

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.

kind

The .kind field specifies the type of resource being deployed.

metadata

Manifest Metadata

spec

The .spec section contains the specification of the object to be deployed. The structure varies with the type of the object.

Dependent Variables

https://kubernetes.io/docs/tasks/inject-data-application/define-interdependent-environment-variables/

Kubernetes manifests support dependent variables, which allow you to reference previously defined variables in the value definition of other entries, with the $(...) notation. The values will be resolved during the startup of the container. Order matters, if you reference a variable defined later in the list, it will not be resolved and $(...) reference will be taken over literally.

[...]
spec:
  containers:
  - [...]
    env:
    - name: PORT
      value: "8181"
    - name: IP                        1
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: MY_URL
      value: "https://$(IP):$(PORT)"

Manifest Operations