Skip to content

Commit

Permalink
[zh] update concept workload pods
Browse files Browse the repository at this point in the history
  • Loading branch information
@mayocream
mayocream committed Oct 12, 2021
1 parent 15be888 commit dd1e1ae
Show file tree
Hide file tree
Showing 6 changed files with 182 additions and 248 deletions.
69 changes: 53 additions & 16 deletions content/zh/docs/concepts/workloads/pods/_index.md
View file
Expand Up @@ -480,21 +480,26 @@ Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值
<!--
## Privileged mode for containers
Any container in a Pod can enable privileged mode, using the `privileged` flag on
the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
Processes within a privileged container get almost the same privileges that are available to processes outside a container.
In Linux, any container in a Pod can enable privileged mode using the `privileged` (Linux) flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
If your cluster has the `WindowsHostProcessContainers` feature enabled, you can create a [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod) by setting the `windowsOptions.hostProcess` flag on the security context of the pod spec. All containers in these pods must run as Windows HostProcess containers. HostProcess pods run directly on the host and can also be used to perform administrative tasks as is done with Linux privileged containers.
-->
## 容器的特权模式 {#privileged-mode-for-containers}

Pod 中的任何容器都可以使用容器规约中的
在 Linux 中，Pod 中的任何容器都可以使用容器规约中的
[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
`privileged` 参数启用特权模式。
`privileged`（Linux）参数启用特权模式。
这对于想要使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
的容器很有用。
容器内的进程几乎可以获得与容器外的进程相同的特权。

如果你的集群启用了 `WindowsHostProcessContainers` 特性，你可以使用 Pod 规约中安全上下文的
`windowsOptions.hostProcess` 参数来创建
[Windows HostProcess Pod](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
这些 Pod 中的所有容器都必须以 Windows HostProcess 容器方式运行。
HostProcess Pod 可以直接运行在主机上，它也能像 Linux 特权容器一样，用于执行管理任务。

<!--
Your {< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
-->
{{< note >}}
你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持
Expand Down Expand Up @@ -538,29 +543,61 @@ but cannot be controlled from there.
这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API
服务器来控制。

{{< note >}}
<!--
The `spec` of a static Pod cannot refer to other API objects
(e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}},
{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}},
{{< glossary_tooltip text="Secret" term_id="secret" >}}, etc).
-->
静态 Pod 的 `spec` 不能引用其他的 API 对象（例如：{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}、{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}、{{< glossary_tooltip text="Secret" term_id="secret" >}}等）。
{{< /note >}}

<!--
## Container probes
A _probe_ is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet can invoke different actions:
- `ExecAction` (performed with the help of the container runtime)
- `TCPSocketAction` (checked directly by the kubelet)
- `HTTPGetAction` (checked directly by the kubelet)
You can read more about [probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
in the Pod Lifecycle documentation.
-->
## 容器探针 {#container-probes}

_Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 可以执行三种动作：

- `ExecAction`（借助容器运行时执行）
- `TCPSocketAction`（由 kubelet 直接检测）
- `HTTPGetAction`（由 kubelet 直接检测）

你可以参阅 Pod 的生命周期文档中的[探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)部分。

## {{% heading "whatsnext" %}}

<!--
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
* Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
configure different Pods with different container runtime configurations.
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
* Pod is a top-level resource in the Kubernetes REST API.
The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
* Pod is a top-level resource in the Kubernetes REST API.
The {{< api-reference page="workload-resources/pod-v1" >}}
object definition describes the object in detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
--
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
-->
* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它
来配置不同的 Pod 使用不同的容器运行时配置
* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 了解 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)，以及你
如何可以利用它在出现干扰因素时管理应用的可用性
* Pod 在 Kubernetes REST API 中是一个顶层资源；
[Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
如何可以利用它在出现干扰因素时管理应用的可用性。
* Pod 在 Kubernetes REST API 中是一个顶层资源。
{{< api-reference page="workload-resources/pod-v1" >}}
对象的定义中包含了更多的细节信息。
* 博客 [分布式系统工具箱：复合容器模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* 博客 [分布式系统工具箱：复合容器模式](/blog/2015/06/the-distributed-system-toolkit-patterns/)
中解释了在同一 Pod 中包含多个容器时的几种常见布局。

<!--
Expand Down
8 changes: 4 additions & 4 deletions content/zh/docs/concepts/workloads/pods/disruptions.md
View file
Expand Up @@ -52,15 +52,15 @@ an application. Examples are:
- cloud provider or hypervisor failure makes VM disappear
- a kernel panic
- the node disappears from the cluster due to cluster network partition
- eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource/).
- eviction of a pod due to the node being [out-of-resources](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
-->

- 节点下层物理机的硬件故障
- 集群管理员错误地删除虚拟机（实例）
- 云提供商或虚拟机管理程序中的故障导致的虚拟机消失
- 内核错误
- 节点由于集群网络隔离从集群中消失
- 由于节点[资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)导致 pod 被驱逐。
- 由于节点[资源不足](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。

<!--
Except for the out-of-resources condition, all these conditions
Expand Down Expand Up @@ -161,7 +161,7 @@ rolling out node software updates can cause voluntary disruptions. Also, some im
of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes.
Your cluster administrator or hosting provider should have documented what level of voluntary
disruptions, if any, to expect. Certain configuration options, such as
[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
[using PriorityClasses](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
in your pod spec can also cause voluntary (and involuntary) disruptions.
-->
自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，没有自愿干扰（只有用户触发的干扰）。
Expand All @@ -170,7 +170,7 @@ in your pod spec can also cause voluntary (and involuntary) disruptions.
实现可能导致碎片整理和紧缩节点的自愿干扰。集群
管理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。
有些配置选项，例如在 pod spec 中
[使用 PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
[使用 PriorityClasses](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
也会产生自愿（和非自愿）的干扰。

<!--
Expand Down
163 changes: 9 additions & 154 deletions content/zh/docs/concepts/workloads/pods/ephemeral-containers.md
View file
Expand Up @@ -12,7 +12,7 @@ weight: 80

<!-- overview -->

{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}

<!--
This page provides an overview of ephemeral containers: a special type of container
Expand All @@ -27,14 +27,12 @@ containers to inspect services rather than to build applications.

{{< 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
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.
Ephemeral containers are in alpha state and are not suitable for production
clusters. 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.
-->
临时容器处于早期的 Alpha 阶段，不适用于生产环境集群。
应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。
临时容器处于 Alpha 阶段，不适用于生产环境集群。
根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)，
此 Alpha 功能将来可能发生重大变化或被完全删除。
{{< /warning >}}
Expand Down Expand Up @@ -141,151 +139,8 @@ you can view processes in other containers.
[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
很有帮助，可以查看其他容器中的进程。

{{% heading "whatsnext" %}}
<!--
See [Debugging with Ephemeral Debug Container](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)
for examples of troubleshooting using ephemeral containers.
* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container).
-->
关于如何使用临时容器来执行故障排查的例子，可参阅
[使用临时调试容器来调试](/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.
-->
本节中的示例要求启用 `EphemeralContainers`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
并且 kubernetes 客户端和服务端版本要求为 v1.16 或更高版本。
{{< /note >}}

<!--
The examples in this section demonstrate how ephemeral containers appear in
the API. You would normally use `kubectl debug` or another `kubectl`
[plugin](/docs/tasks/extend-kubectl/kubectl-plugins/) to automate these steps
rather than invoking the API directly.
-->
本节中的示例演示了临时容器如何出现在 API 中。
通常，你会使用 `kubectl debug` 或别的 `kubectl`
[插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/) 自动执行这些步骤，而不是直接调用API。

<!--
Ephemeral containers are created using the `ephemeralcontainers` subresource
of Pod, which can be demonstrated using `kubectl -raw`. First describe
the ephemeral container to add as an `EphemeralContainers` list:
-->
临时容器是使用 Pod 的 `ephemeralcontainers` 子资源创建的，可以使用
`kubectl --raw` 命令进行显示。
首先描述临时容器被添加为一个 `EphemeralContainers` 列表：

```json
{
"apiVersion": "v1",
"kind": "EphemeralContainers",
"metadata": {
"name": "example-pod"
},
"ephemeralContainers": [{
"command": [
"sh"
],
"image": "busybox",
"imagePullPolicy": "IfNotPresent",
"name": "debugger",
"stdin": true,
"tty": true,
"terminationMessagePolicy": "File"
}]
}
```

<!--
To update the ephemeral containers of the already running `example-pod`:
-->
使用如下命令更新已运行的临时容器 `example-pod`：

```shell
kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
```

<!--
This will return the new list of ephemeral containers:
-->
这将返回临时容器的新列表：

```json
{
"kind":"EphemeralContainers",
"apiVersion":"v1",
"metadata":{
"name":"example-pod",
"namespace":"default",
"selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
"uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
"resourceVersion":"15886",
"creationTimestamp":"2019-08-29T06:41:42Z"
},
"ephemeralContainers":[
{
"name":"debugger",
"image":"busybox",
"command":[
"sh"
],
"resources":{

},
"terminationMessagePolicy":"File",
"imagePullPolicy":"IfNotPresent",
"stdin":true,
"tty":true
}
]
}
```

<!--
You can view the state of the newly created ephemeral container using `kubectl describe`:
-->
可以使用以下命令查看新创建的临时容器的状态：

```shell
kubectl describe pod example-pod
```

输出为：

```
...
Ephemeral Containers:
debugger:
Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
Image: busybox
Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
Port: <none>
Host Port: <none>
Command:
sh
State: Running
Started: Thu, 29 Aug 2019 06:42:21 +0000
Ready: False
Restart Count: 0
Environment: <none>
Mounts: <none>
...
```

<!--
You can attach to the new ephemeral container using `kubectl attach`:
-->
可以使用以下命令连接到新的临时容器：

```shell
kubectl attach -it example-pod -c debugger
```

* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)

0 comments on commit dd1e1ae

Please sign in to comment.