containers

2024年11月13日

柏拉文

越努力，越幸运

一、containers

1.1 认识

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

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

1.2 语法

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

二、name

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

三、image

3.1 认识

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

3.2 语法

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

四、imagePullPolicy

4.1 认识

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

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

4.2 规则

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

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

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

4.3 语法

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

五、ports

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

六、env

6.1 认识

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

6.2 语法

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] 查看输出结果）。

6.3 用法

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

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 地址。

七、command

7.1 认识

在 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 来完全覆盖镜像中的入口点。

7.2 语法

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

7.3 用法

一、同时指定 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 已经包括了命令和参数。

八、args

8.1 认识

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

8.2 语法

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

8.3 用法

一、同时指定 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 已经包括了命令和参数。

九、resources

9.1 认识

在 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 资源。

9.2 语法

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 时间片的使用）。

十、volumeMounts

10.1 认识

在 Kubernetes 中，volumeMounts 是一种将卷（volume）挂载到容器文件系统中的方式。通过 volumeMounts，容器可以访问指定的存储，存储数据和配置文件，或在容器之间共享数据。volumeMounts 通常与 Pod 中的 volumes 配合使用，定义卷的类型和属性，然后将这些卷挂载到各容器中。

10.2 参数

name: 指向 Pod 中定义的 volumes 的名字。name: config-volume 指向一个名为 config-volume 的卷。
mountPath: 定义在容器中的挂载路径，即卷在容器文件系统中的位置。挂载到 mountPath 的路径下的原内容将被替换，需确保路径无关紧要或为空。mountPath: /app/config 表示把卷挂载到 /app/config 路径。
readOnly: 控制挂载的卷是否只读。需要共享配置文件等无需修改的内容。readOnly: true 表示只读挂载，容器无法修改卷内容。
subPath: 指定卷内的子路径，将子路径挂载到 mountPath，而不是整个卷。一个卷中包含多个文件或目录，且容器只需要其中的一部分。subPath: myconfig.conf 表示只挂载 myconfig.conf 文件，而非整个卷。
mountPropagation: 控制卷的挂载传播，适用于特权模式容器。数据从宿主机传递到容器，或需要挂载更新的高共享性环境。mountPropagation: Bidirectional 允许容器和宿主机共享卷挂载的变化。

10.3 语法

apiVersion: v1
kind: Pod
metadata:
  name: volume-mount-demo
spec:
  volumes:
    - name: config-volume
      configMap:
        name: my-configmap   # 这里引用了一个 ConfigMap 卷
    - name: data-volume
      emptyDir: {}           # 使用临时存储卷
  containers:
    - name: myapp-container
      image: nginx
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
          readOnly: true
        - name: data-volume
          mountPath: /var/www/data

10.4 用法

场景一、配置文件: 将配置文件或环境变量（通过 ConfigMap 或 Secret）挂载到容器，使容器能够读取所需的配置。在这个配置中，容器可以从 /etc/config 读取 ConfigMap 中的配置文件，确保了配置文件的内容只读、不被更改的需求。

apiVersion: v1
kind: Pod
metadata:
  name: config-volume-demo
spec:
  volumes:
    - name: config-volume
      configMap:
        name: my-config   # 引用的 ConfigMap 名称
  containers:
    - name: myapp
      image: busybox
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
          readOnly: true  # 以只读方式挂载配置
      command: ["cat", "/etc/config/config-file"]

场景二、持久存储: 将数据存储卷（如 PersistentVolume）挂载到容器，保证数据即使在 Pod 重启后仍然可用。

场景三、日志共享: 使用 emptyDir 等临时卷在多容器的 Pod 中共享日志文件。

apiVersion: v1
kind: Pod
metadata:
  name: empty-dir-volume-demo
spec:
  volumes:
    - name: empty-dir-volume
      emptyDir: {}
  containers:
    - name: myapp
      image: busybox
      volumeMounts:
        - name: empty-dir-volume
          mountPath: /data/log
      command: ["cat", "/etc/config/config-file"]

场景四、文件覆盖: 将文件内容覆盖到容器的某些路径中，替换容器镜像中默认的文件。

十一、livenessProbe

11.1 认识

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

11.2 语法

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 端点，探测容器是否健康，若失败则重启容器。

十二、readinessProbe

12.1 认识

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

12.2 语法

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 端点，探测容器是否准备好接收请求。

十三、startupProbe

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

十四、lifecycle

14.1 认识

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

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

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

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

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

14.2 语法

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

十五、securityContext

15.1 认识

在 Kubernetes 中，securityContext 是一个用于配置 Pod 和容器安全性的选项。通过 securityContext，用户可以指定一些安全性参数来控制容器的权限、执行环境和行为，从而提高集群的安全性。securityContext 可以在 Pod 级别和容器级别进行配置。

Pod 级别：应用于整个 Pod 中的所有容器。
容器级别：只应用于特定容器，并覆盖 Pod 级别的设置。

15.2 参数

容器级别配置项:

runAsUser: 指定运行容器的用户 ID (UID)。避免使用 root 用户，减少权限，提升安全性。runAsUser: 1000 表示容器中的进程将以 UID 为 1000 的用户身份运行，而不是默认的 root 用户。
runAsGroup: 指定运行容器的组 ID (GID)。控制进程组权限，便于与文件系统权限配合。runAsGroup: 3000 表示进程将以 GID 为 3000 的组身份运行。
fsGroup: 为挂载的卷和持久存储指定一个组 ID，使得该组对文件系统有读写权限。确保卷中的数据可以被进程访问，尤其适用于持久化存储。fsGroup: 2000 表示挂载卷中的文件将属于 GID 为 2000 的组。
allowPrivilegeEscalation: 控制容器进程是否可以获取更高权限（例如 sudo）。防止容器内进程使用漏洞获取 root 权限，提升安全性。allowPrivilegeEscalation: false 表示禁止权限提升。
privileged: 是否允许容器以特权模式运行。启用特权模式可访问宿主机设备，适用于需要直接访问宿主机的特殊场景，但应谨慎使用。privileged: true 允许容器拥有访问宿主机的所有设备权限。
capabilities: 定义容器的特定 Linux 功能集，允许添加或移除权限。精细控制容器权限，只保留必要的权限，减少潜在的攻击面。
readOnlyRootFilesystem: 指定容器的根文件系统是否只读。限制容器修改根文件系统中的内容，增强安全性。readOnlyRootFilesystem: true 表示根文件系统为只读模式。
seccompProfile: 定义 seccomp（安全计算模式）配置文件，以限制系统调用。限制容器对某些系统调用的访问，进一步降低潜在风险。
runAsNonRoot: 确保容器不会以 root 用户身份运行。强制容器使用低权限用户，提升安全性。runAsNonRoot: true 表示容器必须使用非 root 用户。

通过合理配置 securityContext，可以增强容器的安全性，限制不必要的权限和访问，从而降低潜在的攻击面。

15.3 语法

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  containers:
  - name: myapp
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      fsGroup: 2000
      allowPrivilegeEscalation: false
      privileged: false
      capabilities:
        add: ["NET_ADMIN"]
        drop: ["MKNOD"]
      readOnlyRootFilesystem: true
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true

一、containers​

1.1 认识​

1.2 语法​

二、name​

三、image​

3.1 认识​

3.2 语法​

四、imagePullPolicy​

4.1 认识​

4.2 规则​

4.3 语法​

五、ports​

六、env​

6.1 认识​

6.2 语法​

6.3 用法​

七、command​

7.1 认识​

7.2 语法​

7.3 用法​

八、args​

8.1 认识​

8.2 语法​

8.3 用法​

九、resources​

9.1 认识​

9.2 语法​

十、volumeMounts​

10.1 认识​

10.2 参数​

10.3 语法​

10.4 用法​

十一、livenessProbe​

11.1 认识​

11.2 语法​

十二、readinessProbe​

12.1 认识​

12.2 语法​

十三、startupProbe​

十四、lifecycle​

14.1 认识​

14.2 语法​

十五、securityContext​

15.1 认识​

15.2 参数​

15.3 语法​

十六、stdin​

十七、tty​

十八、workingDir​