7.Kubernetes Pod深度解析-优快云博客

本文链接：https://blog.youkuaiyun.com/lml4856/article/details/149028701

一：什么是Pod

Pod 是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在 Pod 中，所有容器都被统一安排和调度。对于具体应用而言，Pod 是它们的逻辑主机，Pod 包含业务相关的多个应用容器。所以，Pod 是一组具有共享命名空间、IP地址和端口的容器的集合。

1：从使用角度来看

在实际的使用时,单个容器是无法单独来支撑我们的应用的,往往需要很多微服务才能组成一个系统,并且还会存在A服务依赖B服务，B服务需要和C服务共用某个目录。另外，在使用裸容器时，很难实现对容器内进行健康检査以及横向扩容等操作，而 Pod 可以轻松解决这些问题。

2：从kubernetes的角度来看

Docker 只是容器 Runtime(运行时)的一种们还有很多容器 Runtime，比如 Rkt、CRI-0等，而
Kubernetes 作为目前最流行的容器编排工具，需要支持各个 Runtime 并且不依赖于底层 Runtime 的实现技术，于是就抽象出了 Pod 这个概念，用于管理多个紧密相连的符合 CRI 标准的容器

Pod 可以简单的理解为一组、一个或多个容器，每个Pod 还包含一个 Pause 容器，Pause 容器是 Poc的父容器，主要负责僵尸进程的回收管理。同时，通过Pause 容器可以使同一个 Pod 里面的不同容器其享存储、网络、PID、IPC(进程间通信)等，容器之间可以使用 Localhost:Port 的方式相互访问，可以使用 volume 实现数据共享。根据 Docker 的构造，Pod 可以被创建为一组具有共享命名空间、IP 地址和端口的容器。

Pod有两个必须知道的特点：

网络：每个Pod都会被指派一个唯一的IP地址，在Pod中的每一个容器共享命名空间，包括IP地址和网络接口。在同一个Pod中的容器可以同localhsot进行互通通信。当Pod中的容器需要与POd外的实体进行通信时，则需要通过端口等共享的网络资源。

存储：Pod能够被指定共享存储卷的集合，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启

3：Pod的状态

（1）kubectl命令创建pod

kubectl run nginx --image-nginx:1.7.9 --labels="app=nginx"

(2)查看pod

kubectl get pods -n default

（3）显示pod的更多信息

kubectl get pod nginx -o wide

（4）查看pod日志

curl 10.244.58.195

kubectl logs nginx

（5）以yaml格式显示pod详细信息

kubectl get pod nginx -o yaml

（6）显示资源的详细描述信息

kubectl describe pod nginx

备注：

kubectl get：常用于查看同一资源类型的一个或多个资源对象，可以使用-o参数自定义输出格式。

kubectl describe：侧重描述指定资源的各方面的详细信息，不仅会返回节点信息，还会返回在其上运行的pod的摘要、节点事件等信息

（7）在pod的容器中执行命令

Kubectl exec nginx -c nginx -- date

备注：-c 指定pod中容器的名字

（8）登录到pod中的容器中

kubectl exec -it nginx -c nginx -- bash

备注：kubectl exec -it nginx -- bash

如果登陆的时候不指定容器，就登录到pod中的第一个容器中

（9）在线编辑运行中的资源对象

kubectl edit pod nginx

（10）将pod的端口映射到宿主机

kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80

其他主机访问测试：curl 192.168.10.101:8080

（11）在宿主机和pod的容器之间拷贝文件

kubectl cp nginx:etc/fstab /opt/aaa.txt

kubectl co /opt/aaa.txt nginx:etc/bbb.txt

（12）pod的状态

kubectl get pods -n default

pod状态字段phase的不同取值：

pending（挂起）：Pod 已经被 Kubernetes 系统接收，但是仍有一个或多个容器未被创建，可以通过 kubectl describe 查看处于Pending 状态的原因。

Running（运行中）：Pod 已经被绑定到一个节点上，并且所有的容器都已经被创建，而且至少有一个是运行的状态、正在启动或者重启，可以通过 kubectl logs 査看 Pod 的日志。

Succeeded（成功）：所有容器执行成功，并终止，并且不会再次重启，可以通过kubectl logs 査看 Pod 的日志

Failed（失败）：所有容器都已终止，并且至少一个容器以失败的方式终止也就是说这个容器要么以非零状态退出，要么被系统终止可以通过 logs 和 describe 査看 Pod 的日志和状态

Unknown（未知）：通常是由于通信问题造成的无法获得 Pod 的状态

ImagePullBackOff
ErrImagePul：镜像拉取失败，一般是由于镜像不存在、网络不通或者需要登录认证引起的，可以使用 describe 命令查看具体的原因

CrashLoopBackOff：容器启动失败，可以通过 logs 命令查看具体的原因，一般为启动命令不正确、健康检查不通过等原因

OOMKilled：容器内存溢出，一般是容器的内存 Limit 设置的过小，或者程序本身有内存溢出，可以通过 logs 查看程序的启动日志

Terminating：Pod 正在被删除，可以通过 describe 查看状态

SysctlForbiden：Pod 自定义了内核配置，但 kubect1 没有添加内核配置或配置的内核参数不支持，可以通过 describe 查看具体原因

Completed：容器内部主进程退出，一般计划任务执行结束会显示该该状态，此时可以通过 logs 查看容器日志

Containercreating：Pod 正在创建,一般正在下载镜像,或者有配置不当的地方,可以通过 describe 查看具体原因

（13）删除pod

kubectl delete pod nginx

二：pod探针

生产环境中，进程正常启动并不代表应用能正常处理请求，所以合理的设计应用的健康检查尤其重要。在使用裸机容器部署时，一般很难对应用做很完善的健康检查，而pod提供的探针可以很方便的用来检测容器的应用是否正常

1：Pod探针的实现方式

ExecAction：在容器内执行一个指令的命令，如果命令返回值为0，则认为容器健康

TCPSocketAction：通过TCP连接检查指定的端口，如果端口开放，则认为容器健康

HTTPGetAction：对指定的URL进行get请求，如果状态码在200~400之间，则认为容器健康

2：容器状态

Success：容器通过检查

Failure;容器检查失败

Unknown：诊断失败，因此不采取任何措施

3：pod探针类型

（1）livenessProbe（存活探针）

它被用来知道一个容器是否在正常运行。如果容器未能通过存活探针的检查，则系统会认为该容器已经进入了一个必须被重启的状态，从而自动重启这个容器。这种机制可以确保容器在出现问题后能够自动恢复到可用状态。
存活探针支持以下几种类型:
HTTP GET 请求 - 通过发送 HTTP 请求到容器内的某个 URL 来检测容器是否处于健康状态。

Exec执行命令 -在容器内执行一个自定义命令或可执行文件，并根据其退出码判断容器是否健康。TCP Socket - 尝试打开一个 TCP socket 连接到容器上的指定端口，如果连接成功则认为容器是健康的。

（2）readinessProbe（就绪探针）

判断容器是否能够进入 ready 状态，用于确定 Pod 中的容器是否已准备好接收流量。与livenessProbe 不同,readinessProbe 主要关注的是容器是否已经准备好为服务提供者处理请求。如果容器没有通过就绪探针的检査，Kubernetes 将不会把任何新的网络流量路由到这个容器上。
当一个容器报告自己尚未准备好时，Kubernetes可能会采取以下行动:

a.服务(Service)不会将流量路由到未准备好的 Pod。
b.如果 Pod 是副本集(Replicaset)、部署(Deployment)、状态集(statefulset)等的一部分,控制器会认为这个实例不可用。
c.对于使用 Pod 的滚动更新策略的情况,就绪探针可以帮助确保新版本的 Pod 在旧版本被终止之前就已经准备好了

就像 livenessProbe 一样，readinessProbe 也支持多种类型的探测方法:
HTTP GET 请求 - 发送 HTTP 请求到容器内的某个 URL。
Exec执行命令 -在容器内执行一个自定义命令或可执行文件。
TCP Socket - 尝试建立一个到容器上的指定端口的 TCP 连接。

（3）startupProbe(启动探针)

判断容器内的应用是否启动成功，在 success 状态前，其它探针都处于无效状态。它专门用于检测容器是否完成了初始化并进入了预期的运行状态。与1ivenessProbe(存活探针)和 readinessProbe(就绪探针)不同，startupProbe 专注于容器启动阶段，并且仅在容器启动过程中使用。
startupProbe 的主要作用是在容器启动期间持续检査容器是否已经完成启动。一旦容器通过了startupProbe 的检査，Kubernetes 就会认为容器已经成功启动，并停止对该容器的启动探针检査。如果容器始终无法通过启动探针的检査，那么 Kubernetes 将会根据配置重试一定的次数，超过重试次数后可能会采取进一步的措施，如重启容器。

三：pod镜像拉取策略和重启策略

1：镜像拉取策略

在发布应用或者更改控制器配置时,会触发 Pod 的滚动更新,此时针对容器的镜像有不同的拉取方式。

操作方式	说明
Always	总是拉取，无论镜像是否存在，总是拉取
Never	无论是否存在都不会拉取
IfNotPressent	镜像不存在时拉取镜像,是 k8s 默认的策略但是如果 tag为latest，则总是拉取

指定拉取策略

kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --image-pull-policy=Never

2：pod重启策略

在 Kubernetes 中，Pod 的重启策略(Restart Policy)定义了当容器退出或失败时，kubelet 如何处理容器。重启策略是 Pod 级别的配置，适用于Pod 中的所有容器。
在 Always 策略中，只要容器退出(无论退出码是什么)，kubelet 都会自动重启容器。适用于需要
持续运行的服务(如 Web 服务器、数据库等)。在 onFailure 策略中，只有当容器以非零退出码退出时，kubelet 才会重启容器，如果容器正常退出(退出码为 8)，则不会重启。适用于任务型 Pod(如批处理任务)，任务完成后不需要重启。在 Never 策略中，无论容器以何种方式退出，kubelet 都不会重启容器。适用于一次性任务，任务完成后不需要重启。

操作方式	说明
Always	容器退出即重启，适用于长期运行的服务
OnFailure	容器失败时重启，适用于任务型工作负载
Never	容器退出后不重启，适用于一次性任务。

指定重启策略:

kubectl delete pod nginx

kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --restart=OnFailure

四：编写pod

在Kubernetes（K8s）中，Pod是最小的部署单元，用于封装容器应用。以下是Pod配置文件的核心知识点，帮助你快速理解其结构和关键选项：

一、Pod文件基础结构

1. 格式与核心字段

◦ 基于YAML格式，通常包含apiVersion、kind、metadata、spec四大核心字段。

◦ 示例：
apiVersion: v1 # API版本
kind: Pod # 资源类型为Pod
metadata:
name: my-pod # Pod名称
labels:
app: my-app # 标签，用于筛选资源
spec:
containers:
- name: my-container # 容器名称
image: nginx:latest # 容器镜像
ports:
- containerPort: 80 # 容器端口
2. 多容器Pod

◦ 一个Pod可包含多个容器（如主容器+辅助容器），共享网络和存储，适用于紧密耦合的应用场景。

二、关键字段及选项含义

1. metadata（元数据）

• name：Pod的唯一名称，同一命名空间内不可重复。

• labels：键值对标签，用于Selector筛选（如app: my-app）。

• namespace：所属命名空间，默认default，可通过metadata.namespace指定。

2. spec（规格）

▶ 容器配置（containers）

• image：容器镜像地址（如nginx:latest或私有仓库镜像）。

• imagePullPolicy：镜像拉取策略：

◦ Always：每次都拉取最新镜像（默认，适用于开发）。

◦ IfNotPresent：本地有则使用，无则拉取（适用于生产）。

◦ Never：仅使用本地镜像，不拉取（很少用）。

• ports：容器暴露的端口，需指定containerPort（如80），可选hostPort（映射到节点端口，不推荐直接使用）。

• resources：资源限制与请求：
resources:
requests:
cpu: "100m" # 请求0.1个CPU核心
memory: "128Mi" # 请求128MB内存
limits:
cpu: "200m" # 最大0.2个CPU核心
memory: "256Mi" # 最大256MB内存
• livenessProbe/readinessProbe：存活/就绪探针，用于检测容器状态：
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5 # 启动5秒后开始检测
periodSeconds: 10 # 每10秒检测一次
▶ Pod级配置

• restartPolicy：重启策略（Pod内容器失败时的行为）：

◦ Always：总是重启（默认）。

◦ OnFailure：仅容器失败时重启。

◦ Never：不重启。

• nodeSelector：节点选择器，指定Pod调度到符合标签的节点：
nodeSelector:
disk-type: ssd # 调度到标签为disk-type=ssd的节点
• affinity/anti-affinity：亲和性调度（高级功能）：

◦ nodeAffinity：偏好调度到特定节点。

◦ podAffinity：偏好与其他Pod部署在同一节点/区域。

◦ podAntiAffinity：避免与其他Pod部署在一起。

• volumes：存储卷，Pod内容器共享存储：
volumes:
- name: my-volume
hostPath:
path: /data # 挂载节点本地路径
3. status（状态）

• 由K8s自动生成，包含Pod的运行状态、IP、容器状态等，无需手动配置。

三、常用场景配置示例

1. 简单单容器Pod

apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.23
ports: - containerPort: 80

2. 带存储卷的Pod

apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: my-app:v1
volumeMounts:
- name: data-volume
mountPath: /app/data # 容器内挂载路径
volumes:
- name: data-volume
persistentVolumeClaim:
claimName: my-pvc # 关联PVC存储