spec

2024年08月28日

柏拉文

越努力，越幸运

一、containers

Containers 是 Kubernetes 中最常见的工作负载定义部分, 用来定义定义 Pod 中主容器的列表。它们代表应用程序的主要进程或服务，负责处理应用的核心业务逻辑。通常，Containers 会运行实际的应用程序代码，如 Web 服务器、数据库、缓存服务等。它们有以下几个特点和应用场景:

并行启动: Pod 中的所有 Containers 默认情况下会并行启动，并且可以共享同一个网络命名空间和存储卷，这使得它们能够相互通信并共享数据。
资源请求与限制: 每个 Container 可以指定 CPU 和内存的资源请求和限制，以确保它们在集群中分配适当的资源，同时避免资源过载。
生命周期管理: Containers 的生命周期与 Pod 紧密相关。Pod 可能会因为各种原因（如节点故障、调度策略）而重启或迁移，这会导致 Containers 被终止并重新启动。
健康检查: Kubernetes 提供了探针（Liveness、Readiness、Startup）来检查 Containers 的健康状况，确保应用程序在正确的状态下运行。

语法

apiVersion: v1 
kind: Pod 
metadata:
    name: my-pod 
    labels:
        name: my-pod 
spec:
    containers:
    - name: my-container-1 
      image: docker.io/library/xx:yy
      command: [xx,yy]
      ports:
        - containerPort: 80

1.1 name

name: 容器的名字，必须在 Pod 内唯一。

1.2 image

image: 容器的镜像，可以包含镜像版本号（例如 nginx:1.19.0）。

语法

spec:
  containers:
  - name: my-container // 使用 Docker Hub 上的公共镜像
    image: nginx:1.19.0
    imagePullPolicy: IfNotPresent

spec:
  containers:
  - name: my-container
    image: registry.example.com/myapp/backend:2.0.0 // 使用特定镜像仓库的镜像
    imagePullPolicy: IfNotPresent

1.3 imagePullPolicy

imagePullPolicy 在指定镜像时，可以通过 imagePullPolicy 字段控制镜像的拉取策略，确保 Pod 启动时镜像是否需要被重新拉取。可选值包括：

Always: 总是拉取镜像，不管本地是否已有该镜像。适用于需要保证镜像更新的场景。
IfNotPresent: 如果本地已有该镜像，则不重新拉取。适用于减少网络开销的场景。
Never: 从不拉取镜像，只使用本地已有的镜像。适用于完全离线或确定镜像已存在的场景。

imagePullPolicy 镜像拉取策略的默认行为:

如果镜像标签是 latest，则默认值为 Always。这意味着 Kubernetes 会假定 latest 代表镜像的最新版本，因此总是会重新拉取。
如果镜像使用了其他标签（如 v1.0.0）或没有标签，默认值为 IfNotPresent。这种情况下，Kubernetes 只会在本地没有该镜像时才拉取镜像。

因此, 在生产环境中，最好使用明确的版本号标签（如 my-app-image:v1.0.0），并将 imagePullPolicy 设置为 IfNotPresent，避免频繁拉取镜像。

语法

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: my-app-image:latest
    imagePullPolicy: Always

1.4 ports

ports: 容器暴露的端口列表。containerPort 定义容器内部应用监听的端口号。

1.5 env

在 Kubernetes 中，env 用于定义容器内的环境变量。这些环境变量可以传递配置信息，帮助应用根据不同的环境设置其行为，或存储敏感数据（如数据库连接信息、API 密钥等）。通过 env 字段，您可以为容器配置静态值或动态从其他资源（如 ConfigMap、Secret、Downward API）中获取值。

语法

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:1.27.1-perl-linux-arm64
      ports:
        - containerPort: 80
      env:
        - name: IP
          value: "192.168.0.0"
        - name: PORT
          value: "8080"
        - name: ADDR
          value: $(IP):$(PORT)
      command:
        [
          "sh",
          "-c",
          "echo The app is running in $ADDR && nginx -g 'daemon off;'",
        ]

ENVIRONMENT 是定义的环境变量，值为 production。
容器启动时会运行 sh -c，并输出 The app is running in 192.168.0.0:8080，因为 $ADDR 被替换为 192.168.0.0:8080（通过 kubectl logs [pod] 查看输出结果）。

用法

用法一、静态环境变量: 直接提供环境变量的键值对。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:1.27.1-perl-linux-arm64
      ports:
        - containerPort: 80
      env:
        - name: ENVIRONMENT
          value: "production"
      command:
        [
          "sh",
          "-c",
          "echo The app is running in $ENVIRONMENT && nginx -g 'daemon off;'",
        ]

ENVIRONMENT 是定义的环境变量，值为 production。
容器启动时会运行 sh -c，并输出 The app is running in production，因为 $ENVIRONMENT 被替换为 production（通过 kubectl logs [pod] 查看输出结果）。

用法二、从 ConfigMap 中获取环境变量: 通过 valueFrom.configMapKeyRef 引用 ConfigMap 中的键值。ConfigMap 是 Kubernetes 中用于管理非敏感配置数据的资源。你可以从 ConfigMap 中引用并注入环境变量。

// configMap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: config-map-data
  namespace: default
data:
  NAME: "bolawen"
  AGE: "23"

// pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:1.27.1-perl-linux-arm64
      ports:
        - containerPort: 80
      env:
        - name: NAME
          valueFrom:
            configMapKeyRef:
              name: config-map-data
              key: NAME
        - name: AGE
          valueFrom:
            configMapKeyRef:
              name: config-map-data
              key: AGE
      command: ["sh", "-c", "echo $NAME $AGE && nginx -g 'daemon off;'"]

NAME 和 AGE 环境变量的值来自 ConfigMap config-map-data 中的键。
容器启动时将输出：bolawen 23（通过 kubectl logs [pod] 查看输出结果）。

用法三、从 Secret 中获取环境变量: 通过 valueFrom.secretKeyRef 引用 Secret 中的敏感数据。Secret 用于管理敏感数据，如密码、密钥等。你可以从 Secret 中安全地获取这些值并注入到环境变量中。

# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQ=  # base64 编码的 "password"

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: DB_PASSWORD

DB_PASSWORD 环境变量的值来自 Secret app-secret，其值为 password（cGFzc3dvcmQ= 是 base64 编码后的 "password"）。
容器内的应用程序可以通过 DB_PASSWORD 环境变量访问数据库密码（通过 kubectl logs [pod] 查看输出结果）。

用法四、通过 Downward API 获取 Pod 元数据: 通过 valueFrom.fieldRef 引用 Pod 的元数据（如名称、IP 地址等）。可以使用 Downward API 将 Pod 的元数据（如名称、节点名、UID 等）注入到环境变量中。

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP

POD_NAME 获取当前 Pod 的名称。
POD_IP 获取当前 Pod 的 IP 地址。

1.6 command

在 Kubernetes 中，command 和 args 用于定义容器启动时执行的命令及其参数。它们允许你自定义容器启动时的行为，而不依赖于容器镜像的默认启动命令。command 和 args 都是可选的，如果不提供，Kubernetes 将使用容器镜像中的默认入口点（entrypoint）和参数。

command 定义了容器启动时要运行的主要命令。如果没有指定 command，Kubernetes 会使用容器镜像中的默认命令（等同于 Docker 中的 ENTRYPOINT）。command 和 args 的结合使用可以覆盖镜像中的 ENTRYPOINT 和 CMD。command 等价于容器的入口点。如果你在 command 中定义多个字符串（如 ["sleep", "3600"]），Kubernetes 会认为这是一个完整的命令，并不会再使用 args 中的值作为参数。而 args 仅在没有完全覆盖 command 时作为参数使用。因此， command 可以指定命令来覆盖默认命令，当容器镜像的默认行为不符合预期，或者你希望为某些特定任务自定义命令时，可以使用 command 来完全覆盖镜像中的入口点。

语法

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["echo"]
    args: ["Hello, Kubernetes!"]

用法

一、同时指定 command 和 args

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["echo"]
    args: ["Hello, Kubernetes!"]

在这个例子中，Pod 启动时会执行 echo 命令，并输出 Hello, Kubernetes!。
command：覆盖了镜像中的默认入口点，使用 echo 命令。
args：为 echo 命令提供了参数 Hello, Kubernetes!。

二、仅指定 args

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    args: ["sleep", "3600"]

在这个例子中，Pod 会启动 busybox 容器的默认命令，并将 sleep 3600 作为参数传递给它。
如果 busybox 镜像的默认命令是 sh，那么这个 Pod 的行为就相当于执行 sh -c "sleep 3600"。

三、仅指定 command

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["sleep", "3600"]

在这个例子中，command 会覆盖镜像中的默认命令，直接执行 sleep 3600。
没有提供 args，因此不会有额外的参数。如果此时提供 args 参数，该参数不会生效。这是因为 command 字段中的命令是完整的，不再需要从 args 中获取参数。Kubernetes 在这种情况下会忽略 args，因为 command 已经包括了命令和参数。

1.7 args

args 是传递给 command 的参数列表。如果只定义了 args，而没有定义 command，Kubernetes 会使用容器镜像中的默认命令，并将 args 作为该命令的参数。（等同于 Docker 中的 CMD）。command 和 args 的结合使用可以覆盖镜像中的 ENTRYPOINT 和 CMD。如果你想使用镜像中的默认命令，但需要根据环境动态传递参数，可以仅使用 args。

语法

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["echo"]
    args: ["Hello, Kubernetes!"]

用法

一、同时指定 command 和 args

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["echo"]
    args: ["Hello, Kubernetes!"]

在这个例子中，Pod 启动时会执行 echo 命令，并输出 Hello, Kubernetes!。
command：覆盖了镜像中的默认入口点，使用 echo 命令。
args：为 echo 命令提供了参数 Hello, Kubernetes!。

二、仅指定 args

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    args: ["sleep", "3600"]

在这个例子中，Pod 会启动 busybox 容器的默认命令，并将 sleep 3600 作为参数传递给它。
如果 busybox 镜像的默认命令是 sh，那么这个 Pod 的行为就相当于执行 sh -c "sleep 3600"。

三、仅指定 command

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["sleep", "3600"]

在这个例子中，command 会覆盖镜像中的默认命令，直接执行 sleep 3600。
没有提供 args，因此不会有额外的参数。如果此时提供 args 参数，该参数不会生效。这是因为 command 字段中的命令是完整的，不再需要从 args 中获取参数。Kubernetes 在这种情况下会忽略 args，因为 command 已经包括了命令和参数。

1.8 resources

在 Kubernetes 中，你可以通过为 Pod 分配 CPU 资源来控制容器使用的计算能力。Kubernetes 使用资源请求 (requests) 和资源限制 (limits) 来管理和调度 CPU 资源。你可以为每个容器定义它需要的最小 CPU 资源以及允许使用的最大 CPU 资源。Kubernetes 会根据这些设置在节点上调度容器，确保资源分配符合预期。

Kubernetes 为 Pod 分配 CPU 资源: 在 Pod 的 spec.containers.resources 字段中，你可以设置 requests 和 limits：

requests：表示容器需要的最小资源量，确保容器能够正常运行。调度时基于此值来分配节点。
limits：表示容器使用的最大资源量，防止容器使用过多资源。如果容器试图使用超过此限制的资源，Kubernetes 将会对其进行限制（如通过 cgroup 限制 CPU 使用）。

Kubernetes 调度器处理逻:

调度：Kubernetes 调度器会根据 requests 来决定在哪个节点上运行 Pod。节点必须有足够的 CPU 来满足 Pod 的 requests，否则该 Pod 不会被调度到该节点。
资源限制：容器可以使用的 CPU 最多为 limits 设置的值。如果没有设置 limits，则容器可以使用节点上所有可用的 CPU 资源。

语法

apiVersion: v1
kind: Pod
metadata:
  name: cpu-requests-limits
spec:
  containers:
    - name: busybox
      image: busybox
      command: ["sh", "-c", "while true; do echo Hello, Kubernetes!; sleep 1; done"]
      resources:
        requests:
          cpu: "500m"   # 请求 0.5 核 CPU
        limits:
          cpu: "1"      # 限制最大使用 1 核 CPU

requests.cpu: 设置为 500m，表示这个容器需要至少 0.5 个 CPU 核才能正常工作。调度器会根据这个值确定是否可以在节点上运行该容器。
limits.cpu: 设置为 1，表示该容器最多可以使用 1 个 CPU 核。如果容器使用的 CPU 超过这个值，Kubernetes 会限制它的使用（比如通过 cgroup 限制 CPU 时间片的使用）。

1.9 volumeMounts

volumeMounts: 定义容器挂载的卷和挂载路径。mountPath 是在容器内部的挂载路径，name 对应 volumes 中定义的卷的名字。

1.10 livenessProbe

存活探针（Liveness Probe） 用于检查容器是否处于健康状态。如果存活探针失败，Kubernetes 会将容器重启。这对于那些可能在运行过程中出现崩溃或陷入死循环的应用非常有用。

语法

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: my-app
    image: my-app-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

livenessProbe: 检查 /healthz 端点，探测容器是否健康，若失败则重启容器。

1.11 readinessProbe

就绪探针（Readiness Probe） 用于决定容器是否可以接受流量或请求。它的作用是在应用程序准备好处理请求之前，阻止 Kubernetes 将流量路由到该容器。如果探针失败，Kubernetes 将从服务端点中移除该 Pod。

语法

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: my-app
    image: my-app-image
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

readinessProbe: 检查 /ready 端点，探测容器是否准备好接收请求。

1.12 startupProbe

启动探针（Startup Probe） 专门用于检测容器的启动阶段是否完成。它帮助处理那些启动时间较长的应用程序，确保应用完全启动后再执行 Liveness 和 Readiness 探针。

1.13 lifecycle

Pod 生命周期钩子（Hooks）: 在 Kubernetes 中，Pod 生命周期钩子（Lifecycle Hooks）是一组允许用户在容器的生命周期中指定特定操作的机制。这些钩子为在容器启动前或终止前执行定制逻辑提供了灵活性，从而帮助确保应用程序的平滑启动和优雅终止。

Kubernetes 提供了两种主要的生命周期钩子：

postStart 钩子：在容器启动后立即调用。容器已经创建并准备运行，但还没有开始处理请求或进入其主循环。因此, postStart 钩子可用于在应用程序正式启动前执行初始化任务，如注册服务、生成初始配置文件、检查依赖的服务状态等。
preStop 钩子：在容器被终止之前执行。容器终止前，Kubernetes 会首先调用 preStop 钩子，等待其完成或达到超时限制，然后再终止容器。因此，preStop 常用于优雅地关闭应用程序，保存状态，或释放资源，例如关闭连接、刷新缓存、通知其他服务等。比如说: preStop 钩子可以帮助应用程序在终止前完成必要的清理工作，例如关闭数据库连接、提交未完成的事务、通知其他服务等。通过 preStop 钩子，在应用程序终止前保存重要数据或状态，确保在应用重启或扩展时不会丢失重要信息。

Pod 生命周期钩子的执行方式

exec: 在容器内执行指定的命令。通常用于简单的操作或需要访问容器内部资源的任务。
httpGet: 向容器内的某个 HTTP 端点发起 GET 请求。通常用于触发应用程序的特定逻辑，例如通知应用程序它将要停止。

语法

apiVersion: v1 
kind: Pod 
metadata:
    name: lifecycle
spec:
    containers:
    - name: lifecycle
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:stable-otel-linux-arm64
      lifecycle:
        postStart:
          exec: 
            command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
        preStop:
            exec:
                command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]
      ports:
        - containerPort: 80

1.14 securityContext

1.15 stdin

1.16 tty

1.17 workingDir

二、volumes

volumes: 定义 Pod 中使用的卷，可以是多种类型的存储（例如 HostPath、ConfigMap、PersistentVolume 等）。

语法

volumes:
- name: config-volume
  configMap:
    name: my-config
- name: secret-volume
  secret:
    secretName: my-secret

三、initContainers

在 Kubernetes 中，InitContainers 是一种特殊类型的容器，它在主应用容器（通常称为Containers）启动之前运行。InitContainers 的主要目的是执行初始化任务，确保主应用容器在一个已准备好或已配置的环境中运行。它们有以下几个特点和应用场景:

InitContainers 特点

串行运行: InitContainers 在主容器启动之前按顺序运行。只有当所有 InitContainers 成功执行后，主容器才会启动。
与主容器隔离: 每个 InitContainer 都可以有与主容器不同的镜像、资源请求/限制、环境变量和其他配置。InitContainers 具有独立的文件系统，与主容器的文件系统隔离，除非通过卷共享。
执行初始化任务: InitContainers 通常用于执行一些初始化任务，如:
- 等待资源的准备：等待一个依赖的服务或资源（如数据库、缓存等）变为可用。
- 配置文件的生成：在主容器启动之前，生成或下载配置文件。
- 数据迁移或检查：进行数据迁移或一致性检查，确保主容器的运行环境是合适的。
- 预拉取依赖：下载主容器需要的依赖，避免在主容器启动后占用其启动时间。
重试机制: 如果某个 InitContainer 失败，Kubernetes 会重试运行它，直到成功或达到预定义的重启策略上限。这种机制确保了主容器只在适当的条件下启动。

InitContainers 场景

服务依赖等待：在微服务架构中，确保一个服务只有在它依赖的其他服务准备就绪后才启动。
安全性：执行一些安全检查或验证操作，防止主容器在不安全的条件下启动。
配置初始化：为主容器生成所需的配置文件，或根据运行环境动态调整配置。

通过将初始化任务分离到 InitContainers 中，主容器的启动逻辑可以简化，减少在主容器代码中处理复杂初始化逻辑的需求。

语法

3.1 name

3.2 image

3.3 command

四、restartPolicy

在 Kubernetes 中，restartPolicy 是 Pod 的一种重要重启策略，用于控制 Pod 内部容器的重启行为。restartPolicy 决定了当容器失败时，Kubernetes 如何处理容器的重启。它是 Pod 的 spec 部分中的一个字段，能够影响容器的生命周期。restartPolicy 的默认值是 Always，但是根据应用的需求，可以设置为其他值。restartPolicy` 的三种取值:

Always：表示容器无论是由于什么原因退出，都会被重新启动。这是默认的策略，适用于长期运行的服务（如 Web 服务或数据库）。只要 Pod 没有被删除或手动停止，容器就会一直保持重新启动状态。使用场景: 对于希望 Pod 始终保持运行的应用，尤其是后台服务，建议使用 Always。
OnFailure：只有当容器退出代码非 0（表示异常退出）时才会重启容器。如果容器正常退出（退出码为 0），则不会进行重启。这一策略适用于那些在非正常状态下需要重新启动的应用。使用场景: 用于批处理任务或有明确退出码标志的应用程序。例如，当任务处理失败时重启 Pod。
Never: 容器不管以什么状态退出，都不会重新启动。这种策略适用于那些需要只运行一次的任务型 Pod。使用场景: 适用于一次性运行的作业或任务，当任务完成后不再需要重启。

语法

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: my-app-image
  restartPolicy: OnFailure

五、terminationGracePeriodSeconds

六、activeDeadlineSeconds

七、dnsPolicy

八、nodeSelector

九、affinity

在 Kubernetes 中，亲和性调度（Affinity Scheduling） 是一种强大且灵活的机制，用于控制 Pod 如何被调度到特定的节点或与其他 Pod 之间的关系。通过使用亲和性，您可以优化资源利用、提高应用的可靠性和性能。

亲和性调度 允许您定义 Pod 与节点或其他 Pod 之间的调度规则。这些规则可以基于标签、拓扑域（如区域、可用区、主机名）等，以确保 Pod 被调度到最合适的位置。Kubernetes 提供了以下几种亲和性类型：

节点亲和性（Node Affinity）：控制 Pod 调度到哪些节点。
Pod 亲和性（Pod Affinity）：控制 Pod 被调度到与特定标签的其他 Pod 相同的节点或拓扑域。
Pod 反亲和性（Pod Anti-Affinity）：控制 Pod 被调度到与特定标签的其他 Pod 不同的节点或拓扑域。

语法

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - disk1
  containers:
    - name: nginx
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:1.27.1-perl-linux-arm64
      imagePullPolicy: IfNotPresent

9.1 nodeAffinity

节点亲和性（Node Affinity） 允许您指定 Pod 应该被调度到哪些节点，或者哪些节点更适合运行该 Pod。节点亲和性分为必需（required）和偏好（preferred）两种类型：

语法

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - disk1
  containers:
    - name: nginx
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:1.27.1-perl-linux-arm64
      imagePullPolicy: IfNotPresent

场景

场景一、必须亲和性: 必需的节点亲和性 （Required Node Affinity） 这是一个硬性约束，Pod 只能被调度到满足条件的节点上。如果没有符合条件的节点，Pod 将无法调度成功。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd
  containers:
    - name: nginx
      image: registry.cn-hangzhou.aliyuncs.com/bolawen/nginx:1.27.1-perl-linux-arm64
      imagePullPolicy: IfNotPresent

场景二、偏好亲和性: 偏好的节点亲和性（Preferred Node Affinity） 这是一个软性约束，表示调度器会优先选择满足条件的节点，但如果没有符合条件的节点，Pod 仍然可以被调度到其他节点上。

apiVersion: v1
kind: Pod
metadata:
  name: preferred-node-affinity-pod
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: region
            operator: In
            values:
            - us-west
  containers:
  - name: app-container
    image: nginx

9.2 podAffinity

9.3 podAntiAffinity

Pod 亲和性（Pod Affinity） 允许 Pod 被调度到与具有特定标签的其他 Pod 相同的节点或拓扑域，而 Pod 反亲和性则相反，防止 Pod 被调度到与具有特定标签的其他 Pod 相同的节点或拓扑域。

一、containers​

1.1 name​

1.2 image​

1.3 imagePullPolicy​

1.4 ports​

1.5 env​

1.6 command​

1.7 args​

1.8 resources​

1.9 volumeMounts​

1.10 livenessProbe​

1.11 readinessProbe​

1.12 startupProbe​

1.13 lifecycle​

1.14 securityContext​

1.15 stdin​

1.16 tty​

1.17 workingDir​

二、volumes​

三、initContainers​

3.1 name​

3.2 image​

3.3 command​

四、restartPolicy​

五、terminationGracePeriodSeconds​

六、activeDeadlineSeconds​

七、dnsPolicy​

八、nodeSelector​

九、affinity​

9.1 nodeAffinity​

9.2 podAffinity​

9.3 podAntiAffinity​