文章目录
-
- 前言
- [一、K8s 标准网络模型(全网统一核心准则)](#一、K8s 标准网络模型(全网统一核心准则))
-
- [1.1 K8s 网络三大铁律](#1.1 K8s 网络三大铁律)
- [1.2 K8s 四层网络通信架构(通俗分层)](#1.2 K8s 四层网络通信架构(通俗分层))
- [二、Pod 互通原理(同节点 + 跨节点 白话拆解)](#二、Pod 互通原理(同节点 + 跨节点 白话拆解))
-
- [2.1 同节点 Pod 互通(最简单)](#2.1 同节点 Pod 互通(最简单))
- [2.2 跨节点 Pod 互通(核心重点)](#2.2 跨节点 Pod 互通(核心重点))
- [三、ClusterIP / NodePort 彻底区分(新手100%混淆点)](#三、ClusterIP / NodePort 彻底区分(新手100%混淆点))
-
- [3.1 ClusterIP(默认类型)](#3.1 ClusterIP(默认类型))
- [3.2 NodePort(测试/外网访问类型)](#3.2 NodePort(测试/外网访问类型))
- [3.3 两者核心区别对照表(一目了然)](#3.3 两者核心区别对照表(一目了然))
- [四、K8s 数据持久化核心:PV / PVC 完整实战](#四、K8s 数据持久化核心:PV / PVC 完整实战)
-
- [4.1 PV、PVC 白话定义(永久记住)](#4.1 PV、PVC 白话定义(永久记住))
-
- [PV(PersistentVolume 持久卷)](#PV(PersistentVolume 持久卷))
- [PVC(PersistentVolumeClaim 持久卷声明)](#PVC(PersistentVolumeClaim 持久卷声明))
- [4.2 PV-PVC-Pod 绑定关系(核心链路)](#4.2 PV-PVC-Pod 绑定关系(核心链路))
- [4.3 手把手实战:PV+PVC 数据持久化](#4.3 手把手实战:PV+PVC 数据持久化)
-
- 步骤1:创建PV资源(pv.yaml)
- 步骤2:创建PVC资源(pvc.yaml)
- [步骤3:Deployment 挂载 PVC(业务关联存储)](#步骤3:Deployment 挂载 PVC(业务关联存储))
- 步骤4:持久化效果验证
- [4.4 PV 核心访问模式(生产必懂)](#4.4 PV 核心访问模式(生产必懂))
- [五、企业级 K8s 存储方案选型(生产落地标准)](#五、企业级 K8s 存储方案选型(生产落地标准))
-
- [5.1 HostPath(仅学习测试)](#5.1 HostPath(仅学习测试))
- [5.2 NFS 共享存储(中小企业主流)](#5.2 NFS 共享存储(中小企业主流))
- [5.3 云厂商存储(大厂生产标配)](#5.3 云厂商存储(大厂生产标配))
- [5.4 存储类 SC(动态存储,高阶生产)](#5.4 存储类 SC(动态存储,高阶生产))
- 六、本篇核心总结
前言
上一篇我们吃透了 K8s 三大核心资源:Pod、Deployment、Service,掌握了服务部署、滚动更新、版本回滚、动态扩缩容的完整实操。
但目前我们的集群还存在两个核心短板,完全无法直接上线生产:
\1. 网络认知模糊:不知道 Pod 和 Pod、节点和 Pod、内外网之间如何互通,分不清 ClusterIP、NodePort 适用场景;
\2. 数据完全不持久:容器删除、Pod 重建后,所有数据直接丢失,数据库、缓存等有状态服务完全无法部署。
本篇一次性补齐 K8s 生产最后两大核心能力:容器网络原理 + 数据持久化存储。全程白话通俗讲解、原理+实操结合、区分新手易错点、落地企业标准存储方案,学完即可部署有状态生产服务。
一、K8s 标准网络模型(全网统一核心准则)
K8s 拥有强制统一的网络规范,所有网络插件(Calico/Flannel)都必须遵循,只需记住三句核心规则,彻底吃透 K8s 网络底层逻辑:
1.1 K8s 网络三大铁律
- 每个 Pod 拥有唯一独立 IP:集群内所有 Pod IP 不重复,无需 NAT 转换,可直接通信
- Pod 与 Pod 无差别互通:无论两个 Pod 在同一节点、还是跨不同节点,默认直接连通,无需手动配置路由
- Pod IP 动态可变:Pod 是临时资源,重建、迁移、扩容后 IP 会改变,绝对不能用 Pod IP 固定访问服务
1.2 K8s 四层网络通信架构(通俗分层)
从内到外依次为:容器 → Pod → 节点 → 集群外网
- 容器和容器:同 Pod 内容器共享网络栈,直接本地通信
- Pod 和 Pod:集群核心通信方式,同节点/跨节点均可直连
- Pod 和 Node:节点可直接访问 Pod,Pod 可访问节点服务
- 集群和外网:通过 Service 端口映射实现双向访问
二、Pod 互通原理(同节点 + 跨节点 白话拆解)
很多新手疑惑:为什么不同服务器上的 Pod,不配置任何路由就能互相访问?核心依靠我们之前部署的 Calico 网络插件,下面分两种场景讲透。
2.1 同节点 Pod 互通(最简单)
同一台服务器上的所有 Pod,共享节点网桥设备,数据转发流程:
PodA → 节点虚拟网桥 → 直接转发到 PodB
特点:无需经过物理网卡、无需路由跳转、转发速度最快、延迟极低。
2.2 跨节点 Pod 互通(核心重点)
不同服务器上的 Pod 通信,依靠 Calico 实现隧道转发,完整流程:
- 节点A 上的 PodA 发起访问请求,目标为节点B 上的 PodB IP;
- 节点A 内核识别目标 Pod 为跨节点地址,将数据包交给 Calico 组件;
- Calico 通过 VXLAN 隧道封装数据包,通过物理网卡发送到目标节点B;
- 节点B 的 Calico 解包,将数据转发给本地目标 PodB;
通俗总结:Calico 相当于给所有节点搭建了一条专属高速隧道,让整个集群所有 Pod 处于同一个局域网,天然互通。
三、ClusterIP / NodePort 彻底区分(新手100%混淆点)
Service 是 Pod 的统一入口,其中最常用的两种类型 ClusterIP、NodePort,是日常开发、面试最高频考点,本节彻底分清用途、场景、区别。
3.1 ClusterIP(默认类型)
核心定位:集群内部专属服务入口
- 自动分配一个集群虚拟内网 IP,仅集群内部节点、Pod 可以访问
- 外网电脑、手机、公网无法直接访问
- 自带负载均衡,自动分发流量到后端多个 Pod
适用场景 :微服务内部互相调用
例如:Java 网关调用订单服务、用户服务调用支付服务,服务全部部署在集群内,无需外网访问,首选 ClusterIP。
3.2 NodePort(测试/外网访问类型)
核心定位:对外开放服务入口
- 在所有集群节点上,统一开启一个 30000-32767 区间的物理端口
- 外网可通过
服务器公网IP:端口直接访问服务 - 流量流程:外网IP:端口 → 节点端口 → Service → 后端Pod
适用场景 :前端页面、测试环境、需要外网访问的服务
3.3 两者核心区别对照表(一目了然)
| 对比维度 | ClusterIP | NodePort |
|---|---|---|
| 访问范围 | 仅集群内部 | 支持外网公网访问 |
| 端口范围 | 随机内网端口 | 固定 30000-32767 |
| 生产用途 | 微服务内部调用(主力) | 测试、外网暴露、临时演示 |
| 性能开销 | 低,纯内网转发 | 略高,多一层节点端口映射 |
企业最佳实践:内部服务一律用 ClusterIP,绝不乱用 NodePort,避免端口暴露带来的安全风险。
四、K8s 数据持久化核心:PV / PVC 完整实战
默认情况下,容器数据全部存在容器内部,删除 Pod、重建 Pod、重启容器,数据直接清零,完全无法用于数据库、文件存储等业务。
K8s 通过 PV + PVC 实现数据持久化,彻底实现「容器销毁,数据不丢」,是所有有状态服务的存储核心方案。
4.1 PV、PVC 白话定义(永久记住)
PV(PersistentVolume 持久卷)
集群级真实存储空间:由运维/系统提前创建,代表服务器真实硬盘、NFS共享存储、云硬盘,独立于Pod存在,Pod删了PV和数据依然保留。
通俗理解:提前建好的仓库(真实空间)
PVC(PersistentVolumeClaim 持久卷声明)
用户存储申请单:由开发者创建,用来向集群申请存储空间,只需要填写「需要多大空间、读写权限」,无需关心底层存储是硬盘还是云存储。
通俗理解:租仓库的申请单据
4.2 PV-PVC-Pod 绑定关系(核心链路)
真实存储(PV) → 申请绑定(PVC) → 挂载进Pod
流程:运维创建PV储备空间 → 开发写PVC申请空间 → K8s自动匹配PV与PVC → 挂载到容器目录实现数据持久化
4.3 手把手实战:PV+PVC 数据持久化
我们通过 Nginx 实战验证:挂载持久化存储,删除 Pod 重建后,自定义数据不丢失。
步骤1:创建PV资源(pv.yaml)
yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nginx-pv
spec:
capacity:
storage: 5Gi # 定义PV存储空间大小5G
accessModes:
- ReadWriteOnce # 访问模式:单节点读写
hostPath:
path: /data/nginx-pv # 服务器本地真实存储路径
执行创建命令:
bash
kubectl apply -f pv.yaml
kubectl get pv
状态说明:此时 PV 状态为 Available(空闲可用),等待 PVC 绑定。
步骤2:创建PVC资源(pvc.yaml)
yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nginx-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi # 申请5G存储空间,与PV匹配
执行创建命令:
bash
kubectl apply -f pvc.yaml
kubectl get pvc
绑定效果:PVC 创建后自动匹配同规格 PV,状态变为 Bound(绑定成功),存储通道建立完成。
步骤3:Deployment 挂载 PVC(业务关联存储)
修改 Nginx 部署文件,将持久化存储挂载到容器目录:
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-demo
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:alpine
ports:
- containerPort: 80
# 挂载配置
volumeMounts:
- name: nginx-data
mountPath: /usr/share/nginx/html # 容器网页目录
volumes:
- name: nginx-data
persistentVolumeClaim:
claimName: nginx-pvc # 关联上面创建的PVC
重新部署服务:
bash
kubectl apply -f nginx-deploy.yaml
步骤4:持久化效果验证
- 进入容器,手动创建自定义页面文件;
- 删除当前 Pod,等待 K8s 自动重建新 Pod;
- 进入新 Pod 查看文件,数据依然存在,持久化生效;
核心原理:数据不再存在容器内部,而是存在服务器真实 PV 目录,Pod 重建不会影响底层存储数据。
4.4 PV 核心访问模式(生产必懂)
- ReadWriteOnce(RWO):仅单个节点可读写,最常用,适配绝大多数单机业务
- ReadOnlyMany(ROXM):多节点只读,适合静态文件共享
- ReadWriteMany(RWXM):多节点可读写,适配集群共享读写业务
五、企业级 K8s 存储方案选型(生产落地标准)
新手学习用本地 HostPath PV,生产环境绝对不用!本节整理企业主流存储方案,适配不同业务场景。
5.1 HostPath(仅学习测试)
将节点本地目录作为存储,禁止生产使用
缺点:Pod 漂移到其他节点,数据直接丢失,无法集群共享,稳定性极差
5.2 NFS 共享存储(中小企业主流)
搭建独立 NFS 文件服务器,所有节点挂载共享目录,统一提供存储
优点:配置简单、支持多节点共享、数据独立持久、稳定性高
适用场景:中小型项目、文件存储、日志存储、普通数据库挂载
5.3 云厂商存储(大厂生产标配)
阿里云/腾讯云/华为云 云硬盘、NAS 存储
优点:高可用、自动备份、弹性扩容、无需维护底层硬件
适用场景:云上生产集群、高可用核心业务、大规模微服务集群
5.4 存储类 SC(动态存储,高阶生产)
传统 PV 需手动创建,StorageClass 可实现动态自动创建 PV
开发者只需创建 PVC,集群自动分配对应规格 PV,无需运维手动干预,是大型企业标准化存储方案。
六、本篇核心总结
1、K8s 网络核心三准则:Pod 独立IP、全网互通、IP 动态可变,Calico 插件实现跨节点隧道通信;
2、ClusterIP 用于集群内部微服务调用,NodePort 用于外网测试访问,生产优先使用 ClusterIP,保障安全;
3、PV 是真实集群存储资源,PVC 是存储申请单,二者绑定实现容器数据解耦与持久化;
4、彻底解决容器数据丢失问题,支持 Pod 重建、迁移、扩容场景下数据不丢失;
5、企业存储分层明确:本地HostPath用于学习、NFS用于中小企业、云存储/SC用于大厂生产高可用场景。