K8s存储实战：探索卷、PV与PVC的奥秘 k8s-佚名运维-第四天

第4天

1. Kubernetes中的卷是什么，ConfigMap和Secret是卷吗？

在Kubernetes中，卷（Volume） 是用于在容器之间或容器重启后持久化存储数据的抽象层。它可以被多个容器共享，并且生命周期独立于容器（容器删除后，卷的数据可保留，具体取决于卷类型）。

configmap和secret不是卷。他们是k8s存储配置数据和敏感信息的资源对象

2. 有哪些常用的本地存储卷

• emptyDir
• hostPath 卷-能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用提供了强大的逃生舱。
• Local PV
• Local Volume Provisioner
• 本地临时存储

3. emptyDir 卷的生命周期是什么？有哪些使用场景

emptydir卷的生命周期与pod一致，它是pod创建时自动生成的一个临时目录。

有如下使用场景：

• 可用于Pod内多个容器之间共享临时数据，默认存储在节点的内存或磁盘上（可通过 medium: Memory 指定使用内存）。
• emptyDir 的使用场景
• Pod 内多容器共享临时数据：例如，一个容器生成日志文件，另一个容器（日志收集器）读取该文件，可通过 emptyDir 实现数据共享。
•  临时缓存空间：需要临时存储计算中间结果（如数据分析过程中的临时文件），且数据无需持久化的场景。
•  内存级临时存储：通过 medium: Memory  配置，将 emptyDir 挂载到内存中（类似 tmpfs），适合需要高速读写但数据可丢失的场景（如临时缓存、会话数据）。

4. hostPath 卷有哪些典型风险，应该在什么场景下使用

存在许多安全风险：

1. 节点依赖性强：数据存储在特定节点的本地文件系统，若 Pod 调度到其他节点则不能引用了。

2. 安全风险：若权限配置不当，Pod 可能通过 hostPath 访问节点的敏感文件（如 /etc 、 /var/run  等），存在越权操作节点的风险。

3. 数据一致性问题：同一节点上的多个 Pod 若挂载相同的 hostPath 路径，可能因并发读写导致数据冲突或覆盖。

5. 什么是PV，什么是PVC，两者有什么关系

PV（PersistentVolume，持久卷）

PV 是 Kubernetes 集群中预先配置的持久化存储资源，由管理员手动创建或通过存储类（StorageClass）动态生成，独立于 Pod 生命周期，用于提供可长期保留的存储能力。

PVC（PersistentVolumeClaim，持久卷声明）

PVC 是用户对存储资源的请求，由用户创建，用于声明所需的存储容量、访问模式等需求

5. 什么是PV，什么是PVC，两者有什么关系

PV

持久卷（PersistentVolume，PV） 是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

PVC

持久卷申领（PersistentVolumeClaim，PVC） 表达的是用户对存储的请求，概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）。同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以挂载为 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 或 ReadWriteOncePod， 请参阅访问模式）。

它们的关系类似于资源池与资源请求的关系，通过解耦存储的供应和使用，实现了存储资源的抽象化管理。

6. 找一台集群外的，同局域网集群搭建一个NFS服务，如果不具备条件，可以使用K8s集群内的机器进行搭建

步骤 1:安装 NFS 服务端

# 更新软件源并安装 NFS 服务
sudo apt update
sudo apt install nfs-kernel-server -y

# 确认服务状态（应为 active）
sudo systemctl status nfs-kernel-server

# 设置开机自启
sudo systemctl enable nfs-kernel-server

步骤 2：创建并配置共享目录

# 创建共享目录
sudo mkdir -p /data/nfs_share
sudo chmod 777 /data/nfs_share  # 测试环境使用宽松权限

# 配置 NFS 导出规则
sudo tee /etc/exports <<EOF
/data/nfs_share *(rw,sync,no_root_squash,no_subtree_check)
EOF

# 重新导出共享目录
sudo exportfs -ra

# 验证导出状态
showmount -e localhost

步骤 3：配置防火墙

#不熟悉的可用先关闭防火墙，Ubuntu22.04使用的是ufw
# 临时关闭 ufw 防火墙（立即生效，重启后恢复）
sudo ufw disable

# 确认防火墙状态（应显示 Status: inactive）
sudo ufw status
# 允许 NFS 相关端口
sudo ufw allow 2049/tcp
sudo ufw allow 2049/udp

# 可选：允许 NFSv4 挂载（使用 TCP 端口 111）
sudo ufw allow 111/tcp
sudo ufw allow 111/udp

# 重启防火墙使规则生效
sudo ufw reload

步骤4：客户端配置

# 安装 NFS 客户端工具
sudo apt install nfs-common -y

# 测试连接到 NFS 服务器
showmount -e 192.168.5.128  # 替换为 server 节点 IP

# 创建本地挂载点并临时挂载
mkdir -p /mnt/nfs_test
sudo mount 192.168.5.128:/data/nfs_share /mnt/nfs_test

# 验证挂载
df -hT /mnt/nfs_test

# 创建测试文件
echo "Hello from NFS" | sudo tee /mnt/nfs_test/test.txt

# 在服务端验证文件存在
ls -l /data/nfs_share/
total 4
-rw-r--r-- 1 root root 15  7月  8 18:30 test.txt

7. 创建Pod直接挂载上面创建的NFS

步骤 1：创建测试 Pod 配置文件

创建一个名为 nfs-test-pod.yaml 的文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: nfs-test-pod
spec:
  containers:
  - name: test-container
    image: nginx:alpine  # 使用轻量级镜像
    ports:
    - containerPort: 80
    volumeMounts:
    - name: nfs-volume
      mountPath: /usr/share/nginx/html  # 挂载到Nginx的网页目录
  volumes:
  - name: nfs-volume
    nfs:
      server: 192.168.1.100  # NFS服务器IP（master节点）
      path: "/data/nfs_share"  # NFS共享路径
      readOnly: false  # 可读写模式

步骤 2：创建 Pod 并验证挂载

# 创建Pod
kubectl apply -f nfs-test-pod.yaml

# 检查Pod状态
kubectl get pod nfs-test-pod

# 进入容器验证NFS挂载
kubectl exec -it nfs-test-pod -- sh

# 在容器内查看挂载内容（应显示之前创建的 test.txt 文件）
ls /usr/share/nginx/html
test.txt

# 创建一个测试页面
echo "Hello from NFS!" > /usr/share/nginx/html/index.html
exit

8. 使用上面的NFS创建静态PV和PVC，并使用pod挂载创建好的PVC

创建pv资源

cat > nfs-pv.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 5Gi  # 容量
  accessModes:
    - ReadWriteMany  # 多节点读写
  persistentVolumeReclaimPolicy: Retain  # 回收策略：保留数据
  storageClassName: nfs-storage  # 存储类名称
  nfs:
    server: 192.168.5.128  # NFS服务器IP
    path: "/data/nfs_share"  # NFS共享路径
    readOnly: false
EOF
kubectl apply -f nfs-pv.yaml
kubectl get pv nfs-pv  # 查看状态（应为Available）
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
nfs-pv   5Gi        RWX            Retain           Available    default/nfs-pvc   nfs-storage    <unset>                          9m36s

创建pvc请求资源

cat > nfs-pvc.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi  # 请求容量需小于等于PV容量
  storageClassName: nfs-storage  # 必须与PV的storageClassName一致
EOF
kubectl apply -f nfs-pvc.yaml
kubectl get pvc nfs-pvc  # 状态应为Bound

步骤 3：创建 Pod 挂载 PVC

cat > nfs-pod.yaml  <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nfs-pod
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
    volumeMounts:
    - name: nfs-volume
      mountPath: /usr/share/nginx/html  # 挂载到Nginx网页目录
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: nfs-pvc  # 引用PVC名称
EOF

验证pod：

kubectl apply -f nfs-pod.yaml
kubectl get pod nfs-pod  # 确保Pod状态为Running

# 进入容器检查挂载
kubectl exec -it nfs-pod -- sh
ls /usr/share/nginx/html  # 应显示NFS共享目录内容
ls /usr/share/nginx/html
index.html     test.txt

9. 正常的删除PV流程是什么样的，删除上面创建的Pod、PVC和PV

如果用户删除被某 Pod 使用的 PVC 对象，该 PVC 申领不会被立即移除。 PVC 对象的移除会被推迟，直至其不再被任何 Pod 使用。 此外，如果管理员删除已绑定到某 PVC 申领的 PV 卷，该 PV 卷也不会被立即移除。 PV 对象的移除也要推迟到该 PV 不再绑定到 PVC。

删除顺序：必须按 Pod → PVC → PV 的顺序删除，否则可能导致资源卡住

若要删除每个资源所绑定的东西可用使用以下命令：

##查看pv的被谁绑定 
kubectl describe pv <pv名称>   # 确认PVC（PersistentVolumeClaim）绑定到该 PV。

#查找到pvc后，再查看有那些pod绑定了这个pvc,使用grep过来pvc名称
kubectl get pods  -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep nfs-pvc

这里使用的是上面的pvc（nfs-pvc），pv（nfs-pv），pod（nfs-pod）的名字空间做完整删除所绑定的pv

步骤 1：删除 Pod
kubectl delete pod nfs-pod

# 验证Pod已删除
kubectl get pods

步骤 2：删除 PVC
删除 PVC 会解除与 PV 的绑定，但不会立即删除 PV（取决于回收策略）：
kubectl delete pvc nfs-pvc

# 验证PVC已删除
kubectl get pvc

步骤 3：清理 PV（针对 Retain 策略）
对于Retain策略的 PV，需手动清理后才能重新使用或删除：
# 查看PV状态（应为Released）
kubectl get pv nfs-pv

# 编辑PV，删除spec.claimRef字段（解除与PVC的绑定）
kubectl edit pv nfs-pv

# 删除PV
kubectl delete pv nfs-pv

# 验证PV已删除
kubectl get pv

10. PV有哪些回收策略和访问模式，各有什么区别

回收策略

1. Retain（保留

2. Recycle（回收，已弃用）

3. Delete（删除）

回收策略	作用对象	数据处理方式	使用场景
Retain	PV	保留数据和 PV，需手动清理	关键数据备份、迁移
Delete	PV	自动删除 PV 和底层存储	云存储卷、动态供给
Recycle	PV	清理数据后重置 PV（已弃用）	历史版本兼容性

二、PV 访问模式（Access Modes）

访问模式定义了 PV 的挂载权限和并发访问能力。支持三种模式（一个 PV 只能设置一种，但 PVC 可请求多种）：
 

1. ReadWriteOnce (RWO)

• 含义：PV 可被单个节点以读写模式挂载。
• 限制：同一时间只能被一个节点访问，多个 Pod 可在同一节点上共享。
• 适用场景：大多数有状态应用（如 MySQL、MongoDB）。

2. ReadOnlyMany (ROX)

• 含义：PV 可被多个节点以只读模式挂载。
• 适用场景：静态数据共享（如 Web 服务器的 HTML 文件）。

3. ReadWriteMany (RWX)

• 含义：PV 可被多个节点以读写模式同时挂载。
• 限制：需要存储系统本身支持多节点并发读写（如 NFS、Ceph、GlusterFS）。
• 适用场景：分布式文件系统、内容管理系统（CMS）。

4. ReadWriteOncePod (RWOP，实验性)

• 含义：PV 只能被单个 Pod 以读写模式挂载，即使 Pod 被调度到其他节点。
• 适用场景：需要严格单实例访问的场景（如分布式锁服务）。

访问模式	并发节点	读写权限	存储系统要求
ReadWriteOnce (RWO)	单节点	读写	所有存储类型
ReadOnlyMany (ROX)	多节点	只读	所有支持共享的存储
ReadWriteMany (RWX)	多节点	读写	特殊存储（NFS、Ceph 等）
ReadWriteOncePod (RWOP)	单 Pod	读写	CSI 驱动支持（实验性）

11. 如果 PVC 的状态为 Pending，常见的排查步骤有哪些

1. PVC 配置 → 2. StorageClass 存在性 → 3. 可用 PV → 4. 动态供给组件 → 5. 事件日志 → 6. 命名空间限制 → 7. PV 状态 → 8. 存储插件日志 → 9. 节点状态 → 10. 验证测试

12. 如果一个 Pod 无法挂载 PVC，如何通过 events 或日志排查原因

查看pv和pvc是否可用且成功绑定

#查看pod的Event
kubectl describe pod <pod-name> -n <namespace>

# 查看PVC状态（是否为Bound）
kubectl get pvc <pvc-name> -n <namespace>

# 查看PVC的Events
kubectl describe pvc <pvc-name> -n <namespace>

13. 如何通过 PVC 挂载持久卷后，在多个 Pod 之间实现数据共享

pv-nfs.yaml：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi  # 存储容量
  accessModes:
    - ReadWriteMany  # 支持多节点读写
  persistentVolumeReclaimPolicy: Retain  # 回收策略（删除PVC后PV保留数据）
  nfs:
    server: 192.168.1.100  # NFS服务器IP
    path: /nfs-share       # NFS共享目录

创建 PV：

bash

kubectl apply -f pv-nfs.yaml

步骤 3：创建匹配的 PVC

PVC 需与 PV 的访问模式匹配（此处为RWX），用于绑定 PV。

pvc-nfs.yaml：

yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany  # 必须与PV支持的模式一致
  resources:
    requests:
      storage: 5Gi  # 需≤PV的容量（此处10Gi）

创建 PVC：

bash

kubectl apply -f pvc-nfs.yaml

验证绑定：

kubectl get pvc nfs-pvc  # 状态应为Bound

步骤 4：多 Pod 挂载 PVC 实现共享

多个 Pod 通过引用同一个 PVC，挂载到各自的容器路径，即可共享数据。

pod1.yaml（第一个 Pod）：

apiVersion: v1
kind: Pod
metadata:
  name: pod-share-1
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: shared-data  # 挂载卷名称
      mountPath: /shared  # 容器内挂载路径
  volumes:
  - name: shared-data
    persistentVolumeClaim:
      claimName: nfs-pvc  # 引用前面创建的PVC

pod2.yaml（第二个 Pod）：

apiVersion: v1
kind: Pod
metadata:
  name: pod-share-2
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /shared  # 与pod1的挂载路径可不同，但指向同一份存储
  volumes:
  - name: shared-data
    persistentVolumeClaim:
      claimName: nfs-pvc

创建两个 Pod：

kubectl apply -f pod1.yaml -f pod2.yaml

三、验证数据共享

1. 在pod-share-1中写入数据：

   kubectl exec -it pod-share-1 -- sh
   echo "Hello from Pod1" > /shared/test.txt  # 写入共享目录
   exit
   

2. 在pod-share-2中读取数据：

   kubectl exec -it pod-share-2 -- sh
   cat /shared/test.txt  # 应输出"Hello from Pod1"

14. 如果删除了 PVC，绑定的 PV 会立刻被删除吗？什么时候会被保留

条件	PVC 删除后 PV 是否保留？	数据是否保留？
PV 回收策略为 Retain	✅ 保留	✅ 保留
PV 回收策略为 Delete	❌ 删除	❌ 删除
PV 回收策略为 Recycle（已弃用）	✅ 保留（状态变为 Available）	❌ 数据被清理
使用 StorageClass 且 reclaimPolicy=Delete	❌ 删除	❌ 删除

15. 如何验证 PVC 实际挂载到了容器的哪个路径下

直接看pod的详细描述中的容器字段的mounts

k describe pod pod-share-1

Containers:
  nginx:
    Container ID:   
    Mounts:
      /shared from shared-data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-7pb5w (ro)

16. 什么是动态制备卷，对比静态有哪些特点

在 Kubernetes 中，动态制备卷（Dynamic Volume Provisioning）是一种自动化创建 PV（PersistentVolume）的机制，与传统的静态 PV 管理方式形成对比。

静态与动态的对比

特性	静态 PV	动态制备卷
创建方式	管理员手动创建 PV	基于 StorageClass 自动创建
资源利用率	需预先分配，易造成浪费	按需创建，利用率高
运维复杂度	高（需管理大量 PV）	低（只需维护 StorageClass）
灵活性	低（PV 参数固定）	高（可通过 StorageClass 调整）
适用场景	固定存储需求、存量存储	云环境、频繁创建 / 删除 PVC
典型存储后端	NFS、本地存储	AWS EBS、Ceph、云存储

17. 尝试使用csi-driver-nfs实现动态制备卷

安装 外部驱动。这里推荐使用csi-driver-nfs https://github.com/kubernetes-csi/csi-driver-nfs

unzip csi-driver-nfs-4.11.0.zip
cd csi-driver-nfs-4.11.0

修改镜像源

sed -i 's@image: registry.k8s.io@image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/registry.k8s.io@g' deploy/v4.11.0/csi-nfs-node.yaml
sed -i 's@image: registry.k8s.io@image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/registry.k8s.io@g' deploy/v4.11.0/csi-nfs-controller.yaml

进行安装

bash ./deploy/install-driver.sh v4.10.0 local

相关的pod会启动再kube-system命名空间下

kubectl get  pod -n kube-system
NAME                                  READY   STATUS    RESTARTS        AGE
coredns-857d9ff4c9-nrt4x              1/1     Running   12 (124m ago)   15d
coredns-857d9ff4c9-p256x              1/1     Running   12 (124m ago)   15d
csi-nfs-controller-55666b7c48-5db4h   5/5     Running   2 (77m ago)     99m
csi-nfs-node-6qzb6                    3/3     Running   1 (91m ago)     99m
csi-nfs-node-7l5ct                    3/3     Running   1 (79m ago)     99m

创建相关的StorageClass

#创建sc-nfs.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass            # 资源类型
metadata:
  name: nfs-csi               # StorageClass的名称
provisioner: nfs.csi.k8s.io   # 指定用于动态卷制备的CSI插件
parameters:                   # 指定NFS服务器的相关选项
  server: 192.168.5.128
  share: /data/nfs_share
reclaimPolicy: Delete         # 指定PV回收策略为自动删除
volumeBindingMode: Immediate  # 指定卷绑定模式为 PVC创建后立即绑定PV
allowVolumeExpansion: true    # 允许动态扩展PVC的存储容量
mountOptions:                 # 指定挂载项参数
  - nfsvers=4.1

#应用

kubectl apply -f sc-nfs.yaml

查看创建的StorageClass，可以简写为sc

kubectl get sc 
NAME      PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-csi   nfs.csi.k8s.io   Delete          Immediate           true                   17m

创建pvc

##nfs-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
  namespace: default
spec:
  storageClassName: nfs-csi  # 执行使用的存储类（StorageClass）名称
  accessModes:
    - ReadWriteMany          # 多个节点可以以读写模式挂载
  resources:                # 定义PVC的资源需求
    requests:                # 定义PVC请求的资源
      storage: 1Mi           # 指定PVC请求的存储容量为1MiB

注意：这里声明的请求资源为1M，但实际并没有限制

应用：

kubectl apply -f nfs-pvc.yaml

查看pv和pvc

kubectl get pvc
NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
nfs-pvc   Bound    pvc-487d511f-156e-43cf-9ac0-dc75d1bde286   1Mi        RWX            nfs-csi        <unset>                 15m


kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-487d511f-156e-43cf-9ac0-dc75d1bde286   1Mi        RWX            Delete           Bound    default/nfs-pvc   nfs-csi        <unset>                          29s

创建pod挂载这个pvc

nfs-busybox-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nfs-busybox-pod
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox
    args: ["sh", "-c", "sleep 9999999"]
    volumeMounts:
    - name: nfs-storage
      mountPath: /sc_data
  volumes:
  - name: nfs-storage
    persistentVolumeClaim:
      claimName: nfs-pvc

应用

kubectl apply -f nfs-busybox-pod.yaml

这样会在nfs的主目录下自动创建一个以PV名称命名的目录进行挂载，与之前挂载整个NFS主目录的方式不同。并且在删除PVC时会自动删除PV和这个自动创建的目录。

之后我们新创建的Pod需要挂载存储时，只需要创建一个PVC即可自动创建绑定PV

删除nfs-csi

cd csi-driver-nfs-4.10.0
bash ./deploy/uninstall-driver.sh v4.9.0 local

18. 如果一个pod无法启动，要如何进行排查

使用 kubectl  get pod <pod name> ##查看pod 的状态

使用 kubectl describe pod <pod name>  -n <pod所在的命名空间>

具体查看event事件，具体问题具体解决

可能遇到的问题：

1. images拉取问题：
2. 资源调度问题

19. Pod可能会有哪些状态，这些状态表示的含义是什么

1. Pending

• 含义：Pod 已被 Kubernetes 接受，但尚未完全创建。
• 可能原因：
  • 资源不足（CPU/Memory）
  • 镜像拉取配置问题
  • PVC 未绑定（持久卷声明）
  • 调度失败（节点选择器不匹配）

2. Running

• 含义：Pod 已绑定到节点，所有容器已创建，至少有一个容器正在运行或重启中。
• 子状态：
  • 所有容器均正常运行
  • 部分容器处于重启中（如 CrashLoopBackOff）

3. Succeeded

• 含义：所有容器均已成功终止，且不会重启（适用于一次性任务，如 Job）。

4. Failed

• 含义：所有容器均已终止，但至少有一个容器以失败状态退出。
• 可能原因：
  • 容器内应用程序崩溃
  • 命令执行失败
  • 探针检查持续失败

5. Unknown

• 含义：Kubernetes 无法获取 Pod 的状态，通常是由于与节点通信失败。
• 可能原因：
  • 节点网络断开
  • kubelet 服务异常
  • 节点资源耗尽

二、特殊状态与子状态

1. CrashLoopBackOff

• 含义：容器启动后崩溃，Kubernetes 正在重试启动。
• 排查方向：
  • 查看容器日志（kubectl logs <pod> --previous）
  • 检查应用程序启动命令和环境变量

2. ImagePullBackOff/ErrImagePull

• 含义：镜像拉取失败。
• 可能原因：
  • 镜像不存在或标签错误
  • 镜像仓库认证失败
  • 网络问题导致无法访问仓库

3. Init:0/1 或 Init:CrashLoopBackOff

• 含义：初始化容器（Init Container）未完成。
• 排查方向：
  • 查看初始化容器日志（kubectl logs <pod> -c <init-container-name>）
  • 确认初始化任务是否依赖外部服务

4. ContainerCreating

• 含义：Kubernetes 正在为 Pod 创建容器。
• 可能耗时较长的原因：
  • 镜像体积过大
  • 存储卷挂载缓慢（如 NFS、Ceph）
  • 节点资源紧张

5. Terminating

• 含义：Pod 正在被删除（优雅终止中）。
• 可能卡住的原因：
  • 容器未响应终止信号（SIGTERM）
  • 优雅终止宽限期（terminationGracePeriodSeconds）设置过长