配置 Pods 和容器

• 1: 为容器和 Pod 分配内存资源
• 2: 为容器和 Pods 分配 CPU 资源
• 3: 调整分配给容器的 CPU 和内存资源
• 4: 为 Windows Pod 和容器配置 GMSA
• 5: 为 Windows 的 Pod 和容器配置 RunAsUserName
• 6: 创建 Windows HostProcess Pod
• 7: 配置 Pod 的服务质量
• 8: 为容器分派扩展资源
• 9: 配置 Pod 以使用卷进行存储
• 10: 配置 Pod 以使用 PersistentVolume 作为存储
• 11: 配置 Pod 使用投射卷作存储
• 12: 为 Pod 或容器配置安全上下文
• 13: 为 Pod 配置服务账号
• 14: 从私有仓库拉取镜像
• 15: 配置存活、就绪和启动探针
• 16: 将 Pod 分配给节点
• 17: 用节点亲和性把 Pod 分配到节点
• 18: 配置 Pod 初始化
• 19: 为容器的生命周期事件设置处理函数
• 20: 配置 Pod 使用 ConfigMap
• 21: 在 Pod 中的容器之间共享进程命名空间
• 22: Pod 使用镜像卷
• 23: 为 Pod 配置 user 名字空间
• 24: 创建静态 Pod
• 25: 将 Docker Compose 文件转换为 Kubernetes 资源
• 26: 通过配置内置准入控制器实施 Pod 安全标准
• 27: 使用名字空间标签来实施 Pod 安全性标准
• 28: 从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器

1 - 为容器和 Pod 分配内存资源

此页面展示如何将内存请求（request）和内存限制（limit）分配给一个容器。 我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

你集群中的每个节点必须拥有至少 300 MiB 的内存。

该页面上的一些步骤要求你在集群中运行 metrics-server 服务。 如果你已经有在运行中的 metrics-server，则可以跳过这些步骤。

如果你运行的是 Minikube，可以运行下面的命令启用 metrics-server：

minikube addons enable metrics-server

要查看 metrics-server 或资源指标 API (metrics.k8s.io) 是否已经运行，请运行以下命令：

kubectl get apiservices

如果资源指标 API 可用，则输出结果将包含对 metrics.k8s.io 的引用信息。

NAME
v1beta1.metrics.k8s.io

创建命名空间

创建一个命名空间，以便将本练习中创建的资源与集群的其余部分隔离。

kubectl create namespace mem-example

指定内存请求和限制

要为容器指定内存请求，请在容器资源清单中包含 resources: requests 字段。 同理，要指定内存限制，请包含 resources: limits。

在本练习中，你将创建一个拥有一个容器的 Pod。 容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。 这是 Pod 的配置文件：

pods/resource/memory-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

配置文件的 args 部分提供了容器启动时的参数。 "--vm-bytes", "150M" 参数告知容器尝试分配 150 MiB 内存。

开始创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example

验证 Pod 中的容器是否已运行：

kubectl get pod memory-demo --namespace=mem-example

查看 Pod 相关的详细信息：

kubectl get pod memory-demo --output=yaml --namespace=mem-example

输出结果显示：该 Pod 中容器的内存请求为 100 MiB，内存限制为 200 MiB。

...
resources:
  requests:
    memory: 100Mi
  limits:
    memory: 200Mi
...

运行 kubectl top 命令，获取该 Pod 的指标数据：

kubectl top pod memory-demo --namespace=mem-example

输出结果显示：Pod 正在使用的内存大约为 162,900,000 字节，约为 150 MiB。 这大于 Pod 请求的 100 MiB，但在 Pod 限制的 200 MiB之内。

NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

删除 Pod：

kubectl delete pod memory-demo --namespace=mem-example

超过容器限制的内存

当节点拥有足够的可用内存时，容器可以使用其请求的内存。 但是，容器不允许使用超过其限制的内存。 如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。 如果容器继续消耗超出其限制的内存，则终止容器。 如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。

在本练习中，你将创建一个 Pod，尝试分配超出其限制的内存。 这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB：

pods/resource/memory-request-limit-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

在配置文件的 args 部分中，你可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example

查看 Pod 相关的详细信息：

kubectl get pod memory-demo-2 --namespace=mem-example

此时，容器可能正在运行或被杀死。重复前面的命令，直到容器被杀掉：

NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          24s

获取容器更详细的状态信息：

kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example

输出结果显示：由于内存溢出（OOM），容器已被杀掉：

lastState:
   terminated:
     containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
     exitCode: 137
     finishedAt: 2017-06-20T20:52:19Z
     reason: OOMKilled
     startedAt: null

本练习中的容器可以被重启，所以 kubelet 会重启它。 多次运行下面的命令，可以看到容器在反复的被杀死和重启：

kubectl get pod memory-demo-2 --namespace=mem-example

输出结果显示：容器被杀掉、重启、再杀掉、再重启……：

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          37s

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-2   1/1       Running   2          40s

查看关于该 Pod 历史的详细信息：

kubectl describe pod memory-demo-2 --namespace=mem-example

输出结果显示：该容器反复的在启动和失败：

... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff   Back-off restarting failed container

查看关于集群节点的详细信息：

kubectl describe nodes

输出结果包含了一条练习中的容器由于内存溢出而被杀掉的记录：

Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child

删除 Pod：

kubectl delete pod memory-demo-2 --namespace=mem-example

超过整个节点容量的内存

内存请求和限制是与容器关联的，但将 Pod 视为具有内存请求和限制，也是很有用的。 Pod 的内存请求是 Pod 中所有容器的内存请求之和。 同理，Pod 的内存限制是 Pod 中所有容器的内存限制之和。

Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。

在本练习中，你将创建一个 Pod，其内存请求超过了你集群中的任意一个节点所拥有的内存。 这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了你集群中任何节点的容量。

pods/resource/memory-request-limit-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-3-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "1000Gi"
      limits:
        memory: "1000Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example

查看 Pod 状态：

kubectl get pod memory-demo-3 --namespace=mem-example

输出结果显示：Pod 处于 PENDING 状态。 这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：

kubectl get pod memory-demo-3 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-3   0/1       Pending   0          25s

查看关于 Pod 的详细信息，包括事件：

kubectl describe pod memory-demo-3 --namespace=mem-example

输出结果显示：由于节点内存不足，该容器无法被调度：

Events:
  ...  Reason            Message
       ------            -------
  ...  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient memory (3).

内存单位

内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为 纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面是一些近似相同的值：

128974848, 129e6, 129M, 123Mi

删除 Pod：

kubectl delete pod memory-demo-3 --namespace=mem-example

如果你没有指定内存限制

如果你没有为一个容器指定内存限制，则自动遵循以下情况之一：

• 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存， 进而可能导致该节点调用 OOM Killer。 此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。

• 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。 集群管理员可用使用 LimitRange 来指定默认的内存限制。

内存请求和限制的目的

通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。 通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。 通过让内存限制大于内存请求，你可以完成两件事：

• Pod 可以进行一些突发活动，从而更好的利用可用内存。
• Pod 在突发活动期间，可使用的内存被限制为合理的数量。

清理

删除命名空间。下面的命令会删除你根据这个任务创建的所有 Pod：

kubectl delete namespace mem-example

接下来

应用开发者扩展阅读

• 为容器和 Pod 分配 CPU 资源

• 分配 Pod 级别的 CPU 和内存资源

• 配置 Pod 的服务质量

集群管理员扩展阅读

• 为命名空间配置默认的内存请求和限制
• 为命名空间配置默认的 CPU 请求和限制
• 配置命名空间的最小和最大内存约束
• 配置命名空间的最小和最大 CPU 约束
• 为命名空间配置内存和 CPU 配额
• 配置命名空间下 Pod 总数
• 配置 API 对象配额
• 调整分配给容器的 CPU 和内存资源的大小

2 - 为容器和 Pods 分配 CPU 资源

本页面展示如何为容器设置 CPU request（请求） 和 CPU limit（限制）。 容器使用的 CPU 不能超过所配置的限制。 如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

你的集群必须至少有 1 个 CPU 可用才能运行本任务中的示例。

本页的一些步骤要求你在集群中运行 metrics-server 服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。

如果你正在运行 Minikube，请运行以下命令启用 metrics-server：

minikube addons enable metrics-server

查看 metrics-server（或者其他资源指标 API metrics.k8s.io 服务提供者）是否正在运行， 请键入以下命令：

kubectl get apiservices

如果资源指标 API 可用，则会输出将包含一个对 metrics.k8s.io 的引用。

NAME
v1beta1.metrics.k8s.io

创建一个名字空间

创建一个名字空间，以便将 本练习中创建的资源与集群的其余部分资源隔离。

kubectl create namespace cpu-example

指定 CPU 请求和 CPU 限制

要为容器指定 CPU 请求，请在容器资源清单中包含 resources: requests 字段。 要指定 CPU 限制，请包含 resources:limits。

在本练习中，你将创建一个具有一个容器的 Pod。容器将会请求 0.5 个 CPU，而且最多限制使用 1 个 CPU。 这是 Pod 的配置文件：

pods/resource/cpu-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

配置文件的 args 部分提供了容器启动时的参数。 -cpus "2" 参数告诉容器尝试使用 2 个 CPU。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example

验证所创建的 Pod 处于 Running 状态

kubectl get pod cpu-demo --namespace=cpu-example

查看显示关于 Pod 的详细信息：

kubectl get pod cpu-demo --output=yaml --namespace=cpu-example

输出显示 Pod 中的一个容器的 CPU 请求为 500 milliCPU，并且 CPU 限制为 1 个 CPU。

resources:
  limits:
    cpu: "1"
  requests:
    cpu: 500m

使用 kubectl top 命令来获取该 Pod 的指标：

kubectl top pod cpu-demo --namespace=cpu-example

此示例输出显示 Pod 使用的是 974 milliCPU，即略低于 Pod 配置中指定的 1 个 CPU 的限制。

NAME                        CPU(cores)   MEMORY(bytes)
cpu-demo                    974m         <something>

回想一下，通过设置 -cpu "2"，你将容器配置为尝试使用 2 个 CPU， 但是容器只被允许使用大约 1 个 CPU。 容器的 CPU 用量受到限制，因为该容器正尝试使用超出其限制的 CPU 资源。

CPU 单位

CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于：

• 1 个 AWS vCPU
• 1 个 GCP核心
• 1 个 Azure vCore
• 裸机上具有超线程能力的英特尔处理器上的 1 个超线程

小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 精度不能超过 1m。

CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。

删除 Pod：

kubectl delete pod cpu-demo --namespace=cpu-example

设置超过节点能力的 CPU 请求

CPU 请求和限制与都与容器相关，但是我们可以考虑一下 Pod 具有对应的 CPU 请求和限制这样的场景。 Pod 对 CPU 用量的请求等于 Pod 中所有容器的请求数量之和。 同样，Pod 的 CPU 资源限制等于 Pod 中所有容器 CPU 资源限制数之和。

Pod 调度是基于资源请求值来进行的。 仅在某节点具有足够的 CPU 资源来满足 Pod CPU 请求时，Pod 将会在对应节点上运行：

在本练习中，你将创建一个 Pod，该 Pod 的 CPU 请求对于集群中任何节点的容量而言都会过大。 下面是 Pod 的配置文件，其中有一个容器。容器请求 100 个 CPU，这可能会超出集群中任何节点的容量。

pods/resource/cpu-request-limit-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-2
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    resources:
      limits:
        cpu: "100"
      requests:
        cpu: "100"
    args:
    - -cpus
    - "2"

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example

查看该 Pod 的状态：

kubectl get pod cpu-demo-2 --namespace=cpu-example

输出显示 Pod 状态为 Pending。也就是说，Pod 未被调度到任何节点上运行， 并且 Pod 将无限期地处于 Pending 状态：

NAME         READY     STATUS    RESTARTS   AGE
cpu-demo-2   0/1       Pending   0          7m

查看有关 Pod 的详细信息，包含事件：

kubectl describe pod cpu-demo-2 --namespace=cpu-example

输出显示由于节点上的 CPU 资源不足，无法调度容器：

Events:
  Reason                        Message
  ------                        -------
  FailedScheduling      No nodes are available that match all of the following predicates:: Insufficient cpu (3).

删除你的 Pod：

kubectl delete pod cpu-demo-2 --namespace=cpu-example

如果不指定 CPU 限制

如果你没有为容器指定 CPU 限制，则会发生以下情况之一：

• 容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。

• 容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。 集群管理员可以使用 LimitRange 指定 CPU 限制的默认值。

如果你设置了 CPU 限制但未设置 CPU 请求

如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其 设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置 内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。

CPU 请求和限制的初衷

通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。 通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。 通过使 CPU 限制大于 CPU 请求，你可以完成两件事：

• Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。

• Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。

清理

删除名字空间：

kubectl delete namespace cpu-example

接下来

针对应用开发者

• 将内存资源分配给容器和 Pod

• 分配 Pod 级别的 CPU 和内存资源

• 配置 Pod 服务质量

针对集群管理员 {for-cluster-administrators}

• 配置名字空间的默认内存请求和限制
• 为名字空间配置默认 CPU 请求和限制
• 为名字空间配置最小和最大内存限制
• 为名字空间配置最小和最大 CPU 约束
• 为名字空间配置内存和 CPU 配额
• 为名字空间配置 Pod 配额
• 配置 API 对象的配额
• 调整分配给容器的 CPU 和内存资源

3 - 调整分配给容器的 CPU 和内存资源

本页假定你已经熟悉了 Kubernetes Pod 的服务质量。

本页说明如何在不重启 Pod 或其容器的情况下调整分配给运行中 Pod 容器的 CPU 和内存资源。 Kubernetes 节点会基于 Pod 的 requests 为 Pod 分配资源， 并基于 Pod 的容器中指定的 limits 限制 Pod 的资源使用。

要为正在运行的 Pod 更改资源分配量，需要启用 InPlacePodVerticalScaling 特性门控。 并让工作负载控制器创建一个具有不同资源需求的新 Pod。

resize 请求是通过 Pod 的 /resize 子资源处理的。 对于 update 请求，请求体是更新后的完整 Pod； 对于 patch 请求，请求体是对 Pod 对象的补丁。

对于原地调整 Pod 资源而言：

• 针对 CPU 和内存资源的容器的 requests 和 limits 是可变更的。 这些字段表示容器所预期使用的资源。
• Pod 状态中 containerStatuses 的 resources 字段反映了分配给 Pod 容器的资源。 对于正运行的容器，这个字段反映了实际配置的资源 requests 和 limits， 字段值是容器运行时所报告的。对于未运行的容器，字段值是容器启动时为其分配的资源。

• Pod 状态中 resize 字段显示上次请求待处理的调整状态。此字段可以具有以下值：
  • Proposed：此值表示 Pod 大小的规约已被调整，但 kubelet 还未处理此调整请求。
  • InProgress：此值表示节点已接受调整请求，并正在将其应用于 Pod 的容器。
  • Deferred：此值意味着在此时无法批准请求的调整，节点将继续重试。 当其他 Pod 被移除并释放节点资源时，调整可能会被真正实施。
  • Infeasible：此值是一种信号，表示节点无法承接所请求的调整值。 如果所请求的调整超过节点可分配给 Pod 的最大资源，则可能会发生这种情况。
  • ""：留空或不设置，表示上一次调整已完成。 只有容器规约中的资源与容器状态中的资源相匹配时，才会是这种情况。

如果节点有一些 Pod 还未完成调整，调度器将基于容器的预期资源请求的最大值来计算 Pod 请求， 它是状态中所报告的实际请求。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

你必须在控制平面和集群中的所有节点上启用 InPlacePodVerticalScaling 特性门控。

容器调整策略

调整策略允许更精细地控制 Pod 中的容器如何针对 CPU 和内存资源进行调整。 例如，容器的应用程序可以处理 CPU 资源的调整而不必重启， 但是调整内存可能需要应用程序重启，因此容器也必须重启。

为了实现这一点，容器规约允许用户指定 resizePolicy。 针对调整 CPU 和内存可以设置以下重启策略：

• NotRequired：在运行时调整容器的资源。
• RestartContainer：重启容器并在重启后应用新资源。

如果未指定 resizePolicy[*].restartPolicy，则默认为 NotRequired。

下面的示例显示了一个 Pod，其中 CPU 可以在不重启容器的情况下进行调整，但是内存调整需要重启容器。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
    - name: qos-demo-ctr-5
      image: nginx
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: RestartContainer
      resources:
        limits:
          memory: "200Mi"
          cpu: "700m"
        requests:
          memory: "200Mi"
          cpu: "700m"

限制

目前就地调整 Pod 资源大小存在以下限制：

• 只能更改 CPU 和内存资源。
• Pod QoS 类不能更改。这意味着 Guaranteed Pod 的 requests 必须继续等于其 limits， Burstable Pod 对于 CPU 和内存的 requests 不能设为等于其 limits， 并且你不能给 BestEffort Pod 添加资源要求。
• Init 容器和临时容器不能调整大小。
• 资源请求和限制一旦被设置就不能移除。
• 容器的内存限制不能降到比其当前用量更低的值。如果某请求将容器置于此状态， 调整的状态将停留在 InProgress，直到预期的内存限制成为可行为止。
• Windows Pod 不能被调整大小。

创建具有资源请求和限制的 Pod

你可以通过为 Pod 的容器指定请求和/或限制来创建 Guaranteed 或 Burstable 服务质量类的 Pod。

考虑以下包含一个容器的 Pod 的清单。

pods/qos/qos-pod-5.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

在 qos-example 名字空间中创建该 Pod：

kubectl create namespace qos-example
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-5.yaml --namespace=qos-example

此 Pod 被分类为 Guaranteed QoS 类，请求 700m CPU 和 200Mi 内存。

查看有关 Pod 的详细信息：

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

另请注意，resizePolicy[*].restartPolicy 的值默认为 NotRequired， 表示可以在容器运行的情况下调整 CPU 和内存大小。

spec:
  containers:
    ...
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
...
  containerStatuses:
...
    name: qos-demo-ctr-5
    ready: true
...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    restartCount: 0
    started: true
...
  qosClass: Guaranteed

更新 Pod 的资源

假设要求的 CPU 需求已上升，现在需要 0.8 CPU。这可以手动指定，或由如 VerticalPodAutoscaler (VPA) 这样的实体确定并可能以编程方式应用。

现在对 Pod 的 Container 执行 patch 命令，将容器的 CPU 请求和限制均设置为 800m：

kubectl -n qos-example patch pod qos-demo-5 --subresource resize --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

在 Pod 已打补丁后查询其详细信息。

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

以下 Pod 规约反映了更新后的 CPU 请求和限制。

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
...
  containerStatuses:
...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
    restartCount: 0
    started: true

观察到 allocatedResources 的值已更新，反映了新的预期 CPU 请求。 这表明节点能够容纳提高后的 CPU 资源需求，而且新的 CPU 资源已经被应用。 Container 的 restartCount 保持不变，表示已在无需重启容器的情况下调整了容器的 CPU 资源。

清理

删除你的名字空间：

kubectl delete namespace qos-example

接下来

对于应用开发人员

• 为容器和 Pod 分配内存资源

• 为容器和 Pod 分配 CPU 资源

• 分配 Pod 级别的 CPU 和内存资源

对于集群管理员

• 为名字空间配置默认内存请求和限制

• 为名字空间配置默认 CPU 请求和限制

• 为名字空间配置最小和最大内存约束

• 为名字空间配置最小和最大 CPU 约束

• 为名字空间配置内存和 CPU 配额

4 - 为 Windows Pod 和容器配置 GMSA

本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置 组管理的服务账号（Group Managed Service Accounts，GMSA）。 组管理的服务账号是活动目录（Active Directory）的一种特殊类型， 提供自动化的密码管理、简化的服务主体名称（Service Principal Name，SPN） 管理以及跨多个服务器将管理操作委派给其他管理员等能力。

在 Kubernetes 环境中，GMSA 凭据规约配置为 Kubernetes 集群范围的自定义资源 （Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为使用 GMSA 来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便与其他 Windows 服务相交互。

准备开始

你需要一个 Kubernetes 集群，以及 kubectl 命令行工具， 且工具必须已配置为能够与你的集群通信。集群预期包含 Windows 工作节点。 本节讨论需要为每个集群执行一次的初始操作。

安装 GMSACredentialSpec CRD

你需要在集群上配置一个用于 GMSA 凭据规约资源的 CustomResourceDefinition(CRD)， 以便定义类型为 GMSACredentialSpec 的自定义资源。首先下载 GMSA CRD YAML 并将其保存为 gmsa-crd.yaml。接下来执行 kubectl apply -f gmsa-crd.yaml 安装 CRD。

安装 Webhook 来验证 GMSA 用户

你需要为 Kubernetes 集群配置两个 Webhook，在 Pod 或容器级别填充和检查 GMSA 凭据规约引用。

1. 一个修改模式（Mutating）的 Webhook，将对 GMSA 的引用（在 Pod 规约中体现为名字） 展开为完整凭据规约的 JSON 形式，并保存回 Pod 规约中。

2. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权给 Pod 的服务账号使用的。

安装以上 Webhook 及其相关联的对象需要执行以下步骤：

1. 创建一个证书密钥对（用于允许 Webhook 容器与集群通信）

2. 安装一个包含如上证书的 Secret

3. 创建一个包含核心 Webhook 逻辑的 Deployment

4. 创建引用该 Deployment 的 Validating Webhook 和 Mutating Webhook 配置

你可以使用这个脚本 来部署和配置上述 GMSA Webhook 及相关联的对象。你还可以在运行脚本时设置 --dry-run=server 选项以便审查脚本将会对集群做出的变更。

脚本所使用的 YAML 模板 也可用于手动部署 Webhook 及相关联的对象，不过需要对其中的参数作适当替换。

在活动目录中配置 GMSA 和 Windows 节点

在配置 Kubernetes 中的 Pod 以使用 GMSA 之前，需要按 Windows GMSA 文档 中描述的那样先在活动目录中准备好期望的 GMSA。 Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便访问与期望的 GSMA 相关联的秘密凭据数据。这一操作的描述位于 Windows GMSA 文档 中。

创建 GMSA 凭据规约资源

当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA 凭据规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。 其中包含的信息主要用于容器运行时，便于后者向 Windows 描述容器所期望的 GMSA。 GMSA 凭据规约可以使用 PowerShell 脚本 以 YAML 格式生成。

下面是手动以 JSON 格式生成 GMSA 凭据规约并对其进行 YAML 转换的步骤：

1. 导入 CredentialSpec 模块：ipmo CredentialSpec.psm1

2. 使用 New-CredentialSpec 来创建一个 JSON 格式的凭据规约。 要创建名为 WebApp1 的 GMSA 凭据规约，调用 New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)。

3. 使用 Get-CredentialSpec 来显示 JSON 文件的路径。

4. 将凭据规约从 JSON 格式转换为 YAML 格式，并添加必要的头部字段 apiVersion、kind、metadata 和 credspec，使其成为一个可以在 Kubernetes 中配置的 GMSACredentialSpec 自定义资源。

下面的 YAML 配置描述的是一个名为 gmsa-WebApp1 的 GMSA 凭据规约：

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-WebApp1  # 这是随意起的一个名字，将用作引用
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: WebApp1   # GMSA 账号的用户名
      Scope: CONTOSO  # NETBIOS 域名
    - Name: WebApp1   # GMSA 账号的用户名
      Scope: contoso.com # DNS 域名
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: contoso.com  # DNS 域名
    DnsTreeName: contoso.com # DNS 域名根
    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # 域名的 GUID
    MachineAccountName: WebApp1 # GMSA 账号的用户名
    NetBiosName: CONTOSO  # NETBIOS 域名
    Sid: S-1-5-21-2126449477-2524075714-3094792973 # 域名的 SID

上面的凭据规约资源可以保存为 gmsa-Webapp1-credspec.yaml，之后使用 kubectl apply -f gmsa-Webapp1-credspec.yml 应用到集群上。

配置集群角色以启用对特定 GMSA 凭据规约的 RBAC

你需要为每个 GMSA 凭据规约资源定义集群角色。 该集群角色授权某主体（通常是一个服务账号）对特定的 GMSA 资源执行 use 动作。 下面的示例显示的是一个集群角色，对前文创建的凭据规约 gmsa-WebApp1 执行鉴权。 将此文件保存为 gmsa-webapp1-role.yaml 并执行 kubectl apply -f gmsa-webapp1-role.yaml。

# 创建集群角色读取凭据规约
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["gmsa-WebApp1"]

将角色指派给要使用特定 GMSA 凭据规约的服务账号

你需要将某个服务账号（Pod 配置所对应的那个）绑定到前文创建的集群角色上。 这一绑定操作实际上授予该服务账号使用所指定的 GMSA 凭据规约资源的访问权限。 下面显示的是一个绑定到集群角色 webapp1-role 上的 default 服务账号， 使之能够使用前面所创建的 gmsa-WebApp1 凭据规约资源。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-gmsa-WebApp1
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: webapp1-role
  apiGroup: rbac.authorization.k8s.io

在 Pod 规约中配置 GMSA 凭据规约引用

Pod 规约字段 securityContext.windowsOptions.gmsaCredentialSpecName 可用来设置对指定 GMSA 凭据规约自定义资源的引用。 设置此引用将会配置 Pod 中的所有容器使用所给的 GMSA。 下面是一个 Pod 规约示例，其中包含了对 gmsa-WebApp1 凭据规约的引用：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: gmsa-webapp1
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
      nodeSelector:
        kubernetes.io/os: windows

Pod 中的各个容器也可以使用对应容器的 securityContext.windowsOptions.gmsaCredentialSpecName 字段来设置期望使用的 GMSA 凭据规约。例如：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
        securityContext:
          windowsOptions:
            gmsaCredentialSpecName: gmsa-Webapp1
      nodeSelector:
        kubernetes.io/os: windows

当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次发生以下事件：

1. Mutating Webhook 解析对 GMSA 凭据规约资源的引用，并将其全部展开， 得到 GMSA 凭据规约的实际内容。

2. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约上执行 use 动作。

3. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约， 这样容器就可以以活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。

使用主机名或 FQDN 对网络共享进行身份验证

如果你在使用主机名或 FQDN 从 Pod 连接到 SMB 共享时遇到问题，但能够通过其 IPv4 地址访问共享， 请确保在 Windows 节点上设置了以下注册表项。

reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1

然后需要重新创建正在运行的 Pod 以使行为更改生效。有关如何使用此注册表项的更多信息， 请参见此处。

故障排查

如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能的故障。

首先，确保 credspec 已传递给 Pod。为此，你需要先运行 exec 进入到你的一个 Pod 中并检查 nltest.exe /parentdomain 命令的输出。

在下面的例子中，Pod 未能正确地获得凭据规约：

kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe

nltest.exe /parentdomain 导致以下错误：

Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

如果 Pod 未能正确获得凭据规约，则下一步就要检查与域之间的通信。 首先，从 Pod 内部快速执行一个 nslookup 操作，找到域根。

这一操作会告诉我们三件事情：

1. Pod 能否访问域控制器（DC）
2. DC 能否访问 Pod
3. DNS 是否正常工作

如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了安全通信通道。 要执行这一检查，你需要再次通过 exec 进入到你的 Pod 中并执行 nltest.exe /query 命令。

nltest.exe /query

结果输出如下：

I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

这告诉我们，由于某种原因，Pod 无法使用 credspec 中指定的帐户登录到域。 你可以尝试通过运行以下命令来修复安全通道：

nltest /sc_reset:domain.example

如果命令成功，你将看到类似以下内容的输出：

Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

如果以上命令修复了错误，你可以通过将以下生命周期回调添加到你的 Pod 规约中来自动执行该步骤。 如果这些操作没有修复错误，你将需要再次检查你的 credspec 并确认它是正确和完整的。

        image: registry.domain.example/iis-auth:1809v1
        lifecycle:
          postStart:
            exec:
              command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
        imagePullPolicy: IfNotPresent

如果你向你的 Pod 规约中添加如上所示的 lifecycle 节，则 Pod 会自动执行所列举的命令来重启 netlogon 服务，直到 nltest.exe /query 命令返回时没有错误信息。

5 - 为 Windows 的 Pod 和容器配置 RunAsUserName

本页展示如何为运行为在 Windows 节点上运行的 Pod 和容器配置 RunAsUserName。 大致相当于 Linux 上的 runAsUser，允许在容器中以与默认值不同的用户名运行应用。

准备开始

你必须有一个 Kubernetes 集群，并且 kubectl 必须能和集群通信。 集群应该要有 Windows 工作节点，将在其中调度运行 Windows 工作负载的 pod 和容器。

为 Pod 设置 Username

要指定运行 Pod 容器时所使用的用户名，请在 Pod 声明中包含 securityContext (PodSecurityContext) 字段， 并在其内部包含 windowsOptions (WindowsSecurityContextOptions) 字段的 runAsUserName 字段。

你为 Pod 指定的 Windows SecurityContext 选项适用于该 Pod 中（包括 init 容器）的所有容器。

这儿有一个已经设置了 runAsUserName 字段的 Windows Pod 的配置文件：

windows/run-as-username-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
    kubernetes.io/os: windows

创建 Pod：

kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml

验证 Pod 容器是否在运行：

kubectl get pod run-as-username-pod-demo

获取该容器的 shell：

kubectl exec -it run-as-username-pod-demo -- powershell

检查运行 shell 的用户的用户名是否正确：

echo $env:USERNAME

输出结果应该是这样：

ContainerUser

为容器设置 Username

要指定运行容器时所使用的用户名，请在容器清单中包含 securityContext (SecurityContext) 字段，并在其内部包含 windowsOptions （WindowsSecurityContextOptions） 字段的 runAsUserName 字段。

你为容器指定的 Windows SecurityContext 选项仅适用于该容器，并且它会覆盖 Pod 级别设置。

这里有一个 Pod 的配置文件，其中只有一个容器，并且在 Pod 级别和容器级别都设置了 runAsUserName：

windows/run-as-username-container.yaml

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-container-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
    securityContext:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
    kubernetes.io/os: windows

创建 Pod：

kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml

验证 Pod 容器是否在运行：

kubectl get pod run-as-username-container-demo

获取该容器的 shell：

kubectl exec -it run-as-username-container-demo -- powershell

检查运行 shell 的用户的用户名是否正确（应该是容器级别设置的那个）：

echo $env:USERNAME

输出结果应该是这样：

ContainerAdministrator

Windows Username 的局限性

想要使用此功能，在 runAsUserName 字段中设置的值必须是有效的用户名。 它必须是 DOMAIN\USER 这种格式，其中 DOMAIN\ 是可选的。 Windows 用户名不区分大小写。此外，关于 DOMAIN 和 USER 还有一些限制：

• runAsUserName 字段不能为空，并且不能包含控制字符（ASCII 值：0x00-0x1F、0x7F）
• DOMAIN 必须是 NetBios 名称或 DNS 名称，每种名称都有各自的局限性：
  • NetBios 名称：最多 15 个字符，不能以 .（点）开头，并且不能包含以下字符：\ / : * ? " < > |
  • DNS 名称：最多 255 个字符，只能包含字母、数字、点和中划线，并且不能以 .（点）或 -（中划线）开头和结尾。
• USER 最多不超过 20 个字符，不能只包含点或空格，并且不能包含以下字符：" / \ [ ] : ; | = , + * ? < > @

runAsUserName 字段接受的值的一些示例：ContainerAdministrator、ContainerUser、 NT AUTHORITY\NETWORK SERVICE、NT AUTHORITY\LOCAL SERVICE。

关于这些限制的更多信息，可以查看这里和这里。

接下来

• Kubernetes 中调度 Windows 容器的指南
• 使用组托管服务帐户（GMSA）管理工作负载身份
• Windows 下 Pod 和容器的 GMSA 配置

6 - 创建 Windows HostProcess Pod

Windows HostProcess 容器让你能够在 Windows 主机上运行容器化负载。 这类容器以普通的进程形式运行，但能够在具有合适用户特权的情况下， 访问主机网络名字空间、存储和设备。HostProcess 容器可用来在 Windows 节点上部署网络插件、存储配置、设备插件、kube-proxy 以及其他组件， 同时不需要配置专用的代理或者直接安装主机服务。

类似于安装安全补丁、事件日志收集等这类管理性质的任务可以在不需要集群操作员登录到每个 Windows 节点的前提下执行。HostProcess 容器可以以主机上存在的任何用户账号来运行， 也可以以主机所在域中的用户账号运行，这样管理员可以通过用户许可权限来限制资源访问。 尽管文件系统和进程隔离都不支持，在启动容器时会在主机上创建一个新的卷， 为其提供一个干净的、整合的工作空间。HostProcess 容器也可以基于现有的 Windows 基础镜像来制作，并且不再有 Windows 服务器容器所带有的那些 兼容性需求， 这意味着基础镜像的版本不必与主机操作系统的版本匹配。 不过，仍然建议你像使用 Windows 服务器容器负载那样，使用相同的基础镜像版本， 这样你就不会有一些未使用的镜像占用节点上的存储空间。HostProcess 容器也支持 在容器卷内执行卷挂载。

我何时该使用 Windows HostProcess 容器？

• 当你准备执行需要访问主机上网络名字空间的任务时，HostProcess 容器能够访问主机上的网络接口和 IP 地址。
• 当你需要访问主机上的资源，如文件系统、事件日志等等。
• 需要安装特定的设备驱动或者 Windows 服务时。
• 需要对管理任务和安全策略进行整合时。使用 HostProcess 容器能够缩小 Windows 节点上所需要的特权范围。

准备开始

本任务指南是特定于 Kubernetes v1.32 的。 如果你运行的不是 Kubernetes v1.32，请移步访问正确 版本的 Kubernetes 文档。

在 Kubernetes v1.32 中，HostProcess 容器功能特性默认是启用的。 kubelet 会直接与 containerd 通信，通过 CRI 将主机进程标志传递过去。 你可以使用 containerd 的最新版本（v1.6+）来运行 HostProcess 容器。 参阅如何安装 containerd。

限制

以下限制是与 Kubernetes v1.32 相关的：

• HostProcess 容器需要 containerd 1.6 或更高版本的 容器运行时， 推荐 containerd 1.7。
• HostProcess Pods 只能包含 HostProcess 容器。这是在 Windows 操作系统上的约束； 非特权的 Windows 容器不能与主机 IP 名字空间共享虚拟网卡（vNIC）。
• HostProcess 在主机上以一个进程的形式运行，除了通过 HostProcess 用户账号所实施的资源约束外，不提供任何形式的隔离。HostProcess 容器不支持文件系统或 Hyper-V 隔离。

• 卷挂载是被支持的，并且要花在到容器卷下。参见卷挂载。
• 默认情况下有一组主机用户账号可供 HostProcess 容器使用。 参见选择用户账号。
• 对资源约束（磁盘、内存、CPU 个数）的支持与主机上进程相同。
• 不支持命名管道或者 UNIX 域套接字形式的挂载，需要使用主机上的路径名来访问 （例如，\\.\pipe\*）。

HostProcess Pod 配置需求

启用 Windows HostProcess Pod 需要在 Pod 安全配置中设置合适的选项。 在 Pod 安全标准中所定义的策略中， HostProcess Pod 默认是不被 basline 和 restricted 策略支持的。因此建议 HostProcess 运行在与 privileged 模式相看齐的策略下。

当运行在 privileged 策略下时，下面是要启用 HostProcess Pod 创建所需要设置的选项：

配置清单示例（片段）

spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\Local service"
  hostNetwork: true
  containers:
  - name: test
    image: image1:latest
    command:
      - ping
      - -t
      - 127.0.0.1
  nodeSelector:
    "kubernetes.io/os": windows

卷挂载

HostProcess 容器支持在容器卷空间中挂载卷的能力。 卷挂载行为将因节点所使用的 containerd 运行时版本而异。

containerd v1.6

在容器内运行的应用能够通过相对或者绝对路径直接访问卷挂载。 环境变量 $CONTAINER_SANDBOX_MOUNT_POINT 在容器创建时被设置为指向容器卷的绝对主机路径。 相对路径是基于 .spec.containers.volumeMounts.mountPath 配置来推导的。

容器内支持通过下面的路径结构来访问服务账号令牌：

• .\var\run\secrets\kubernetes.io\serviceaccount\
• $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

containerd v1.7（及更高版本）

容器内运行的应用可以通过 volumeMount 指定的 mountPath 直接访问卷挂载 （就像 Linux 和非 HostProcess Windows 容器一样）。

为了向后兼容性，卷也可以通过使用由 containerd v1.6 配置的相同相对路径进行访问。

例如，要在容器中访问服务帐户令牌，你将使用以下路径之一：

• c:\var\run\secrets\kubernetes.io\serviceaccount
• /var/run/secrets/kubernetes.io/serviceaccount/
• $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

资源限制

资源限制（磁盘、内存、CPU 个数）作用到任务之上，并在整个任务上起作用。 例如，如果内存限制设置为 10MB，任何 HostProcess 任务对象所分配的内存不会超过 10MB。 这一行为与其他 Windows 容器类型相同。资源限制的设置方式与编排系统或容器运行时无关。 唯一的区别是用来跟踪资源所进行的磁盘资源用量的计算，出现差异的原因是因为 HostProcess 容器启动引导的方式造成的。

选择用户账号

系统账号

默认情况下，HostProcess 容器支持以三种被支持的 Windows 服务账号之一来运行：

• LocalSystem
• LocalService
• NetworkService

你应该为每个 HostProcess 容器选择一个合适的 Windows 服务账号，尝试限制特权范围， 避免给主机代理意外的（甚至是恶意的）伤害。LocalSystem 服务账号的特权级 在三者之中最高，只有在绝对需要的时候才应该使用。只要可能，应该使用 LocalService 服务账号，因为该账号在三者中特权最低。

本地账号

取决于配置，HostProcess 容器也能够以本地用户账号运行， 从而允许节点操作员为工作负载提供细粒度的访问权限。

要以本地用户运行 HostProcess 容器，必须首先在节点上创建一个本地用户组， 并在部署中在 runAsUserName 字段中指定该本地用户组的名称。 在初始化 HostProcess 容器之前，将创建一个新的临时本地用户账号，并加入到指定的用户组中， 使用这个账号来运行容器。这样做有许多好处，包括不再需要管理本地用户账号的密码。 作为服务账号运行的初始 HostProcess 容器可用于准备用户组，以供后续的 HostProcess 容器使用。

例如：

1. 在节点上创建本地用户组（这可以在另一个 HostProcess 容器中完成）。

   net localgroup hpc-localgroup /add
   

2. 为本地用户组授予访问所需资源的权限。这可以通过使用 icacls 这类工具达成。

3. 针对 Pod 或个别容器，将 runAsUserName 设置为本地用户组的名称。

   securityContext:
     windowsOptions:
       hostProcess: true
       runAsUserName: hpc-localgroup
   

4. 调度 Pod！

HostProcess 容器的基础镜像

HostProcess 容器可以基于任何现有的 Windows Container 基础镜像进行构建。

此外，还专为 HostProcess 容器创建了一个新的基础镜像！有关更多信息，请查看 windows-host-process-containers-base-image github 项目。

HostProcess 容器的故障排查

• HostProcess 容器因 failed to create user process token: failed to logon user: Access is denied.: unknown 启动失败。

  确保 containerd 以 LocalSystem 或 LocalService 服务帐户运行。 用户账号（即使是管理员账号）没有权限为任何支持的用户账号创建登录令牌。

7 - 配置 Pod 的服务质量

本页介绍怎样配置 Pod 以让其归属于特定的 服务质量类（Quality of Service class，QoS class）. Kubernetes 在 Node 资源不足时使用 QoS 类来就驱逐 Pod 作出决定。

Kubernetes 创建 Pod 时，会将如下 QoS 类之一设置到 Pod 上：

• Guaranteed
• Burstable
• BestEffort

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

你还需要能够创建和删除名字空间。

创建名字空间

创建一个名字空间，以便将本练习所创建的资源与集群的其余资源相隔离。

kubectl create namespace qos-example

创建一个 QoS 类为 Guaranteed 的 Pod

对于 QoS 类为 Guaranteed 的 Pod：

• Pod 中的每个容器都必须指定内存限制和内存请求。
• 对于 Pod 中的每个容器，内存限制必须等于内存请求。
• Pod 中的每个容器都必须指定 CPU 限制和 CPU 请求。
• 对于 Pod 中的每个容器，CPU 限制必须等于 CPU 请求。

这些限制同样适用于初始化容器和应用程序容器。 临时容器（Ephemeral Container） 无法定义资源，因此不受这些约束限制。

下面是包含一个 Container 的 Pod 清单。该 Container 设置了内存请求和内存限制，值都是 200 MiB。 该 Container 设置了 CPU 请求和 CPU 限制，值都是 700 milliCPU：

pods/qos/qos-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example

查看 Pod 详情：

kubectl get pod qos-demo --namespace=qos-example --output=yaml

结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Guaranteed。 结果也确认了 Pod 容器设置了与内存限制匹配的内存请求，设置了与 CPU 限制匹配的 CPU 请求。

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    ...
status:
  qosClass: Guaranteed

清理

删除 Pod：

kubectl delete pod qos-demo --namespace=qos-example

创建一个 QoS 类为 Burstable 的 Pod

如果满足下面条件，Kubernetes 将会指定 Pod 的 QoS 类为 Burstable：

• Pod 不符合 Guaranteed QoS 类的标准。
• Pod 中至少一个 Container 具有内存或 CPU 的请求或限制。

下面是包含一个 Container 的 Pod 清单。该 Container 设置的内存限制为 200 MiB， 内存请求为 100 MiB。

pods/qos/qos-pod-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example

查看 Pod 详情：

kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml

结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable：

spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: qos-demo-2-ctr
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi
  ...
status:
  qosClass: Burstable

清理

删除 Pod：

kubectl delete pod qos-demo-2 --namespace=qos-example

创建一个 QoS 类为 BestEffort 的 Pod

对于 QoS 类为 BestEffort 的 Pod，Pod 中的 Container 必须没有设置内存和 CPU 限制或请求。

下面是包含一个 Container 的 Pod 清单。该 Container 没有设置内存和 CPU 限制或请求。

pods/qos/qos-pod-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example

查看 Pod 详情：

kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml

结果表明 Kubernetes 为 Pod 配置的 QoS 类为 BestEffort。

spec:
  containers:
    ...
    resources: {}
  ...
status:
  qosClass: BestEffort

清理

删除 Pod：

kubectl delete pod qos-demo-3 --namespace=qos-example

创建包含两个容器的 Pod

下面是包含两个 Container 的 Pod 清单。一个 Container 指定内存请求为 200 MiB。 另外一个 Container 没有指定任何请求或限制。

pods/qos/qos-pod-4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-4
  namespace: qos-example
spec:
  containers:

  - name: qos-demo-4-ctr-1
    image: nginx
    resources:
      requests:
        memory: "200Mi"

  - name: qos-demo-4-ctr-2
    image: redis

注意此 Pod 满足 Burstable QoS 类的标准。也就是说它不满足 Guaranteed QoS 类标准， 因为它的 Container 之一设有内存请求。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example

查看 Pod 详情：

kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml

结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable：

spec:
  containers:
    ...
    name: qos-demo-4-ctr-1
    resources:
      requests:
        memory: 200Mi
    ...
    name: qos-demo-4-ctr-2
    resources: {}
    ...
status:
  qosClass: Burstable

检视 Pod 的 QoS 类

你也可以只查看你所需要的字段，而不是查看所有字段：

kubectl --namespace=qos-example get pod qos-demo-4 -o jsonpath='{ .status.qosClass}{"\n"}'

Burstable

环境清理

删除名字空间：

kubectl delete namespace qos-example

接下来

应用开发者参考

• 为 Pod 和容器分配内存资源
• 为 Pod 和容器分配 CPU 资源

集群管理员参考

• 为名字空间配置默认的内存请求和限制
• 为名字空间配置默认的 CPU 请求和限制
• 为名字空间配置最小和最大内存限制
• 为名字空间配置最小和最大 CPU 限制
• 为名字空间配置内存和 CPU 配额
• 为名字空间配置 Pod 配额
• 为 API 对象配置配额
• 控制节点上的拓扑管理策略

8 - 为容器分派扩展资源

本文介绍如何为容器指定扩展资源。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

在你开始此练习前，请先练习 为节点广播扩展资源。 在那个练习中将配置你的一个节点来广播 dongle 资源。

给 Pod 分派扩展资源

要请求扩展资源，需要在你的容器清单中包括 resources:requests 字段。 扩展资源可以使用任何完全限定名称，只是不能使用 *.kubernetes.io/。 有效的扩展资源名的格式为 example.com/foo，其中 example.com 应被替换为 你的组织的域名，而 foo 则是描述性的资源名称。

下面是包含一个容器的 Pod 配置文件：

pods/resource/extended-resource-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo
spec:
  containers:
  - name: extended-resource-demo-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 3
      limits:
        example.com/dongle: 3

在配置文件中，你可以看到容器请求了 3 个 dongles。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml

检查 Pod 是否运行正常：

kubectl get pod extended-resource-demo

描述 Pod:

kubectl describe pod extended-resource-demo

输出结果显示 dongle 请求如下：

Limits:
  example.com/dongle: 3
Requests:
  example.com/dongle: 3

尝试创建第二个 Pod

下面是包含一个容器的 Pod 配置文件，容器请求了 2 个 dongles。

pods/resource/extended-resource-pod-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo-2
spec:
  containers:
  - name: extended-resource-demo-2-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 2
      limits:
        example.com/dongle: 2

Kubernetes 将不能满足 2 个 dongles 的请求，因为第一个 Pod 已经使用了 4 个可用 dongles 中的 3 个。

尝试创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml

描述 Pod：

kubectl describe pod extended-resource-demo-2

输出结果表明 Pod 不能被调度，因为没有一个节点上存在两个可用的 dongles。

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  ...
  ... Warning   FailedScheduling  pod (extended-resource-demo-2) failed to fit in any node
fit failure summary on nodes : Insufficient example.com/dongle (1)

查看 Pod 的状态：

kubectl get pod extended-resource-demo-2

输出结果表明 Pod 虽然被创建了，但没有被调度到节点上正常运行。Pod 的状态为 Pending：

NAME                       READY     STATUS    RESTARTS   AGE
extended-resource-demo-2   0/1       Pending   0          6m

清理

删除本练习中创建的 Pod：

kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2

接下来

应用开发者参考

• 为容器和 Pod 分配内存资源
• 为容器和 Pod 分配 CPU 资源

集群管理员参考

• 为节点广播扩展资源

9 - 配置 Pod 以使用卷进行存储

此页面展示了如何配置 Pod 以使用卷进行存储。

只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。 对于独立于容器的持久化存储，你可以使用卷。 这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

为 Pod 配置卷

在本练习中，你将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 emptyDir 的卷， 在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：

pods/storage/redis.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}

1. 创建 Pod：

   kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
   

2. 验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：

   kubectl get pod redis --watch
   

   输出如下：

   NAME      READY     STATUS    RESTARTS   AGE
   redis     1/1       Running   0          13s
   

3. 在另一个终端，用 Shell 连接正在运行的容器：

   kubectl exec -it redis -- /bin/bash
   

4. 在你的 Shell 中，切换到 /data/redis 目录下，然后创建一个文件：

   root@redis:/data# cd /data/redis/
   root@redis:/data/redis# echo Hello > test-file
   

5. 在你的 Shell 中，列出正在运行的进程：

   root@redis:/data/redis# apt-get update
   root@redis:/data/redis# apt-get install procps
   root@redis:/data/redis# ps aux
   

   输出类似于：

   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
   root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
   root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
   

6. 在你的 Shell 中，结束 Redis 进程：

   root@redis:/data/redis# kill <pid>
   

   其中 <pid> 是 Redis 进程的 ID (PID)。

7. 在你原先终端中，留意 Redis Pod 的更改。最终你将会看到和下面类似的输出：

   NAME      READY     STATUS     RESTARTS   AGE
   redis     1/1       Running    0          13s
   redis     0/1       Completed  0         6m
   redis     1/1       Running    1         6m
   

此时，容器已经终止并重新启动。这是因为 Redis Pod 的 restartPolicy 为 Always。

1. 用 Shell 进入重新启动的容器中：

   kubectl exec -it redis -- /bin/bash
   

2. 在你的 Shell 中，进入到 /data/redis 目录下，并确认 test-file 文件是否仍然存在。

   root@redis:/data/redis# cd /data/redis/
   root@redis:/data/redis# ls
   test-file
   

3. 删除为此练习所创建的 Pod：

   kubectl delete pod redis
   

接下来

• 参阅 Volume。
• 参阅 Pod。
• 除了 emptyDir 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案， 包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节， 例如安装和卸载设备。了解更多详情请参阅卷。

10 - 配置 Pod 以使用 PersistentVolume 作为存储

本文将向你介绍如何配置 Pod 使用 PersistentVolumeClaim 作为存储。 以下是该过程的总结：

1. 你作为集群管理员创建由物理存储支持的 PersistentVolume。你不会将该卷与任何 Pod 关联。

2. 你现在以开发人员或者集群用户的角色创建一个 PersistentVolumeClaim， 它将自动绑定到合适的 PersistentVolume。

3. 你创建一个使用以上 PersistentVolumeClaim 作为存储的 Pod。

准备开始

• 你需要一个包含单个节点的 Kubernetes 集群，并且必须配置 kubectl 命令行工具以便与集群交互。 如果还没有单节点集群，可以使用 Minikube 创建一个。

• 熟悉持久卷文档。

在你的节点上创建一个 index.html 文件

打开集群中的某个节点的 Shell。 如何打开 Shell 取决于集群的设置。 例如，如果你正在使用 Minikube，那么可以通过输入 minikube ssh 来打开节点的 Shell。

在该节点的 Shell 中，创建一个 /mnt/data 目录：

# 这里假定你的节点使用 "sudo" 来以超级用户角色执行命令
sudo mkdir /mnt/data

在 /mnt/data 目录中创建一个 index.html 文件：

# 这里再次假定你的节点使用 "sudo" 来以超级用户角色执行命令
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"

测试 index.html 文件确实存在：

cat /mnt/data/index.html

输出应该是：

Hello from Kubernetes storage

现在你可以关闭节点的 Shell 了。

创建 PersistentVolume

在本练习中，你将创建一个 hostPath 类型的 PersistentVolume。 Kubernetes 支持用于在单节点集群上开发和测试的 hostPath 类型的 PersistentVolume。 hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟网络附加存储。

在生产集群中，你不会使用 hostPath。 集群管理员会提供网络存储资源，比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。 集群管理员还可以使用 StorageClass 来设置动态制备存储。

下面是 hostPath PersistentVolume 的配置文件：

pods/storage/pv-volume.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

此配置文件指定卷位于集群节点上的 /mnt/data 路径。 其配置还指定了卷的容量大小为 10 GB，访问模式为 ReadWriteOnce， 这意味着该卷可以被单个节点以读写方式安装。 此配置文件还在 PersistentVolume 中定义了 StorageClass 的名称为 manual。 它将用于将 PersistentVolumeClaim 的请求绑定到此 PersistentVolume。

创建 PersistentVolume：

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

查看 PersistentVolume 的信息：

kubectl get pv task-pv-volume

输出结果显示该 PersistentVolume 的状态（STATUS）为 Available。 这意味着它还没有被绑定给 PersistentVolumeClaim。

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s

创建 PersistentVolumeClaim

下一步是创建一个 PersistentVolumeClaim。 Pod 使用 PersistentVolumeClaim 来请求物理存储。 在本练习中，你将创建一个 PersistentVolumeClaim，它请求至少 3 GB 容量的卷， 该卷一次最多可以为一个节点提供读写访问。

下面是 PersistentVolumeClaim 的配置文件：

pods/storage/pv-claim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

创建 PersistentVolumeClaim：

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

创建 PersistentVolumeClaim 之后，Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。 如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume， 则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。

再次查看 PersistentVolume 信息：

kubectl get pv task-pv-volume

现在输出的 STATUS 为 Bound。

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m

查看 PersistentVolumeClaim：

kubectl get pvc task-pv-claim

输出结果表明该 PersistentVolumeClaim 绑定了你的 PersistentVolume task-pv-volume。

NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s

创建 Pod

下一步是创建一个使用你的 PersistentVolumeClaim 作为存储卷的 Pod。

下面是此 Pod 的配置文件：

pods/storage/pv-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

注意 Pod 的配置文件指定了 PersistentVolumeClaim，但没有指定 PersistentVolume。 对 Pod 而言，PersistentVolumeClaim 就是一个存储卷。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml

检查 Pod 中的容器是否运行正常：

kubectl get pod task-pv-pod

打开一个 Shell 访问 Pod 中的容器：

kubectl exec -it task-pv-pod -- /bin/bash

在 Shell 中，验证 Nginx 是否正在从 hostPath 卷提供 index.html 文件：

# 一定要在上一步 "kubectl exec" 所返回的 Shell 中执行下面三个命令
apt update
apt install curl
curl http://localhost/

输出结果是你之前写到 hostPath 卷中的 index.html 文件中的内容：

Hello from Kubernetes storage

如果你看到此消息，则证明你已经成功地配置了 Pod 使用 PersistentVolumeClaim 的存储。

清理

删除 Pod、PersistentVolumeClaim 和 PersistentVolume 对象：

kubectl delete pod task-pv-pod
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume

如果你还没有连接到集群中节点的 Shell，可以按之前所做操作，打开一个新的 Shell。

在节点的 Shell 上，删除你所创建的目录和文件：

# 这里假定你使用 "sudo" 来以超级用户的角色执行命令
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data

你现在可以关闭连接到节点的 Shell。

在两个地方挂载相同的 persistentVolume

pods/storage/pv-duplicate.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: nginx
      volumeMounts:
        # 网站数据挂载
        - name: config
          mountPath: /usr/share/nginx/html
          subPath: html
        # Nginx 配置挂载
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: config
      persistentVolumeClaim:
        claimName: test-nfs-claim

你可以在 nginx 容器上执行两个卷挂载：

• /usr/share/nginx/html 用于静态网站
• /etc/nginx/nginx.conf 作为默认配置

访问控制

使用组 ID（GID）配置的存储仅允许 Pod 使用相同的 GID 进行写入。 GID 不匹配或缺失将会导致无权访问错误。 为了减少与用户的协调，管理员可以对 PersistentVolume 添加 GID 注解。 这样 GID 就能自动添加到使用 PersistentVolume 的任何 Pod 中。

使用 pv.beta.kubernetes.io/gid 注解的方法如下所示：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
  annotations:
    pv.beta.kubernetes.io/gid: "1234"

当 Pod 使用带有 GID 注解的 PersistentVolume 时，注解的 GID 会被应用于 Pod 中的所有容器， 应用的方法与 Pod 的安全上下文中指定的 GID 相同。 每个 GID，无论是来自 PersistentVolume 注解还是来自 Pod 规约，都会被应用于每个容器中运行的第一个进程。

接下来

• 进一步了解 PersistentVolumes
• 阅读持久存储设计文档

参考

• PersistentVolume
• PersistentVolumeSpec
• PersistentVolumeClaim
• PersistentVolumeClaimSpec

11 - 配置 Pod 使用投射卷作存储

本文介绍怎样通过 projected 卷将现有的多个卷资源挂载到相同的目录。 当前，secret、configMap、downwardAPI 和 serviceAccountToken 卷可以被投射。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

为 Pod 配置投射卷

本练习中，你将使用本地文件来创建用户名和密码 Secret， 然后创建运行一个容器的 Pod， 该 Pod 使用projected 卷将 Secret 挂载到相同的路径下。

下面是 Pod 的配置文件：

pods/storage/projected.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox:1.28
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

1. 创建 Secret：

   # 创建包含用户名和密码的文件：
   echo -n "admin" > ./username.txt
   echo -n "1f2d1e2e67df" > ./password.txt
   
   # 在 Secret 中引用上述文件
   kubectl create secret generic user --from-file=./username.txt
   kubectl create secret generic pass --from-file=./password.txt
   

2. 创建 Pod：

   kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
   

3. 确认 Pod 中的容器运行正常，然后监视 Pod 的变化：

   kubectl get --watch pod test-projected-volume
   

   输出结果和下面类似：

   NAME                    READY     STATUS    RESTARTS   AGE
   test-projected-volume   1/1       Running   0          14s
   

4. 在另外一个终端中，打开容器的 shell：

   kubectl exec -it test-projected-volume -- /bin/sh
   

5. 在 shell 中，确认 projected-volume 目录包含你的投射源：

   ls /projected-volume/
   

清理

删除 Pod 和 Secret：

kubectl delete pod test-projected-volume
kubectl delete secret user pass

接下来

• 进一步了解 projected 卷。
• 阅读一体卷设计文档。

12 - 为 Pod 或容器配置安全上下文

安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。 安全上下文包括但不限于：

• 自主访问控制（Discretionary Access Control）： 基于用户 ID（UID）和组 ID（GID） 来判定对对象（例如文件）的访问权限。

• 安全性增强的 Linux（SELinux）： 为对象赋予安全性标签。

• 以特权模式或者非特权模式运行。

• Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。

• AppArmor：使用程序配置来限制个别程序的权能。

• Seccomp：过滤进程的系统调用。

• allowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。 此布尔值直接控制是否为容器进程设置 no_new_privs标志。 当容器满足一下条件之一时，allowPrivilegeEscalation 总是为 true：

  • 以特权模式运行，或者
  • 具有 CAP_SYS_ADMIN 权能

• readOnlyRootFilesystem：以只读方式加载容器的根文件系统。

以上条目不是安全上下文设置的完整列表 -- 请参阅 SecurityContext 了解其完整列表。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

为 Pod 设置安全性上下文

要为 Pod 设置安全性设置，可在 Pod 规约中包含 securityContext 字段。securityContext 字段值是一个 PodSecurityContext 对象。你为 Pod 所设置的安全性配置会应用到 Pod 中所有 Container 上。 下面是一个 Pod 的配置文件，该 Pod 定义了 securityContext 和一个 emptyDir 卷：

pods/security/security-context.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    supplementalGroups: [4000]
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

在配置文件中，runAsUser 字段指定 Pod 中的所有容器内的进程都使用用户 ID 1000 来运行。runAsGroup 字段指定所有容器中的进程都以主组 ID 3000 来运行。 如果忽略此字段，则容器的主组 ID 将是 root（0）。 当 runAsGroup 被设置时，所有创建的文件也会划归用户 1000 和组 3000。 由于 fsGroup 被设置，容器中所有进程也会是附组 ID 2000 的一部分。 卷 /data/demo 及在该卷中创建的任何文件的属主都会是组 ID 2000。 此外，当 supplementalGroups 字段被指定时，容器的所有进程也会成为所指定的组的一部分。 如果此字段被省略，则表示为空。

创建该 Pod：

kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml

检查 Pod 的容器处于运行状态：

kubectl get pod security-context-demo

开启一个 Shell 进入到运行中的容器：

kubectl exec -it security-context-demo -- sh

在你的 Shell 中，列举运行中的进程：

ps

输出显示进程以用户 1000 运行，即 runAsUser 所设置的值：

PID   USER     TIME  COMMAND
    1 1000      0:00 sleep 1h
    6 1000      0:00 sh
...

在你的 Shell 中，进入 /data 目录列举其内容：

cd /data
ls -l

输出显示 /data/demo 目录的组 ID 为 2000，即 fsGroup 的设置值：

drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo

在你的 Shell 中，进入到 /data/demo 目录下创建一个文件：

cd demo
echo hello > testfile

列举 /data/demo 目录下的文件：

ls -l

输出显示 testfile 的组 ID 为 2000，也就是 fsGroup 所设置的值：

-rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile

运行下面的命令：

id

输出类似于：

uid=1000 gid=3000 groups=2000,3000,4000

从输出中你会看到 gid 值为 3000，也就是 runAsGroup 字段的值。 如果 runAsGroup 被忽略，则 gid 会取值 0（root），而进程就能够与 root 用户组所拥有以及要求 root 用户组访问权限的文件交互。 你还可以看到，除了 gid 之外，groups 还包含了由 fsGroup 和 supplementalGroups 指定的组 ID。

退出你的 Shell：

exit

容器镜像内 /etc/group 中定义的隐式组成员身份

默认情况下，Kubernetes 会将 Pod 中的组信息与容器镜像内 /etc/group 中定义的信息合并。

pods/security/security-context-5.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

此 Pod 的安全上下文包含 runAsUser、runAsGroup 和 supplementalGroups。
然而，你可以看到，挂接到容器进程的实际附加组将包括来自容器镜像中 /etc/group 的组 ID。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/security/security-context-5.yaml

验证 Pod 的 Container 正在运行：

kubectl get pod security-context-demo

打开一个 Shell 进入正在运行的 Container：

kubectl exec -it security-context-demo -- sh

检查进程身份：

$ id

输出类似于：

uid=1000 gid=3000 groups=3000,4000,50000

你可以看到 groups 包含组 ID 50000。 这是因为镜像中定义的用户（uid=1000）属于在容器镜像内 /etc/group 中定义的组（gid=50000）。

检查容器镜像中的 /etc/group：

$ cat /etc/group

你可以看到 uid 1000 属于组 50000。

...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

退出你的 Shell：

exit

配置 Pod 的细粒度 SupplementalGroups 控制

通过为 kubelet 和 kube-apiserver 设置 SupplementalGroupsPolicy 特性门控， 并为 Pod 设置 .spec.securityContext.supplementalGroupsPolicy 字段，此特性可以被启用。

supplementalGroupsPolicy 字段为 Pod 中的容器进程定义了计算附加组的策略。 此字段有两个有效值：

• Merge：为容器的主用户在 /etc/group 中定义的组成员身份将被合并。 如果不指定，这就是默认策略。

• Strict：仅将 fsGroup、supplementalGroups 或 runAsGroup 字段中的组 ID 挂接为容器进程的附加组。这意味着容器主用户在 /etc/group 中的组成员身份将不会被合并。

当此特性被启用时，它还会在 .status.containerStatuses[].user.linux 字段中暴露挂接到第一个容器进程的进程身份。这对于检测是否挂接了隐式组 ID 非常有用。

pods/security/security-context-6.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

此 Pod 清单定义了 supplementalGroupsPolicy=Strict。 你可以看到没有将 /etc/group 中定义的组成员身份合并到容器进程的附加组中。

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/security/security-context-6.yaml

验证 Pod 的 Container 正在运行：

kubectl get pod security-context-demo

检查进程身份：

kubectl exec -it security-context-demo -- id

输出类似于：

uid=1000 gid=3000 groups=3000,4000

查看 Pod 的状态：

kubectl get pod security-context-demo -o yaml

你可以看到 status.containerStatuses[].user.linux 字段暴露了挂接到第一个容器进程的进程身份。

...
status:
  containerStatuses:
  - name: sec-ctx-demo
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

实现

已知以下容器运行时支持细粒度的 SupplementalGroups 控制。

CRI 级别：

• containerd，自 v2.0 起
• CRI-O，自 v1.31 起

你可以在 Node 状态中查看此特性是否受支持。

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

为 Pod 配置卷访问权限和属主变更策略

默认情况下，Kubernetes 在挂载一个卷时，会递归地更改每个卷中的内容的属主和访问权限， 使之与 Pod 的 securityContext 中指定的 fsGroup 匹配。 对于较大的数据卷，检查和变更属主与访问权限可能会花费很长时间，降低 Pod 启动速度。 你可以在 securityContext 中使用 fsGroupChangePolicy 字段来控制 Kubernetes 检查和管理卷属主和访问权限的方式。

fsGroupChangePolicy - fsGroupChangePolicy 定义在卷被暴露给 Pod 内部之前对其 内容的属主和访问许可进行变更的行为。此字段仅适用于那些支持使用 fsGroup 来 控制属主与访问权限的卷类型。此字段的取值可以是：

• OnRootMismatch：只有根目录的属主与访问权限与卷所期望的权限不一致时， 才改变其中内容的属主和访问权限。这一设置有助于缩短更改卷的属主与访问 权限所需要的时间。
• Always：在挂载卷时总是更改卷中内容的属主和访问权限。

例如：

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

将卷权限和所有权更改委派给 CSI 驱动程序

如果你部署了一个容器存储接口 (CSI) 驱动，而该驱动支持 VOLUME_MOUNT_GROUP NodeServiceCapability， 在 securityContext 中指定 fsGroup 来设置文件所有权和权限的过程将由 CSI 驱动而不是 Kubernetes 来执行。在这种情况下，由于 Kubernetes 不执行任何所有权和权限更改， fsGroupChangePolicy 不会生效，并且按照 CSI 的规定，CSI 驱动应该使用所指定的 fsGroup 来挂载卷，从而生成了一个对 fsGroup 可读/可写的卷.

为 Container 设置安全性上下文

若要为 Container 设置安全性配置，可以在 Container 清单中包含 securityContext 字段。securityContext 字段的取值是一个 SecurityContext 对象。你为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置在与 Pod 层面设置的内容发生重叠时，会重写 Pod 层面的设置。Container 层面的设置不会影响到 Pod 的卷。

下面是一个 Pod 的配置文件，其中包含一个 Container。Pod 和 Container 都有 securityContext 字段：

pods/security/security-context-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false

创建该 Pod：

kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml

验证 Pod 中的容器处于运行状态：

kubectl get pod security-context-demo-2

启动一个 Shell 进入到运行中的容器内：

kubectl exec -it security-context-demo-2 -- sh

在你的 Shell 中，列举运行中的进程：

ps aux

输出显示进程以用户 2000 运行。该值是在 Container 的 runAsUser 中设置的。 该设置值重写了 Pod 层面所设置的值 1000。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js
...

退出你的 Shell：

exit

为 Container 设置权能

使用 Linux 权能， 你可以赋予进程 root 用户所拥有的某些特权，但不必赋予其全部特权。 要为 Container 添加或移除 Linux 权能，可以在 Container 清单的 securityContext 节包含 capabilities 字段。

首先，看一下不包含 capabilities 字段时候会发生什么。 下面是一个配置文件，其中没有添加或移除容器的权能：

pods/security/security-context-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-3
spec:
  containers:
  - name: sec-ctx-3
    image: gcr.io/google-samples/hello-app:2.0

创建该 Pod：

kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml

验证 Pod 的容器处于运行状态：

kubectl get pod security-context-demo-3

启动一个 Shell 进入到运行中的容器：

kubectl exec -it security-context-demo-3 -- sh

在你的 Shell 中，列举运行中的进程：

ps aux

输出显示容器中进程 ID（PIDs）：

USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js

在你的 Shell 中，查看进程 1 的状态：

cd /proc/1
cat status

输出显示进程的权能位图：

...
CapPrm:	00000000a80425fb
CapEff:	00000000a80425fb
...

记下进程权能位图，之后退出你的 Shell：

exit

接下来运行一个与前例中容器相同的容器，只是这个容器有一些额外的权能设置。

下面是一个 Pod 的配置，其中运行一个容器。配置为容器添加 CAP_NET_ADMIN 和 CAP_SYS_TIME 权能：

pods/security/security-context-4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

创建 Pod：

kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml

启动一个 Shell，进入到运行中的容器：

kubectl exec -it security-context-demo-4 -- sh

在你的 Shell 中，查看进程 1 的权能：

cd /proc/1
cat status

输出显示的是进程的权能位图：

...
CapPrm:	00000000aa0435fb
CapEff:	00000000aa0435fb
...

比较两个容器的权能位图：

00000000a80425fb
00000000aa0435fb

在第一个容器的权能位图中，位 12 和 25 是没有设置的。在第二个容器中，位 12 和 25 是设置了的。位 12 是 CAP_NET_ADMIN 而位 25 则是 CAP_SYS_TIME。 参见 capability.h 了解权能常数的定义。

为容器设置 Seccomp 配置

若要为容器设置 Seccomp 配置（Profile），可在你的 Pod 或 Container 清单的 securityContext 节中包含 seccompProfile 字段。该字段是一个 SeccompProfile 对象，包含 type 和 localhostProfile 属性。 type 的合法选项包括 RuntimeDefault、Unconfined 和 Localhost。 localhostProfile 只能在 type: Localhost 配置下才可以设置。 该字段标明节点上预先设定的配置的路径，路径是相对于 kubelet 所配置的 Seccomp 配置路径（使用 --root-dir 设置）而言的。

下面是一个例子，设置容器使用节点上容器运行时的默认配置作为 Seccomp 配置：

...
securityContext:
  seccompProfile:
    type: RuntimeDefault

下面是另一个例子，将 Seccomp 的样板设置为位于 <kubelet-根目录>/seccomp/my-profiles/profile-allow.json 的一个预先配置的文件。

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-profiles/profile-allow.json

为 Container 设置 AppArmor 配置

要为 Container 设置 AppArmor 配置，请在 Container 的 securityContext 节中包含 appArmorProfile 字段。 appArmorProfile 字段是一个 AppArmorProfile 对象，由 type 和 localhostProfile 组成。
type 的有效选项包括 RuntimeDefault（默认）、Unconfined 和 Localhost。 只有当 type 为 Localhost 时，才能设置 localhostProfile。
它表示节点上预配的配置文件的名称。 此配置需要被加载到所有适合 Pod 的节点上，因为你不知道 Pod 将被调度到哪里。
关于设置自定义配置的方法，参见使用配置文件设置节点。

注意：如果 containers[*].securityContext.appArmorProfile.type 被显式设置为 RuntimeDefault，那么如果 AppArmor 未在 Node 上被启用，Pod 将不会被准入。
然而，如果 containers[*].securityContext.appArmorProfile.type 未被指定， 则只有在节点已启用 AppArmor 时才会应用默认值（也是 RuntimeDefault）。
如果节点已禁用 AppArmor，Pod 将被准入，但 Container 将不受 RuntimeDefault 配置的限制。

以下是将 AppArmor 配置设置为节点的容器运行时默认配置的例子：

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: RuntimeDefault

以下是将 AppArmor 配置设置为名为 k8s-apparmor-example-deny-write 的预配配置的例子：

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write

有关更多细节参见使用 AppArmor 限制容器对资源的访问。

为 Container 赋予 SELinux 标签

若要给 Container 设置 SELinux 标签，可以在 Pod 或 Container 清单的 securityContext 节包含 seLinuxOptions 字段。 seLinuxOptions 字段的取值是一个 SELinuxOptions 对象。下面是一个应用 SELinux 标签的例子：

...
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

高效重打 SELinux 卷标签

默认情况下，容器运行时递归地将 SELinux 标签赋予所有 Pod 卷上的所有文件。 为了加快该过程，Kubernetes 使用挂载可选项 -o context=<label> 可以立即改变卷的 SELinux 标签。

要使用这项加速功能，必须满足下列条件：

• 必须启用 ReadWriteOncePod 和 SELinuxMountReadWriteOncePod 特性门控。

• Pod 必须使用带有对应的 accessModes 和特性门控 的 PersistentVolumeClaim。
  • 卷具有 accessModes: ["ReadWriteOncePod"]，并且 SELinuxMountReadWriteOncePod 特性门控已启用。
  • 或者卷可以使用任何其他访问模式，并且必须启用 SELinuxMountReadWriteOncePod、SELinuxChangePolicy 和 SELinuxMount 特性门控，且 Pod 已将 spec.securityContext.seLinuxChangePolicy 设置为 nil（默认值）或 MountOption。

• Pod（或其中使用 PersistentVolumeClaim 的所有容器）必须设置 seLinuxOptions。

• 对应的 PersistentVolume 必须是：
  • 使用传统树内（In-Tree） iscsi、rbd 或 fs 卷类型的卷。
  • 或者是使用 CSI 驱动程序的卷 CSI 驱动程序必须能够通过在 CSIDriver 实例中设置 spec.seLinuxMount: true 以支持 -o context 挂载。

对于所有其他卷类型，重打 SELinux 标签的方式有所不同： 容器运行时为卷中的所有节点（文件和目录）递归地修改 SELinux 标签。

对于不希望使用挂载选项来重新打标签的 Pod，可以将 spec.securityContext.seLinuxChangePolicy 设置为 Recursive。 当多个 Pod 共享同一节点上的单个卷，但使用不同的 SELinux 标签以允许同时访问此卷时， 此配置是必需的。例如，一个特权 Pod 运行时使用 spc_t 标签， 而一个非特权 Pod 运行时使用默认标签 container_file_t。 在不设置 spec.securityContext.seLinuxChangePolicy（或使用默认值 MountOption）的情况下， 这样的多个 Pod 中只能有一个在节点上运行，其他 Pod 会在 ContainerCreating 时报错 conflicting SELinux labels of volume <卷名称>: <正运行的 Pod 的标签> and <未启动的 Pod 的标签>。

SELinuxWarningController

为了更容易识别受 SELinux 卷重新打标签的变化所影响的 Pod，一个名为 SELinuxWarningController 的新控制器已被添加到 kube-controller-manager 中。 这个控制器默认是被禁用的，你可以通过设置 --controllers=*,selinux-warning-controller 命令行标志或通过在 KubeControllerManagerConfiguration 中设置 genericControllerManagerConfiguration.controllers 字段来启用。 此控制器需要启用 SELinuxChangePolicy 特性门控。

当此控制器被启用时，它会观察运行中的 Pod。 当控制器检测到两个 Pod 使用相同的卷但具有不同的 SELinux 标签时：

1. 它会向这两个 Pod 发出一个事件。通过 kubectl describe pod <Pod 名称> 可以看到：

   SELinuxLabel "<Pod 上的标签>" conflicts with pod <另一个 Pod 名称> that uses the same volume as this pod with SELinuxLabel "<另一个 Pod 标签>". If both pods land on the same node, only one of them may access the volume.
   

2. 增加 selinux_warning_controller_selinux_volume_conflict 指标值。 此指标将两个 Pod 的名称 + 命名空间作为标签，以便轻松识别受影响的 Pod。

集群管理员可以使用此信息识别受规划变更所影响的 Pod，并主动筛选出不需优化的 Pod （即设置 spec.securityContext.seLinuxChangePolicy: Recursive）。

特性门控

以下特性门控可以控制 SELinux 卷重新打标签的行为：

• SELinuxMountReadWriteOncePod：为具有 accessModes: ["ReadWriteOncePod"] 的卷启用优化。 启用此特性门控是非常安全的，因为在这种访问模式下，不会出现两个 Pod 共享同一卷的情况。 此特性门控自 v1.28 起默认被启用。

• SELinuxChangePolicy：在 Pod 中启用 spec.securityContext.seLinuxChangePolicy 字段， 并在 kube-controller-manager 中启用相关的 SELinuxWarningController。 你可以在启用 SELinuxMount 之前使用此特性来检查集群中正在运行的 Pod，并主动筛选出不需优化的 Pod。 此特性门控需要启用 SELinuxMountReadWriteOncePod。它在 1.32 中是 Alpha 阶段，并默认被禁用。

• SELinuxMount：为所有符合条件的卷启用优化。由于可能会破坏现有的工作负载，所以我们建议先启用 SELinuxChangePolicy 特性门控和 SELinuxWarningController，以检查这种更改的影响。 此特性门控要求启用 SELinuxMountReadWriteOncePod 和 SELinuxChangePolicy。 它在 1.32 中是 Alpha 阶段，并默认被禁用。

管理对 /proc 文件系统的访问

对于遵循 OCI 运行时规范的运行时，容器默认运行模式下，存在多个被屏蔽且只读的路径。 这样做的结果是在容器的 mount 命名空间内会存在这些路径，并且这些路径的工作方式与容器是隔离主机时类似， 但容器进程无法写入它们。 被屏蔽的和只读的路径列表如下：

• 被屏蔽的路径：

  • /proc/asound
  • /proc/acpi
  • /proc/kcore
  • /proc/keys
  • /proc/latency_stats
  • /proc/timer_list
  • /proc/timer_stats
  • /proc/sched_debug
  • /proc/scsi
  • /sys/firmware
  • /sys/devices/virtual/powercap

• 只读的路径：

  • /proc/bus
  • /proc/fs
  • /proc/irq
  • /proc/sys
  • /proc/sysrq-trigger

对于某些 Pod，你可能希望绕过默认的路径屏蔽。 最常见的情况是你尝试在 Kubernetes 容器内（在 Pod 内）运行容器。

securityContext 字段 procMount 允许用户请求容器的 /proc 为 Unmasked， 或者由容器进程以读写方式挂载。这一设置也适用于不在 /proc 内的 /sys/firmware 路径。

...
securityContext:
  procMount: Unmasked

讨论

Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的卷（如果有的话）。 尤其是，fsGroup 和 seLinuxOptions 按下面的方式应用到挂载卷上：

• fsGroup：支持属主管理的卷会被修改，将其属主变更为 fsGroup 所指定的 GID， 并且对该 GID 可写。进一步的细节可参阅 属主变更设计文档。

• seLinuxOptions：支持 SELinux 标签的卷会被重新打标签，以便可被 seLinuxOptions 下所设置的标签访问。通常你只需要设置 level 部分。 该部分设置的是赋予 Pod 中所有容器及卷的 多类别安全性（Multi-Category Security，MCS)标签。

清理

删除之前创建的所有 Pod：

kubectl delete pod security-context-demo
kubectl delete pod security-context-demo-2
kubectl delete pod security-context-demo-3
kubectl delete pod security-context-demo-4

接下来

• PodSecurityContext API 定义
• SecurityContext API 定义
• CRI 插件配置指南
• 安全上下文的设计文档（英文）
• 属主管理的设计文档（英文）
• Pod 安全性准入
• AllowPrivilegeEscalation 的设计文档（英文）
• 关于在 Linux 系统中的安全机制的更多信息，可参阅 Linux 内核安全性能力概述（注意：部分信息已过时）。
• 了解 Linux Pod 的 user 命名空间。
• OCI 运行时规范中的被屏蔽的路径

13 - 为 Pod 配置服务账号

Kubernetes 提供两种完全不同的方式来为客户端提供支持，这些客户端可能运行在你的集群中， 也可能与你的集群的控制面相关， 需要向 API 服务器完成身份认证。

服务账号（Service Account） 为 Pod 中运行的进程提供身份标识， 并映射到 ServiceAccount 对象。当你向 API 服务器执行身份认证时， 你会将自己标识为某个用户（User）。Kubernetes 能够识别用户的概念， 但是 Kubernetes 自身并不提供 User API。

本服务是关于 ServiceAccount 的，而 ServiceAccount 则确实存在于 Kubernetes 的 API 中。 本指南为你展示为 Pod 配置 ServiceAccount 的一些方法。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

使用默认的服务账号访问 API 服务器

当 Pod 与 API 服务器联系时，Pod 会被认证为某个特定的 ServiceAccount（例如：default）。 在每个名字空间中，至少存在一个 ServiceAccount。

每个 Kubernetes 名字空间至少包含一个 ServiceAccount：也就是该名字空间的默认服务账号， 名为 default。如果你在创建 Pod 时没有指定 ServiceAccount，Kubernetes 会自动将该名字空间中名为 default 的 ServiceAccount 分配给该 Pod。

你可以检视你刚刚创建的 Pod 的细节。例如：

kubectl get pods/<podname> -o yaml

在输出中，你可以看到字段 spec.serviceAccountName。当你在创建 Pod 时未设置该字段时， Kubernetes 自动为 Pod 设置这一属性的取值。

Pod 中运行的应用可以使用这一自动挂载的服务账号凭据来访问 Kubernetes API。 参阅访问集群以进一步了解。

当 Pod 被身份认证为某个 ServiceAccount 时， 其访问能力取决于所使用的鉴权插件和策略。

当 Pod 被删除时，即使设置了终结器，API 凭据也会自动失效。 需要额外注意的是，API 凭据会在 Pod 上设置的 .metadata.deletionTimestamp 之后的 60 秒内失效 （删除时间戳通常是 delete 请求被接受的时间加上 Pod 的终止宽限期）。

放弃 API 凭据的自动挂载

如果你不希望 kubelet 自动挂载某 ServiceAccount 的 API 访问凭据，你可以选择不采用这一默认行为。 通过在 ServiceAccount 对象上设置 automountServiceAccountToken: false，可以放弃在 /var/run/secrets/kubernetes.io/serviceaccount/token 处自动挂载该服务账号的 API 凭据。

例如：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
automountServiceAccountToken: false
...

你也可以选择不给特定 Pod 自动挂载 API 凭据：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...

如果 ServiceAccount 和 Pod 的 .spec 都设置了 automountServiceAccountToken 值， 则 Pod 上 spec 的设置优先于服务账号的设置。

使用多个服务账号

每个名字空间都至少有一个 ServiceAccount：名为 default 的默认 ServiceAccount 资源。 你可以用下面的命令列举你当前名字空间 中的所有 ServiceAccount 资源：

kubectl get serviceaccounts

输出类似于：

NAME      SECRETS    AGE
default   1          1d

你可以像这样来创建额外的 ServiceAccount 对象：

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF

ServiceAccount 对象的名字必须是一个有效的 DNS 子域名。

如果你查询服务账号对象的完整信息，如下所示：

kubectl get serviceaccounts/build-robot -o yaml

输出类似于：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2019-06-16T00:12:34Z
  name: build-robot
  namespace: default
  resourceVersion: "272500"
  uid: 721ab723-13bc-11e5-aec2-42010af0021e

你可以使用鉴权插件来设置服务账号的访问许可。

要使用非默认的服务账号，将 Pod 的 spec.serviceAccountName 字段设置为你想用的服务账号名称。

只能在创建 Pod 时或者为新 Pod 指定模板时，你才可以设置 serviceAccountName。 你不能更新已经存在的 Pod 的 .spec.serviceAccountName 字段。

清理

如果你尝试了创建前文示例中所给的 build-robot ServiceAccount， 你可以通过运行下面的命令来完成清理操作：

kubectl delete serviceaccount/build-robot

手动为 ServiceAccount 创建 API 令牌

假设你已经有了一个前文所提到的名为 "build-robot" 的服务账号。 你可以使用 kubectl 为该 ServiceAccount 获得一个有时限的 API 令牌：

kubectl create token build-robot

这一命令的输出是一个令牌，你可以使用该令牌来将身份认证为对应的 ServiceAccount。 你可以使用 kubectl create token 命令的 --duration 参数来请求特定的令牌有效期 （实际签发的令牌的有效期可能会稍短一些，也可能会稍长一些）。

使用 kubectl v1.31 或更高版本，可以创建一个直接绑定到 Node 的服务账号令牌：

kubectl create token build-robot --bound-object-kind Node --bound-object-name node-001 --bound-object-uid 123...456

此令牌将有效直至其过期或关联的 Node 或服务账户被删除。

手动为 ServiceAccount 创建长期有效的 API 令牌

如果你需要为 ServiceAccount 获得一个 API 令牌，你可以创建一个新的、带有特殊注解 kubernetes.io/service-account.name 的 Secret 对象。

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF

如果你通过下面的命令来查看 Secret：

kubectl get secret/build-robot-secret -o yaml

你可以看到 Secret 中现在包含针对 "build-robot" ServiceAccount 的 API 令牌。

鉴于你所设置的注解，控制面会自动为该 ServiceAccount 生成一个令牌，并将其保存到相关的 Secret 中。控制面也会为已删除的 ServiceAccount 执行令牌清理操作。

kubectl describe secrets/build-robot-secret

输出类似于这样：

Name:           build-robot-secret
Namespace:      default
Labels:         <none>
Annotations:    kubernetes.io/service-account.name: build-robot
                kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1338 bytes
namespace:      7 bytes
token:          ...

当你删除一个与某 Secret 相关联的 ServiceAccount 时，Kubernetes 的控制面会自动清理该 Secret 中长期有效的令牌。

为服务账号添加 ImagePullSecrets

首先，生成一个 imagePullSecret； 接下来，验证该 Secret 已被创建。例如：

• 按为 Pod 设置 imagePullSecret 所描述的，生成一个镜像拉取 Secret：

  kubectl create secret docker-registry myregistrykey --docker-server=<registry name> \
          --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
          --docker-email=DUMMY_DOCKER_EMAIL
  

• 检查该 Secret 已经被创建。

  kubectl get secrets myregistrykey
  

  输出类似于这样：

  NAME             TYPE                              DATA    AGE
  myregistrykey    kubernetes.io/.dockerconfigjson   1       1d
  

将镜像拉取 Secret 添加到服务账号

接下来更改名字空间的默认服务账号，将该 Secret 用作 imagePullSecret。

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

你也可以通过手动编辑该对象来实现同样的效果：

kubectl edit serviceaccount/default

sa.yaml 文件的输出类似于：

你所选择的文本编辑器会被打开，展示如下所示的配置：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  resourceVersion: "243024"
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6

使用你的编辑器，删掉包含 resourceVersion 主键的行，添加包含 imagePullSecrets: 的行并保存文件。对于 uid 而言，保持其取值与你读到的值一样。

当你完成这些变更之后，所编辑的 ServiceAccount 看起来像是这样：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
  - name: myregistrykey

检查 imagePullSecrets 已经被设置到新 Pod 上

现在，在当前名字空间中创建新 Pod 并使用默认 ServiceAccount 时， 新 Pod 的 spec.imagePullSecrets 会被自动设置。

kubectl run nginx --image=<registry name>/nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'

输出为：

myregistrykey

服务账号令牌卷投射

kubelet 还可以将 ServiceAccount 令牌投射到 Pod 中。你可以指定令牌的期望属性， 例如受众和有效期限。这些属性在 default ServiceAccount 令牌上无法配置。 当 Pod 或 ServiceAccount 被删除时，该令牌也将对 API 无效。

你可以使用类型为 ServiceAccountToken 的投射卷来为 Pod 的 spec 配置此行为。

来自此投射卷的令牌是一个 JSON Web Token (JWT)。 此令牌的 JSON 载荷遵循明确定义的模式，绑定到 Pod 的令牌的示例载荷如下：

{
  "aud": [  # 匹配请求的受众，或当没有明确请求时匹配 API 服务器的默认受众
    "https://kubernetes.default.svc"
  ],
  "exp": 1731613413,
  "iat": 1700077413,
  "iss": "https://kubernetes.default.svc",  # 匹配传递到 --service-account-issuer 标志的第一个值
  "jti": "ea28ed49-2e11-4280-9ec5-bc3d1d84661a",
  "kubernetes.io": {
    "namespace": "kube-system",
    "node": {
      "name": "127.0.0.1",
      "uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
    },
    "pod": {
      "name": "coredns-69cbfb9798-jv9gn",
      "uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
    },
    "serviceaccount": {
      "name": "coredns",
      "uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
    },
    "warnafter": 1700081020
  },
  "nbf": 1700077413,
  "sub": "system:serviceaccount:kube-system:coredns"
}

启动使用服务账号令牌投射的 Pod

要为某 Pod 提供一个受众为 vault 并且有效期限为 2 小时的令牌，你可以定义一个与下面类似的 Pod 清单：

pods/pod-projected-svc-token.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

创建此 Pod：

kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml

kubelet 组件会替 Pod 请求令牌并将其保存起来；通过将令牌存储到一个可配置的路径以使之在 Pod 内可用；在令牌快要到期的时候刷新它。kubelet 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时的时候主动请求将其轮换掉。

应用负责在令牌被轮换时重新加载其内容。通常而言，周期性地（例如，每隔 5 分钟） 重新加载就足够了，不必跟踪令牌的实际过期时间。

发现服务账号分发者

如果你在你的集群中已经为 ServiceAccount 启用了令牌投射， 那么你也可以利用其发现能力。Kubernetes 提供一种方式来让客户端将一个或多个外部系统进行联邦， 作为标识提供者（Identity Provider），而这些外部系统的角色是依赖方（Relying Party）。

当此特性被启用时，Kubernetes API 服务器会通过 HTTP 发布一个 OpenID 提供者配置文档。 该配置文档发布在 /.well-known/openid-configuration 路径。 这里的 OpenID 提供者配置（OpenID Provider Configuration）有时候也被称作 “发现文档（Discovery Document）”。 Kubernetes API 服务器也通过 HTTP 在 /openid/v1/jwks 处发布相关的 JSON Web Key Set（JWKS）。

使用 RBAC 的集群都包含一个的默认 RBAC ClusterRole, 名为 system:service-account-issuer-discovery。 默认的 RBAC ClusterRoleBinding 将此角色分配给 system:serviceaccounts 组， 所有 ServiceAccount 隐式属于该组。这使得集群上运行的 Pod 能够通过它们所挂载的服务账号令牌访问服务账号发现文档。 此外，管理员可以根据其安全性需要以及期望集成的外部系统，选择是否将该角色绑定到 system:authenticated 或 system:unauthenticated。

JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账号令牌的公钥数据。 依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 jwks_uri 来查找 JWKS。

在很多场合，Kubernetes API 服务器都不会暴露在公网上，不过对于缓存并向外提供 API 服务器响应数据的公开末端而言，用户或者服务提供商可以选择将其暴露在公网上。 在这种环境中，可能会重载 OpenID 提供者配置中的 jwks_uri，使之指向公网上可用的末端地址，而不是 API 服务器的地址。 这时需要向 API 服务器传递 --service-account-jwks-uri 参数。 与分发者 URL 类似，此 JWKS URI 也需要使用 https 模式。

接下来

另请参见：

• 阅读为集群管理员提供的服务账号指南
• 阅读 Kubernetes中的鉴权
• 阅读 Secret 的概念
  • 或者学习使用 Secret 来安全地分发凭据
  • 不过也要注意，使用 Secret 来完成 ServiceAccount 身份验证的做法已经过时。 建议的替代做法是执行 ServiceAccount 令牌卷投射。

• 阅读理解投射卷
• 关于 OIDC 发现的相关背景信息，阅读服务账号签署密钥检索 KEP 这一 Kubernetes 增强提案
• 阅读 OIDC 发现规范

14 - 从私有仓库拉取镜像

本文介绍如何使用 Secret 从私有的镜像仓库或代码仓库拉取镜像来创建 Pod。 有很多私有镜像仓库正在使用中。这个任务使用的镜像仓库是 Docker Hub。

准备开始

• 你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

  • Killercoda
  • 玩转 Kubernetes

• 要进行此练习，你需要 docker 命令行工具和一个知道密码的 Docker ID。
• 如果你要使用不同的私有的镜像仓库，你需要有对应镜像仓库的命令行工具和登录信息。

登录 Docker 镜像仓库

在个人电脑上，要想拉取私有镜像必须在镜像仓库上进行身份验证。

使用 docker 命令工具来登录到 Docker Hub。 更多详细信息，请查阅 Docker ID accounts 中的 log in 部分。

docker login

当出现提示时，输入你的 Docker ID 和登录凭据（访问令牌或 Docker ID 的密码）。

登录过程会创建或更新保存有授权令牌的 config.json 文件。 查看 Kubernetes 如何解析这个文件。

查看 config.json 文件：