Kubernetes核心对象实战：从Pod探针到Ceph持久化存储

在Kubernetes里摸爬滚打久了，你会意识到所谓的K8s资源对象并不是一堆抽象概念，而是日常排障、架构设计、容量规划时真正要反复打交道的东西。这篇文章我把API、Pod探针、Service、Volume、StatefulSet、DaemonSet、PV/PVC这些核心对象串起来，最后再落到结合Ceph做持久化存储的实际场景上。不管你是刚入门准备考CKA，还是在生产环境里已经被存储问题折腾过几回，这份整理都能给你一个相对完整的视角：各个对象解决什么问题、怎么配合、哪里有坑。

我习惯把K8s的资源对象理解成搭建一套系统的“预制积木”。你不需要自己实现网络、存储、负载均衡这些底层能力，而是通过声明式的API告诉K8s你要什么，剩下的调度、拉取、挂载、暴露，都由控制面帮你完成。下面我会按实战中踩坑最多的几条主线展开，每个部分都会给出可复现的配置片段和排查思路，而不是只讲概念。

1. 资源对象的整体认知与设计思路

1.1 从API对象说起：一切皆资源

Kubernetes的API设计很有意思，几乎所有的功能都是通过API对象暴露的。Pod是资源，Service是资源，PV、PVC、StatefulSet、DaemonSet统统都是资源。这种设计的好处是你可以用统一的工具（kubectl）和统一的数据格式（YAML或JSON）去操作一切。对运维和开发来说，这意味着基础设施也是“代码”，可以走版本管理、走Code Review、走自动化发布。

API对象的核心由三部分组成：metadata、spec和status。metadata是身份信息，比如名称、命名空间、标签；spec是你声明的期望状态；status是当前实际状态，由控制器负责维护。这里有个必须建立的心态：K8s是“声明式”的，你只需要改spec，控制器会帮你把现状拉向期望状态。就像你告诉空调“我要22度”，而不是去手动扳压缩机。

为什么要强调这一点？因为很多人调试K8s时还在用命令式操作，例如直接kubectl run一个Pod再改配置，最后发现失效了。正确做法是写一个Deployment的YAML，更新它。后续要讲的探针、Volume、PVC，全都是通过API对象来声明，理解了“一切皆资源”这个基础，后面的概念才不会乱。

1.2 资源对象的组合逻辑

单独看每个对象都比较容易，难的是理解为什么它们要组合在一起。用我自己的话梳理一下这些对象的协作关系：

• Pod是最小的调度单位，但Pod本身是“临时”的，所以需要Deployment保证副本数量和滚动更新。
• Pod挂掉后IP会变，所以需要Service给Pod提供一个稳定的访问入口。
• Pod默认的存储是临时的，容器重建后数据就没了，所以需要Volume，更进一步用PV/PVC把存储和Pod的生命周期解耦。
• 像数据库这类有状态应用，需要稳定的网络标识和独立存储，这时候StatefulSet比Deployment更合适。
• 如果要在集群里每个节点上都跑一个日志采集器或监控代理，那就是DaemonSet的活。
• 而这些对象最终都需要跟真实存储配合，生产环境里我接触最多的是Ceph，通过CSI插件或StorageClass动态供给PV。

一个比较直观的组合场景是：StatefulSet里的Pod通过Headless Service获得稳定的DNS名字，每个Pod通过volumeClaimTemplates自动创建一个PVC，PVC再动态绑定一个由Ceph RBD提供的PV。数据落在Ceph集群里，Pod哪怕被删掉重建，新Pod也能通过同一个PVC挂载到原来的数据。这套链路把上面几个对象全部串起来了，也是后面几节会反复提到的核心逻辑。

2. Pod探针与业务健康保障

2.1 三种探针的职责与区别

Pod探针是K8s用来判断容器“活没活”“能不能接流量”的机制。很多人在本地跑容器没问题，一到K8s里就被重启，就是因为探针没配对。探针一共三种：

• livenessProbe：存活探针。如果失败，Kubelet会杀掉容器并按策略重启。它解决的是“进程活着但业务卡死”的场景。
• readinessProbe：就绪探针。如果失败，端点控制器会把Pod从Service后端摘掉，不再转发流量。它解决的是“容器启动成功但业务还没准备好”的场景。
• startupProbe：启动探针。它是用来保护慢启动容器的。在启动探针成功之前，其余探针不会执行，避免因启动慢被存活探针误杀。

用一个通俗类比：存活探针是“人有没有心跳”，就绪探针是“人有没有准备好接客”，启动探针是“从起床到出门的缓冲时间”。三者职责完全不同，别图省事只配一个。

2.2 探针配置的通用参数与踩坑

探针支持三种检测方式：exec（容器内执行命令）、httpGet（请求HTTP接口）、tcpSocket（建立TCP连接）。配置时有几个参数会直接影响稳定性，我列一张速查表：

参数	含义	推荐经验值
initialDelaySeconds	容器启动后延迟多久开始探测	按业务启动时间，一般10～60s
periodSeconds	探测周期	10s左右
timeoutSeconds	单次探测超时	1～3s
failureThreshold	连续失败多少次才判定失败	3次
successThreshold	连续成功多少次判定恢复	1次（存活探针固定为1）

这里最常见的坑是timeoutSeconds设得太短。我见过有人把HTTP探针超时设成1秒，但业务接口因为慢查询偶尔要2秒返回，结果探针判定失败，Pod被反复重启。更合理的做法是先结合应用实际响应时间，留出30%以上余量。另一个坑是readinessProbe和livenessProbe用同一个接口。如果这个接口依赖了外部数据库，数据库一抖动，存活探针也跟着失败，Kubelet会直接杀掉容器。正确的做法是：存活探针只检查进程或本地端口，就绪探针才去检查依赖资源。

2.3 一个实际探针配置示例

下面是一个偏实战的Deployment配置片段，应用是常规Java服务，启动大概需要40秒：

apiVersion: apps/v1 kind: Deployment metadata: name: webapp spec: replicas: 3 selector: matchLabels: app: webapp template: metadata: labels: app: webapp spec: containers: - name: webapp image: registry.example/webapp:v2.3 ports: - containerPort: 8080 startupProbe: httpGet: path: /health/startup port: 8080 failureThreshold: 30 periodSeconds: 5 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 50 periodSeconds: 15 timeoutSeconds: 3

这里故意让startupProbe的失败阈值很大（30次 x 5秒 = 最多150秒），相当于给应用一个“慢启动宽限期”。就绪探针用独立的/health/ready，检查外部依赖。存活探针走TCP，只确认进程还活着。这套配置在生产环境里实测下来比较稳，既不会误杀，也能及时摘除不健康的Pod。

3. Service与Volume：从服务暴露到存储挂载

3.1 Service的核心类型与选型

Service的作用是为一组Pod提供稳定的访问入口，它通过标签选择器匹配后端Pod。类型主要有四类：

• ClusterIP：默认类型，集群内部虚拟IP，稳定不变。
• NodePort：在每个节点上开一个端口，流量通过节点IP+端口进来，再转发到后端Pod。
• LoadBalancer：对接云厂商或自建负载均衡器，本质是在NodePort基础上做了一层外部负载均衡。
• Headless Service：不分配VIP，DNS直接返回后端Pod IP列表。这种类型特别适合StatefulSet，因为有状态应用需要直接访问某个固定的Pod。

选型其实不复杂：内部服务用ClusterIP；需要从集群外部访问但没有负载均衡器时用NodePort；云环境或已有外部LB时用LoadBalancer；有状态应用需要稳定网络标识时用Headless。这里要注意一个细节：Headless Service并不等于无头雾水，它的clusterIP: None是明确的声明方式，配合StatefulSet，每个Pod的DNS名会变成类似podname.svcname.namespace.svc.cluster.local这样的稳定地址。

3.2 Volume基础：emptyDir/hostPath/CSI

Volume是K8s从Pod层面解决容器数据持久化和共享的抽象。有几种常见类型需要区分：

• emptyDir：Pod创建时分配一个空目录，Pod删除后数据消失。适合临时缓存、同Pod内多容器共享临时数据。
• hostPath：把宿主机目录挂载进容器。适合读取宿主机信息，比如运维Agent要读取/var/log，但数据并不跨节点共享，多节点场景几乎不能当常规存储用。
• CSI：容器存储接口，把外部存储系统（比如Ceph、云盘）通过插件挂载给Pod。这是生产环境持久化存储的主流方式。

刚接触K8s的人最容易混淆“Volume”和“PV/PVC”。简单说，Volume是Pod规格里的字段，比如volumes:下面直接写emptyDir或hostPath；而PV/PVC是独立于Pod的API对象，用于把存储的供给和消费解耦。直接写Volume虽然简单，但和存储集群的对接信息（比如Ceph的monitor地址、用户名、密钥）就会散落在Pod模板里，非常不利于维护。后面讲到PV/PVC你就明白为什么要有这套解耦了。

3.3 结合Ceph的Volume挂载思路

Ceph作为分布式存储，在K8s里的典型接入方式有两种：RBD块存储和CephFS文件系统。RBD适合块设备，常见场景是数据库的裸盘；CephFS适合共享文件系统，比如多个Pod同时读写同一个目录。在Volume这一层，你当然可以直接用csi类型挂载，但更推荐的做法是走PV/PVC + StorageClass，原因有三个：

1. 存储参数集中管理，不在每个Pod里重复出现。
2. PVC的申请和Pod的解耦，开发不用关心存储IP、密钥、pool。
3. 动态供给能自动创建、扩容、删除存储卷，运维成本降低很多。

我曾经见过一个团队把所有Ceph的monitor地址和管理员密钥直接写在Pod的volume定义里，结果泄漏到了代码仓库。后来改成PV/PVC后，密钥都收进StorageClass对应的Secret里，权限也收敛了。所以下面的重点就直接切入PV/PVC和Ceph的组合使用。

4. 有状态应用的编排：StatefulSet与DaemonSet

4.1 StatefulSet为什么是“有状态的关键”

StatefulSet和Deployment最大的区别是：它给Pod赋予了两个“稳定”属性——稳定的网络标识和稳定的存储。

网络标识方面，StatefulSet里的每个Pod名字是固定编号，比如mysql-0、mysql-1。配合Headless Service，每个Pod都有固定的DNS名，集群内可以通过这个DNS名直连某个实例。这对很多有状态应用非常重要，比如MySQL主从复制，从库要指定主库的地址，如果主库Pod被重建IP变了，从库还得去发现新IP，非常麻烦。有了固定DNS名，主库地址就可以写成mysql-0.mysql.default.svc.cluster.local，一劳永逸。

存储方面，StatefulSet里可以声明volumeClaimTemplates，它会自动为每个Pod生成一个PVC。以3副本为例：mysql-0绑定>apiVersion: apps/v1 kind: StatefulSet metadata: name: redis-cluster spec: serviceName: redis-hs replicas: 3 selector: matchLabels: app: redis-cluster template: metadata: labels: app: redis-cluster spec: containers: - name: redis image: redis:7-alpine command: - redis-server - --appendonly - "yes" ports: - containerPort: 6379 volumeMounts: - name: data mountPath: /data volumeClaimTemplates: - metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: ceph-rbd-sc

这里serviceName: redis-hs用来关联一个Headless Service，每个Pod的DNS名才能稳定。volumeClaimTemplates相当于模板，每次创建Pod都会调StorageClass动态申请一个10Gi的RBD块设备。注意accessModes用的ReadWriteOnce，意思是这个卷同一时间只能被一个节点挂载读写，适合Redis这类单机模式的实例。

5. PV/PVC与Ceph的深度结合

5.1 PV/PVC的静态供给与动态供给原理

PV是集群里的存储资源，PVC是Pod对存储的申请。二者绑定后，Pod才能正常挂载。先讲静态供给：你手动创建若干个PV，指定容量、访问模式和存储路径，然后PVC通过storageClassName或volumeName去匹配。这种方式的好处是可控，缺点是需要运维预分配容量，一旦存储快满了就得人工再建PV。

动态供给是现代云原生存储的主流做法。你不需要提前建PV，只要定义好StorageClass，用户创建PVC时，控制器会调用存储插件自动创建对应存储卷，再自动生成PV并绑定。整个过程对用户透明，扩容也更灵活。简单说：静态供给是“先有车位再停车”，动态供给是“按需画车位”。

结合Ceph时，动态供给的流程是：PVC -> StorageClass -> Ceph CSI插件 -> Ceph RBD/CephFS -> 返回PV -> 绑定PVC -> Pod挂载。这里的核心是StorageClass里的provisioner，它指明了谁来创建卷。

5.2 StorageClass与Ceph RBD的配置

以Ceph RBD为例，一个最基础的StorageClass配置大致长这样：

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-rbd-sc provisioner: rbd.csi.ceph.com parameters: clusterID: ceph-cluster-a pool: kubernetes imageFeatures: layering csi.storage.k8s.io/fstype: ext4 csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-secret csi.storage.k8s.io/controller-expand-secret-namespace: kube-system reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate

其中provisioner指定的是Ceph CSI的插件名。clusterID要对应Ceph集群配置。pool是Ceph里的存储池名。imageFeatures: layering用于开启RBD动态分层。最关键的还是认证，通过Secret传入admin用户的keyring。动态扩容依赖allowVolumeExpansion: true，这样后续可以直接修改PVC容量在线扩容。

实际项目里你需要先在Ceph端创建对应的pool、客户端用户，比如client.k8s，然后把密钥放到一个Secret里。这个Secret的key通常叫key，value是Ceph的keyring内容。遗漏Secret或者namespace不对，会导致PVC一直Pending，后面第6节我会专门说这个。

5.3 CephFS与RBD的选择

Ceph提供两种接入方式：RBD块存储和CephFS文件系统。我的选型经验是：

维度	RBD	CephFS
访问模式	ReadWriteOnce（单节点读写）为主	ReadWriteMany（多节点读写）
适用场景	数据库、Redis、Kafka等	共享文件、媒体存储、日志收集
性能	块设备性能更好，延迟低	文件系统有元数据开销
挂载方式	作为块设备格式化为文件系统后挂载	直接挂载成共享文件系统
扩容	支持在线扩容	支持在线扩容，但需要关注元数据

同一个Ceph集群可以同时提供RBD和CephFS，你只需要分别建对应的StorageClass。有些团队一开始图省事，所有应用都走CephFS，结果数据库跑起来性能很难看。更合理的做法是：有状态、单读写、性能敏感的应用用RBD；多个Pod同时读写的场景才考虑CephFS。

5.4 动态供给的完整PVC配置

有了StorageClass之后，PVC本身非常简洁。下面是申请3Gi RBD卷的配置：

apiVersion: v1 kind: PersistentVolumeClaim metadata: name:>spec: containers: - name: app image: app:latest volumeMounts: - name: data mountPath: /var/lib/data volumes: - name: data persistentVolumeClaim: claimName:>