Lazy loaded image
运维管理
k8s Pod 和容器管理
Words 7023Read Time≈ 18 min
2025-12-8
2025-12-8
date
related_level
slug
type
relate_date
summary
status
tags
category
last_updated
Dec 8, 2025 10:16 AM
是否已更新
orginal_page
是否推荐

Pod 生命周期

参考资料
Pod 生命周期的特性
  • Pod 仅被调度一次，调度后绑定到特定节点
    • 调度：选择使用哪个节点的过程
      • SchedulingGates 机制可延迟 Pod 调度，直到满足特定条件
        • 如所有相关 Pod 创建完成
    • 绑定：将 Pod 分配到特定节点
  • 若绑定的节点无法启动 Pod（如崩溃），则此 Pod 永不运行
  • kubelet 负责在节点上管理 Pod，包括重启容器以应对故障，并根据容器状态决定恢复动作
故障与故障恢复
  • 分为容器故障，Pod 故障，节点故障
    • 容器故障时，可能会尝试重启特定的容器
    • Pod 故障时，Kubernetes 会删除 Pod 并依赖其他组件如控制器提供自动修复
    • 节点故障时，Pod 会被视为不健康，最终被删除
  • 故障恢复
    • 被删除的 Pod 不会被重新调度，而是被一个新的、几乎完全相同的 Pod 替换掉
      • 替换 Pod 将具有与旧 Pod 不同的 .metadata.uid
    • 不保证现有 Pod 的替换 Pod 会被调度到与被替换的旧 Pod 相同的节点
spec.schedulingGates 控制 Pod 何时准备好被纳入考量进行调度
参考资料
  • 通过 patch 去除 spec.schedulingGates 来恢复调度
    • kubectl patch pod <pod-name> --type='json' -p='[{"op": "remove", "path": "/spec/schedulingGates"}]'
spec.schedulingGates 样例
Pod 顶级字段 status 主要包含 phase, conditions, containerStatuses
phase 字段简要描述 Pod 当前运行状态
阶段
说明
Pending
Pod 已被 API Server 接受，但： • 尚未调度到节点（如资源不足、调度门控） • 或正在拉取镜像/挂载卷等初始化操作
Running
Pod 已成功绑定到节点，且至少有一个容器已启动 • Init 容器已完成 • 主容器可能仍在启动或已就绪（包括重启）
Succeeded
Pod 中所有容器均已成功终止（退出码为 0），且不会重启 → 通常用于 Job/CronJob 的一次性任务
Failed
Pod 中至少有一个容器以非零退出码终止，且不会重启 → 表示任务失败 → 节点失联会导致该节点所有 Pod 变为 Failed
Unknown
无法获取 Pod 状态（如节点失联、kubelet 无响应） → 通常是节点通信故障导致
注意，kubectl 显示的 status 不等于 phase
  • kubectl 命令的 Status 字段中可能会出现 Terminating 或 CrashLoopBackOff
  • conditions 字段详细描述 Pod 当前运行状态
conditions[].type 内置可用值
  • PodScheduled：Pod 已经被调度到某节点
PodReadyToStartContainers：Pod 沙箱被成功创建并且配置了网络
  • 需要启用 PodReadyToStartContainersCondition 特性门控
    • 1.34 起默认启用
  • 状态为 False 的典型场景：
    • Pod 刚被调度，沙箱尚未创建
    • 节点重启后 Pod 沙箱被销毁但未重建
    • 使用 VM 隔离的运行时（如 Kata Containers）中沙箱重启期间
  • 与 Initialized 状况的关系：
    • 无 Init 容器的 Pod：Initialized 在沙箱创建前设为 True
    • 有 Init 容器的 Pod：Initialized 在 Init 容器成功完成后才设为 True
  • Initialized：所有的 Init 容器都已成功完成
  • ContainersReady：Pod 中所有容器都已就绪
  • Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中
  • DisruptionTarget：由于干扰（例如抢占、驱逐或垃圾回收），Pod 即将被终止
  • PodResizePending：已请求对 Pod 进行调整大小，但尚无法应用
  • PodResizeInProgress：Pod 正在调整大小中
通过 spec.readinessGates 引用 conditions 数组中自定义类型的 condition
  • 如果需要设置 Pod 的 status.conditions，应用或者 Operators 需要使用 PATCH 操作
    • 命令 kubectl patch 不支持修改对象的状态
  • 对于 PodConditions 的 Pod 而言，只有满足以下条件时才会被评估为就绪：
    • Pod 中所有容器都已就绪
    • readinessGates 中的所有 Condition 的 status 都为 True 值
      • 如果无法在 status.conditions 字段中找到该自定义类型的 Condition，则状态值默认为 False
  • 当 Pod 的容器都已就绪，但至少一个定制状况没有取值或者取值为 False， kubelet 将 Pod 的状况设置为 ContainersReady
spec.readinessGates 样例
容器状态 containerStatuses 字段：Waiting, Running, Terminated
  • Waiting
    • 容器仍在运行它完成启动所需要的操作
    • Reason 字段给出了容器处于等待状态的原因
  • Running
    • 容器正在执行状态并且没有问题发生
  • Terminated
    • 容器开始执行后，运行至正常结束或者因为某些原因失败
phase 与 conditions 的关系
  • phase 是 Pod 正处在哪个大阶段；conditions 解释了它为什么在这个阶段以及它当前的详细健康状态
  • phase 不反映容器探针状态（返回 Failure 不会直接改变 phase，running 也不区分 readinessProbe 是否就绪），也不区分是否被驱逐
    • 即使不断 CrashLoopBackOff，phase 也仍然是 Running
Pod 终止关键机制
  • Pod 删除时不会直接被强杀，而是进入体面终止流程
    • 默认 terminationGracePeriodSeconds 为 30 秒
  • kubelet 会在宽限期内向容器主进程发送 SIGTERM（或镜像定义的 STOPSIGNAL），让进程有机会执行清理
  • 容器运行时按异步方式处理停止请求，顺序不保证
  • 若在体面终止限期内仍未退出，则发送 SIGKILL 强制终止，并从 API Server 中删除 Pod
  • 若 kubelet/运行时在终止中途重启，Pod 会重新获得完整宽限期
停止信号可由镜像的 STOPSIGNAL 指令定义，默认是 SIGTERM
  • 支持在 Pod Lifecycle 中配置自定义停止信号（需开启 ContainerStopSignals feature gate），但 Windows 节点仅支持 SIGTERM 与 SIGKILL
自定义停止信号样例
Pod 正常终止流程
  1. 触发删除：通过 kubectl delete 标记 Pod 为 Terminating
  1. kubelet 开始关闭本地节点 Pod
      • 看到 Pod 进入终止状态后，kubelet 开始本地终止流程
      • 若容器定义了 preStop hook 且 terminationGracePeriodSeconds 不为 0，先执行 preStop
      • 若 preStop 超时，kubelet 会额外给一次性 2 秒延长
  1. kubelet 发送 TERM 信号
      • kubelet 让容器运行时向各容器的 PID 1 发送 SIGTERM
      • 若有 Sidecar，主容器先终止，Sidecar 按逆序延迟终止；否则容器之间顺序不保证
  1. 控制面同时将 Pod 从服务中移除
      • 在 kubelet 开始关闭的同时，控制面逐步把终止中的 Pod 从 EndpointSlice 中移除
        • 不会立即从 EndpointSlice 中被删除，正在终止的会标记为 ready=false，因此不会再接收新流量
      • 需要排空流量的应用可以结合 serving 状态实现更优雅的流量下线
  1. 强制终止
      • 若宽限期结束仍未退出：
        • kubelet 向所有容器发送 SIGKILL
        • 清理 pause 容器
      • kubelet 设置 Pod 为完成阶段（Succeeded/Failed）
      • kubelet 将 terminationGracePeriodSeconds 改为 0，请求 API Server 立即删除 Pod 对象
  1. API Server 删除 Pod 对象
      • Pod 完全从集群状态中移除
kubectl delete --force 强制终止，不等待 kubelet 确认，可能导致节点上残留进程
  • --grace-period=0 立即强制终止
    • 默认 terminationGracePeriodSeconds 为 30 秒
Pod 垃圾回收机制
  • 在 Pod 个数超出所配置的阈值时自动清理已终止 Pod，避免资源泄露
    • 阈值由 terminated-pod-gc-threshold 控制
    • pod 的 status.phase 为 Succeeded/Failed
  • 同时也会清理满足以下任一条件的 Pod：
    • 孤儿 Pod（绑定到已不存在的节点）
      • 清理孤儿 Pod 时会添加 DisruptionTarget 状况
    • 计划外终止的 Pod
    • 绑定到带 node.kubernetes.io/out-of-service 污点的未就绪节点上的 Pod
  • 清理非终止状态阶段 Pod 时会将其标记为失败

Pod 容器生命周期管理

Kubernetes 通过指数级回退（CrashLoopBackOff）机制来处理容器异常退出
  • 每次崩溃会导致重启间隔增加，从 10s → 20s → 40s 直到上限 300s
    • 容器连续正常运行 10 分钟后重置计数器
通过特性门控调整容器重启延迟
  • 均为默认禁用
开启 ReduceDefaultCrashLoopBackOffDecay 特性门控减少容器重启延迟
  • 集群中容器启动重试的初始延迟将从 10 秒减少到 1 秒， 之后每次重启延迟时间按 2 倍指数增长，直到达到最大延迟 60 秒（之前为 300 秒，即 5 分钟）
开启 KubeletCrashLoopBackOffMax 特性门控配置容器启动重试之间的最大延迟
  • 需要针对每个节点使用 kubelet 配置进行设置 crashLoopBackOff.maxContainerRestartPeriod
    • 默认值为 300 秒（5 分钟）
    • 取值范围在 "1s" 到 "300s" 之间
  • 配置样例
    容器崩溃处理流程
    1. 首次崩溃：按 restartPolicy 立即重启。
    1. 反复崩溃：进入指数回退（）。
    1. CrashLoopBackOff 状态：表示容器不断启动失败，回退计时生效中。
    1. 回退重置：容器连续正常运行 10 分钟后，再次崩溃将视为首次崩溃。
    引发 CrashLoopBackOff 的常见原因
    • 应用程序错误导致的容器退出
    • 配置错误，如环境变量不正确或配置文件丢失
    • 资源限制，容器可能没有足够的内存或 CPU 正常启动
    • 如果应用程序没有在预期时间内启动服务，健康检查就会失败
    • 容器的存活探针或者启动探针返回 Failure 结果
    容器崩溃排查方式
    1. 检查日志：使用 kubectl logs <pod名称> 检查容器的日志。 这通常是诊断导致崩溃的问题的最直接方法
    1. 检查事件：使用 kubectl describe pod <pod名称> 查看 Pod 的事件， 这可以提供有关配置或资源问题的提示
    1. 审查配置：确保 Pod 配置正确无误，包括环境变量和挂载卷，并且所有必需的外部资源都可用
    1. 检查资源限制： 确保容器被分配了足够的 CPU 和内存。有时，增加 Pod 定义中的资源可以解决问题
    1. 调试应用程序：应用程序代码中可能存在错误或配置不当。 在本地或开发环境中运行此容器镜像有助于诊断应用程序的特定问题
    spec.restartPolicy 指定容器重启策略：Always, OnFailure, Never
    • Always：只要容器终止就自动重启容器
      • 默认
    • OnFailure：只有在容器错误退出（退出状态非零）时才重新启动容器
    • Never：不会自动重启已终止的容器
    启用 ContainerRestartRules 特性门控可以针对单个容器指定 containers[].restartPolicy, containers[].restartPolicyRules
    restartPolicyRules 定义了一系列在容器退出时应用的规则
    • 规则会按顺序进行评估
      • 一旦匹配成功，立即执行相应动作
      • 没有任何规则的状况被匹配，回退到容器配置的 restartPolicy
    •  支持的动作是 Restart，表示容器将被重启
    • 支持的条件是 exitCodes，用于将容器的退出码与给定值列表进行比较
    restartPolicyRules 样例
    探针(Probe) 是由 kubelet 对容器执行的定期诊断
    参考资料
    三种探针类型：livenessProbe, readinessProbe, startupProbe
    livenessProbe：判断容器是否存活
    • 如果容器不提供 livenessProbe， 则默认状态为 Success
    • 如果 livenessProbe 探测失败，则 kubelet 会杀死容器， 并且容器将根据其 restartPolicy 决定未来
    readinessProbe：判断是否能接收流量
    • 如果容器不提供 readinessProbe， 则默认状态为 Success
    • 初始延迟之前的 readinessProbe 的状态值默认为 Failure
    • 如果 livenessProbe 探测失败， EndpointSlice 控制器将从与该 Pod 匹配的所有 Service 的 EndpointSlice 中删除该 Pod 的 IP 地址
    startupProbe：判断应用是否已经成功启动；若配置了它，其他探针在其成功前不会运行
    • 如果容器不提供 startupProbe， 则默认状态为 Success
    • 如果 startupProbe 探测失败，则 kubelet 会杀死容器， 并且容器将根据其 restartPolicy 决定未来
    不同探针的使用场景
    • livenessProbe：希望进程异常时自动被重启；若程序能自动崩溃并退出则可不配置。
    • readinessProbe：希望 Pod 只有就绪后才接收流量；可用于依赖后端服务、延迟加载数据、维护模式等。
    • startupProbe：适用于启动时间较长的应用，避免 livenessProbe 因启动慢而误杀容器
      • initialDelaySeconds + periodSeconds * failureThreshold 决定必须成功的总时间
        • 如果 successThreshold 为 1
      • 如果启动时间超过该时间可以考虑配置 startupProbe 而不是调高 livenessProbe 的参数
    四种机制实现：exec, gRPC, httpGet 或 tcpSocket
    • exec 在容器内执行指定命令
      • 如果命令退出时返回码为 0 则认为诊断成功
    • gRPC 执行一个远程过程调用，目标应该实现 gRPC 健康检查
      • 如果响应的状态是 "SERVING"，则认为诊断成功
    • httpGet 对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求
      • 如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的
    • tcpSocket 对容器的 IP 地址上指定端口 TCP 检查
      • 如果端口打开，则诊断被认为是成功的
      • 如果容器在打开连接后立即将其关闭，这算作是健康的
    exec 探针的实现涉及每次执行时创建/复制多个进程，可能会增加节点的 CPU 负载
    • 在集群中具有较高 pod 密度、较低的 initialDelaySeconds 和 periodSeconds 时长的时候， 请考虑使用其他探针机制以避免额外的开销
    三种探测结果：Success, Failure, Unknown
    • Success 容器通过了诊断
    • Failure 容器未通过诊断
    • Unknown 诊断失败，因此不会采取任何行动
    probe 诊断配置参数
    • initialDelaySeconds：开始探测前等待多久
    • periodSeconds：每隔多久探测一次（默认 10 秒）
    • timeoutSeconds：探针等待容器响应的最大秒数（默认 1 秒），超过这个时间则视为失败
    • successThreshold：连续成功多少次后认为存活（默认 1 次）
    • failureThreshold：连续失败多少次后认为存活失败（默认 3 次）
    • terminationGracePeriodSeconds：Pod 优雅终止时间（默认 30 秒）
      • 探针层面的 terminationGracePeriodSeconds 优先于 Pod 层面
    probe 规范
    • probeType：livenessProbe, readinessProbe, startupProbe
    • 四种机制具体规范
      • exec.command
      • grpc.port
        • gRPC 探针不支持使用命名端口
      • grpc.service
      • httpGet.host
      • httpGet.port
      • httpGet.path
      • httpGet.httpHeaders[].name
      • httpGet.httpHeaders[].value
      • httpGet.scheme：HTTP, HTTPS
      • tcpSocket.host
      • tcpSocket.port
    • 诊断参数
      • timeoutSeconds
      • successThreshold
      • failureThreshold
      • initialDelaySeconds
      • periodSeconds
      • terminationGracePeriodSeconds
    livenessProbe httpGet 样例
    livenessProbe exec 样例
    livenessProbe tcp 样例
    livenessProbe gRPC 样例
    startupProbe 样例
     

    特殊 Pod 和容器类型

    静态 Pod（Static Pod）通常绑定到某个节点上的 kubelet，用于部署自托管的控制平面组件
    pod 命名以所在的 node 名称结尾
    • <pod-name>-<nodename>
    配置声明文件存放路径
    • /etc/kubernetes/manifests
      • 默认路径
    • 或者 kubelet 的 StaticPodPath 参数指定路径
      • cat /var/lib/kubelet/config.yaml | grep StaticPodPath
    • 或者 Kubeconfig 的 StaticPodPath 指定路径
    • 直接由特定节点上的 kubelet 守护进程管理， 不需要 API 服务器看到它们
      • 大多数 Pod 都是通过控制平面（例如，Deployment） 来管理的
      • 对于静态 Pod 而言，kubelet 直接监控每个 Pod，并在其失效时重启之
      • metadata.ownerReferences 显示为 kind: node
    • kubelet 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个镜像 Pod
      • 这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制
    Static Pod 样例
    • vim /etc/kubernetes/manifests/static-web.yaml
    init container 在 Pod 内的应用容器启动之前运行
    • 通过 spec.initContainers 字段添加 init container
      • restartPolicy: Never
    多个 init 容器按顺序逐个运行，全部成功后启动 Pod 应用容器
    • 如果 Pod 的 init 容器失败，kubelet 会不断地重启该 init 容器直到该容器成功为止
    • 如果 Pod 对应的 restartPolicy 值为 "Never"，并且 init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败
    • 如果 Pod 重启，所有 init 容器必须重新执行
    • 因为 init 容器可能会被重启、重试或者重新执行，所以 init 容器的代码应该是幂等的
    与普通 containers 区别
    • 与主应用容器共享资源（CPU、内存、网络），但不直接与主应用容器进行交互
      • 因为 init container 在主容器启动之前就终止了
    • 不支持 lifecycle、livenessProbe、readinessProbe 或 startupProbe 字段
      • 除非设置 restartPolicy: Always 字段改为 sidecar container
    所有 init container 的 resources 最大值作为 Pod 初始有效 requests/limits
    • init container 顺序执行，只取最大值
    • Pod 对资源的有效 limit/request 是如下两者中的较大者
      • 所有应用容器对某个资源的 limit/request 之和
      • 对某个资源的初始有效 limit/request
    init container 样例
    • 第一个等待 myservice 启动， 第二个等待 mydb 启动
    sidecar container 作为一种特殊的 init container 提供额外的服务或功能
    参考资料
    • 通过指定 spec.initContainers.restartPolicy: Always 来设置
      • sidecar container 完成后不终止而是继续运行
    sidecar container 具有独立的生命周期，可以独立于应用容器启动、停止和重启
    • 在整个 Pod 的生命周期内启动并持续运行
      • 可以更新、扩展或维护 sidecar container，而不影响主应用
    •  与 Init container 不同， sidecar container 支持 probe 来控制其生命周期
      • 可定义 readinessProbe，其就绪状态会影响整个 Pod 的 Ready 状态
    • 启动和终止遵循 init container 的顺序执行语义
      • 只有当前一个 init container（包括 sidecar）被标记为“已启动”（通过进程运行或 startupProbe 成功），下一个才会启动
      • 终止时延迟关闭，直到主应用容器完全停止，并按反向顺序终止
    sidecar container 可以直接与主应用容器交互
    • 与应用容器共享相同的网络，可以共享卷（文件系统）
    • init container 无法与 Pod 中的应用容器交互，只能单向传递给主容器传递数据
      • 因为 init container 在主容器启动之前就终止了
    sidecar container 样例
    ephemeral container 用于调试正在运行的 Pod
    参考资料
    ephemeral container 特点：临时性，共享运行时环境，无资源保障
    • 不会持久化到 Pod Spec，重启 Pod 后消失
    • 缺少对资源或执行的保证，并且永远不会自动重启
      • 不支持 resources、ports、livenessProbe 等字段
    静态 Pod 不支持 ephemeral container
    • 静态 Pod 由 kubelet 本地管理，kube-apiserver 看到的是只读镜像
    • ephemeral container 是通过 Kubernetes API 向 API Server 发起请求，然后由 kubelet 在运行时动态注入到 Pod 中
    • 只能动态创建，定义位于 spec.ephemeralContainers 字段
    kubectl debug --target 创建 ephemeral container
    • kubectl run ephemeral-demo --image=registry.k8s.io/pause:3.1 --restart=Never
    • kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
      • --target 参数指定另一个容器的进程命名空间
        • CRI 必须支持 --target 参数
        • 如果不支持，则临时容器可能不会启动，或者可能使用隔离的进程命名空间启动， 导致 ps 不显示其他容器内的进程
     

    配置容器运行参数和环境

    Kubernetes Pod 容器中的 command, args 与 docker compose 类似但存在重要区别
    • 当 dockerfile 定义了 ENTRYPOINT + CMD 时，Pod containers 里的定义会覆盖对应部分而不影响另外一个
      • docker run 的指令会完全替代 dockerfile 镜像的 CMD
      • docker 可以通过 --entrypoint 选项单独覆盖 ENTRYPOINT
    kubectl run 配置 command, args
    • kubectl run <pod-name> \ --image=<image> \ --command \ -- <arg1> <arg2>
      • --command 完全替换 ENTRYPOINT，默认为 false
    • kubectl run <name> --image=<image> --args="--arg1 value1" --args="--arg2 value2"
      • --args 配置 CMD，必须放在 image 后
      • 每个参数单独用一个 --args，不要合并
    容器配置环境变量值的三种方法：env.value 直接定义，env.valueFrom 引用，envFrom 导入 configmap 或 secret
    • env: name: <key> value: <value>
    env[].valueFrom.configMapKeyRef, secretKeyRef 引用 configmap 或 secret 的某项作为单个变量
    • env: name: <key> valueFrom: configMapKeyRef: name: <configmap-name> key: <configmap-key>
    • env: name: <key> valueFrom: secretKeyRef: name: <secret-name> key: <secret-key>
    env[].valueFrom.fieldRef, resourceFieldRef 引用 Pod 或者容器信息作为环境变量
    fieldRef.fieldPath 支持以下字段
    • metadata.name
    • metadata.namespace
    • metadata.labels['<KEY>']
    • metadata.annotations['<KEY>']
    • spec.nodeName
    • spec.serviceAccountName
    • status.hostIP
    • status.podIP
    • status.podIPs
    resourceFieldRef.resource 目前仅支持资源限制和请求
    • limits.cpu
    • limits.memory
    • limits.ephemeral-storage
    • requests.cpu
    • requests.memory
    • requests.ephemeral-storage
    fieldRef 样例
    resourceFieldRef 样例
    envFrom 导入 configmap 或 secret 全部数据作为变量列表
    需要对应内容均为单值而非复杂对象
    • envFrom: - configMapKeyRef: name: <configmap-name>
    • envFrom: - secretKeyRef: name: <secret-name>
    容器 volumes 读取 configmap 或 secret 作为配置文件，volumeMounts 挂载对应配置文件到指定路径
    • spec.volumes[i].name 要与 spec.containers[i].volumeMounts.name 一致
    • 注意，volumes 读取 secret 的 key 名称为 spec.volumes[0].secret.secretName
    vim demo-pod.yaml
    • 如果 configmap 完全忽略 items 数组，则每个键都会变成一个与该键同名的文件，最终会得到四个文件
      • items 除了用于筛选也可以用于重命名
     

    容器安全上下文

    参考资料
    • 安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置
      • Pod 会覆盖 Container 对应配置
    通过 spec.securityContext 字段设置 pod 安全上下文
    可选键值
    • runAsUser 指定容器主进程运行时的 userid
    • runAsGroup 指定容器主进程运行时的 groupid
    • runAsNonRoot 强制容器以非 root 用户（UID ≠ 0）运行
    • fsGroup 为 Pod 中所有容器设置共享卷（volume）的属组
      • 自动将卷中文件/目录的组权限修改为该 GID
    • fsGroupChangePolicy 控制是否以及何时递归修改（chgrp）卷中文件的属组
      • 可选，默认为 Always
        • Always 总是递归修改整个卷的属组
        • OnRootMismatch 仅当卷根目录的属组 ≠ fsGroup 时才修改
    • supplementalGroups 为容器进程添加额外的组 ID（附加组）
      • 用于访问特定组权限的文件
    • supplementalGroupsPolicy 控制容器内主进程的附加组 ID 如何计算
      • 实验性功能
        • 可选，默认为 Merge
        • Merge 合并镜像中 /etc/group 的组定义, supplementalGroups 和 fsGroup
        • Strict 忽略镜像中 /etc/group 的组定义，仅使用 supplementalGroups 和 fsGroup
    • sysctls 在容器内设置内核参数
      • 只允许“安全”的 sysctl（如 net.core.somaxconn）
      • “不安全” sysctl（如 kernel.msg*）需节点显式启用，并通过 annotation 允许
    • seccompProfile 限制容器可调用的系统调用（syscall）
    • appArmorProfile 为容器应用 AppArmor 安全策略
      • 节点需启用 AppArmor，且加载对应 profile
    • seLinuxOptions 为 Pod/容器设置 SELinux 标签
      • 节点必须启用 SELinux，且策略允许
    • seLinuxChangePolicy 定义如何将容器的 SELinux 标签应用到 Pod 使用的所有卷
      • 节点必须启用 SELinux，且策略允许
    • windowsOptions 为 Windows 节点上的容器设置安全选项
    pod 安全上下文样例 security-context-demo
    通过 spec.containers.securityContext 字段设置 container 安全上下文
    • spec.containers.securityContext 字段为 SecurityContext 对象
      • Kubernetes API Reference Docs
        Kubernetes API Reference Docs

        Kubernetes API Reference Docs

        Welcome to the Kubernetes API. You can use the Kubernetes API to read and write Kubernetes resource objects via a Kubernetes API endpoint.

    可选键值
    • 其余参考 pod 安全上下文部分
    部分独有键值
    • privileged 将容器设置为特权容器
    • procMount 表示容器使用的 proc 挂载类型
      • 可选，默认值是 Default
        • Default 使用容器运行时的默认策略
          • 某些路径（如 /proc/kcore, /proc/sysrq-trigger）被挂载为只读或空目录
        • Unmasked 绕过所有默认屏蔽，容器看到完整的、未修改的 /proc
          • 容器可访问所有 /proc 内容，包括可能用于提权或信息收集的路径
    • readOnlyRootFilesystem 将容器的根文件系统（/）挂载为只读
      • 阻止容器内进程修改文件系统（如写日志、创建临时文件）
    • allowPrivilegeEscalation 控制容器进程是否可以提升权限
      • 未显式设置时，若容器非特权且未指定用户，默认为 true
    • capabilities 精细控制容器进程拥有的 Linux 内核能力
      • 建议 drop ALL 再按需 add
      • 不可用 pod 安全上下文键值
        • fsGroup
        • fsGroupChangePolicy
        • supplementalGroups
        • supplementalGroupsPolicy
        • sysctls
      container 安全上下文样例 security-context-demo-2
       
      上一篇
      使用 kubeadm 创建和管理 Kubernetes 集群
      下一篇
      TrueNAS 安装 gitea 提供 git 服务
      Comments
      Loading...
      Catalog