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) 的文档。
+