Kubernetes Prow Robot
GitHub
commit
75b3d76ed6
|
|
@ -1,4 +1,524 @@
|
|||
---
|
||||
title: "Pods"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- erictune
|
||||
title: Pods
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
|
||||
|
||||
A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
|
||||
{{< glossary_tooltip text="containers" term_id="container" >}}
|
||||
with shared storage/network resources, and a specification
|
||||
for how to run the containers. A Pod's contents are always co-located and
|
||||
co-scheduled, and run in a shared context. A Pod models an
|
||||
application-specific "logical host": it contains one or more application
|
||||
containers which are relatively tightly coupled.
|
||||
In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
|
||||
-->
|
||||
_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
|
||||
|
||||
_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）
|
||||
{{< glossary_tooltip text="容器" term_id="container" >}}；
|
||||
这些容器共享存储、网络、以及怎样运行这些容器的声明。
|
||||
Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。
|
||||
Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，
|
||||
这些容器是相对紧密的耦合在一起的。
|
||||
在非云环境中，在相同的物理机或虚拟机上运行的应用类似于
|
||||
在同一逻辑主机上运行的云应用。
|
||||
|
||||
<!--
|
||||
As well as application containers, a Pod can contain
|
||||
[init containers](/docs/concepts/workloads/pods/init-containers/) that run
|
||||
during Pod startup. You can also inject
|
||||
[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/)
|
||||
for debugging if your cluster offers this.
|
||||
-->
|
||||
除了应用容器，Pod 还可以包含在 Pod 启动期间运行的
|
||||
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
|
||||
你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/)
|
||||
的情况外，为调试的目的注入临时性容器。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 什么是 Pod？ {#what-is-a-pod}
|
||||
|
||||
<!--
|
||||
While Kubernetes supports more
|
||||
{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}}
|
||||
than just Docker, [Docker](https://www.docker.com/) is the most commonly known
|
||||
runtime, and it helps to describe Pods using some terminology from Docker.
|
||||
-->
|
||||
{{< note >}}
|
||||
除了 Docker 之外，Kubernetes 支持
|
||||
很多其他{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，
|
||||
[Docker](https://www.docker.com/) 是最有名的运行时，
|
||||
使用 Docker 的术语来描述 Pod 会很有帮助。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The shared context of a Pod is a set of Linux namespaces, cgroups, and
|
||||
potentially other facets of isolation - the same things that isolate a Docker
|
||||
container. Within a Pod's context, the individual applications may have
|
||||
further sub-isolations applied.
|
||||
|
||||
In terms of Docker concepts, a Pod is similar to a group of Docker containers
|
||||
with shared namespaces and shared filesystem volumes.
|
||||
-->
|
||||
Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离
|
||||
方面，即用来隔离 Docker 容器的技术。
|
||||
在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。
|
||||
|
||||
就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker
|
||||
容器。
|
||||
|
||||
<!--
|
||||
## Using Pods
|
||||
|
||||
Usually you don't need to create Pods directly, even singleton Pods.
|
||||
Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
|
||||
term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
|
||||
If your Pods need to track state, consider the
|
||||
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
|
||||
|
||||
Pods in a Kubernetes cluster are used in two main ways:
|
||||
-->
|
||||
## 使用 Pod {#using-pods}
|
||||
|
||||
通常你不需要直接创建 Pod，甚至单实例 Pod。
|
||||
相反，你会使用诸如
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或
|
||||
{{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源
|
||||
来创建 Pod。如果 Pod 需要跟踪状态，
|
||||
可以考虑 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
资源。
|
||||
|
||||
Kubernetes 集群中的 Pod 主要有两种用法：
|
||||
|
||||
<!--
|
||||
* **Pods that run a single container**. The "one-container-per-Pod" model is the
|
||||
most common Kubernetes use case; in this case, you can think of a Pod as a
|
||||
wrapper around a single container; Kubernetes manages Pods rather than managing
|
||||
the containers directly.
|
||||
* **Pods that run multiple containers that need to work together**. A Pod can
|
||||
encapsulate an application composed of multiple co-located containers that are
|
||||
tightly coupled and need to share resources. These co-located containers
|
||||
form a single cohesive unit of service—for example, one container serving data
|
||||
stored in a shared volume to the public, while a separate _sidecar_ container
|
||||
refreshes or updates those files.
|
||||
The Pod wraps these containers, storage resources, and an ephemeral network
|
||||
identity together as a single unit.
|
||||
|
||||
Grouping multiple co-located and co-managed containers in a single Pod is a
|
||||
relatively advanced use case. You should use this pattern only in specific
|
||||
instances in which your containers are tightly coupled.
|
||||
-->
|
||||
* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；
|
||||
在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
|
||||
* **运行多个协同工作的容器的 Pod**。
|
||||
Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
|
||||
这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，
|
||||
而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。
|
||||
Pod 将这些容器和存储资源打包为一个可管理的实体。
|
||||
|
||||
{{< note >}}
|
||||
将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。
|
||||
只有在一些场景中，容器之间紧密关联时你才应该使用这种模式。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Each Pod is meant to run a single instance of a given application. If you want to
|
||||
scale your application horizontally (to provide more overall resources by running
|
||||
more instances), you should use multiple Pods, one for each instance. In
|
||||
Kubernetes, this is typically referred to as _replication_.
|
||||
Replicated Pods are usually created and managed as a group by a workload resource
|
||||
and its {{< glossary_tooltip text="controller" term_id="controller" >}}.
|
||||
|
||||
See [Pods and controllers](#pods-and-controllers) for more information on how
|
||||
Kubernetes uses workload resources, and their controllers, to implement application
|
||||
scaling and auto-healing.
|
||||
-->
|
||||
|
||||
每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例
|
||||
以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。
|
||||
在 Kubernetes 中，这通常被称为 _副本（Replication）_。
|
||||
通常使用一种工作负载资源及其{{< glossary_tooltip text="控制器" term_id="controller" >}}
|
||||
来创建和管理一组 Pod 副本。
|
||||
|
||||
参见 [Pod 和控制器](#pods-and-controllers)以了解 Kubernetes
|
||||
如何使用工作负载资源及其控制器以实现应用的扩缩和自动修复。
|
||||
|
||||
<!--
|
||||
### How Pods manage multiple containers
|
||||
|
||||
Pods are designed to support multiple cooperating processes (as containers) that form
|
||||
a cohesive unit of service. The containers in a Pod are automatically co-located and
|
||||
co-scheduled on the same physical or virtual machine in the cluster. The containers
|
||||
can share resources and dependencies, communicate with one another, and coordinate
|
||||
when and how they are terminated.
|
||||
-->
|
||||
### Pod 怎样管理多个容器
|
||||
|
||||
Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。
|
||||
Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。
|
||||
容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。
|
||||
|
||||
<!--
|
||||
For example, you might have a container that
|
||||
acts as a web server for files in a shared volume, and a separate "sidecar" container
|
||||
that updates those files from a remote source, as in the following diagram:
|
||||
-->
|
||||
|
||||
例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的
|
||||
“sidecar（挂斗）”容器负责从远端更新这些文件，如下图所示：
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
|
||||
|
||||
<!--
|
||||
Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}}
|
||||
as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}.
|
||||
Init containers run and complete before the app containers are started.
|
||||
|
||||
Pods natively provide two kinds of shared resources for their constituent containers:
|
||||
[networking](#pod-networking) and [storage](#pod-storage).
|
||||
-->
|
||||
有些 Pod 具有 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}} 和
|
||||
{{< glossary_tooltip text="应用容器" term_id="app-container" >}}。
|
||||
Init 容器会在启动应用容器之前运行并完成。
|
||||
|
||||
Pod 天生地为其成员容器提供了两种共享资源：[网络](#pod-networking)和
|
||||
[存储](#pod-storage)。
|
||||
|
||||
<!--
|
||||
## Working with Pods
|
||||
|
||||
You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This
|
||||
is because Pods are designed as relatively ephemeral, disposable entities. When
|
||||
a Pod gets created (directly by you, or indirectly by a
|
||||
{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is
|
||||
scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster.
|
||||
The Pod remains on that node until the Pod finishes execution, the Pod object is deleted,
|
||||
the Pod is *evicted* for lack of resources, or the node fails.
|
||||
-->
|
||||
## 使用 Pod {#working-with-pods}
|
||||
|
||||
你很少在 Kubernetes 中直接创建一个个的 Pod，甚至是单实例（Singleton）的 Pod。
|
||||
这是因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体。
|
||||
当 Pod 由你或者间接地由 {{< glossary_tooltip text="控制器" term_id="controller" >}}
|
||||
创建时，它被调度在集群中的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
|
||||
Pod 会保持在该节点上运行，直到 Pod 结束执行、Pod 对象被删除、Pod 因资源不足而被
|
||||
*驱逐* 或者节点失效为止。
|
||||
|
||||
<!--
|
||||
Restarting a container in a Pod should not be confused with restarting a Pod. A Pod
|
||||
is not a process, but an environment for running container(s). A Pod persists until
|
||||
it is deleted.
|
||||
-->
|
||||
{{< note >}}
|
||||
重启 Pod 中的容器不应与重启 Pod 混淆。
|
||||
Pod 不是进程，而是容器运行的环境。
|
||||
在被删除之前，Pod 会一直存在。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
When you create the manifest for a Pod object, make sure the name specified is a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
-->
|
||||
当你为 Pod 对象创建清单时，要确保所指定的 Pod 名称是合法的
|
||||
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
|
||||
<!--
|
||||
### Pods and controllers
|
||||
|
||||
You can use workload resources to create and manage multiple Pods for you. A controller
|
||||
for the resource handles replication and rollout and automatic healing in case of
|
||||
Pod failure. For example, if a Node fails, a controller notices that Pods on that
|
||||
Node have stopped working and creates a replacement Pod. The scheduler places the
|
||||
replacement Pod onto a healthy Node.
|
||||
|
||||
Here are some examples of workload resources that manage one or more Pods:
|
||||
-->
|
||||
### Pod 和控制器 {#pods-and-controllers}
|
||||
|
||||
你可以使用工作负载资源来创建和管理多个 Pod。
|
||||
资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。
|
||||
例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作，
|
||||
就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行。
|
||||
|
||||
下面是一些管理一个或者多个 Pod 的工作负载资源的示例：
|
||||
|
||||
* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
|
||||
|
||||
<!--
|
||||
### Pod templates
|
||||
|
||||
Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
|
||||
from a _pod template_ and manage those Pods on your behalf.
|
||||
|
||||
PodTemplates are specifications for creating Pods, and are included in workload resources such as
|
||||
[Deployments](/docs/concepts/workloads/controllers/deployment/),
|
||||
[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
|
||||
-->
|
||||
### Pod 模版 {#pod-templates}
|
||||
|
||||
{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用 _Pod 模板（Pod Template）_
|
||||
来替你创建 Pod 并管理它们。
|
||||
|
||||
Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
|
||||
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
|
||||
[Job](/zh/docs/concepts/workloads/containers/job/) 和
|
||||
[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。
|
||||
|
||||
<!--
|
||||
Each controller for a workload resource uses the `PodTemplate` inside the workload
|
||||
object to make actual Pods. The `PodTemplate` is part of the desired state of whatever
|
||||
workload resource you used to run your app.
|
||||
|
||||
The sample below is a manifest for a simple Job with a `template` that starts one
|
||||
container. The container in that Pod prints a message then pauses.
|
||||
-->
|
||||
工作负载的控制器会使用负载对象中的 `PodTemplate` 来生成实际的 Pod。
|
||||
`PodTemplate` 是你用来运行应用时指定的负载资源的目标状态的一部分。
|
||||
|
||||
下面的示例是一个简单的 Job 的清单，其中的 `template` 指示启动一个容器。
|
||||
该 Pod 中的容器会打印一条消息之后暂停。
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
template:
|
||||
# 这里是 Pod 模版
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
|
||||
restartPolicy: OnFailure
|
||||
# 以上为 Pod 模版
|
||||
```
|
||||
|
||||
<!--
|
||||
Modifying the pod template or switching to a new pod template has no effect on the
|
||||
Pods that already exist. Pods do not receive template updates directly. Instead,
|
||||
a new Pod is created to match the revised pod template.
|
||||
|
||||
For example, the deployment controller ensures that the running Pods match the current
|
||||
pod template for each Deployment object. If the template is updated, the Deployment has
|
||||
to remove the existing Pods and create new Pods based on the updated template. Each workload
|
||||
resource implements its own rules for handling changes to the Pod template.
|
||||
-->
|
||||
修改 Pod 模版或者切换到新的 Pod 模版都不会对已经存在的 Pod 起作用。
|
||||
Pod 不会直接收到模版的更新。相反，
|
||||
新的 Pod 会被创建出来，与更改后的 Pod 模版匹配。
|
||||
|
||||
例如，Deployment 控制器针对每个 Deployment 对象确保运行中的 Pod 与当前的 Pod
|
||||
模版匹配。如果模版被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模版
|
||||
创建新的 Pod。每个工作负载资源都实现了自己的规则，用来处理对 Pod 模版的更新。
|
||||
|
||||
<!--
|
||||
On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
|
||||
directly observe or manage any of the details around pod templates and updates; those
|
||||
details are abstracted away. That abstraction and separation of concerns simplifies
|
||||
system semantics, and makes it feasible to extend the cluster's behavior without
|
||||
changing existing code.
|
||||
-->
|
||||
在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}并不直接监测
|
||||
或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。
|
||||
这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的
|
||||
前提下就能扩展集群的行为。
|
||||
|
||||
<!--
|
||||
## Resource sharing and communication
|
||||
|
||||
Pods enable data sharing and communication among their constituent
|
||||
containters.
|
||||
-->
|
||||
### 资源共享和通信 {#resource-sharing-and-communication}
|
||||
|
||||
Pod 使它的成员容器间能够进行数据共享和通信。
|
||||
|
||||
<!--
|
||||
### Storage in Pods {#pod-storage}
|
||||
|
||||
A Pod can specify a set of shared storage
|
||||
{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers
|
||||
in the Pod can access the shared volumes, allowing those containers to
|
||||
share data. Volumes also allow persistent data in a Pod to survive
|
||||
in case one of the containers within needs to be restarted. See
|
||||
[Storage](/docs/concepts/storage/) for more information on how
|
||||
Kubernetes implements shared storage and makes it available to Pods.
|
||||
-->
|
||||
### Pod 中的存储 {#pod-storage}
|
||||
|
||||
一个 Pod 可以设置一组共享的存储{{< glossary_tooltip text="卷" term_id="volume" >}}。
|
||||
Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。
|
||||
卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。
|
||||
有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息，
|
||||
请参考[卷](/zh/docs/concepts/storage/)。
|
||||
|
||||
<!--
|
||||
### Pod networking
|
||||
|
||||
Each Pod is assigned a unique IP address for each address family. Every
|
||||
container in a Pod shares the network namespace, including the IP address and
|
||||
network ports. Inside a Pod (and **only** then), the containers that belong to the Pod
|
||||
can communicate with one another using `localhost`. When containers in a Pod communicate
|
||||
with entities *outside the Pod*,
|
||||
they must coordinate how they use the shared network resources (such as ports).
|
||||
-->
|
||||
### Pod 联网 {#pod-networking}
|
||||
|
||||
每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。
|
||||
Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。
|
||||
*Pod 内* 的容器可以使用 `localhost` 互相通信。
|
||||
当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源
|
||||
（例如端口）。
|
||||
|
||||
<!--
|
||||
Within a Pod, containers share an IP address and port space, and
|
||||
can find each other via `localhost`. The containers in a Pod can also communicate
|
||||
with each other using standard inter-process communications like SystemV semaphores
|
||||
or POSIX shared memory. Containers in different Pods have distinct IP addresses
|
||||
and can not communicate by IPC without
|
||||
[special configuration](/docs/concepts/policy/pod-security-policy/).
|
||||
Containers that want to interact with a container running in a different Pod can
|
||||
use IP networking to comunicate.
|
||||
-->
|
||||
在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 发现对方。
|
||||
他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。
|
||||
不同 Pod 中的容器的 IP 地址互不相同，没有
|
||||
[特殊配置](/zh/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。
|
||||
如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。
|
||||
|
||||
<!--
|
||||
Containers within the Pod see the system hostname as being the same as the configured
|
||||
`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
|
||||
section.
|
||||
-->
|
||||
Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。
|
||||
[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。
|
||||
|
||||
<!--
|
||||
## 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.
|
||||
-->
|
||||
## 容器的特权模式 {#rivileged-mode-for-containers}
|
||||
|
||||
Pod 中的任何容器都可以使用容器规约中的
|
||||
[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
|
||||
`privileged` 参数启用特权模式。
|
||||
这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
|
||||
的容器很有用。
|
||||
容器内的进程几乎可以获得与容器外的进程相同的特权。
|
||||
|
||||
<!--
|
||||
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" >}}必须支持
|
||||
特权容器的概念才能使用这一配置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Static Pods
|
||||
|
||||
_Static Pods_ are managed directly by the kubelet daemon on a specific node,
|
||||
without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
|
||||
observing them.
|
||||
Whereas most Pods are managed by the control plane (for example, a
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static
|
||||
Pods, the kubelet directly supervises each static Pod (and restarts it if it fails).
|
||||
-->
|
||||
## 静态 Pod {#static-pods}
|
||||
|
||||
_静态 Pod（Static Pod）_ 直接由特定节点上的 `kubelet` 守护进程管理，
|
||||
不需要{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}看到它们。
|
||||
尽管大多数 Pod 都是通过控制面（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
|
||||
来管理的，对于静态 Pod 而言，`kubelet` 直接监控每个 Pod，并在其失效时重启之。
|
||||
|
||||
<!--
|
||||
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
|
||||
The main use for static Pods is to run a self-hosted control plane: in other words,
|
||||
using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
|
||||
|
||||
The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
|
||||
on the Kubernetes API server for each static Pod.
|
||||
This means that the Pods running on a node are visible on the API server,
|
||||
but cannot be controlled from there.
|
||||
-->
|
||||
静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。
|
||||
其主要用途是运行自托管的控制面。
|
||||
在自托管场景中，使用 `kubelet` 来管理各个独立的
|
||||
[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)。
|
||||
|
||||
`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个
|
||||
{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
|
||||
这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API
|
||||
服务器来控制。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||
* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
|
||||
* Lean 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)
|
||||
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.
|
||||
--
|
||||
* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
* 了解 [PodPresets](/zh/docs/concepts/workloads/pods/podpreset/)
|
||||
* 了解 [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)
|
||||
对象的定义中包含了更多的细节信息。
|
||||
* 博客 [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 中解释了在同一 Pod 中包含多个容器时的几种常见布局。
|
||||
|
||||
<!--
|
||||
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
|
||||
-->
|
||||
要了解为什么 Kubernetes 会在其他资源
|
||||
（如 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
|
||||
封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：
|
||||
|
||||
* [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,265 +0,0 @@
|
|||
---
|
||||
title: Pod 概览
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
title: Pod Overview
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
|
||||
-->
|
||||
<!-- overview -->
|
||||
本节提供了 `Pod` 的概览信息，`Pod` 是最小可部署的 Kubernetes 对象模型。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Understanding Pods
|
||||
-->
|
||||
## 理解 Pod
|
||||
|
||||
<!--
|
||||
A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" >}}.
|
||||
-->
|
||||
*Pod* 是 Kubernetes 应用程序的基本执行单元，即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在 {{< glossary_tooltip term_id="cluster" >}} 上运行的进程。
|
||||
|
||||
<!--
|
||||
A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
|
||||
-->
|
||||
Pod 封装了应用程序容器（或者在某些情况下封装多个容器）、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。
|
||||
Pod 表示部署单元：*Kubernetes 中应用程序的单个实例*，它可能由单个 {{< glossary_tooltip text="容器" term_id="container" >}} 或少量紧密耦合并共享资源的容器组成。
|
||||
|
||||
<!--
|
||||
[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
|
||||
-->
|
||||
[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的[容器运行时](/docs/setup/production-environment/container-runtimes/)。
|
||||
|
||||
|
||||
<!--
|
||||
Pods in a Kubernetes cluster can be used in two main ways:
|
||||
-->
|
||||
Kubernetes 集群中的 Pod 可被用于以下两个主要用途：
|
||||
|
||||
<!--
|
||||
* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
|
||||
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
|
||||
The [Kubernetes Blog](https://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
|
||||
-->
|
||||
|
||||
* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
|
||||
* **运行多个协同工作的容器的 Pod**。
|
||||
Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
|
||||
这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。
|
||||
Pod 将这些容器和存储资源打包为一个可管理的实体。
|
||||
[Kubernetes 博客](https://kubernetes.io/blog) 上有一些其他的 Pod 用例信息。更多信息请参考：
|
||||
|
||||
<!--
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
-->
|
||||
* [分布式系统工具包：容器组合的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [容器设计模式](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
|
||||
<!--
|
||||
Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information.
|
||||
-->
|
||||
|
||||
每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例），则应该使用多个 Pod，每个应用实例使用一个 Pod 。在 Kubernetes 中，这通常被称为 _副本_。通常使用一个称为控制器的抽象来创建和管理一组副本 Pod。更多信息请参见 [Pod 和控制器](#pods-and-controllers)。
|
||||
|
||||
<!--
|
||||
### How Pods manage multiple Containers
|
||||
-->
|
||||
### Pod 怎样管理多个容器
|
||||
|
||||
<!--
|
||||
Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
|
||||
-->
|
||||
Pod 被设计成支持形成内聚服务单元的多个协作过程（作为容器）。
|
||||
Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上，并可以一起进行调度。
|
||||
容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。
|
||||
|
||||
<!--
|
||||
Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
|
||||
-->
|
||||
|
||||
注意，在单个 Pod 中将多个并置和共同管理的容器分组是一个相对高级的使用方式。
|
||||
只在容器紧密耦合的特定实例中使用此模式。
|
||||
例如，您可能有一个充当共享卷中文件的 Web 服务器的容器，以及一个单独的 sidecar 容器，该容器从远端更新这些文件，如下图所示：
|
||||
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" alt="Pod 图例" width="50%" >}}
|
||||
|
||||
|
||||
<!--
|
||||
Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
|
||||
-->
|
||||
有些 Pod 具有 {{< glossary_tooltip text="初始容器" term_id="init-container" >}} 和 {{< glossary_tooltip text="应用容器" term_id="app-container" >}}。初始容器会在启动应用容器之前运行并完成。
|
||||
|
||||
<!--
|
||||
Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
|
||||
-->
|
||||
|
||||
Pod 为其组成容器提供了两种共享资源：*网络* 和 *存储*。
|
||||
|
||||
<!--
|
||||
#### Networking
|
||||
-->
|
||||
#### 网络
|
||||
|
||||
<!--
|
||||
Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
|
||||
-->
|
||||
每个 Pod 分配一个唯一的 IP 地址。
|
||||
Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口。
|
||||
*Pod 内的容器* 可以使用 `localhost` 互相通信。
|
||||
当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。
|
||||
|
||||
<!--
|
||||
#### Storage
|
||||
-->
|
||||
#### 存储
|
||||
|
||||
<!--
|
||||
A Pod can specify a set of shared storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
|
||||
-->
|
||||
一个 Pod 可以指定一组共享存储{{< glossary_tooltip text="卷" term_id="volume" >}}。
|
||||
Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。
|
||||
卷还允许 Pod 中的持久数据保留下来，以防其中的容器需要重新启动。
|
||||
有关 Kubernetes 如何在 Pod 中实现共享存储的更多信息，请参考[卷](/docs/concepts/storage/volumes/)。
|
||||
|
||||
<!--
|
||||
## Working with Pods
|
||||
-->
|
||||
## 使用 Pod
|
||||
|
||||
<!--
|
||||
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the Node fails.
|
||||
-->
|
||||
你很少在 Kubernetes 中直接创建单独的 Pod，甚至是单个存在的 Pod。
|
||||
这是因为 Pod 被设计成了相对短暂的一次性的实体。
|
||||
当 Pod 由您创建或者间接地由控制器创建时，它被调度在集群中的 {{< glossary_tooltip term_id="node" >}} 上运行。
|
||||
Pod 会保持在该节点上运行，直到进程被终止、Pod 对象被删除、Pod 因资源不足而被 *驱逐* 或者节点失效为止。
|
||||
|
||||
<!--
|
||||
Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
|
||||
-->
|
||||
{{< note >}}
|
||||
重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行，而是作为容器运行的环境，并且一直保持到被删除为止。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself 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 *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
|
||||
-->
|
||||
|
||||
Pod 本身并不能自愈。
|
||||
如果 Pod 被调度到失败的节点，或者如果调度操作本身失败，则删除该 Pod；同样，由于缺乏资源或进行节点维护，Pod 在被驱逐后将不再生存。
|
||||
Kubernetes 使用了一个更高级的称为 *控制器* 的抽象，由它处理相对可丢弃的 Pod 实例的管理工作。
|
||||
因此，虽然可以直接使用 Pod，但在 Kubernetes 中，更为常见的是使用控制器管理 Pod。
|
||||
有关 Kubernetes 如何使用控制器实现 Pod 伸缩和愈合的更多信息，请参考 [Pod 和控制器](#pods-and-controllers)。
|
||||
|
||||
<!--
|
||||
### Pods and Controllers
|
||||
-->
|
||||
### Pod 和控制器 {#pods-and-controllers}
|
||||
|
||||
<!--
|
||||
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
|
||||
-->
|
||||
控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。
|
||||
例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。
|
||||
|
||||
<!--
|
||||
Some examples of Controllers that contain one or more pods include:
|
||||
-->
|
||||
包含一个或多个 Pod 的控制器一些示例包括：
|
||||
|
||||
<!--
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
-->
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
<!--
|
||||
In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
|
||||
-->
|
||||
控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。
|
||||
|
||||
<!--
|
||||
## Pod Templates
|
||||
-->
|
||||
## Pod 模板
|
||||
|
||||
<!--
|
||||
Pod templates are pod specifications which are included in other objects, such as
|
||||
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Controllers use Pod Templates to make actual pods.
|
||||
The sample below is a simple manifest for a Pod which contains a container that prints
|
||||
a message.
|
||||
-->
|
||||
Pod 模板是包含在其他对象中的 Pod 规范，例如
|
||||
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) 和
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/)。
|
||||
控制器使用 Pod 模板来制作实际使用的 Pod。
|
||||
下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
```
|
||||
|
||||
<!--
|
||||
Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no "quantum entanglement". Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.
|
||||
-->
|
||||
|
||||
Pod 模板就像饼干切割器，而不是指定所有副本的当前期望状态。
|
||||
一旦饼干被切掉，饼干就与切割器没有关系。
|
||||
没有“量子纠缠”。
|
||||
随后对模板的更改或甚至切换到新的模板对已经创建的 Pod 没有直接影响。
|
||||
类似地，由副本控制器创建的 Pod 随后可以被直接更新。
|
||||
这与 Pod 形成有意的对比，Pod 指定了属于 Pod 的所有容器的当前期望状态。
|
||||
这种方法从根本上简化了系统语义，增加了原语的灵活性。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
|
||||
* Learn more about Pod behavior:
|
||||
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
-->
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 详细了解 [Pod](/docs/concepts/workloads/pods/pod/)
|
||||
* 了解有关 Pod 行为的更多信息：
|
||||
* [Pod 的终止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
|
|
@ -1,383 +0,0 @@
|
|||
---
|
||||
title: Pods
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
title: Pods
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
_Pods_ are the smallest deployable units of computing that can be created and
|
||||
managed in Kubernetes.
|
||||
-->
|
||||
|
||||
_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## What is a Pod?
|
||||
-->
|
||||
## Pod 是什么？
|
||||
|
||||
<!--
|
||||
A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
|
||||
{{< glossary_tooltip text="containers" term_id="container" >}} (such as
|
||||
Docker containers), with shared storage/network, and a specification
|
||||
for how to run the containers. A Pod's contents are always co-located and
|
||||
co-scheduled, and run in a shared context. A Pod models an
|
||||
application-specific "logical host" - it contains one or more application
|
||||
containers which are relatively tightly coupled — in a pre-container
|
||||
world, being executed on the same physical or virtual machine would mean being
|
||||
executed on the same logical host.
|
||||
-->
|
||||
_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）{{< glossary_tooltip text="容器" term_id="container" >}}（例如 Docker 容器），这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。
|
||||
Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起 — 在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。
|
||||
|
||||
<!--
|
||||
While Kubernetes supports more container runtimes than just Docker, Docker is
|
||||
the most commonly known runtime, and it helps to describe Pods in Docker terms.
|
||||
-->
|
||||
虽然 Kubernetes 支持多种容器运行时，但 Docker 是最常见的一种运行时，它有助于使用 Docker 术语来描述 Pod。
|
||||
|
||||
<!--
|
||||
The shared context of a Pod is a set of Linux namespaces, cgroups, and
|
||||
potentially other facets of isolation - the same things that isolate a Docker
|
||||
container. Within a Pod's context, the individual applications may have
|
||||
further sub-isolations applied.
|
||||
-->
|
||||
Pod 的共享上下文是一组 Linux 命名空间、cgroups、以及其他潜在的资源隔离相关的因素，这些相同的东西也隔离了 Docker 容器。在 Pod 的上下文中，单个应用程序可能还会应用进一步的子隔离。
|
||||
|
||||
<!--
|
||||
Containers within a Pod share an IP address and port space, and
|
||||
can find each other via `localhost`. They can also communicate with each
|
||||
other using standard inter-process communications like SystemV semaphores or
|
||||
POSIX shared memory. Containers in different Pods have distinct IP addresses
|
||||
and can not communicate by IPC without
|
||||
[special configuration](/docs/concepts/policy/pod-security-policy/).
|
||||
These containers usually communicate with each other via Pod IP addresses.
|
||||
|
||||
Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
|
||||
as part of a Pod and are made available to be mounted into each application's
|
||||
filesystem.
|
||||
-->
|
||||
Pod 中的所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 互相发现。他们也能通过标准的进程间通信（如 SystemV 信号量或 POSIX 共享内存）方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同，没有 [特殊配置](/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。
|
||||
|
||||
Pod 中的应用也能访问共享 {{< glossary_tooltip text="卷" term_id="volume" >}}，共享卷是 Pod 定义的一部分，可被用来挂载到每个应用的文件系统上。
|
||||
|
||||
<!--
|
||||
In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
|
||||
a group of Docker containers with shared namespaces and shared filesystem
|
||||
volumes.
|
||||
-->
|
||||
在 [Docker](https://www.docker.com/) 体系的术语中，Pod 被建模为一组具有共享命名空间和共享文件系统[卷](/docs/concepts/storage/volumes/) 的 Docker 容器。
|
||||
|
||||
<!--
|
||||
Like individual application containers, Pods are considered to be relatively
|
||||
ephemeral (rather than durable) entities. As discussed in
|
||||
[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
|
||||
scheduled to nodes where they remain until termination (according to restart
|
||||
policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
|
||||
scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
|
||||
"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
|
||||
with even the same name if desired, but with a new UID (see [replication
|
||||
controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
|
||||
-->
|
||||
与单个应用程序容器一样，Pod 被认为是相对短暂的（而不是持久的）实体。如 [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) 所讨论的那样：Pod 被创建、给它指定一个唯一 ID （UID）、被调度到节点、在节点上存续直到终止（取决于重启策略）或被删除。如果 {{< glossary_tooltip term_id="node" >}} 宕机，调度到该节点上的 Pod 会在一个超时周期后被安排删除。给定 Pod （由 UID 定义）不会重新调度到新节点；相反，它会被一个完全相同的 Pod 替换掉，如果需要甚至连 Pod 名称都可以一样，除了 UID 是新的(更多信息请查阅 [副本控制器（replication
|
||||
controller）](/docs/concepts/workloads/controllers/replicationcontroller/)。
|
||||
|
||||
<!--
|
||||
When something is said to have the same lifetime as a Pod, such as a volume,
|
||||
that means that it exists as long as that Pod (with that UID) exists. If that
|
||||
Pod is deleted for any reason, even if an identical replacement is created, the
|
||||
related thing (e.g. volume) is also destroyed and created anew.
|
||||
-->
|
||||
当某些东西被说成与 Pod（如卷）具有相同的生命周期时，这表明只要 Pod（具有该 UID）存在，它就存在。如果出于任何原因删除了该 Pod，即使创建了相同的 Pod，相关的内容（例如卷）也会被销毁并重新创建。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
|
||||
|
||||
<!--
|
||||
*A multi-container Pod that contains a file puller and a
|
||||
web server that uses a persistent volume for shared storage between the containers.*
|
||||
-->
|
||||
|
||||
*一个多容器 Pod，其中包含一个文件拉取器和一个 Web 服务器，该 Web 服务器使用持久卷在容器之间共享存储*
|
||||
|
||||
<!--
|
||||
## Motivation for pods
|
||||
-->
|
||||
## 设计 Pod 的目的
|
||||
|
||||
<!--
|
||||
### Management
|
||||
-->
|
||||
### 管理
|
||||
|
||||
<!--
|
||||
Pods are a model of the pattern of multiple cooperating processes which form a
|
||||
cohesive unit of service. They simplify application deployment and management
|
||||
by providing a higher-level abstraction than the set of their constituent
|
||||
applications. Pods serve as unit of deployment, horizontal scaling, and
|
||||
replication. Colocation (co-scheduling), shared fate (e.g. termination),
|
||||
coordinated replication, resource sharing, and dependency management are
|
||||
handled automatically for containers in a Pod.
|
||||
-->
|
||||
Pod 是形成内聚服务单元的多个协作过程模式的模型。它们提供了一个比它们的应用组成集合更高级的抽象，从而简化了应用的部署和管理。Pod 可以用作部署、水平扩展和制作副本的最小单元。在 Pod 中，系统自动处理多个容器的在并置运行（协同调度）、生命期共享（例如，终止），协同复制、资源共享和依赖项管理。
|
||||
|
||||
<!--
|
||||
### Resource sharing and communication
|
||||
-->
|
||||
### 资源共享和通信
|
||||
|
||||
<!--
|
||||
Pods enable data sharing and communication among their constituents.
|
||||
-->
|
||||
Pod 使它的组成容器间能够进行数据共享和通信。
|
||||
|
||||
<!--
|
||||
The applications in a Pod all use the same network namespace (same IP and port
|
||||
space), and can thus "find" each other and communicate using `localhost`.
|
||||
Because of this, applications in a Pod must coordinate their usage of ports.
|
||||
Each Pod has an IP address in a flat shared networking space that has full
|
||||
communication with other physical computers and Pods across the network.
|
||||
-->
|
||||
Pod 中的应用都使用相同的网络命名空间（相同 IP 和 端口空间），而且能够互相“发现”并使用 `localhost` 进行通信。因此，在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个 IP 地址，该空间通过网络与其他物理计算机和 Pod 进行全面通信。
|
||||
|
||||
<!--
|
||||
Containers within the Pod see the system hostname as being the same as the configured
|
||||
`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
|
||||
section.
|
||||
-->
|
||||
Pod 中的容器获取的系统主机名与为 Pod 配置的 `name` 相同。[网络](/docs/concepts/cluster-administration/networking/) 部分提供了更多有关此内容的信息。
|
||||
|
||||
<!--
|
||||
In addition to defining the application containers that run in the Pod, the Pod
|
||||
specifies a set of shared storage volumes. Volumes enable data to survive
|
||||
container restarts and to be shared among the applications within the Pod.
|
||||
-->
|
||||
Pod 除了定义了 Pod 中运行的应用程序容器之外，Pod 还指定了一组共享存储卷。该共享存储卷能使数据在容器重新启动后继续保留，并能在 Pod 内的应用程序之间共享。
|
||||
|
||||
<!--
|
||||
## Uses of pods
|
||||
-->
|
||||
## 使用 Pod
|
||||
|
||||
<!--
|
||||
Pods can be used to host vertically integrated application stacks (e.g. LAMP),
|
||||
but their primary motivation is to support co-located, co-managed helper
|
||||
programs, such as:
|
||||
|
||||
* content management systems, file and data loaders, local cache managers, etc.
|
||||
* log and checkpoint backup, compression, rotation, snapshotting, etc.
|
||||
* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
|
||||
* proxies, bridges, and adapters
|
||||
* controllers, managers, configurators, and updaters
|
||||
-->
|
||||
Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的目的是支持位于同一位置的、共同管理的工具程序，例如：
|
||||
|
||||
* 内容管理系统、文件和数据加载器、本地缓存管理器等。
|
||||
* 日志和检查点备份、压缩、旋转、快照等。
|
||||
* 数据更改监视器、日志跟踪器、日志和监视适配器、事件发布器等。
|
||||
* 代理、桥接器和适配器
|
||||
* 控制器、管理器、配置器和更新器
|
||||
|
||||
|
||||
<!--
|
||||
Individual Pods are not intended to run multiple instances of the same
|
||||
application, in general.
|
||||
-->
|
||||
通常，不会用单个 Pod 来运行同一应用程序的多个实例。
|
||||
|
||||
<!--
|
||||
For a longer explanation, see [The Distributed System ToolKit: Patterns for
|
||||
Composite
|
||||
Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
|
||||
-->
|
||||
有关详细说明，请参考 [分布式系统工具包：组合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)。
|
||||
|
||||
<!--
|
||||
## Alternatives considered
|
||||
-->
|
||||
## 可考虑的备选方案
|
||||
|
||||
<!--
|
||||
_Why not just run multiple programs in a single (Docker) container?_
|
||||
|
||||
1. Transparency. Making the containers within the Pod visible to the
|
||||
infrastructure enables the infrastructure to provide services to those
|
||||
containers, such as process management and resource monitoring. This
|
||||
facilitates a number of conveniences for users.
|
||||
1. Decoupling software dependencies. The individual containers may be
|
||||
versioned, rebuilt and redeployed independently. Kubernetes may even support
|
||||
live updates of individual containers someday.
|
||||
1. Ease of use. Users don't need to run their own process managers, worry about
|
||||
signal and exit-code propagation, etc.
|
||||
1. Efficiency. Because the infrastructure takes on more responsibility,
|
||||
containers can be lighter weight.
|
||||
-->
|
||||
_为什么不在单个（Docker）容器中运行多个程序？_
|
||||
|
||||
1. 透明度。Pod 内的容器对基础设施可见，使得基础设施能够向这些容器提供服务，例如流程管理和资源监控。这为用户提供了许多便利。
|
||||
1. 解耦软件依赖关系。可以独立地对单个容器进行版本控制、重新构建和重新部署。Kubernetes 有一天甚至可能支持单个容器的实时更新。
|
||||
1. 易用性。用户不需要运行他们自己的进程管理器、也不用担心信号和退出代码传播等。
|
||||
1. 效率。因为基础结构承担了更多的责任，所以容器可以变得更加轻量化。
|
||||
|
||||
<!--
|
||||
_Why not support affinity-based co-scheduling of containers?_
|
||||
-->
|
||||
_为什么不支持基于亲和性的容器协同调度？_
|
||||
|
||||
<!--
|
||||
That approach would provide co-location, but would not provide most of the
|
||||
benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
|
||||
simplified management.
|
||||
-->
|
||||
这种处理方法尽管可以提供同址，但不能提供 Pod 的大部分好处，如资源共享、IPC、有保证的命运共享和简化的管理。
|
||||
|
||||
<!--
|
||||
## Durability of pods (or lack thereof)
|
||||
-->
|
||||
## Pod 的持久性（或稀缺性）
|
||||
|
||||
<!--
|
||||
Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
|
||||
-->
|
||||
不得将 Pod 视为持久实体。它们无法在调度失败、节点故障或其他驱逐策略（例如由于缺乏资源或在节点维护的情况下）中生存。
|
||||
|
||||
<!--
|
||||
In general, users shouldn't need to create Pods directly. They should almost
|
||||
always use controllers even for singletons, for example,
|
||||
[Deployments](/docs/concepts/workloads/controllers/deployment/).
|
||||
Controllers provide self-healing with a cluster scope, as well as replication
|
||||
and rollout management.
|
||||
Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
can also provide support to stateful Pods.
|
||||
-->
|
||||
一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的 Pod 创建也一样使用控制器，例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。
|
||||
控制器提供集群范围的自修复以及副本数和滚动管理。
|
||||
像 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) 这样的控制器还可以提供支持有状态的 Pod。
|
||||
|
||||
<!--
|
||||
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
|
||||
-->
|
||||
在集群调度系统中，使用 API 合集作为面向用户的主要原语是比较常见的，包括 [Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、和 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
|
||||
|
||||
<!--
|
||||
Pod is exposed as a primitive in order to facilitate:
|
||||
-->
|
||||
Pod 暴露为原语是为了便于：
|
||||
|
||||
<!--
|
||||
* scheduler and controller pluggability
|
||||
* support for pod-level operations without the need to "proxy" them via controller APIs
|
||||
* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
|
||||
* decoupling of controllers and services — the endpoint controller just watches Pods
|
||||
* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
|
||||
* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
|
||||
-->
|
||||
* 调度器和控制器可插拔性
|
||||
* 支持 Pod 级别的操作，而不需要通过控制器 API "代理" 它们
|
||||
* Pod 生命与控制器生命的解耦，如自举
|
||||
* 控制器和服务的解耦 — 端点控制器只监视 Pod
|
||||
* kubelet 级别的功能与集群级别功能的清晰组合 — kubelet 实际上是 "Pod 控制器"
|
||||
* 高可用性应用程序期望在 Pod 终止之前并且肯定要在 Pod 被删除之前替换 Pod，例如在计划驱逐或镜像预先拉取的情况下。
|
||||
|
||||
<!--
|
||||
## Termination of Pods
|
||||
-->
|
||||
## Pod 的终止
|
||||
|
||||
<!--
|
||||
Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
|
||||
-->
|
||||
因为 Pod 代表在集群中的节点上运行的进程，所以当不再需要这些进程时（与被 KILL 信号粗暴地杀死并且没有机会清理相比），允许这些进程优雅地终止是非常重要的。
|
||||
用户应该能够请求删除并且知道进程何时终止，但是也能够确保删除最终完成。当用户请求删除 Pod 时，系统会记录在允许强制删除 Pod 之前所期望的宽限期，并向每个容器中的主进程发送 TERM 信号。一旦过了宽限期，KILL 信号就发送到这些进程，然后就从 API 服务器上删除 Pod。如果 Kubelet 或容器管理器在等待进程终止时发生重启，则终止操作将以完整的宽限期进行重试。
|
||||
|
||||
|
||||
<!--
|
||||
An example flow:
|
||||
-->
|
||||
流程示例：
|
||||
|
||||
<!--
|
||||
1. User sends command to delete Pod, with default grace period (30s)
|
||||
1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
|
||||
1. Pod shows up as "Terminating" when listed in client commands
|
||||
1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
|
||||
1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
|
||||
1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
|
||||
1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
|
||||
1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
|
||||
1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
|
||||
-->
|
||||
1. 用户发送命令删除 Pod，使用的是默认的宽限期（30秒）
|
||||
1. API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 "死亡"。
|
||||
1. 当使用客户端命令查询 Pod 状态时，Pod 显示为 "Terminating"。
|
||||
1. （和第 3 步同步进行）当 Kubelet 看到 Pod 由于步骤 2 中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。
|
||||
1. 如果 Pod 定义了 [preStop 钩子](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，就在 Pod 内部调用它。如果宽限期结束了，但是 `preStop` 钩子还在运行，那么就用小的（2 秒）扩展宽限期调用步骤 2。
|
||||
1. 给 Pod 内的进程发送 TERM 信号。请注意，并不是所有 Pod 中的容器都会同时收到 TERM 信号，如果它们关闭的顺序很重要，则每个容器可能都需要一个 `preStop` 钩子。
|
||||
1. （和第 3 步同步进行）从服务的端点列表中删除 Pod，Pod 也不再被视为副本控制器的运行状态的 Pod 集的一部分。因为负载均衡器（如服务代理）会将其从轮换中删除，所以缓慢关闭的 Pod 无法继续为流量提供服务。
|
||||
1. 当宽限期到期时，仍在 Pod 中运行的所有进程都会被 SIGKILL 信号杀死。
|
||||
1. kubelet 将通过设置宽限期为 0 （立即删除）来完成在 API 服务器上删除 Pod 的操作。该 Pod 从 API 服务器中消失，并且在客户端中不再可见。
|
||||
|
||||
|
||||
<!--
|
||||
By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=<seconds>` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
|
||||
You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
|
||||
-->
|
||||
默认情况下，所有删除操作宽限期是 30 秒。`kubectl delete` 命令支持 `--grace-period=<seconds>` 选项，允许用户覆盖默认值并声明他们自己的宽限期。设置为 `0` 会[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) Pod。您必须指定一个附加标志 `--force` 和 `--grace-period=0` 才能执行强制删除操作。
|
||||
|
||||
<!--
|
||||
### Force deletion of pods
|
||||
-->
|
||||
### Pod 的强制删除
|
||||
|
||||
<!--
|
||||
Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
|
||||
-->
|
||||
强制删除 Pod 被定义为从集群状态与 etcd 中立即删除 Pod。当执行强制删除时，API 服务器并不会等待 kubelet 的确认信息，该 Pod 已在所运行的节点上被终止了。强制执行删除操作会从 API 服务器中立即清除 Pod， 因此可以用相同的名称创建一个新的 Pod。在节点上，设置为立即终止的 Pod 还是会在被强制删除前设置一个小的宽限期。
|
||||
|
||||
<!--
|
||||
Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
-->
|
||||
强制删除对某些 Pod 可能具有潜在危险，因此应该谨慎地执行。对于 StatefulSet 管理的 Pod，请参考 [从 StatefulSet 中删除 Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/) 的任务文档。
|
||||
|
||||
<!--
|
||||
## Privileged mode for pod containers
|
||||
-->
|
||||
## Pod 容器的特权模式
|
||||
|
||||
<!--
|
||||
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 Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
|
||||
-->
|
||||
Pod 中的任何容器都可以使用容器规范 [security context](/docs/tasks/configure-pod-container/security-context/) 上的 `privileged` 参数启用特权模式。这对于想要使用 Linux 功能（如操纵网络堆栈和访问设备）的容器很有用。容器内的进程几乎可以获得与容器外的进程相同的特权。使用特权模式，将网络和卷插件编写为不需要编译到 kubelet 中的独立的 Pod 应该更容易。
|
||||
|
||||
<!--
|
||||
Your container runtime must support the concept of a privileged container for this setting to be relevant.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
您的容器运行时必须支持特权容器模式才能使用此设置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## API Object
|
||||
-->
|
||||
## API 对象
|
||||
|
||||
<!--
|
||||
Pod is a top-level resource in the Kubernetes REST API.
|
||||
The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
|
||||
describes the object in detail.
|
||||
-->
|
||||
Pod 是 Kubernetes REST API 中的顶级资源。
|
||||
[Pod API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)定义详细描述了该 Pod 对象。
|
||||
|
||||
|
||||
Loading…
Reference in New Issue