kubernetes之Pod概述

kubernetes之Pod概述

Pod概述

什么是Pod

一个pod是Kubernetes应用最小，最简单的在创建或部署Kubernetes对象模型单元的基本执行单元。Pod表示在群集上运行的进程。

Pod封装了应用程序的容器（或在某些情况下为多个容器），存储资源，唯一的网络IP以及控制容器应如何运行的选项。Pod表示部署的单元：Kubernetes中应用程序的单个实例，可能由单个容器组成。或紧密耦合并共享资源的少量容器。

Docker是Kubernetes Pod中最常用的容器运行时，但Pods也支持其他容器运行时。

Kubernetes集群中的Pod可以通过两种主要方式使用：

运行单个容器的容器。“每个容器一个容器”模型是最常见的Kubernetes用例。在这种情况下，您可以将Pod视为单个容器的包装，而Kubernetes则直接管理Pod，而不是直接管理容器。运行多个需要协同工作的容器的Pod。Pod可能封装了一个应用程序，该应用程序由紧密关联且需要共享资源的多个同位容器组成。这些位于同一地点的容器可能形成一个统一的服务单元–一个容器将文件从共享卷提供给公众，而一个单独的“ sidecar”容器则刷新或更新这些文件。Pod将这些容器和存储资源包装在一起，成为一个可管理的实体。

每个Pod旨在运行给定应用程序的单个实例。如果要水平扩展应用程序（例如，运行多个实例），则应使用多个Pod，每个实例一个。在Kubernetes中，这通常称为复制。复制的Pod通常由称为Controller的抽象作为一个组创建和管理

Pods如何管理多个容器

Pod旨在支持形成协作服务单元的多个协作过程（作为容器）。Pod中的容器会自动位于同一群集中的同一物理或虚拟机上，并在同一位置进行调度。容器可以共享资源和依赖项，彼此通信，并协调何时以及如何终止它们。

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

某些Pod具有init容器以及应用程序容器。在启动应用程序容器之前，初始化容器会运行并完成。

Pod为它们的组成容器提供两种共享资源：网络和存储。

网络

每个Pod分配有一个唯一的IP地址。Pod中的每个容器都共享网络名称空间，包括IP地址和网络端口。Pod内的容器可以使用相互通信localhost。当Pod中的容器与Pod 外部的实体进行通信时，它们必须协调它们如何使用共享的网络资源（例如端口）。

存储

Pod可以指定一组共享存储。Volumes Pod中。Pod中的所有容器都可以访问共享卷，从而使这些容器可以共享数据。卷还允许Pod中的持久数据保留下来，以防其中的容器之一需要重新启动。

Working with Pods

您很少会直接在Kubernetes中创建单个Pod，甚至是单例Pod。这是因为Pod被设计为相对短暂的一次性实体。当创建Pod（由您直接或由控制器间接创建）时，它被安排在节点上运行。在您的集群中。Pod会保留在该节点上，直到进程终止，删除Pod对象，由于缺少资源而将Pod 逐出或节点发生故障为止。

注意：不要将重新启动Pod中的容器与重新启动Pod混淆。Pod本身不会运行，而是容器在其中运行并一直存在直到被删除的环境。

pod本身无法自我修复。如果将Pod调度到发生故障的节点，或者调度操作本身失败，则将Pod删除；否则，该Pod将被删除。同样，由于缺乏资源或Node维护，Pod无法幸免。Kubernetes使用称为Controller的更高级别的抽象来处理管理相对易用的Pod实例的工作。因此，虽然可以直接使用Pod，但在Kubernetes中使用Controller管理您的Pod更为常见。

Pod和Controller

Controller可以为您创建和管理多个Pod，以处理复制和部署，并在集群范围内提供自我修复功能。例如，如果某个节点发生故障，则控制器可能会通过在另一个节点上安排相同的替换操作来自动替换Pod。

包含一个或多个pod的Controller的一些示例包括：

DeploymentStatefulSetDaemonSet

通常，控制器使用您提供的Pod模板创建负责的Pod。

Pod模板

Pod模板是Pod规范，包含在其他对象中，如 Replication Controllers，Jobs和 DaemonSets。控制器使用Pod模板制作实际的Pod。下面的示例是一个Pod的简单清单，其中包含一个打印消息的容器。

apiVersion: v1kind: Podmetadata: name: myapp-pod labels: app: myappspec: containers: - name: myapp-container image: busybox    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Pod模板没有指定所有副本的当前期望状态，而是像Cookie切割器一样。一旦Cookie被切割，该Cookie就与切割器无关。没有“量子纠缠”。模板的后续更改，甚至切换到新模板，对已创建的容器没有直接影响。类似地，复制控制器创建的Pod随后可以直接更新。这与pod形成了鲜明的对比，pod确实指定了属于pod的所有容器的当前期望状态。这种方法从根本上简化了系统语义并增加了原语的灵活性。