[zh] Resync concepts section (7)
Qiming Teng
parent
c8ce9801a5
commit
210775f691
|
|
@ -5,6 +5,10 @@ weight: 60
|
|||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- erictune
|
||||
- foxish
|
||||
- davidopp
|
||||
title: Disruptions
|
||||
content_type: concept
|
||||
weight: 60
|
||||
|
|
@ -136,18 +140,18 @@ Here are some ways to mitigate involuntary disruptions:
|
|||
[stateless](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.)
|
||||
- For even higher availability when running replicated applications,
|
||||
spread applications across racks (using
|
||||
[anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature))
|
||||
or across zones (if using a
|
||||
[multi-zone cluster](/docs/setup/multiple-zones).)
|
||||
spread applications across racks (using
|
||||
[anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity))
|
||||
or across zones (if using a
|
||||
[multi-zone cluster](/docs/setup/multiple-zones).)
|
||||
-->
|
||||
- 确保 Pod 在请求中给出[所需资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)。
|
||||
- 如果需要更高的可用性，请复制应用程序。
|
||||
（了解有关运行多副本的[无状态](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
|
||||
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
|
||||
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域
|
||||
（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
|
||||
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
|
||||
或跨区域（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
|
||||
|
||||
<!--
|
||||
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
|
||||
|
|
@ -186,9 +190,9 @@ number needed for a quorum. A web front end might want to
|
|||
ensure that the number of replicas serving load never falls below a certain
|
||||
percentage of the total.
|
||||
-->
|
||||
## 干扰预算
|
||||
## 干扰预算 {#pod-disruption-budgets}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
|
||||
|
||||
即使你会经常引入自愿性干扰，Kubernetes 也能够支持你运行高度可用的应用。
|
||||
|
||||
|
|
@ -199,11 +203,11 @@ Web 前端可能希望确保提供负载的副本数量永远不会低于总数
|
|||
|
||||
<!--
|
||||
Cluster managers and hosting providers should use tools which
|
||||
respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)
|
||||
respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)
|
||||
instead of directly deleting pods or deployments. Examples are the `kubectl drain` command
|
||||
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
|
||||
-->
|
||||
集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口
|
||||
集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口
|
||||
（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
|
||||
而不是直接删除 Pod 或 Deployment。
|
||||
|
||||
|
|
@ -264,7 +268,7 @@ during application updates is configured in spec for the specific workload resou
|
|||
When a pod is evicted using the eviction API, it is gracefully
|
||||
[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination),
|
||||
hornoring the
|
||||
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
|
||||
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
-->
|
||||
当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
|
||||
[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
|
||||
|
|
|
|||
|
|
@ -20,10 +20,12 @@ that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to
|
|||
accomplish user-initiated actions such as troubleshooting. You use ephemeral
|
||||
containers to inspect services rather than to build applications.
|
||||
-->
|
||||
本页面概述了临时容器：一种特殊的容器，该容器在现有 {{< glossary_tooltip text="Pod" term_id="pod" >}}
|
||||
本页面概述了临时容器：一种特殊的容器，该容器在现有
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}
|
||||
中临时运行，以便完成用户发起的操作，例如故障排查。
|
||||
你会使用临时容器来检查服务，而不是用它来构建应用程序。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Ephemeral containers are in early alpha state and are not suitable for production
|
||||
clusters. You should expect the feature not to work in some situations, such as
|
||||
|
|
@ -31,11 +33,10 @@ when targeting the namespaces of a container. In accordance with the [Kubernetes
|
|||
Deprecation Policy](/docs/reference/using-api/deprecation-policy/), this alpha
|
||||
feature could change significantly in the future or be removed entirely.
|
||||
-->
|
||||
{{< warning >}}
|
||||
临时容器处于早期的 alpha 阶段，不适用于生产环境集群。
|
||||
临时容器处于早期的 Alpha 阶段，不适用于生产环境集群。
|
||||
应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。
|
||||
根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)，
|
||||
此 alpha 功能将来可能发生重大变化或被完全删除。
|
||||
此 Alpha 功能将来可能发生重大变化或被完全删除。
|
||||
{{< /warning >}}
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -49,7 +50,7 @@ replaceable, you cannot add a container to a Pod once it has been created.
|
|||
Instead, you usually delete and replace Pods in a controlled fashion using
|
||||
{{< glossary_tooltip text="deployments" term_id="deployment" >}}.
|
||||
-->
|
||||
## 了解临时容器
|
||||
## 了解临时容器 {#understanding-ephemeral-containers}
|
||||
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}} 是 Kubernetes 应用程序的基本构建块。
|
||||
由于 Pod 是一次性且可替换的，因此一旦 Pod 创建，就无法将容器加入到 Pod 中。
|
||||
|
|
@ -74,7 +75,7 @@ they are not appropriate for building applications. Ephemeral containers are
|
|||
described using the same `ContainerSpec` as regular containers, but many fields
|
||||
are incompatible and disallowed for ephemeral containers.
|
||||
-->
|
||||
### 什么是临时容器？
|
||||
### 什么是临时容器？ {#what-is-an-ephemeral-container}
|
||||
|
||||
临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，
|
||||
因此不适用于构建应用程序。
|
||||
|
|
@ -89,9 +90,7 @@ are incompatible and disallowed for ephemeral containers.
|
|||
-->
|
||||
- 临时容器没有端口配置，因此像 `ports`，`livenessProbe`，`readinessProbe`
|
||||
这样的字段是不允许的。
|
||||
|
||||
- Pod 资源分配是不可变的，因此 `resources` 配置是不允许的。
|
||||
|
||||
- 有关允许字段的完整列表，请参见
|
||||
[EphemeralContainer 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)。
|
||||
|
||||
|
|
@ -116,7 +115,7 @@ Ephemeral containers are useful for interactive troubleshooting when `kubectl
|
|||
exec` is insufficient because a container has crashed or a container image
|
||||
doesn't include debugging utilities.
|
||||
-->
|
||||
## 临时容器的用途
|
||||
## 临时容器的用途 {#uses-for-ephemeral-containers}
|
||||
|
||||
当由于容器崩溃或容器镜像不包含调试工具而导致 `kubectl exec` 无用时，
|
||||
临时容器对于交互式故障排查很有用。
|
||||
|
|
@ -128,7 +127,7 @@ and exposure to bugs and vulnerabilities. Since distroless images do not include
|
|||
shell or any debugging utilities, it's difficult to troubleshoot distroless
|
||||
images using `kubectl exec` alone.
|
||||
-->
|
||||
尤其是，[distroless 镜像](https://github.com/GoogleContainerTools/distroless)
|
||||
尤其是，[Distroless 镜像](https://github.com/GoogleContainerTools/distroless)
|
||||
允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。
|
||||
由于 distroless 镜像不包含 Shell 或任何的调试工具，因此很难单独使用
|
||||
`kubectl exec` 命令进行故障排查。
|
||||
|
|
@ -138,19 +137,28 @@ When using ephemeral containers, it's helpful to enable [process namespace
|
|||
sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
|
||||
you can view processes in other containers.
|
||||
-->
|
||||
使用临时容器时，启用[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
使用临时容器时，启用
|
||||
[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
很有帮助，可以查看其他容器中的进程。
|
||||
|
||||
<!--
|
||||
### Examples
|
||||
See [Debugging with Ephemeral Debug Container](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)
|
||||
for examples of troubleshooting using ephemeral containers.
|
||||
-->
|
||||
关于如何使用临时容器来执行故障排查的例子，可参阅
|
||||
[使用临时调试容器来调试](/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)。
|
||||
|
||||
<!--
|
||||
## Ephemeral containers API
|
||||
-->
|
||||
### 临时容器 API {#ephemeral-containers-api}」
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The examples in this section require the `EphemeralContainers` [feature
|
||||
gate](/docs/reference/command-line-tools-reference/feature-gates/) to be
|
||||
enabled, and Kubernetes client and server version v1.16 or later.
|
||||
-->
|
||||
### 示例
|
||||
|
||||
{{< note >}}
|
||||
本节中的示例要求启用 `EphemeralContainers`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
|
||||
并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。
|
||||
|
|
@ -180,7 +188,7 @@ the ephemeral container to add as an `EphemeralContainers` list:
|
|||
"apiVersion": "v1",
|
||||
"kind": "EphemeralContainers",
|
||||
"metadata": {
|
||||
"name": "example-pod"
|
||||
"name": "example-pod"
|
||||
},
|
||||
"ephemeralContainers": [{
|
||||
"command": [
|
||||
|
|
@ -281,34 +289,3 @@ You can attach to the new ephemeral container using `kubectl attach`:
|
|||
kubectl attach -it example-pod -c debugger
|
||||
```
|
||||
|
||||
<!--
|
||||
If process namespace sharing is enabled, you can see processes from all the containers in that Pod.
|
||||
For example, after attaching, you run `ps` in the debugger container:
|
||||
-->
|
||||
如果启用了进程命名空间共享，则可以查看该 Pod 所有容器中的进程。
|
||||
例如，运行上述 `attach` 操作后，在调试器容器中运行 `ps` 操作：
|
||||
|
||||
```shell
|
||||
# 在 "debugger" 临时容器内中运行此 shell 命令
|
||||
ps auxww
|
||||
```
|
||||
|
||||
运行命令后，输出类似于：
|
||||
|
||||
```
|
||||
PID USER TIME COMMAND
|
||||
1 root 0:00 /pause
|
||||
6 root 0:00 nginx: master process nginx -g daemon off;
|
||||
11 101 0:00 nginx: worker process
|
||||
12 101 0:00 nginx: worker process
|
||||
13 101 0:00 nginx: worker process
|
||||
14 101 0:00 nginx: worker process
|
||||
15 101 0:00 nginx: worker process
|
||||
16 101 0:00 nginx: worker process
|
||||
17 101 0:00 nginx: worker process
|
||||
18 101 0:00 nginx: worker process
|
||||
19 root 0:00 /pause
|
||||
24 root 0:00 sh
|
||||
29 root 0:00 ps auxww
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
---
|
||||
approvers:
|
||||
- erictune
|
||||
title: Init 容器
|
||||
content_type: concept
|
||||
weight: 40
|
||||
|
|
@ -514,9 +512,6 @@ Pod 级别的 cgroups 是基于有效 Pod 的请求和限制值，和调度器
|
|||
A Pod can restart, causing re-execution of init containers, for the following
|
||||
reasons:
|
||||
|
||||
* A user updates the Pod specification, causing the init container image to change.
|
||||
Any changes to the init container image restarts the Pod. App container image
|
||||
changes only restart the app container.
|
||||
* The Pod infrastructure container is restarted. This is uncommon and would
|
||||
have to be done by someone with root access to nodes.
|
||||
* All containers in a Pod are terminated while `restartPolicy` is set to Always,
|
||||
|
|
@ -527,15 +522,22 @@ reasons:
|
|||
|
||||
Pod 重启会导致 Init 容器重新执行，主要有如下几个原因：
|
||||
|
||||
* 用户更新 Pod 的规约导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启。
|
||||
应用容器镜像的变更仅会重启应用容器。
|
||||
|
||||
* Pod 的基础设施容器 (译者注：如 `pause` 容器) 被重启。这种情况不多见，
|
||||
必须由具备 root 权限访问节点的人员来完成。
|
||||
|
||||
* 当 `restartPolicy` 设置为 "`Always`"，Pod 中所有容器会终止而强制重启。
|
||||
由于垃圾收集机制的原因，Init 容器的完成记录将会丢失。
|
||||
|
||||
<!--
|
||||
The Pod will not be restarted when the init container image is changed, or the
|
||||
init container completion record has been lost due to garbage collection. This
|
||||
applies for Kubernetes v1.20 and later. If you are using an earlier version of
|
||||
Kubernetes, consult the documentation for the version you are using.
|
||||
-->
|
||||
当 Init 容器的镜像发生改变或者 Init 容器的完成记录因为垃圾收集等原因被丢失时，
|
||||
Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。如果你在使用较早
|
||||
版本的 Kubernetes，可查阅你所使用的版本对应的文档。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -74,18 +74,17 @@ ID（[UID](/zh/docs/concepts/overview/working-with-objects/names/#uids)），
|
|||
|
||||
<!--
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a
|
||||
{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
|
||||
or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't
|
||||
{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise, a Pod won't
|
||||
survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
|
||||
higher-level abstraction, called a
|
||||
{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of
|
||||
managing the relatively disposable Pod instances.
|
||||
-->
|
||||
Pod 自身不具有自愈能力。如果 Pod 被调度到某{{< glossary_tooltip text="节点" term_id="node" >}}
|
||||
而该节点之后失效，或者调度操作本身失效，Pod 会被删除；与此类似，Pod 无法在节点资源
|
||||
耗尽或者节点维护期间继续存活。Kubernetes 使用一种高级抽象，称作
|
||||
{{< glossary_tooltip term_id="controller" text="控制器" >}}，来管理这些相对而言
|
||||
可随时丢弃的 Pod 实例。
|
||||
而该节点之后失效，Pod 会被删除；类似地，Pod 无法在因节点资源
|
||||
耗尽或者节点维护而被驱逐期间继续存活。Kubernetes 使用一种高级抽象
|
||||
来管理这些相对而言可随时丢弃的 Pod 实例，称作
|
||||
{{< glossary_tooltip term_id="controller" text="控制器" >}}。
|
||||
|
||||
<!--
|
||||
A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
|
||||
|
|
@ -577,14 +576,14 @@ is different from the liveness probe.
|
|||
如果你希望容器能够自行进入维护状态，也可以指定一个就绪态探针，检查某个特定于
|
||||
就绪态的因此不同于存活态探测的端点。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If you just want to be able to drain requests when the Pod is deleted, you do not
|
||||
If you want to be able to drain requests when the Pod is deleted, you do not
|
||||
necessarily need a readiness probe; on deletion, the Pod automatically puts itself
|
||||
into an unready state regardless of whether the readiness probe exists.
|
||||
The Pod remains in the unready state while it waits for the containers in the Pod
|
||||
to stop.
|
||||
-->
|
||||
{{< note >}}
|
||||
请注意，如果你只是想在 Pod 被删除时能够排空请求，则不一定需要使用就绪态探针；
|
||||
在删除 Pod 时，Pod 会自动将自身置于未就绪状态，无论就绪态探针是否存在。
|
||||
等待 Pod 中的容器停止期间，Pod 会一直处于未就绪状态。
|
||||
|
|
@ -677,18 +676,6 @@ An example flow:
|
|||
On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
|
||||
as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
|
||||
shutdown process.
|
||||
|
||||
1. If one of the Pod's containers has defined a `preStop`
|
||||
[hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
|
||||
runs that hook inside of the container. If the `preStop` hook is still running after the
|
||||
grace period expires, the kubelet requests a small, one-off grace period extension of 2
|
||||
seconds.
|
||||
If the `preStop` hook needs longer to complete than the default grace period allows,
|
||||
you must modify `terminationGracePeriodSeconds` to suit this.
|
||||
1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
|
||||
container.
|
||||
The containers in the Pod receive the TERM signal at different times and in an arbitrary
|
||||
order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
|
||||
-->
|
||||
下面是一个例子：
|
||||
|
||||
|
|
@ -701,6 +688,19 @@ An example flow:
|
|||
在 Pod 运行所在的节点上：`kubelet` 一旦看到 Pod
|
||||
被标记为正在终止（已经设置了体面终止限期），`kubelet` 即开始本地的 Pod 关闭过程。
|
||||
|
||||
<!--
|
||||
1. If one of the Pod's containers has defined a `preStop`
|
||||
[hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
|
||||
runs that hook inside of the container. If the `preStop` hook is still running after the
|
||||
grace period expires, the kubelet requests a small, one-off grace period extension of 2
|
||||
seconds.
|
||||
If the `preStop` hook needs longer to complete than the default grace period allows,
|
||||
you must modify `terminationGracePeriodSeconds` to suit this.
|
||||
1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each
|
||||
container.
|
||||
The containers in the Pod receive the TERM signal at different times and in an arbitrary
|
||||
order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
|
||||
-->
|
||||
1. 如果 Pod 中的容器之一定义了 `preStop`
|
||||
[回调](/zh/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，
|
||||
`kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，`preStop` 回调逻辑
|
||||
|
|
@ -847,7 +847,6 @@ This avoids a resource leak as Pods are created and terminated over time.
|
|||
and
|
||||
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
|
||||
-->
|
||||
|
||||
* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
|
||||
* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
|
||||
* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
|
||||
|
|
|
|||
|
|
@ -95,10 +95,11 @@ graph TB
|
|||
{{< /mermaid >}}
|
||||
|
||||
<!--
|
||||
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters.
|
||||
|
||||
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
|
||||
-->
|
||||
你可以复用在大多数集群上自动创建和填充的
|
||||
[常用标签](/zh/docs/reference/kubernetes-api/labels-annotations-taints/)，
|
||||
[常用标签](/zh/docs/reference/labels-annotations-taints/)，
|
||||
而不是手动添加标签。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
Loading…
Reference in New Issue