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

[zh] Sync changes from English site (3)

Browse Source
This commit is contained in:
Qiming Teng
2020-11-12 21:03:41 +08:00
parent 7a44e1a820
commit 95ab5ac197
8 changed files with 104 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/containers/container-lifecycle-hooks.md
+41 -18
View File
@@ -48,11 +48,11 @@ There are two hooks that are exposed to Containers:
`PostStart`
<!--
This hook executes immediately after a container is created.
This hook is executed immediately after a container is created.
However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
No parameters are passed to the handler.
-->
这个回调在创建容器之后立即执行。
这个回调在容器被创建之后立即被执行。
但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。
没有参数传递给处理程序。
@@ -61,13 +61,13 @@ No parameters are passed to the handler.
<!--
This hook is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention and others. A call to the preStop hook fails if the container is already in terminated or completed state.
It is blocking, meaning it is synchronous,
so it must complete before the call to delete the container can be sent.
so it must complete before the signal to stop the container can be sent.
No parameters are passed to the handler.
-->
在容器因 API 请求或者管理事件（诸如存活态探针失败、资源抢占、资源竞争等）而被终止之前，
此回调会被调用。
如果容器已经处于终止或者完成状态，则对 preStop 回调的调用将失败。
此调用是阻塞的，也是同步调用，因此必须在删除容器的调用之前完成。
此调用是阻塞的，也是同步调用，因此必须在发出删除容器的信号之前完成。
没有参数传递给处理程序。
<!--
@@ -102,11 +102,13 @@ Resources consumed by the command are counted against the Container.
### Hook handler execution
When a Container lifecycle management hook is called,
the Kubernetes management system executes the handler in the Container registered for that hook. 
the Kubernetes management system execute the handler according to the hook action,
`exec` and `tcpSocket` are executed in the container, and `httpGet` is executed by the kubelet process.
-->
### 回调处理程序执行
当调用容器生命周期管理回调时，Kubernetes 管理系统在注册了回调的容器中执行处理程序。
当调用容器生命周期管理回调时，Kubernetes 管理系统根据回调动作执行其处理程序，
`exec` 和 `tcpSocket` 在容器内执行，而 `httpGet` 则由 kubelet 进程执行。
<!--
Hook handler calls are synchronous within the context of the Pod containing the Container.
@@ -120,15 +122,35 @@ the Container cannot reach a `running` state.
但是，如果回调运行或挂起的时间太长，则容器无法达到 `running` 状态。
<!--
The behavior is similar for a `PreStop` hook.
If the hook hangs during execution,
the Pod phase stays in a `Terminating` state and is killed after `terminationGracePeriodSeconds` of pod ends.
If a `PostStart` or `PreStop` hook fails,
`PreStop` hooks are not executed asynchronously from the signal
to stop the Container; the hook must complete its execution before
the signal can be sent.
If a `PreStop` hook hangs during execution,
the Pod's phase will be `Terminating` and remain there until the Pod is
killed after its `terminationGracePeriodSeconds` expires.
This grace period applies to the total time it takes for both
the `PreStop` hook to execute and for the Container to stop normally.
If, for example, `terminationGracePeriodSeconds` is 60, and the hook
takes 55 seconds to complete, and the Container takes 10 seconds to stop
normally after receiving the signal, then the Container will be killed
before it can stop normally, since `terminationGracePeriodSeconds` is
less than the total time (55+10) it takes for these two things to happen.
-->
`PreStop` 回调并不会与停止容器的信号处理程序异步执行；回调必须在
可以发送信号之前完成执行。
如果 `PreStop` 回调在执行期间停滞不前，Pod 的阶段会变成 `Terminating`
并且一致处于该状态，直到其 `terminationGracePeriodSeconds` 耗尽为止，
这时 Pod 会被杀死。
这一宽限期是针对 `PreStop` 回调的执行时间及容器正常停止时间的总和而言的。
例如，如果 `terminationGracePeriodSeconds` 是 60，回调函数花了 55 秒钟
完成执行，而容器在收到信号之后花了 10 秒钟来正常结束，那么容器会在其
能够正常结束之前即被杀死，因为 `terminationGracePeriodSeconds` 的值
小于后面两件事情所花费的总时间（55 + 10）。
<!--
If either a `PostStart` or `PreStop` hook fails,
it kills the Container.
-->
行为与 `PreStop` 回调的行为类似。
如果回调在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，
并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。
如果 `PostStart` 或 `PreStop` 回调失败，它会杀死容器。
<!--
@@ -147,10 +169,11 @@ which means that a hook may be called multiple times for any given event,
such as for `PostStart` or `PreStop`.
It is up to the hook implementation to handle this correctly.
-->
### 回调寄送保证
### 回调递送保证
回调的寄送应该是 *至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，回调可以被调用多次。
如何正确处理，是回调实现所要考虑的问题。
回调的递送应该是 *至少一次*，这意味着对于任何给定的事件，
例如 `PostStart` 或 `PreStop`，回调可以被调用多次。
如何正确处理被多次调用的情况，是回调实现所要考虑的问题。
<!--
Generally, only single deliveries are made.
@@ -160,9 +183,9 @@ In some rare cases, however, double delivery may occur.
For instance, if a kubelet restarts in the middle of sending a hook,
the hook might be resent after the kubelet comes back up.
-->
通常情况下，只会进行单次寄送。
通常情况下，只会进行单次递送。
例如，如果 HTTP 回调接收器宕机，无法接收流量，则不会尝试重新发送。
然而，偶尔也会发生重复寄送的可能。
然而，偶尔也会发生重复递送的可能。
例如，如果 kubelet 在发送回调的过程中重新启动，回调可能会在 kubelet 恢复后重新发送。
<!--
content/zh/docs/concepts/containers/images.md
+14 -13
View File
@@ -87,7 +87,7 @@ Instead, specify a meaningful tag such as `v1.42.0`.
{{< /caution >}}
<!--
## Updating Images
## Updating images
The default pull policy is `IfNotPresent` which causes the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
@@ -116,17 +116,18 @@ When `imagePullPolicy` is defined without a specific value, it is also set to `A
如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。
<!--
## Multi-architecture Images with Manifests
## Multi-architecture images with image indexes
As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
As well as providing binary images, a container registry can also serve a [container image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md). An image index can point to multiple [image manifests](https://github.com/opencontainers/image-spec/blob/master/manifest.md) for architecture-specific versions of a container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
-->
## 使用清单（manifest）构建多架构镜像
## 带镜像索引的多架构镜像 {#multi-architecture-images-with-image-indexes}
除了提供二进制的镜像之外，容器仓库也可以提供
[容器镜像清单](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。
清单文件（Manifest）可以为特定于体系结构的镜像版本引用其镜像清单。
[容器镜像索引](https://github.com/opencontainers/image-spec/blob/master/image-index.md)。
镜像索引可以根据特定于体系结构版本的容器指向镜像的多个
[镜像清单](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。
这背后的理念是让你可以为镜像命名（例如：`pause`、`example/mycontainer`、`kube-apiserver`）
的同时，允许不同的系统基于它们所使用的机器体系结构取回正确的二进制镜像。
@@ -137,7 +138,7 @@ Kubernetes 自身通常在命名容器镜像时添加后缀 `-$(ARCH)`。
YAML 文件也能兼容。
<!--
## Using a Private Registry
## Using a private registry
Private registries may require keys to read images from them.
Credentials can be provided in several ways:
@@ -179,7 +180,7 @@ These options are explaind in more detail below.
下面将详细描述每一项。
<!--
### Configuring Nodes to authenticate to a Private Registry
### Configuring nodes to authenticate to a private registry
If you run Docker on your nodes, you can configure the Docker container
runtime to authenticate to a private container registry.
@@ -333,7 +334,7 @@ registry keys are added to the `.docker/config.json`.
在 `.docker/config.json` 中配置了私有仓库密钥后，所有 Pod 都将能读取私有仓库中的镜像。
<!--
### Pre-pulled Images
### Pre-pulled images
-->
### 提前拉取镜像 {#pre-pulled-images}
@@ -371,7 +372,7 @@ All pods will have read access to any pre-pulled images.
所有的 Pod 都可以使用节点上提前拉取的镜像。
<!--
### Specifying ImagePullSecrets on a Pod
### Specifying imagePullSecrets on a Pod
-->
### 在 Pod 上指定 ImagePullSecrets {#specifying-imagepullsecrets-on-a-pod}
@@ -389,7 +390,7 @@ Kubernetes supports specifying container image registry keys on a Pod.
Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。
<!--
#### Creating a Secret with a Docker Config
#### Creating a Secret with a Docker config
Run the following command, substituting the appropriate uppercase values:
-->
@@ -491,12 +492,12 @@ will be merged.
来自不同来源的凭据会被合并。
<!--
### Use Cases
## Use cases
There are a number of solutions for configuring private registries. Here are some
common use cases and suggested solutions.
-->
### 使用案例 {#use-cases}
## 使用案例 {#use-cases}
配置私有仓库有多种方案，以下是一些常用场景和建议的解决方案。
content/zh/docs/concepts/containers/runtime-class.md
+6 -6
View File
@@ -313,14 +313,14 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。
## {{% heading "whatsnext" %}}
<!--
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
-->
- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
- 阅读关于 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/) 的概念
- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念
- [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)