K8s 网络与存储(容器网络互通与数据持久化)

文章目录

    • 前言
    • [一、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 数据持久化)
      • [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 实现隧道转发,完整流程:

  1. 节点A 上的 PodA 发起访问请求,目标为节点B 上的 PodB IP;
  2. 节点A 内核识别目标 Pod 为跨节点地址,将数据包交给 Calico 组件;
  3. Calico 通过 VXLAN 隧道封装数据包,通过物理网卡发送到目标节点B;
  4. 节点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:持久化效果验证
  1. 进入容器,手动创建自定义页面文件;
  2. 删除当前 Pod,等待 K8s 自动重建新 Pod;
  3. 进入新 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用于大厂生产高可用场景。

相关推荐
Cry丶8 小时前
ubuntu安装vsftpd
服务器·网络·ubuntu
SHENGWEI胜为12 小时前
交换机端口显示正常,终端却获取不到 IP 地址?从 DHCP 流程定位故障
服务器·网络·测试工具·缓存·通信工程
IMPYLH13 小时前
Linux 系统备份与镜像
linux·服务器·网络
淘气包海鸟14 小时前
水声网络框架
网络·ns3·水
国科安芯15 小时前
星间激光通信终端CANFD控制网络的时延确定性与辐射可靠性
网络·嵌入式硬件·信息与通信·canfd·低轨卫星·商业航天·抗辐射
中屹指纹浏览器svip16 小时前
网络抖动会标记账号异常?分清两种波动
网络
承渊政道16 小时前
Linux网络学习【传输层协议UDP】
linux·网络·网络协议·学习·ubuntu·udp
小此方16 小时前
Linux网络(三十三):告别O(n)噩梦:从select/poll的挣扎到epoll红黑树+回调的降维打击,一文打通IO多路复用
linux·网络·驱动开发
2301_7779983416 小时前
Linux 网络:数据链路层
linux·服务器·网络
国科安芯17 小时前
空间锂离子电池组管理系统CANFD通信网络的辐射可靠性设计
网络·信息与通信·canfd·电池·低轨卫星·抗辐射