前言

在Kubernetes中，Pod是最小的管理单元，它是容器化应用的逻辑主机，由一个或多个紧密相关的容器组成。与直接管理容器不同，Kubernetes通过Pod来组织和管理容器，这是因为在实际应用中，单个容器往往无法独立支撑复杂的业务需求。多个容器可能需要共享存储、网络和命名空间，或者相互依赖以完成特定的任务。Pod的设计使得这些容器能够作为一个整体被调度和管理，从而简化了应用的部署和运维。

Pod不仅解决了容器之间的依赖和资源共享问题，还提供了健康检查、自动重启、横向扩容等功能，极大地增强了应用的可靠性和可扩展性。Kubernetes通过Pod抽象了底层容器运行时（如Docker、containerd）的差异，使得用户可以在不同的运行时环境中无缝迁移和管理应用。

本章将深入探讨Pod的核心概念、使用方式以及相关的技术细节，包括Pod的探针机制、镜像拉取策略、重启策略、启动过程和运行状态等。此外，我们还将介绍如何通过静态Pod在节点上运行特定的应用，并提供详细的故障排除步骤，帮助读者解决Pod启动和运行中的常见问题。通过本章的学习，读者将能够更好地理解和使用Kubernetes中的Pod，从而更高效地管理和运维容器化应用。

一: 什么是Pod

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

1: 从使用的角度来看

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

2: 从Kubernetes的角度来看

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

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

3: Pod的状态

（1）kubectl命令创建pod

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

（2）查看pod

kubectl get pods -n default

NAME                                  READY   STATUS             RESTARTS   AGE
nginx                              1/1     Running            0          86s

（3）显示Pod的更多信息

kubectl get pod nginx -o wide

NAME    READY   STATUS             RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
nginx   0/1     ImagePullBackOff   0          16m   10.244.140.71   node02   <none>           <none>

（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
Forwarding from 0.0.0.0:8080 -> 80

其他主机访问测试：

curl 192.168.10.101:8080

注意： 此命令会在前台运行，此时就可以在其他客户端用该k8s主机的IP地址和8080的端口号进行访问了，Ctrl+c停止，但停止后就没有这个映射了。

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

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

（12）Pod的状态

kubectl get pods -n default

NAME                                  READY   STATUS             RESTARTS   AGE
nginx                              1/1     Running            0          86s

可以看到此时的Pod的状态是Running，Pod的状态不仅仅只有Running，常见的其他状态如表1所示：

表1：Pod状态字段Phase（阶段）的不同取值

（13）删除Pod

kubectl delete pod nginx

二: Pod探针

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

1: Pod探针的实现方式

目前探针有3种检测方式，可以根据不同的场景选择合适的健康检查方式，分别是ExecAction、TCPSocketAction和HTTPGetAction。具体实现方式如表2所示。

表2：Pod探针的实现方式

2: 容器状态

上述的检查方式可以被周期性的执行，每次检查容器后可能得到的容器状态如表3所示。

表3：Pod探针检查容器后可能得到的状态

3: Pod探针类型

Pod探针有三类，分别是：livenessProbe（存活探针）、readinessProbe（就绪探针）、startupProbe（启动探针）。

（1）livenessProbe（存活探针）

它被用来知道一个容器是否在正常运行。如果容器未能通过存活探针的检查，则系统会认为该容器已经进入了一个必须被重启的状态，从而自动重启这个容器。这种机制可以确保容器在出现问题后能够自动恢复到可用状态。

存活探针支持以下几种类型：

• HTTP GET请求 - 通过发送HTTP请求到容器内的某个URL来检测容器是否处于健康状态。
• Exec执行命令 - 在容器内执行一个自定义命令或可执行文件，并根据其退出码判断容器是否健康。
• TCP Socket - 尝试打开一个TCP socket连接到容器上的指定端口，如果连接成功则认为容器是健康的。

（2）readinessProbe（就绪探针）

判断容器是否能够进入ready状态，用于确定Pod中的容器是否已准备好接收流量。与livenessProbe不同，readinessProbe主要关注的是容器是否已经准备好为服务提供者处理请求。如果容器没有通过就绪探针的检查，Kubernetes将不会把任何新的网络流量路由到这个容器上。

当一个容器报告自己尚未准备好时，Kubernetes可能会采取以下行动：

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

就像livenessProbe一样，readinessProbe也支持多种类型的探测方法：

• HTTP GET请求 - 发送HTTP请求到容器内的某个URL。
• Exec执行命令 - 在容器内执行一个自定义命令或可执行文件。
• TCP Socket - 尝试建立一个到容器上的指定端口的TCP连接。

（3）startupProbe（启动探针）

判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态。它专门用于检测容器是否完成了初始化并进入了预期的运行状态。与livenessProbe（存活探针）和readinessProbe（就绪探针）不同，startupProbe专注于容器启动阶段，并且仅在容器启动过程中使用。

startupProbe的主要作用是在容器启动期间持续检查容器是否已经完成启动。一旦容器通过了startupProbe的检查，Kubernetes就会认为容器已经成功启动，并停止对该容器的启动探针检查。如果容器始终无法通过启动探针的检查，那么Kubernetes将会根据配置重试一定的次数，超过重试次数后可能会采取进一步的措施，如重启容器。

三: Pod镜像拉取策略和重启策略

1: 镜像拉取策略

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

表4：镜像拉取策略

指定拉取策略：

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才会重启容器，如果容器正常退出（退出码为0），则不会重启。适用于任务型Pod（如批处理任务），任务完成后不需要重启。

在Never策略中，无论容器以何种方式退出，kubelet都不会重启容器。适用于一次性任务，任务完成后不需要重启。

各个策略的简要说明如表5。

表5：Pod重启策略

指定重启策略：

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

四: 创建一个简单的Pod

1: 编写一个简单的Pod

vim nginx - pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

2: 编写Pod配置文件frontend - localredis - pod.yaml

cat <<EOF>frontend-localredis-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis-php
  labels:
    name: redis-php
spec:
  containers:
  - name: frontend
    image: kubeguide/guestbook-php-frontend:localredis
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    ports:
    - containerPort: 80
  - name: redis
    image: kubeguide/redis-master
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
  restartPolicy: OnFailure
EOF

备注

• apiVersion: v1 # 必选，版本号
• kind: Pod # 必选，资源类型
• metadata# 必选，元数据

• name: redis-php # 必选，Pod名称
• labels# 自定义的pod标签列表

• name: redis-php # 标签值

• spec# 必选，Pod中容器的详细信息

• containers# 必选，Pod中的容器列表

• - name: frontend# 必选，自定义的容器名称

• image: kubeguide/guestbook-php-frontend:localredis # 必选，容器的镜像名称
• imagePullPolicy: IfNotPresent # 镜像拉取策略
• livenessProbe# 设置存活探针

• tcpSocket# 测试某端口是否可以连接

• port: 80 # 指定要测试的端口
• initialDelaySeconds: 1 # 指定kubelet在执行第一次探测前应该等待1秒，即第一次探测是在容器启动后的第2秒才开始执行。默认是0秒，最小值是0
• periodSeconds: 3 # 指定了kubelet应该每3秒执行一次存活探测。默认是10秒。最小值是1
• timeoutSeconds: 1 # 当探测失败时，Kubernetes在超时之前等待的时间。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃Pod会被打上未就绪的标签。默认值是3。最小值是1

• ports# 需要暴露的端口号列表

• - containerPort: 80 # 容器需要监听的端口号

• - name: redis# 另一个容器的名字

• image: kubeguide/redis-master # 另一个容器的镜像
• ports# 需要暴露的另一个容器的端口列表

• - containerPort: 6379 # 容器需要监听的端口号

• restartPolicy: OnFailure # 重启策略

3: Pod文件语法

（1）Pod文件的一级属性

一级属性主要包含5部分：

• apiVersion <string> 版本，由kubernetes内部定义，版本号必须可以用kubectl api-versions查询到
• kind <string> 类型，由kubernetes内部定义，版本号必须可以用kubectl api-resources查询到
• metadata <Object> 元数据，主要是资源标识和说明，常用的有name、namespace、labels等
• spec <Object> 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
• status <Object> 状态信息，里面的内容不需要定义，由kubernetes自动生成

（2）spec（规格）属性

在一级属性中，spec是研究的重点，它的常见子属性有：

• containers <[]Object> 容器列表，用于定义容器的详细信息
• nodeName <String> 根据nodeName的值将pod调度到指定的Node节点上
• nodeSelector <map[]> 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上
• hostNetwork <boolean> 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
• volumes <[]Object> 存储卷，用于定义Pod上面挂在的存储信息
• restartPolicy<string> 重启策略，表示Pod在遇到故障的时候的处理策略

（3）通过kubectl explain命令来查看每种资源的可配置项

kubectl explain pod
kubectl explain deployment
kubectl explain service
kubectl explain pod.metadata
kubectl explain pod.spec.containers

4: 运行kubectl create命令创建此Pod

kubectl create -f nginx - pod.yaml
kubectl create -f frontend - localredis - pod.yaml

5: 查看已经创建的Pod

kubectl get pods

NAME                                  READY   STATUS             RESTARTS   AGE
nginx                              1/1     Running            0          86s
redis-php	                         2/2     Running						0					 31s

6: 查看pod详细创建信息

kubectl describe pod redis-php

7: 删除pod

kubectl delete -f frontend - localredis - pod.yaml

五: Pod的基本用法

1: 编写pod文件，将两个容器放在同一个pod中

cat <<EOF>nginx - php.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-php
  labels:
    name: nginx-php
spec:
  containers:
  - name: nginx-app
    image: nginx:1.7.9
    ports:
    - containerPort: 80
  - name: php-app
    image: bitnami/php-fpm
    imagePullPolicy: Never
    ports:
    - containerPort: 9000
EOF

2: 部署nginx的pod文件

kubectl apply -f nginx - php.yaml
kubectl get pods

NAME                                  READY   STATUS             RESTARTS   AGE
nginx-php	                         2/2     Running						0					 31s

备注

此时可以看到pod中有两个容器处于running状态中

3: 查看pod的详细信息

kubectl describe pod nginx - php

4: 暴露端口

kubectl expose pod nginx - php --port=8080 --target - port=80 --type=NodePort --name=nginx - php

5: 查看端口映射

kubectl get pod,service nginx - php -o wide

6: 测试访问

用外部主机，访问master的ip地址：映射的端口

http://192.168.10.101:32598/

7: 删除pod

kubectl delete -f nginx - php.yaml

六: 静态pod

静态Pod是由kubelet进行管理的仅存在于各个Node上的Pod。它们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对它们进行健康检查。静态Pod总是由kubelet创建的，并总在kubelet所在的Node上运行。

1: 编写yaml文件

cat <<EOF>/etc/kubernetes/manifests/nginx - pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    name: static-web
spec:
  containers:
  - name: static-web
    image: nginx:1.7.9
    ports:
    - name: nginx
      containerPort: 80
EOF

2: 不需执行部署命令，过一会，查看pod

kubectl get pod

3: 删除静态pod的方法

rm -rf /etc/kubernetes/manifests/nginx - pod.yaml

备注： 不能用如下语句删除

kubectl delete pod static-web-k8s-master01

这样删除，会让pod处于pending状态，但无法删除

七: Pod启动过程与运行状态

Pod创建完之后，一直到持久运行起来，中间有很多步骤，也就有很多出错的可能，因此会有很多不同的状态。

在Pod的启动过程中，会涉及到多个关键组件，保证Pod能够顺利的启动完成，这些关键组件和作用如下所示：

• API Server：接收和处理Pod创建请求。
• etcd：存储集群状态和Pod定义。
• Scheduler：将Pod调度到合适的节点。
• kubelet：在节点上管理Pod的生命周期。
• 容器运行时：负责容器的创建和运行。

通过这些步骤，Kubernetes确保Pod能够按照预期启动并运行。

1: pod的启动过程包含的步骤

Pod的启动过程是Kubernetes中一个关键的操作，涉及多个步骤和组件协同工作。以下是Pod启动的主要过程：

（1）用户提交Pod定义 用户通过kubectl或其他工具提交Pod的YAML或JSON定义文件到Kubernetes API Server。

（2）API Server接收请求 API Server接收到Pod创建请求后，会进行身份验证和授权检查，确保请求合法。 通过检查后，API Server将Pod的定义信息存储到etcd中。

（3）Scheduler调度Pod Scheduler监控API Server，发现有待调度的Pod。 Scheduler根据Pod的资源需求、节点亲和性、污点容忍等策略，选择一个合适的节点。 Scheduler将Pod与节点绑定，并将绑定信息更新到etcd。

（4）kubelet创建Pod 目标节点上的kubelet监控API Server，发现有新的Pod被调度到本节点。 kubelet根据Pod定义，调用容器运行时（如Docker、containerd）创建容器。 kubelet还会为Pod设置网络（通过CNI插件）和存储卷（如emptyDir、hostPath或持久卷）。

（5）容器运行时启动容器 容器运行时根据kubelet的指令，拉取镜像（如果本地没有）并启动容器。 容器启动后，运行时向kubelet报告容器状态。

（6）kubelet更新Pod状态 kubelet监控容器的运行状态，并将Pod的状态更新到API Server。 API Server将状态信息存储到etcd。

（7）Pod进入运行状态 当所有容器成功启动并运行后，Pod进入Running状态。 如果容器启动失败，kubelet会根据重启策略（如Always、OnFailure）决定是否重启容器。

（8）探针检查（可选） 如果Pod定义了存活探针（Liveness Probe）或就绪探针（Readiness Probe），kubelet会定期执行这些探针。 探针检查失败可能导致容器重启或Pod从服务端点移除。

（9）Pod可用 当Pod的所有容器正常运行并通过就绪探针检查后，Pod被视为可用，可以接收流量或执行任务。

（10）持续监控 kubelet持续监控Pod的状态，确保其健康运行。 如果Pod或容器出现问题，kubelet会根据配置采取相应措施（如重启容器）。

2: Pod的运行状态

（1）Pending 表示APIServer创建了Pod资源对象并已经存入了etcd中，但是它并未被调度完成（比如还没有调度到某台node上），或者仍然处于从仓库下载镜像的过程中

（2）Running Pod已经被调度到某节点之上，并且Pod中所有容器都已经被kubelet创建。至少有一个容器正在运行，或者正处于启动或者重启状态（也就是说Running状态下的Pod不一定能被正常访问）。

（3）Succeeded 有些pod不是长久运行的，比如job、cronjob，一段时间后Pod中的所有容器都被成功终止，并且不会再重启。需要反馈任务执行的结果。

（4）Failed Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止，比如command写的有问题。

（5）Unknown 表示无法读取Pod状态，通常是kube - controller - manager无法与Pod通信 。

八: 故障排除步骤

当一个Pod无法正常启动时，可能是由于多种原因导致的。以下是故障排除的详细步骤，帮助你定位和解决问题。

1: 查看Pod事状态

kubectl logs <pod - name> -n <namespace>

2: 查看Pod日志（Failed状态下）

kubectl logs <pod - name> -n <namespace>

如果Pod中有多个容器，使用 -c 指定容器名称：

kubectl logs <pod - name> -n <namespace> -c <container - name>

如果容器不断重启，可以查看上一次崩溃的日志：

kubectl logs <pod - name> -n <namespace> --previous

3: Pod处于Pending状态

可能原因：

• 资源不足（CPU、内存）。
• 没有可用节点满足调度条件（如节点亲和性、污点容忍）。
• 持久卷声明（PVC）未绑定。

排查方法：

• 检查节点资源：kubectl describe node <node - name>
• 检查PVC状态：kubectl get pvc -n <namespace>
• 查看调度器日志（如果启用了调度器日志）。
• 检查节点资源是否充足（CPU、内存）。
• 检查节点是否有污点（Taint）导致Pod无法调度。
• 检查节点是否处于NotReady状态。

4: Pod处于ImagePullBackOff状态

可能原因：

• 镜像名称错误或镜像不存在。
• 私有镜像未配置正确的镜像拉取密钥（imagePullSecrets）。
• 镜像仓库不可访问（网络问题或认证失败）。

排查方法：

• 检查镜像名称和标签是否正确。
• 确保imagePullSecrets配置正确。
• 手动尝试拉取镜像：docker pull <image - name>。

5: Pod处于CrashLoopBackOff状态

可能原因：

• 容器启动后立即崩溃（应用程序错误、配置错误）。
• 资源限制过低（如内存不足导致OOM）。
• 依赖服务未就绪。

排查方法：

• 查看容器日志。
• 检查资源限制：kubectl describe pod <pod - name> -n <namespace>
• 检查应用程序配置和依赖服务。

6: Pod处于ErrImagePull状态

可能原因：

• 镜像拉取失败（镜像不存在或权限问题）。

排查方法：

• 检查镜像名称和权限。
• 确保镜像仓库可访问。

7: Pod处于ContainerCreating状态

可能原因：

• 容器正在创建，但耗时较长。
• 可能由于网络问题（如CNI插件未正确配置）或存储卷未准备好。

排查方法：

• 检查节点网络和CNI插件状态。
• 检查存储卷（PVC）是否已绑定。

8: 检查网络和存储

网络问题：

• 检查CNI插件是否正常运行。
• 检查Pod的DNS配置是否正确。

存储问题：

• 检查PVC是否已绑定：kubectl get pvc -n <namespace>
• 检查存储类（StorageClass）配置是否正确。

9: 检查资源限制

确保资源请求不超过节点可用资源。如果资源限制过低，可能导致容器崩溃（如OOM）。 如果Pod因资源不足无法启动，检查资源请求和限制：

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

通过以上步骤，可以逐步定位Pod无法启动的原因。常见问题包括镜像拉取失败、资源不足、配置错误、网络或存储问题等。根据具体错误信息，结合日志和事件描述，可以快速解决问题。