Kubernetes Pod Manifest: Difference between revisions
(→image) |
|||
| (13 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | =External= | ||
* https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#pod-v1-core | * https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#pod-v1-core | ||
=Internal= | =Internal= | ||
| Line 13: | Line 10: | ||
=Overview= | =Overview= | ||
[[Kubernetes Workload Resources#Overview|Workload resource]] controllers create pods from [[#Pod_Template|pod templates]]. | |||
=Pod Template= | |||
Pod templates are '''specifications''' for creating pods, and they are included in the manifests of the [[#Kubernetes_Workload_Resources|workload resources]]. Modifying the pod template or switching to a new pod template is detected by the workload resource controller, which usually shuts down the current running pods and replaces them with new pods built based on the new template. Each workload resource has its own rules for handling changes in the pod template. | |||
=Example= | =Example= | ||
<font size=-1> | |||
[[Kubernetes_Manifests#apiVersion|apiVersion]]: v1 | [[Kubernetes_Manifests#apiVersion|apiVersion]]: v1 | ||
[[Kubernetes_Manifests#kind|kind]]: Pod | [[Kubernetes_Manifests#kind|kind]]: Pod | ||
| Line 81: | Line 81: | ||
[[#livenessProbe|livenessProbe]]: | [[#livenessProbe|livenessProbe]]: | ||
# See [[Kubernetes_Container_Probes#Probe_Template|Probe Template]] | # See [[Kubernetes_Container_Probes#Probe_Template|Probe Template]] | ||
[[#command|command]]: ['sh', '-c', 'while true; do | [[#command|command]]: ['sh', '-c', 'while true; do sleep 2; done;'] | ||
<span id='securityContext_manifest'></span>[[#containerSecurityContext|securityContext]]: | <span id='securityContext_manifest'></span>[[#containerSecurityContext|securityContext]]: | ||
runAsGroup: 1001 # integer, not quoted | runAsGroup: 1001 # integer, not quoted | ||
| Line 105: | Line 105: | ||
persistentVolumeClaim: | persistentVolumeClaim: | ||
claimName: pvc1 | claimName: pvc1 | ||
</font> | |||
=.<tt>metadata</tt> Elements= | =.<tt>metadata</tt> Elements= | ||
| Line 123: | Line 124: | ||
==<tt>restartPolicy</tt>== | ==<tt>restartPolicy</tt>== | ||
Optional field. See: {{Internal|Kubernetes_Pod_and_Container_Concepts#Container_Restart_Policy|Container Restart Policy}} | Optional field. See: {{Internal|Kubernetes_Pod_and_Container_Concepts#Container_Restart_Policy|Container Restart Policy}} | ||
==<tt>serviceAccountName</tt>== | ==<tt>serviceAccountName</tt>== | ||
The name of [[Kubernetes_Pod_and_Container_Concepts#Pod_Service_Account|this pod's service account]]. Note that "serviceAccount" configuration element also exists, but it is deprecated. If not specified, defaults to the pod's namespace default service account. | The name of [[Kubernetes_Pod_and_Container_Concepts#Pod_Service_Account|this pod's service account]]. Note that "serviceAccount" configuration element also exists, but it is deprecated. If not specified, defaults to the pod's namespace default service account. | ||
| Line 128: | Line 130: | ||
{{Internal|Kubernetes_DNS_Concepts#Name_Resolution_inside_a_Pod|Name Resolution inside a Pod}} | {{Internal|Kubernetes_DNS_Concepts#Name_Resolution_inside_a_Pod|Name Resolution inside a Pod}} | ||
==<tt>imagePullSecrets</tt>== | ==<tt>imagePullSecrets</tt>== | ||
{{Internal|Kubernetes_Cluster_Configuration_Concepts#imagePullSecrets|Kubernetes Configuration Concepts | Secrets Required to Pull Images for Pods}} | |||
==<span id='podSecurityContext'></span><tt>securityContext</tt>== | ==<span id='podSecurityContext'></span><tt>securityContext</tt>== | ||
{{External|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core}} | {{External|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core}} | ||
Latest revision as of 23:32, 1 August 2024
External
Internal
Overview
Workload resource controllers create pods from pod templates.
Pod Template
Pod templates are specifications for creating pods, and they are included in the manifests of the workload resources. Modifying the pod template or switching to a new pod template is detected by the workload resource controller, which usually shuts down the current running pods and replaces them with new pods built based on the new template. Each workload resource has its own rules for handling changes in the pod template.
Example
apiVersion: v1 kind: Pod metadata: name: loop labels: color: blue annotations: ... generateName spec: restartPolicy: Always schedulerName: default-scheduler terminationGracePeriodSeconds: 120 serviceAccountName: 'testServiceAccount' dnsPolicy: ClusterFirst imagePullSecrets: - name: myPullSecret1 - name: myPullSecret2 ... securityContext: runAsUser: 1000 # integer, not quoted runAsGroup: 3000 # integer, not quoted runAsNonRoot: true fsGroup: 2000 fsGroupChangePolicy: seLinuxOptions: seccompProfile: supplementalGroups: sysctls: containers: - name: loop-container image: docker.io/ovidiufeodorov/loop:latest imagePullPolicy: Always lifecycle: [...] resources: requests: memory: '1024Mi' cpu: '500m' limits: memory: '4096Mi' cpu: '1000m' terminationMessagePath: /dev/termination-log terminationMessagePolicy: File command: ... ports: - containerPort: 8080 protocol: TCP name: 'http' - containerPort: 8787 protocol: TCP - containerPort: ... hostPort: .... env: - name: SOMETHING value: "something else" - name: A_BOOLEAN_VARIABLE value: "true" # must be quoted volumeMounts: - name: 'mount-0' mountPath: '/red' subPath: 'orange' readinessProbe: # See Probe Template livenessProbe: # See Probe Template command: ['sh', '-c', 'while true; do sleep 2; done;'] securityContext: runAsGroup: 1001 # integer, not quoted runAsUser: 1001 # integer, not quoted runAsNonRoot: true privileged: false allowPrivilegeEscalation: false readOnlyRootFilesystem: false capabilities: seLinuxOptions: procMount: seccompProfile: initContainers: - name: init-container1 image: busybox command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] volumes: - name: mount-0 hostPath: # '/yellow' must contain an 'orange' sub-directory path: '/yellow' - name: mount-1 persistentVolumeClaim: claimName: pvc1
.metadata Elements
labels
A pod can be tagged with labels. This section contains labels applied to the pod created based on this template. If the template is part of a deployment manifest, the section contains the labels applied to pods created by the deployment, and they must match the deployment's spec.selector values.
Also see:
generateName
"generateName" can be used to append random characters at the end of the base name, thus generating a unique pod name.
.spec Elements
hostname
Optional field. If not specified, the hostname exposed to the processes running inside the pod will be the name of the pod.
restartPolicy
Optional field. See:
serviceAccountName
The name of this pod's service account. Note that "serviceAccount" configuration element also exists, but it is deprecated. If not specified, defaults to the pod's namespace default service account.
dnsPolicy
imagePullSecrets
securityContext
The pod-wide security context, applies to all containers. See:
containers
"containers" contains an array with the pod's container definitions.
name
image
imagePullPolicy
lifecycle
volumeMounts
ports
Contains an array specifying the ports exposed by the containers in this pod.
containerPort
protocol
name
An optional name given to the container port. If declared, it must be a IANA_SVC_NAME and unique within the pod. It can be used in the manifest of the associated service to designate the service's target port.
hostPort
Binds the container port to a host port.
env
Contains a list of name/value pairs representing the list of the environment variables to set in the container. In case of boolean variables, declare the boolean values as Strings ("true"/"false"), otherwise the template won't be processed correctly.
readinessProbe, livenessProbe
command
Optional field. If not present, the docker image's ENTRYPOINT is used. If present, represents the entrypoint array of the container. Not executed within a shell, so if a shell is required, must be specified as below. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not.
Example:
...
command: ['sh', '-c', 'while true; do echo .; sleep 1; done']
Each array element is a string, and in the above case, the array element that follows the '-c' element is passed as one string to the shell to be executed.
Alternative syntax:
...
command:
- /bin/sh
- -c
- 'i=0; echo $i'
The single quotes are optional, the content that follows "-" will be interpreted as a single string:
...
command:
- /bin/sh
- -c
- i=0; echo $i
Also see:
args
TODO
Also see:
resources
requests
limits
securityContext
The section contains the security options this specific container should run with. See:
initContainers
The 'initContainers' section has the same schema as the containers section, described above. For more details about init containers, see:
volumes
List of volumes that can be mounted by containers belonging to the pod. Volumes can be of several types: persistent volume claim, host path, etc.