whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Sync changes from English site (11)

Browse Source
This commit is contained in:
Qiming Teng
2020-11-23 10:24:40 +08:00
parent fd65678baa
commit aca3e081fe
9 changed files with 114 additions and 547 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
+17 -2
View File
@@ -30,7 +30,7 @@ allocated as much CPU as it requests.
Each node in your cluster must have at least 1 CPU.
A few of the steps on this page require you to run the
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
service in your cluster. If you have the metrics-server
running, you can skip those steps.
@@ -39,7 +39,8 @@ following command to enable metrics-server:
-->
集群中的每个节点必须至少有 1 个 CPU 可用才能运行本任务中的示例。
本页的一些步骤要求你在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
本页的一些步骤要求你在集群中运行
[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。
如果你正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
@@ -354,6 +355,20 @@ to specify a default value for the CPU limit.
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
指定 CPU 限制的默认值。
<!--
## If you specify a CPU limit but do not specify a CPU request
If you specify a CPU limit for a Container but do not specify a CPU request, Kubernetes automatically
assigns a CPU request that matches the limit. Similarly, if a Container specifies its own memory limit,
but does not specify a memory request, Kubernetes automatically assigns a memory request that matches
the limit.
-->
## 如果你设置了 CPU 限制但未设置 CPU 请求
如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其
设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置
内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。
<!--
## Motivation for CPU requests and limits
content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md
+57 -41
View File
@@ -5,11 +5,9 @@ weight: 10
---
<!--
---
title: Assign Memory Resources to Containers and Pods
content_type: task
weight: 10
---
-->
<!-- overview -->
@@ -19,34 +17,33 @@ This page shows how to assign a memory *request* and a memory *limit* to a
Container. A Container is guaranteed to have as much memory as it requests,
but is not allowed to use more memory than its limit.
-->
此页面显示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
此页面展示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。
我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 300 MiB of memory.
-->
您集群中的每个节点必须拥有至少 300 MiB 的内存。
你集群中的每个节点必须拥有至少 300 MiB 的内存。
<!--
A few of the steps on this page require you to run the
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
service in your cluster. If you have the metrics-server
running, you can skip those steps.
-->
该页面上的一些步骤要求您在集群中运行 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 服务。如果您已经有在运行中的 metrics-server，则可以跳过这些步骤。
该页面上的一些步骤要求你在集群中运行
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 服务。
如果你已经有在运行中的 metrics-server，则可以跳过这些步骤。
<!--
If you are running Minikube, run the following command to enable the
metrics-server:
-->
如果您运行的是 Minikube，可以运行下面的命令启用 metrics-server：
如果你运行的是 Minikube，可以运行下面的命令启用 metrics-server：
```shell
minikube addons enable metrics-server
@@ -68,13 +65,11 @@ reference to `metrics.k8s.io`.
-->
如果资源指标 API 可用，则输出结果将包含对 `metrics.k8s.io` 的引用信息。
```shell
```
NAME
v1beta1.metrics.k8s.io
```
<!-- steps -->
<!--
@@ -106,7 +101,7 @@ for the Pod:
要为容器指定内存请求，请在容器资源清单中包含 `resources：requests` 字段。
同理，要指定内存限制，请包含 `resources：limits`。
在本练习中，您将创建一个拥有一个容器的 Pod。
在本练习中，你将创建一个拥有一个容器的 Pod。
容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。
这是 Pod 的配置文件：
@@ -203,8 +198,10 @@ restarted, the kubelet restarts it, as with any other type of runtime failure.
-->
## 超过容器限制的内存
当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。
如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超出其限制的内存，则终止容器。
当节点拥有足够的可用内存时，容器可以使用其请求的内存。
但是，容器不允许使用超过其限制的内存。
如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。
如果容器继续消耗超出其限制的内存，则终止容器。
如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。
<!--
@@ -212,7 +209,7 @@ In this exercise, you create a Pod that attempts to allocate more memory than it
Here is the configuration file for a Pod that has one Container with a
memory request of 50 MiB and a memory limit of 100 MiB:
-->
在本练习中，您将创建一个 Pod，尝试分配超出其限制的内存。
在本练习中，你将创建一个 Pod，尝试分配超出其限制的内存。
这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB：
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
@@ -223,7 +220,7 @@ will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limi
Create the Pod:
-->
在配置文件的 `args` 部分中，您可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
在配置文件的 `args` 部分中，你可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
创建 Pod：
@@ -277,7 +274,8 @@ lastState:
The Container in this exercise can be restarted, so the kubelet restarts it. Repeat
this command several times to see that the Container is repeatedly killed and restarted:
-->
本练习中的容器可以被重启，所以 kubelet 会重启它。多次运行下面的命令，可以看到容器在反复的被杀死和重启：
本练习中的容器可以被重启，所以 kubelet 会重启它。
多次运行下面的命令，可以看到容器在反复的被杀死和重启：
```shell
kubectl get pod memory-demo-2 --namespace=mem-example
@@ -371,8 +369,8 @@ of any Node in your cluster.
-->
Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。
在本练习中，你将创建一个 Pod，其内存请求超过了您集群中的任意一个节点所拥有的内存。
这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了您集群中任何节点的容量。
在本练习中，你将创建一个 Pod，其内存请求超过了你集群中的任意一个节点所拥有的内存。
这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了你集群中任何节点的容量。
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
@@ -397,7 +395,8 @@ kubectl get pod memory-demo-3 --namespace=mem-example
<!--
The output shows that the Pod status is PENDING. That is, the Pod is not scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
-->
输出结果显示：Pod 处于 PENDING 状态。这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
输出结果显示：Pod 处于 PENDING 状态。
这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
```
kubectl get pod memory-demo-3 --namespace=mem-example
@@ -436,7 +435,9 @@ For example, the following represent approximately the same value:
-->
## 内存单位
内存资源的基本单位是字节（byte）。您可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值：
内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为
纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。
例如，下面是一些近似相同的值：
```shell
128974848, 129e6, 129M , 123Mi
@@ -469,12 +470,13 @@ Container is automatically assigned the default limit. Cluster administrators ca
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
to specify a default value for the memory limit.
-->
* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。
此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，
进而可能导致该节点调用 OOM Killer。
此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
* 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。
集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
来指定默认的内存限制。
集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
来指定默认的内存限制。
<!--
## Motivation for memory requests and limits
@@ -486,7 +488,9 @@ scheduled. By having a memory limit that is greater than the memory request, you
-->
## 内存请求和限制的目的
通过为集群中运行的容器配置内存请求和限制，您可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，您可以更好地安排 Pod 调度。通过让内存限制大于内存请求，您可以完成两件事：
通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。
通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。
通过让内存限制大于内存请求，你可以完成两件事：
<!--
* The Pod can have bursts of activity where it makes use of memory that happens to be available.
@@ -508,34 +512,46 @@ Delete your namespace. This deletes all the Pods that you created for this task:
kubectl delete namespace mem-example
```
## {{% heading "whatsnext" %}}
<!--
### For app developers
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者扩展阅读
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员扩展阅读
* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [配置命名空间的最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [配置命名空间的最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [配置命名空间下 Pod 总数](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [配置 API 对象配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+4 -5
View File
@@ -284,7 +284,7 @@ affect the HTTP liveness probe.
A third type of liveness probe uses a TCP Socket. With this configuration, the
kubelet will attempt to open a socket to your container on the specified port.
If it can establish a connection, the container is considered healthy, if it
can’t it is considered a failure.
can't it is considered a failure.
-->
## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe}
@@ -419,7 +419,7 @@ Sometimes, applications are temporarily unable to serve traffic.
For example, an application might need to load large data or configuration
files during startup, or depend on external services after startup.
In such cases, you don't want to kill the application,
but you don’t want to send it requests either. Kubernetes provides
but you don't want to send it requests either. Kubernetes provides
readiness probes to detect and mitigate these situations. A pod with containers
reporting that they are not ready does not receive traffic through Kubernetes
Services.
@@ -534,7 +534,7 @@ in the range 1 to 65535.
<!--
For an HTTP probe, the kubelet sends an HTTP request to the specified path and
port to perform the check. The kubelet sends the probe to the pod’s IP address,
port to perform the check. The kubelet sends the probe to the pod's IP address,
unless the address is overridden by the optional `host` field in `httpGet`. If
`scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the
certificate verification. In most scenarios, you do not want to set the `host` field.
@@ -565,7 +565,7 @@ to resolve it.
* Learn more about
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-->
* 进一步了解[容器探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
### Reference
@@ -580,4 +580,3 @@ to resolve it.
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
+6 -9
View File
@@ -55,7 +55,7 @@ Init 容器将共享卷挂载到了 `/work-dir` 目录，应用容器将共享
Init 容器执行完下面的命令就终止：
```shell
wget -O /work-dir/index.html http://kubernetes.io
wget -O /work-dir/index.html http://info.cern.ch
```
<!--
@@ -118,16 +118,13 @@ The output shows that nginx is serving the web page that was written by the init
结果表明 nginx 正在为 Init 容器编写的 web 页面服务：
```
<!Doctype html>
<html id="home">
<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>
<head>
...
"url": "http://kubernetes.io/"}</script>
</head>
<body>
<h1>http://info.cern.ch - home of the first website</h1>
...
<p>Kubernetes is open source giving you the freedom to take advantage ...</p>
<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
...
```