From 38e0a8b10d53fd03073fc429e63b3b6ec4f75633 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 19 Jun 2020 15:12:19 +0800 Subject: [PATCH] [zh] Sync manage resources for containers The manage-compute-resources-container.md file was renamed in the English site. The content in it has been reorganized for *who knows* reasons. This PR fixes the Chinese localization to make things work again. --- .../manage-compute-resources-container.md | 972 ------------ .../manage-resources-containers.md | 1310 +++++++++++++++++ 2 files changed, 1310 insertions(+), 972 deletions(-) delete mode 100644 content/zh/docs/concepts/configuration/manage-compute-resources-container.md create mode 100644 content/zh/docs/concepts/configuration/manage-resources-containers.md diff --git a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md deleted file mode 100644 index 776b977736..0000000000 --- a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md +++ /dev/null @@ -1,972 +0,0 @@ ---- -title: 为容器管理计算资源 -content_type: concept -weight: 20 -feature: - title: 自动装箱 - description: > - 根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 ---- - - - - - - -当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 - - - - - - - - -## 资源类型 - -*CPU* 和*内存*都是*资源类型*。资源类型具有基本单位。CPU 的单位是核心数，内存的单位是字节。 - -如果您使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页资源。巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 - -例如，在默认页面大小为 4KiB 的系统上，您可以指定一个限制，`hugepages-2Mi: 80Mi`。如果容器尝试分配 40 个 2MiB 大页面（总共 80 MiB ），则分配失败。 - -{{< note >}} -您不能过量使用`hugepages- *`资源。 -这与`memory`和`cpu`资源不同。 -{{< /note >}} - -CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 Kubernetes API server 读取和修改的对象。 - - - -## Pod 和 容器的资源请求和限制 - -Pod 中的每个容器都可以指定以下的一个或者多个值： - -- `spec.containers[].resources.limits.cpu` -- `spec.containers[].resources.limits.memory` -- `spec.containers[].resources.requests.cpu` -- `spec.containers[].resources.requests.memory` - -尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。 - - - -## CPU 的含义 - -CPU 资源的限制和请求以 *cpu* 为单位。 - -Kubernetes 中的一个 cpu 等于： - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 *Hyperthread* 在带有超线程的裸机 Intel 处理器上 - -允许浮点数请求。具有 `spec.containers[].resources.requests.cpu` 为 0.5 的容器保证了一半 CPU 要求 1 CPU的一半。表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。具有小数点（如 `0.1`）的请求由 API 转换为`100m`，精度不超过 `1m`。因此，可能会优先选择 `100m` 的形式。 - -CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。 - - - -## 内存的含义 - -内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值： - -```shell -128974848, 129e6, 129M, 123Mi -``` - - - -下面是个例子。 - -以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（226 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" - - name: wp - image: wordpress - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" -``` - - - -## 具有资源请求的 Pod 如何调度 - -当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。 - - - -## 具有资源限制的 Pod 如何运行 - -当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。 - -当使用 Docker 时： - - - -- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的 core 值，再乘以 1024，这个数字和 2 的较大者用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。 - -- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100，结果就是每 100ms 内 container 可以使用的 CPU 总时间。在此时间间隔（100ms）内，一个 container 使用的 CPU 时间不会超过它被分配的时间。 - - - - {{< note >}} - 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 - {{}} - - - -- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。 - - - -如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。 - -如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。 - -容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。 - -要确定容器是否由于资源限制而无法安排或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 - - - -## 监控计算资源使用 - -Pod 的资源使用情况被报告为 Pod 状态的一部分。 - -如果为集群配置了可选 [监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，则可以直接从 -[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 或者监控工具检索 Pod 资源的使用情况。 - - - -## 疑难解答 - -### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling - -如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示： - -```shell -kubectl describe pod frontend | grep -A 3 Events -``` -``` -Events: - FirstSeen LastSeen Count From Subobject PathReason Message - 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others -``` - - - -在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情： - -- 向集群添加更多节点。 -- 终止不需要的 Pod，为待处理的 Pod 腾出空间。 -- 检查 Pod 所需的资源是否大于所有节点的资源。 例如，如果全部节点的容量为`cpu：1`，那么一个请求为 `cpu：1.1`的 Pod 永远不会被调度。 - -您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如： - - -```shell -kubectl describe nodes e2e-test-node-pool-4lw4 -``` -``` -Name: e2e-test-node-pool-4lw4 -[ ... lines removed for clarity ...] -Capacity: - cpu: 2 - memory: 7679792Ki - pods: 110 -Allocatable: - cpu: 1800m - memory: 7474992Ki - pods: 110 -[ ... lines removed for clarity ...] -Non-terminated Pods: (5 in total) - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits - --------- ---- ------------ ---------- --------------- ------------- - kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) - kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) - kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) - kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) - kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) -Allocated resources: - (Total limits may be over 100 percent, i.e., overcommitted.) - CPU Requests CPU Limits Memory Requests Memory Limits - ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) -``` - - - -在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 - -通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。 - -Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 -[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。 -有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 - -可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。 - - - -## 我的容器被终止了 - -您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`： - -```shell -kubectl describe pod simmemleak-hra99 -``` -``` -Name: simmemleak-hra99 -Namespace: default -Image(s): saadali/simmemleak -Node: kubernetes-node-tf0f/10.240.216.66 -Labels: name=simmemleak -Status: Running -Reason: -Message: -IP: 10.244.2.75 -Replication Controllers: simmemleak (1/1 replicas created) -Containers: - simmemleak: - Image: saadali/simmemleak - Limits: - cpu: 100m - memory: 50Mi - State: Running - Started: Tue, 07 Jul 2015 12:54:41 -0700 - Last Termination State: Terminated - Exit Code: 1 - Started: Fri, 07 Jul 2015 12:54:30 -0700 - Finished: Fri, 07 Jul 2015 12:54:33 -0700 - Ready: False - Restart Count: 5 -Conditions: - Type Status - Ready False -Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a -``` - - - -在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 - -您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 - - -```shell -kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 -``` -``` -Container Name: simmemleak -LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] -``` - - - -您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。 - - - -## 本地临时存储 - -Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。 -在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 -Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。 - -该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。 - -{{< note >}} -如果使用可选的运行时分区，则根分区将不保存任何镜像层或可写层。 -{{< /note >}} - - - -### 本地临时存储的请求和限制设置 -Pod 的每个容器可以指定以下一项或多项： - -* `spec.containers[].resources.limits.ephemeral-storage` -* `spec.containers[].resources.requests.ephemeral-storage` - - - -对“临时存储”的限制和请求以字节为单位。您可以使用以下后缀之一将存储表示为纯整数或小数形式：E，P，T，G，M，K。您还可以使用2的幂次方：Ei，Pi，Ti，Gi，Mi，Ki。例如，以下内容表示的值其实大致相同： - -```shell -128974848, 129e6, 129M, 123Mi -``` - - - -例如，以下Pod具有两个容器。每个容器都有一个2GiB的本地临时存储请求。每个容器的本地临时存储限制为4GiB。因此，该Pod要求本地临时存储空间为4GiB，存储空间限制为8GiB。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" - - name: wp - image: wordpress - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" -``` - - - -### 如何调度临时存储请求的 Pod - -创建Pod时，Kubernetes调度程序会选择一个节点来运行Pod。每个节点都可以为Pod提供最大数量的本地临时存储。 -有关更多信息，请参见[节点可分配](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。 - -调度程序会确保调度的容器的资源请求的总和小于节点的容量。 - - - -### 具有临时存储限制的 Pod 如何运行 - -对于容器级隔离，如果容器的可写层和日志使用量超出其存储限制，则将驱逐Pod。对于 pod 级别的隔离，如果来自所有容器的本地临时存储使用量以及 Pod 的 emptyDir 卷的总和超过限制，则将驱逐Pod。 - - - -### 监控临时存储消耗 - -使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。 -通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 -从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。 -项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。 - - - -配额比目录扫描更快，更准确。 -将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 -如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。 - - - -Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 -如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。 - - - -要启用项目配额，集群操作员必须执行以下操作： - -* 在kubelet配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring = true` 功能。 在Kubernetes 1.15中默认为 false，因此必须显式设置为 true。 - -* 确保根分区（或可选的运行时分区）是在启用项目配额的情况下构建的。 所有 XFS 文件系统都支持项目配额，但是 ext4 文件系统必须专门构建。 - -* 确保在启用了项目配额的情况下挂载了根分区（或可选的运行时分区）。 - - - -#### 在启用项目配额的情况下构建和挂载文件系统 - -XFS文件系统在构建时不需要任何特殊操作; 它们是在启用项目配额的情况下自动构建的。 - -Ext4fs文件系统必须在启用了配额的情况下构建，然后必须在文件系统中启用它们： - -``` -% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device -% sudo tune2fs -O project -Q prjquota /dev/block_device - -``` - - - -要挂载文件系统，ext4fs 和 XFS 都需要在 `/etc/fstab` 中设置 `prjquota` 选项： - -``` -/dev/block_device /var/kubernetes_data defaults,prjquota 0 0 -``` - - - - -## 拓展资源 - -拓展资源是 `kubernetes.io` 域名之外的标准资源名称。它们允许集群管理员做分发，而且用户可以使用非Kubernetes内置资源。 -使用扩展资源需要两个步骤。 首先，集群管理员必须分发拓展资源。 其次，用户必须在 Pod 中请求拓展资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - - - -### 管理拓展资源 - -#### 节点级拓展资源 - -节点级拓展资源绑定到节点。 - - - -##### 设备插件托管资源 - -有关如何在每个节点上分发设备插件托管资源的信息，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 - - - -##### 其他资源 -为了发布新的节点级拓展资源，集群操作员可以向API服务器提交 `PATCH` HTTP 请求， -以在 `status.capacity` 中为集群中的节点指定可用数量。 -完成此操作后，节点的 `status.capacity` 将包含新资源。 -由kubelet异步使用新资源自动更新 `status.allocatable` 字段。 -请注意，由于调度程序在评估Pod适合性时使用节点的状态 `status.allocatable` 值， -因此在用新资源修补节点容量和请求在该节点上调度资源的第一个Pod之间可能会有短暂的延迟。 - - - -**示例:** - -这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1` -上通告五个 `example.com/foo` 资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - -{{< note >}} - - - -在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 -有关更多详细信息，请参见 -[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). -{{< /note >}} - - - -#### 集群级扩展资源 - -群集级扩展资源不绑定到节点。 它们通常由调度程序扩展程序管理，这些程序处理资源消耗和资源配额。 - -您可以在[调度程序策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度程序扩展程序处理的扩展资源。 - - - -**示例:** - -通过调度程序策略的以下配置，指示群集级扩展资源 "example.com/foo" 由调度程序扩展程序处理。 - -- 仅当Pod请求 "example.com/foo" 时，调度程序才会将 Pod 发送到调度程序扩展程序。 -- `ignoredByScheduler` 字段指定调度程序不在其 `PodFitsResources` 字段中检查 "example.com/foo" 资源。 - -```json -{ - "kind": "Policy", - "apiVersion": "v1", - "extenders": [ - { - "urlPrefix":"", - "bindVerb": "bind", - "managedResources": [ - { - "name": "example.com/foo", - "ignoredByScheduler": true - } - ] - } - ] -} -``` - - - -### 消耗扩展资源 - -就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 -调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。 - -{{< note >}} - - - -扩展资源取代了 Opaque 整数资源。 用户可以使用保留字 `kubernetes.io` 以外的任何域名前缀。 - -{{< /note >}} - - - -要在Pod中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` 映射中包含资源名称作为键。 - -{{< note >}} - - - -扩展资源不能过量使用，因此如果容器规范中存在请求和限制，则它们必须一致。 - -{{< /note >}} - - - -仅当满足所有资源请求(包括 CPU ，内存和任何扩展资源)时，才能调度 Pod。 只要资源请求无法满足，则 Pod 保持在 `PENDING` 状态。 - -**示例:** - -下面的 Pod 请求2个 CPU 和1个"example.com/foo"(扩展资源)。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: my-pod -spec: - containers: - - name: my-container - image: myimage - resources: - requests: - cpu: 2 - example.com/foo: 1 - limits: - example.com/foo: 1 -``` - - - - -## {{% heading "whatsnext" %}} - - - - -* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 - -* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 - -* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - -* [资源需求](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core) - - diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000..5b7b359848 --- /dev/null +++ b/content/zh/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,1310 @@ +--- +title: 为容器管理资源 +content_type: concept +weight: 40 +feature: + title: 自动装箱 + description: > + 根据资源需求和其他约束自动放置容器，同时避免影响可用性。将关键性工作负载和尽力而为性质的服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 +--- + + + + + + + +当你定义 {{< glossary_tooltip term_id="pod" >}} 时可以选择性地为每个 +{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。 +最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。 + +当你为 Pod 中的 Container 指定了资源 __请求__ 时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 +当你还为 Container 指定了资源 __约束__ 时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 +kubelet 还会为容器预留所 __请求__ 数量的系统资源，供其使用。 + + + + + +## 请求和约束 + +如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源 +`request` 属性所设置的资源量。不过，容器不可以使用超出其资源 `limit` +属性所设置的资源量。 + +例如，如果你将容器的 `memory` 的请求量设置为 256 MiB，而该容器所处的 Pod +被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pods +运行，那么该容器就可以尝试使用更多的内存。 + + + +如果你将某容器的 `memory` 约束设置为 4 GiB，kubelet （和 +{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}） +就会确保该约束生效。 +容器运行时会禁止容器使用超出所设置资源约束的资源。 +例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， +并引发内存不足（OOM）错误。 + +约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 +（系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。 + + + +## 资源类型 + +*CPU* 和*内存*都是*资源类型*。每种资源类型具有其基本单位。 +CPU 表达的是计算处理能力，其单位是 [Kubernetes CPUs](#meaning-of-cpu)。 +内存的单位是字节。 +如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。 +巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 + +例如，在默认页面大小为 4KiB 的系统上，您可以指定约束 `hugepages-2Mi: 80Mi`。 +如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。 + + + + +{{< note >}} +您不能过量使用 `hugepages- * `资源。 +这与 `memory` 和 `cpu` 资源不同。 +{{< /note >}} + +CPU 和内存统称为*计算资源*，或简称为*资源*。 +计算资源的数量是可测量的，可以被请求、被分配、被消耗。 +它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 +Kubernetes API 服务器读取和修改的对象。 + + + +## Pod 和 容器的资源请求和约束 + +Pod 中的每个容器都可以指定以下的一个或者多个值： + +- `spec.containers[].resources.limits.cpu` +- `spec.containers[].resources.limits.memory` +- `spec.containers[].resources.limits.hugepages-` +- `spec.containers[].resources.requests.cpu` +- `spec.containers[].resources.requests.memory` +- `spec.containers[].resources.requests.hugepages-` + +尽管请求和限制值只能在单个容器上指定，我们仍可方便地计算出 Pod 的资源请求和约束。 +Pod 对特定资源类型的请求/约束值是 Pod 中各容器对该类型资源的请求/约束值的总和。 + + + +## CPU 的含义 {#meaning-of-cpu} + +CPU 资源的约束和请求以 *cpu* 为单位。 + +Kubernetes 中的一个 cpu 等于云平台上的 **1 个 vCPU/核**和裸机 Intel +处理器上的 **1 个超线程 **。 + +你也可以表达带小数 CPU 的请求。`spec.containers[].resources.requests.cpu` 为 0.5 +的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 `0.1` 等价于表达式 `100m`， +可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 +具有小数点（如 `0.1`）的请求由 API 转换为 `100m`；最大精度是 `1m`。 +因此，或许你应该优先考虑使用 `100m` 的形式。 + +CPU 总是按绝对数量来请求的，不可以使用相对数量； +0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。 + + + +## 内存的含义 + +内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点整数形式来表示内存： +E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，以下表达式所代表的是大致相同的值： + +```shell +128974848、129e6、129M、123Mi +``` + + + +下面是个例子。 + +以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， +每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 +你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: wp + image: wordpress + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + + + +## 带资源请求的 Pod 如何调度 + +当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。 +每个节点对每种资源类型都有一个容量上限：可为 Pod 提供的 CPU 和内存量。 +调度程序确保对于每种资源类型，所调度的容器的资源请求的总和小于节点的容量。 +请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，如果容量检查失败， +调度程序仍会拒绝在该节点上放置 Pod。 +当稍后节点上资源用量增加，例如到达请求率的每日峰值区间时，节点上也不会出现资源不足的问题。 + + + +## 带资源约束的 Pod 如何运行 + +当 kubelet 启动 Pod 中的 Container 时，它会将 CPU 和内存约束信息传递给容器运行时。 + +当使用 Docker 时： + + + +- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的基础值，再乘以 1024。 + 这个数值和 2 的较大者用作 `docker run` 命令中的 + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) + 标志的值。 +- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100。 + 其结果就是每 100 毫秒内容器可以使用的 CPU 时间总量。在此期间（100ms），容器所使用的 CPU + 时间不会超过它被分配的时间。 + + {{< note >}} + 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 + {{}} + +- `spec.containers[].resources.limits.memory` 被转换为整数值，作为 `docker run` 命令中的 + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + 参数值。 + + + +如果 Container 超过其内存限制，则可能会被终止。如果容器可重新启动，则与所有其他类型的 +运行时失效一样，kubelet 将重新启动容器。 + +如果一个 Container 内存用量超过其内存请求值，那么当节点内存不足时，容器所处的 Pod 可能被逐出。 + +每个 Container 可能被允许也可能不被允许使用超过其 CPU 约束的处理时间。 +但是，容器不会由于 CPU 使用率过高而被杀死。 + +要确定 Container 是否会由于资源约束而无法调度或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 + + + +## 监控计算和内存资源用量 + +Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。 + +如果为集群配置了可选的 +[监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)， +则可以直接从 +[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) +或者监控工具获得 Pod 的资源使用情况。 + + + +## 本地临时存储 + + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +节点通常还可以具有本地的临时性存储，由本地挂接的可写入设备或者有时也用 RAM +来提供支持。 +“临时（Ephemeral）”意味着对所存储的数据不提供长期可用性的保证。 + +Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 +kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 +[`emptyDir`](/docs/concepts/storage/volumes/#emptydir) 类型的 +{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。 + + + +kubelet 也使用此类存储来保存 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +容器镜像文件、以及运行中容器的可写入层。 + +{{< caution >}} +如果节点失效，存储在临时性存储中的数据会丢失。 +你的应用不能对本地临时性存储的性能 SLA（例如磁盘 IOPS）作任何假定。 +{{< /caution >}} + +作为一种 beta 阶段功能特性，Kubernetes 允许你跟踪、预留和限制 Pod +可消耗的临时性本地存储数量。 + + + +### 本地临时性存储的配置 + +Kubernetes 有两种方式支持节点上配置本地临时性存储： + +{{< tabs name="local_storage_configurations" >}} +{{% tab name="单一文件系统" %}} +采用这种配置时，你会把所有类型的临时性本地数据（包括 `emptyDir` +卷、可写入容器层、容器镜像、日志等）放到同一个文件系统中。 +作为最有效的 kubelet 配置方式，这意味着该文件系统是专门提供给 Kubernetes +（kubelet）来保存数据的。 + +kubelet 也会生成 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +并按临时性本地存储的方式对待之。 + + + +kubelet 会将日志写入到所配置的日志目录（默认为 `/var/log`）下的文件中； +还会针对其他本地存储的数据使用同一个基础目录（默认为 `/var/lib/kubelet`）。 + +通常，`/var/lib/kubelet` 和 `/var/log` 都是在系统的根文件系统中。kubelet +的设计也考虑到这一点。 + +你的集群节点当然可以包含其他的、并非用于 Kubernetes 的很多文件系统。 +{{% /tab %}} + + + +{{% tab name="双文件系统" %}} + +你使用节点上的某个文件系统来保存运行 Pods 时产生的临时性数据：日志和 +`emptyDir` 卷等。你可以使用这个文件系统来保存其他数据（例如：与 Kubernetes +无关的其他系统日志）；这个文件系统还可以是根文件系统。 + +kubelet 也将 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +写入到第一个文件系统中，并按临时性本地存储的方式对待之。 + +同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉 +kubelet 将容器镜像层和可写层保存到这第二个文件系统上的某个目录中。 + +第一个文件系统中不包含任何镜像层和可写层数据。 + +当然，你的集群节点上还可以有很多其他与 Kubernetes 没有关联的文件系统。 +{{% /tab %}} +{{< /tabs >}} + + + +kubelet 能够度量其本地存储的用量。实现度量机制的前提是： + +- `LocalStorageCapacityIsolation` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且 +- 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一 + +如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。 + +{{< note >}} +kubelet 会将 `tmpfs` emptyDir 卷的用量当作容器内存用量，而不是本地临时性存储来统计。 +{{< /note >}} + + + +### 为本地临时性存储设置请求和约束值 + +你可以使用_ephemeral-storage_来管理本地临时性存储。 +Pod 中的每个 Container 可以设置以下属性： + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +`ephemeral-storage` 的请求和约束值是按字节计量的。你可以使用一般整数或者定点整数 +加上下面的后缀来表达存储量：E、P、T、G、M、K。 +你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，下面的表达式所表达的大致是同一个值： + +```shell +128974848, 129e6, 129M, 123Mi +``` + + + +在下面的例子中，Pod 包含两个 Container。每个 Container 请求 2 GiB 大小的本地临时性存储。 +每个 Container 都设置了 4 GiB 作为其本地临时性存储的约束值。 +因此，整个 Pod 的本地临时性存储请求是 4 GiB，且其本地临时性存储的约束为 8 GiB。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: wp + image: wordpress + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + + + +### 带 ephemeral-storage 的 Pods 的调度行为 + +当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。 +每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。 +欲了解更多信息，可参考 +[节点可分配资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +节。 + +调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。 + + + +### 临时性存储消耗的管理 {#resource-emphemeralstorage-consumption} + +如果 kubelet 将本地临时性存储作为资源来管理，则 kubelet 会度量以下各处的存储用量： + +- `emptyDir` 卷，除了 _tmpfs_ `emptyDir` 卷 +- 保存节点层面日志的目录 +- 可写入的容器镜像层 + +如果某 Pod 的临时存储用量超出了你所允许的范围，kubelet +会向其发出逐出（eviction）信号，触发该 Pod 被逐出所在节点。 + +就容器层面的隔离而言，如果某容器的可写入镜像层和日志用量超出其存储约束， +kubelet 也会将所在的 Pod 标记为逐出候选。 + +就 Pod 层面的隔离而言，kubelet 会将 Pod 中所有容器的约束值相加，得到 Pod +存储约束的总值。如果所有容器的本地临时性存储用量总和加上 Pod 的 `emptyDir` +卷的用量超出 Pod 存储约束值，kubelet 也会将该 Pod 标记为逐出候选。 + + + +{{< caution >}} +如果 kubelet 没有度量本地临时性存储的用量，即使 Pod +的本地存储用量超出其约束值也不会被逐出。 + +不过，如果用于可写入容器镜像层、节点层面日志或者 `emptyDir` 卷的文件系统中可用空间太少， +节点会为自身设置本地存储不足的{{< glossary_tooltip text="污点" term_id="taint" >}} 标签。 +这一污点会触发对那些无法容忍该污点的 Pods 的逐出操作。 + +关于临时性本地存储的配置信息，请参考[这里](#configurations-for-local-ephemeral-storage) +{{< /caution >}} + + + +kubelet 支持使用不同方式来度量 Pod 的存储用量： + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="周期性扫描" %}} +kubelet 按预定周期执行扫描操作，检查 `emptyDir` 卷、容器日志目录以及可写入容器镜像层。 + +这一扫描会度量存储空间用量。 + +{{< note >}} +在这种模式下，kubelet 并不检查已删除文件所对应的、仍处于打开状态的文件描述符。 + +如果你（或者容器）在 `emptyDir` 卷中创建了一个文件，写入一些内容之后再次打开 +该文件并执行了删除操作，所删除文件对应的 inode 仍然存在，直到你关闭该文件为止。 +kubelet 不会将该文件所占用的空间视为已使用空间。 +{{< /note >}} + +{{% /tab %}} + + + +{{% tab name="文件系统项目配额" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。 +在 Kubernetes 中，你可以启用项目配额以监视存储用量。 +你需要确保节点上为 `emptyDir` 提供存储的文件系统支持项目配额。 +例如，XFS 和 ext4fs 文件系统都支持项目配额。 + +{{< note >}} +项目配额可以帮你监视存储用量，但无法对存储约束执行限制。 +{{< /note >}} + + + +Kubernetes 所使用的项目 ID 始于 `1048576`。 +所使用的 IDs 会注册在 `/etc/projects` 和 `/etc/projid` 文件中。 +如果该范围中的项目 ID 已经在系统中被用于其他目的，则已占用的项目 IDs +也必须注册到 `/etc/projects` 和 `/etc/projid` 中，这样 Kubernetes +才不会使用它们。 + +配额方式与目录扫描方式相比速度更快，结果更精确。当某个目录被分配给某个项目时， +该目录下所创建的所有文件都属于该项目，内核只需要跟踪该项目中的文件所使用的存储块个数。 +如果某文件被创建后又被删除，但对应文件描述符仍处于打开状态， +该文件会继续耗用存储空间。配额跟踪技术能够精确第记录对应存储空间的状态， +而目录扫描方式会忽略被删除文件所占用的空间。 + + + +如果你希望使用项目配额，你需要： + +* 在 kubelet 配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。 + +* 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS + 文件系统都支持项目配额。 + 对 extf 文件系统而言，你需要在文件系统尚未被挂载时启用项目配额跟踪特性： + + ```bash + # 对 ext4 而言，在 /dev/block-device 尚未被挂载时执行下面操作 + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* 确保根文件系统（或者可选的运行时文件系统）在挂载时项目配额特性是被启用了的。 + 对于 XFS 和 ext4fs 而言，对应的挂载选项称作 `prjquota`。 + +{{% /tab %}} +{{< /tabs >}} + + + +## 扩展资源（Extended Resources） + +扩展资源是 `kubernetes.io` 域名之外的标准资源名称。 +它们使得集群管理员能够颁布非 Kubernetes 内置资源，而用户可以使用他们。 + +使用扩展资源需要两个步骤。首先，集群管理员必须颁布扩展资源。 +其次，用户必须在 Pod 中请求扩展资源。 + + + +### 管理扩展资源 + +#### 节点级扩展资源 + +节点级扩展资源绑定到节点。 + +##### 设备插件管理的资源 + +有关如何颁布在各节点上由设备插件所管理的资源，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 + + + +##### 其他资源 + +为了颁布新的节点级扩展资源，集群操作员可以向 API 服务器提交 `PATCH` HTTP 请求， +以在集群中节点的 `status.capacity` 中为其配置可用数量。 +完成此操作后，节点的 `status.capacity` 字段中将包含新资源。 +kubelet 会异步地对 `status.allocatable` 字段执行自动更新操作，使之包含新资源。 +请注意，由于调度器在评估 Pod 是否适合在某节点上执行时会使用节点的 `status.allocatable` 值， +在更新节点容量使之包含新资源之后和请求该资源的第一个 Pod 被调度到该节点之间， +可能会有短暂的延迟。 + + + +**示例：** + +这是一个示例，显示了如何使用 `curl` 构造 HTTP 请求，公告主节点为 `k8s-master` +的节点 `k8s-node-1` 上存在五个 `example.com/foo` 资源。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + + + +{{< note >}} +在前面的请求中，`~1` 是在 patch 路径中对字符 `/` 的编码。 +JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。 +有关更多详细信息，请参见 +[IETF RFC 6901 第 3 节](https://tools.ietf.org/html/rfc6901#section-3)。 +{{< /note >}} + + + +#### 集群层面的扩展资源 + +集群层面的扩展资源并不绑定到具体节点。 +它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。 + +您可以在[调度器策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度器扩展程序处理的扩展资源。 + + + +**示例：** + +下面的调度器策略配置标明集群层扩展资源 "example.com/foo" 由调度器扩展程序处理。 + +- 仅当 Pod 请求 "example.com/foo" 时，调度器才会将 Pod 发送到调度器扩展程序。 +- `ignoredByScheduler` 字段指定调度器不要在其 `PodFitsResources` 断言中检查 + "example.com/foo" 资源。 + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + + + +### 使用扩展资源 + +就像 CPU 和内存一样，用户可以在 Pod 的规约中使用扩展资源。 +调度器负责资源的核算，确保同时分配给 Pod 的资源总量不会超过可用数量。 + + + +{{< note >}} +扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。 +用户可以使用 `kubernetes.io` （保留）以外的任何域名前缀。 +{{< /note >}} + + + +要在 Pod 中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` +映射中包含资源名称作为键。 + +{{< note >}} +扩展资源不能过量使用，因此如果容器规范中同时存在请求和约束，则它们的取值必须相同。 +{{< /note >}} + + + +仅当所有资源请求（包括 CPU、内存和任何扩展资源）都被满足时，Pod 才能被调度。 +在资源请求无法满足时，Pod 会保持在 `PENDING` 状态。 + +**示例：** + +下面的 Pod 请求 2 个 CPU 和 1 个 "example.com/foo"（扩展资源）。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + + + +## 疑难解答 + +### 我的 Pod 处于悬决状态且事件信息显示 failedScheduling + +如果调度器找不到该 Pod 可以匹配的任何节点，则该 Pod 将保持未被调度状态， +直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时， +会产生一个事件，如下所示： + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler} FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + + + +在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 无法被调度。 +由于内存不足（PodExceedsFreeMemory）而导致失败时，也有类似的错误消息。 +一般来说，如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情： + +- 向集群添加更多节点。 +- 终止不需要的 Pod，为悬决的 Pod 腾出空间。 +- 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是`cpu：1`， + 那么一个请求为 `cpu: 1.1` 的 Pod 永远不会被调度。 + +您可以使用 `kubectl describe nodes` 命令检查节点容量和已分配的资源数量。 例如： + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... 这里忽略了若干行以便阅读 ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... 这里忽略了若干行以便阅读 ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + + + +在上面的输出中，你可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 + +通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。 + +可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。 +[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) +的 `allocatable` 字段给出了可用于 Pod 的资源量。 +有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 + +可以配置 [资源配额](/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。 +如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。 + + + +### 我的容器被终止了 + +你的容器可能因为资源紧张而被终止。要查看容器是否因为遇到资源限制而被杀死， +请针对相关的 Pod 执行 `kubectl describe pod`： + +```shell +kubectl describe pod simmemleak-hra99 +``` + +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + + + +在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 + +你可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + + + +你可以看到容器因为 `reason:OOM killed` 而被终止，`OOM` 表示内存不足（Out Of Memory）。 + +## {{% heading "whatsnext" %}} + + + +* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md) +* 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。 +* 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。 +* 阅读 XFS 中关于 [项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。 +