19-workloads-Pod Overview

concepts/workloads/pods/pod-overview/

Pod Overview

This page provides an overview of Pod, the smallest deployable object in the Kubernetes object model本页概述了kubernetes对象模型中最小的可部署对象pod.

Understanding Pods

pod是kubernetes应用程序的基本执行单元,是kubernetes对象模型中创建或部署的最小和最简单的单元。pod表示运行在 Cluster.

pod封装了应用程序的容器(或者,在某些情况下,多个容器)、存储资源、唯一的网络ip以及控制容器运行方式的选项。pod表示部署单元:kubernetes中应用程序的单个实例,可能由单个[容器](https://kubernetes.io/docs/concepts/overvi... is kubernetes/why containers)或少量紧密耦合并共享资源的容器组成。

Docker 是Kubernetes pod中最常用的容器运行环境时,但pod也支持其他容器运行container runtimes时。

kubernetes集群中的pods可以通过两种主要方式使用:

  • 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. 运行单个容器。“每个pod一个容器”模型是最常见的kubernetes用例;在本例中,可以将pod看作单个容器的包装器,kubernetes管理pod,而不是直接管理容器。
  • 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 has some additional information on Pod use cases. For more information, see:运行需要协同工作的多个容器的pod。pod可以封装一个应用程序,该应用程序由多个紧密耦合且需要共享资源的同位置容器组成。这些位于同一位置的容器可能形成一个统一的服务单元——一个容器向公众提供共享卷中的文件,而一个单独的“sidecar”容器刷新或更新这些文件。pod将这些容器和存储资源打包为一个可管理的实体。kubernetes博客有一些关于pod用例的附加信息。有关详细信息,请参见:

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 for more information.

每个pod意味着运行给定应用程序的单个实例。如果您想水平扩展应用程序(例如,运行多个实例),则应该使用多个pod,每个pod对应一个实例。在kubernetes中,这通常称为replication。Replicated pod通常由一个名为controller的抽象作为一个组来创建和管理。有关更多信息,请参阅Pods and Controllers

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中的容器同生共灭, 创建调度销毁

注意,在一个pod中对多个同位置和同管理的容器进行分组是一个相对高级的用例。您应该仅在容器紧密耦合的特定实例中使用此模式。例如,您可能有一个充当共享卷中文件的Web服务器的容器,以及一个从远程源更新这些文件的单独“sidecar”容器,如下图所示:

example pod diagram

Some Pods have init containers as well as app containers. Init containers run and complete before the app containers are started.一些pod有init容器和app容器。初始化容器在应用程序容器启动之前运行并完成

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中的容器可以使用本地主机相互通信。当pod中的容器与pod外的实体通信时,它们必须协调如何使用共享网络资源(如端口)。

Storage

A Pod can specify a set of shared storage Volumes. 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 for more information on how Kubernetes implements shared storage in a Pod.pod可以指定一组共享存储卷。pod中的所有容器都可以访问共享卷,从而允许这些容器共享数据。卷还允许pod中的持久数据在需要重新启动其中一个容器时存活。有关kubernetes如何在pod中实现共享存储的更多信息,请参阅卷。

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 Controller), it is scheduled to run on a 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。这是因为Pods被设计成相对短暂的、可丢弃的实体。当pod被创建(直接由您创建,或者间接由控制器创建)时,它被安排在集群中的节点上运行。pod一直保留在该节点上,直到进程终止、pod对象被删除、pod因缺少资源而被逐出或节点失败。

Note: 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.重启pod中的容器不应与重启容器混淆。pod本身不运行,但它是一个容器运行的环境,并一直持续到被删除为止。

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 for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.Pods本身不会自我愈合。如果pod被调度到一个失败的节点,或者如果调度操作本身失败,那么pod将被删除;同样,由于缺乏资源或节点维护,pod将无法在逐出后生存。kubernetes使用一个更高级的抽象,称为控制器,它处理管理相对可丢弃的pod实例的工作。因此,虽然可以直接使用pod,但在kubernetes中,使用控制器管理pod要常见得多。有关kubernetes如何使用控制器实现pod缩放和修复的更多信息,请参见pods和controllers。

Pods and Controllers

控制器可以为您创建和管理多个pod,处理复制和发布,并在集群范围内提供自我修复功能。例如,如果一个节点发生故障,控制器可能会通过在另一个节点上调度相同的替换来自动替换pod。

一些包含一个或多个pod的控制器示例包括:

一般来说,控制器使用您提供的pod模板来创建它负责的pod。

Pod Templates

Pod templates are pod specifications which are included in other objects, such as Replication Controllers, Jobs, and DaemonSets. 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规范,包含在其他对象(如复制控制器、作业和守护程序)中。控制器使用pod模板来制作实际的pod。下面的示例是一个包含打印消息的容器的pod的简单清单。

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模板不像cookiecutter那样指定所有副本的当前所需状态。一旦曲奇被切下,曲奇就与切割器没有关系。不存在“量子纠缠”。随后对模板的更改甚至切换到新模板对已经创建的pod没有直接影响。类似地,由复制控制器创建的pod随后可以直接更新。这与pods形成了有意的对比,pods确实指定了属于pod的所有容器的当前所需状态。这种方法从根本上简化了系统语义并增加了原语的灵活性。

What's next

Feedback

Was this page helpful?

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!