K8S—Pod详解

Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等控制器对象，用于暴露Pod应用的Service和Ingress对象，为Pod提供存储的PersistentVolume存储资源对象等。

1.2 为什么要使用Pod？Pod在K8S集群中的使用方式？

现代容器技术建议一个容器只运行一个进程，该进程在容器中PID命令空间中的进程号为1，可直接接收并处理信号，进程终止时容器生命周期也就结束了。若想在容器内运行多个进程，需要有一个类似Linux操作系统init进程的管控类进程，以树状结构完成多进程的生命周期管理。运行于各自容器内的进程无法直接完成网络通信，这是由于容器间的隔离机制导致，k8s中的Pod资源抽象正是解决此类问题：

多容器协同：有时候多个容器需要共享资源、网络空间等，这时候就可以将它们放在同一个 Pod 中，方便它们之间的协同工作。
生命周期管理：Pod 提供了统一的生命周期，当 Pod 中的所有容器都终止时，Pod 进程也将终止。这种生命周期的一致性有助于简化应用程序的管理。
共享网络：Pod 内的容器共享相同的网络命名空间，它们可以通过 localhost 直接通信，无需额外的配置。

Pod在K8S集群中有两种使用方式：

一个Pod中运行一个容器（最常见的用法）：一个Pod下的容器必须运行于同一节点上。
在一个Pod中同时运行多个容器：一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位，比如一个容器共享文件，另一个“sidecar”容器来更新这些文件，Pod将这些容器的存储资源作为一个实体来管理。

1.3 基础容器pause

Pod资源中针对各容器提供网络命令空间等共享机制的是底层基础容器pause。

基础容器（也可称为父容器）pause为了管理Pod容器间的共享操作，需要能够准确地知道如何去创建共享运行环境的容器，还能管理这些容器的生命周期。

pause容器有两个核心的功能：

首先，它作为Pod中所有其他容器共享的基础容器，提供了整个Pod的Linux命名空间。这意味着所有其他容器将与"pause"容器共享网络和存储等资源。

其次，"pause"容器在每个Pod中充当PID为1的init进程，并负责管理该Pod中的所有其他容器的进程。它会启用PID命名空间，并处理僵尸进程的回收。这确保了在Pod中的各个容器正常启动和停止，并提供了更好的进程隔离。

pause容器使得Pod中的所有容器可以共享两种资源：

网络：每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。
存储：Pod可以指定多个共享的Volume。Pod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

每个Pod都有一个特殊的被称为“基础容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或者多个紧密相关的用户应用容器。

二 Pod的分类

2.1 自主式Pod和控制器管理的Pod

自主式Pod ：通过手动创建 Pod 资源对象，将应用程序实例直接部署到 Kubernetes 集群中。这种方式不太灵活，因为 Pod 是直接部署到节点上的，一旦 Pod 所在的节点发生故障或者 Pod 本身出现问题，就需要手动介入来修复问题，这种Pod本身是不能自我修复的。
控制器管理的Pod：通过 Kubernetes 中的 Controller 抽象层来管理的，可以提供副本管理、滚动升级和集群级别的自愈能力。Controller 能够自动地管理多个 Pod 实例，对节点故障进行自动调度，并具有自我修复的能力。

2.2 容器的分类

2.2.1 基础容器（infrastructure container）

基础容器提供了 Kubernetes 集群所需的基础设施服务，比如网络、存储、监控等。它们通常不直接参与应用程序的运行，而是为整个集群提供支持和服务。

①负责维护整个 Pod 网络和存储空间；

②node 节点中操作；

③启动一个Pod时，k8s会自动启动一个基础容器。

2.2.2 初始化容器（initcontainers）

初始化容器用于在主应用容器启动之前执行特定的初始化任务，例如加载配置、初始化数据库等。它们可以确保在主应用容器启动之前完成必要的准备工作，使得应用容器能够顺利启动和运行。

Init 容器与普通的容器非常像，除了以下两点：
●Init 容器总是运行到成功完成为止。

●每个 Init 容器都必须在下一个 Init 容器启动之前成功完成启动和退出。如果 Pod 的 Init 容器失败，K8S不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的重启策略（restartPolicy）为 Never，它不会重新启动。

Init 的容器作用：
因为init容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：
●Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。

●Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

●应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

●Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。

●由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，
直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

2.2.3 应用容器（Maincontainer）

应用容器是 Kubernetes Pod 中运行实际应用程序的容器，如 Web 服务器、后端服务、数据库等。它们是构成应用程序的核心组件，负责提供实际的业务功能。

2.3 Pod容器案例

kubectl describe pod myapp-pod

#查看容器日志内容

#创建一个名为myservice的 Service 并查看 K8S集群中的 Pod 和 Service 的状态。

vim myservice.yaml

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

kubectl create -f myservice.yaml

#获取当前 K8S 集群中所有 Service 的状态和信息。

#获取 K8S 集群中所有运行在kube-system命名空间下的 Pod 的状态和信息和获取集群中所有 Pod 的状态和信息

vim mydb.yaml

apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

kubectl create -f mydb.yaml

kubectl get pods

注意：

●在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。
●如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略。
●在所有的Init容器没有成功之前，Pod将不会变成Ready状