Kubernetes 学习笔记之Pods（上）

原创已于 2022-02-18 17:01:43 修改

· 685 阅读

0 ·

版权

文章标签：

#kubernetes #docker #容器

于 2022-02-16 10:35:49 首次发布

K8S 专栏收录该内容

11 篇文章

订阅专栏

本文详细介绍了Kubernetes中的Pods，作为最小可部署单元，Pod包含多个共享IPC、Network和UTC namespace的容器，能直接通过localhost通信。Pod提供优雅终止、资源限制、健康检查等功能，并通过控制器如Deployment、StatefulSet、DaemonSet等进行管理。Pod模板用于创建和管理Pod，而Pod更新通常涉及创建新的Pod对象而非直接修改。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Pods

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

官方文档

什么是Pod

官方定义:
Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，即用来隔离 Docker 容器的技术。在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。

Pod是一组紧密关联的容器集合，支持多个容器在一个Pod中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式完成服务，是Kubernetes调度的基本单位。Pod的设计理念是每个Pod都有一个唯一的IP。

Pod的特点

包含多个共享IPC、Network和UTC namespace的容器，可直接通过localhost通信.每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。 Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。 Pod 内的容器可以使用 localhost 互相通信。当 Pod 中的容器与 Pod 之外的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 localhost 发现对方。他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。不同 Pod 中的容器的 IP 地址互不相同，没有特殊配置就不能使用 IPC 进行通信。如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。Pod 中的容器所看到的系统主机名与为 Pod 配置的 name 属性值相同。网络部分提供了更多有关此内容的信息。

Pod 中的容器所看到的系统主机名与为 Pod 配置的 name 属性值相同。网络部分提供了更多有关此内容的信息。

所有Pod内容器都可以访问共享的Volume，可以访问共享数据，共享网络
优雅终止:Pod删除的时候先给其内的进程发送SIGTERM，等待一段时间(grace period)后才强制停止依然还在运行的进程
特权容器(通过SecurityContext配置)具有改变系统配置的权限(在网络插件中大量应用)
支持三种重启策略（restartPolicy），分别是：Always、OnFailure、Never
支持三种镜像拉取策略（imagePullPolicy），分别是：Always、Never、IfNotPresent
资源限制，Kubernetes通过CGroup限制容器的CPU以及内存等资源，可以设置request以及limit值
健康检查，提供两种健康检查探针，分别是livenessProbe和redinessProbe，前者用于探测容器是否存活，如果探测失败，则根据重启策略进行重启操作，后者用于检查容器状态是否正常，如果检查容器状态不正常，则请求不会到达该Pod
Init container在所有容器运行之前执行，常用来初始化配置
容器生命周期钩子函数，用于监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数，支持两种钩子函数：postStart和preStop，前者是在容器启动后执行，后者是在容器停止前执行

使用Pod

Kubenetes集群中的Pod主要有两种用法

运行单个容器的Pod. 每个Pod一个容器是最常见的使用方法。Pod是容器的运行环境，Kubenetes直接管理Pod，而非是容器
运行多个容器的Pod. Pod可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。一般只有特定场景会使用这种方法。

PS：每个Pod都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序，则应使用多个Pod。在Kubernetes中，这通常称之为副本(Replication)。通常使用工作负载及其控制器来创建和管理一组Pod

Pod和控制器

可以使用工作负载资源来创建和管理多个 Pod。资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作，就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行。

下面是一些管理一个或者多个 Pod 的工作负载资源的示例：

Deployment 管理应用副本的API对象
StatefulSet 管理Pod集合的部署和扩缩，并为这此Pod提供持久存储和标识符
DaemonSet 确认Pod的副本在集群中的一组节点上运行

Pod模版

负载资源的控制器通常使用 Pod 模板（Pod Template）来替你创建 Pod 并管理它们。

Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括 Deployment、 Job 和 DaemonSets等。

工作负载的控制器会使用负载对象中的 PodTemplate 来生成实际的 Pod。 PodTemplate 是你用来运行应用时指定的负载资源的目标状态的一部分。
下面的示例是一个简单的 Job 的清单，其中的 template 指示启动一个容器。该 Pod 中的容器会打印一条消息之后暂停。

apiVersion: batch/v1						#api版本
kind: Job                                         #类别
metadata:                                        # 元数据
  name: hello                                    #key:value
spec:                                                #匹配
  template:                                        #模版
    # 这里是 Pod 模版
    spec:                                           #匹配
      containers:                                #容器
      - name: hello                             #key:value
        image: busybox                       #镜像
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure             #拉起策略
    # 以上为 Pod 模版

Pod 更新与替换

某工作负载的 Pod 模板被改变时，控制器会基于更新的模板创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。

Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作还是可能的。不过，类似 patch 和 replace 这类更新操作有一些限制：

Pod 的绝大多数元数据都是不可变的。例如，你不可以改变其 namespace、name、 uid 或者 creationTimestamp 字段；generation 字段是比较特别的，如果更新该字段，只能增加字段取值而不能减少。
如果 metadata.deletionTimestamp 已经被设置，则不可以向 metadata.finalizers 列表中添加新的条目。
Pod 更新不可以改变除 spec.containers[].image、spec.initContainers[].image、 spec.activeDeadlineSeconds 或 - spec.tolerations 之外的字段。对于 spec.tolerations，你只被允许添加新的条目到其中。
在更新spec.activeDeadlineSeconds 字段时，以下两种更新操作是被允许的：
1. 如果该字段尚未设置，可以将其设置为一个正数；
2. 如果该字段已经设置为一个正数，可以将其设置为一个更小的、非负的整数。