云原生技术04-为什么你的Pod无法互相通信？99%是因为没搞懂CNI，Flannel vs Calico vs Cilium：选错网络插件让你的K8s慢成蜗牛

目录1. 开篇K8s的血管系统危机2. CNIPod的网络身份证3. Flannel小集群的贴心管家4. Calico大厂的BGP网络专家5. CiliumeBPF加持的安全卫士6. CNI选型实战指南7. CSI存储界的USB接口8. PersistentVolume与StorageClass9. 文末三件套开篇K8s的血管系统危机你是否遇到过Pod之间突然无法通信、CNI插件选错导致网络性能腰斩、有状态应用数据神秘丢失的抓狂时刻CNI和CSI是Kubernetes的两大血管系统选错了可是会要命的。本文将给出生产级别的选型指南。效率技巧很多新手一上来就问哪个CNI最好这就像问宝马和奔驰哪个好——不看场景谈选型都是耍流氓。想象一下你的Kubernetes集群是一座繁华的城市Pod是城里的居民。没有CNIContainer Network Interface这些居民就像被关在各自小黑屋里——看得见彼此却永远无法交流。而CSIContainer Storage Interface则是城市的供水供电系统没有它有状态应用就像没有水电的毛坯房根本住不了人。CNIPod的网络身份证什么是CNICNIContainer Network Interface是CNCF云原生计算基金会推出的容器网络标准。你可以把它理解为Pod的网络身份证发放中心。┌─────────────────────────────────────────────────────────────┐ │ Kubernetes 集群 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Pod A │◄──►│ Pod B │◄──►│ Pod C │◄──►│ Pod D │ │ │ │10.244.1.2│ │10.244.1.3│ │10.244.2.2│ │10.244.2.3│ │ │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ └──────────────┴──────────────┴──────────────┘ │ │ │ │ │ ┌────┴────┐ │ │ │ CNI │ ← 网络插件Flannel/Calico/Cilium│ │ │ 插件 │ │ │ └────┬────┘ │ │ │ │ │ ┌─────────────────┼─────────────────┐ │ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │ │ Node 1 │ │ Node 2 │ │ Node 3 │ │ │ │(Worker) │ │(Worker) │ │(Master) │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────────┘CNI的核心职责1.IP分配给每个Pod分配唯一的IP地址就像给每个居民发身份证2.网络连通让Pod之间可以互相通信同一节点和跨节点3.网络策略控制谁能访问谁保安系统⚠️避坑警告CNI和Service不是一回事Service是K8s内置的负载均衡机制而CNI是底层网络实现。没有CNIService也巧妇难为无米之炊。Flannel小集群的贴心管家Flannel是什么Flannel是CoreOS被Red Hat收购开发的轻量级CNI插件主打一个简单够用。它就像你刚毕业时租的小单间——麻雀虽小五脏俱全。VXLAN模式工作原理┌─────────────────────────────────────────────────────────────────────┐ │ Flannel VXLAN 架构 │ │ │ │ Node 1 (10.0.0.1) Node 2 (10.0.0.2) │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ Pod A │ │ Pod B │ │ │ │ 10.244.1.2/24 │ │ 10.244.2.2/24 │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │ │ │ cni0 │ │ │ │ cni0 │ │ │ │ │ │10.244.1.1│ │ │ │10.244.2.1│ │ │ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │ │ │ │flannel.1│◄────┼──────────┼─►│flannel.1│ │ │ │ │ │ VTEP │ │ VXLAN │ │ VTEP │ │ │ │ │ └────┬────┘ │ Tunnel │ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │ │ │ │ eth0 │◄────┼──────────┼─►│ eth0 │ │ │ │ │ │10.0.0.1 │ │ │ │10.0.0.2 │ │ │ │ │ └─────────┘ │ │ └─────────┘ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ 数据包流向Pod A → cni0 → flannel.1 → VXLAN封装 → eth0 ────────► │ │ │ │ │ ▼ │ │ Node 2 eth0 │ │ │ │ │ ▼ │ │ VXLAN解封装 │ │ │ │ │ ▼ │ │ flannel.1 → cni0 → Pod B │ └─────────────────────────────────────────────────────────────────────┘**VXLANVirtual Extensible LAN**是一种网络虚拟化技术它在UDP之上封装二层以太网帧实现跨物理网络的虚拟网络。Flannel部署代码# flannel-deploy.yaml --- apiVersion: v1 kind: Namespace metadata: name: kube-flannel labels: k8s-app: flannel pod-security.kubernetes.io/enforce: privileged --- apiVersion: v1 kind: ServiceAccount metadata: name: flannel namespace: kube-flannel --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: flannel rules: - apiGroups: [] resources: [pods] verbs: [get] - apiGroups: [] resources: [nodes] verbs: [get, list, watch] - apiGroups: [] resources: [nodes/status] verbs: [patch] - apiGroups: [networking.k8s.io] resources: [clustercidrs] verbs: [list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: flannel roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: flannel subjects: - kind: ServiceAccount name: flannel namespace: kube-flannel --- apiVersion: v1 kind: ConfigMap metadata: name: kube-flannel-cfg namespace: kube-flannel labels: tier: node k8s-app: flannel app: flannel data: cni-conf.json: | { name: cbr0, cniVersion: 0.3.1, plugins: [ { type: flannel, delegate: { hairpinMode: true, isDefaultGateway: true } }, { type: portmap, capabilities: { portMappings: true } } ] } net-conf.json: | { Network: 10.244.0.0/16, Backend: { Type: vxlan } } --- apiVersion: apps/v1 kind: DaemonSet metadata: name: kube-flannel-ds namespace: kube-flannel labels: tier: node app: flannel k8s-app: flannel spec: selector: matchLabels: app: flannel template: metadata: labels: tier: node app: flannel spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/os operator: In values: - linux hostNetwork: true priorityClassName: system-node-critical tolerations: - operator: Exists effect: NoSchedule serviceAccountName: flannel initContainers: - name: install-cni-plugin image: docker.io/flannel/flannel-cni-plugin:v1.1.2 command: - cp args: - -f - /flannel - /opt/cni/bin/flannel volumeMounts: - name: cni-plugin mountPath: /opt/cni/bin - name: install-cni image: docker.io/flannel/flannel:v0.22.0 command: - cp args: - -f - /etc/kube-flannel/cni-conf.json - /etc/cni/net.d/10-flannel.conflist volumeMounts: - name: cni mountPath: /etc/cni/net.d - name: flannel-cfg mountPath: /etc/kube-flannel containers: - name: kube-flannel image: docker.io/flannel/flannel:v0.22.0 command: - /opt/bin/flanneld args: - --ip-masq - --kube-subnet-mgr resources: requests: cpu: 100m memory: 50Mi securityContext: privileged: false capabilities: add: [NET_ADMIN, NET_RAW] env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: EVENT_QUEUE_DEPTH value: 5000 volumeMounts: - name: run mountPath: /run/flannel - name: flannel-cfg mountPath: /etc/kube-flannel - name: xtables-lock mountPath: /run/xtables.lock volumes: - name: run hostPath: path: /run/flannel - name: cni-plugin hostPath: path: /opt/cni/bin - name: cni hostPath: path: /etc/cni/net.d - name: flannel-cfg configMap: name: kube-flannel-cfg - name: xtables-lock hostPath: path: /run/xtables.lock type: FileOrCreate部署命令kubectl apply -f flannel-deploy.yamlFlannel的优缺点优点缺点部署简单一条命令搞定不支持网络策略NetworkPolicy资源占用低大规模集群性能下降社区成熟文档丰富功能相对单一支持多种后端VXLAN、host-gw等跨节点通信有封装开销效率技巧Flannel VXLAN模式适合500节点以下的中小规模集群。如果你的集群超过500节点赶紧往下看Calico。幽默一刻Flannel就像你大学宿舍的WiFi——能用但别指望它能承载整个宿舍楼的流量。当你发现Pod之间通信开始转圈圈时就该考虑升级了。Calico大厂的BGP网络专家什么是CalicoCalico是Tigera公司后被SUSE收购开发的企业级CNI插件主打高性能网络策略。如果说Flannel是经济适用的五菱宏光那Calico就是能拉货能越野的丰田陆巡。BGP模式工作原理┌─────────────────────────────────────────────────────────────────────────────┐ │ Calico BGP 架构 │ │ │ │ ┌─────────────┐ │ │ │ Router │ │ │ │ (ToR/核心) │ │ │ │ AS 64512 │ │ │ └──────┬──────┘ │ │ │ │ │ ┌────────────────────────┼────────────────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Node 1 │ │ Node 2 │ │ Node 3 │ │ │ │ AS 64513 │◄────────►│ AS 64514 │◄────────►│ AS 64515 │ │ │ │ (iBGP/eBGP)│ BGP │ (iBGP/eBGP)│ BGP │ (iBGP/eBGP)│ │ │ └──────┬──────┘ Session └──────┬──────┘ Session └──────┬──────┘ │ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐ │ │ │ Pod A │ │ Pod B │ │ Pod C │ │ │ │ 10.244.1.2 │ │ 10.244.2.2 │ │ 10.244.3.2 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ 核心特点 │ │ 1. 每个Node是一个BGP路由器 │ │ 2. Pod IP直接路由无需封装 │ │ 3. 支持细粒度的网络策略NetworkPolicy │ │ 4. 可对接物理网络实现Pod与外部直接通信 │ └─────────────────────────────────────────────────────────────────────────────┘**BGPBorder Gateway Protocol**是互联网的核心路由协议。Calico利用BGP让每个Node成为一个路由器直接宣告Pod IP段实现三层路由。Calico部署代码# 安装Calico使用Operator方式 kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml # 配置Calico安装 kubectl create -f - EOF apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: ipPools: - name: default-ipv4-ippool blockSize: 26 cidr: 10.244.0.0/16 encapsulation: VXLANCrossSubnet # 跨子网使用VXLAN同子网直接路由 natOutgoing: Enabled nodeSelector: all() EOFCalico网络策略示例# deny-all.yaml - 默认拒绝所有入站流量 apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: default-deny spec: selector: all() types: - Ingress --- # allow-frontend.yaml - 只允许frontend访问backend apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: production spec: selector: app backend types: - Ingress ingress: - action: Allow protocol: TCP source: selector: app frontend destination: ports: - 8080 --- # block-external.yaml - 阻止Pod访问外部特定IP apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: block-sensitive-ips spec: selector: all() types: - Egress egress: - action: Deny destination: nets: - 10.0.0.100/32 # 敏感数据库IP - action: AllowCalico的优缺点优点缺点支持10,000节点规模配置相对复杂原生支持网络策略需要理解BGP概念无封装开销BGP模式某些云厂商不支持BGP性能优异学习曲线较陡可与物理网络集成默认模式需要Node支持IP转发⚠️避坑警告在AWS、Azure等公有云上使用Calico时如果开启BGP模式需要确保云厂商支持BGP路由。否则请使用VXLAN或IPIP模式作为fallback。幽默一刻Calico就像公司的IT部门——功能强大但规矩也多。你想让Pod A访问Pod B先填个网络策略申请表等Calico审批通过再说。CiliumeBPF加持的安全卫士什么是CiliumCilium是基于eBPFExtended Berkeley Packet Filter的下一代CNI插件主打可观测性安全性高性能。如果说Calico是丰田陆巡那Cilium就是特斯拉Cybertruck——科技感拉满但你需要先学会开它。eBPF是什么eBPF是Linux内核的一项革命性技术允许在内核中安全地运行沙盒程序。简单说它让Cilium可以住在内核里直接处理网络流量而不需要经过传统的网络栈。┌─────────────────────────────────────────────────────────────────────────────┐ │ Cilium eBPF 架构 │ │ │ │ 传统网络栈 vs eBPF加速 │ │ │ │ 传统方式Flannel/Calico │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Pod A │──►│ veth │──►│ Bridge │──►│ Route │──►│ eth0 │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │ 用户态 内核态 内核态 内核态 硬件 │ │ │ │ Cilium eBPF方式 │ │ ┌─────────┐ │ │ │ Pod A │──────────────────────────────────────────┐ │ │ └────┬────┘ │ │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ eBPF Hook │ │ │ │ │ (直接处理) │ │ │ │ └──────┬──────┘ │ │ │ │ │ │ └────────────────────────────────────────────────┘ │ │ 绕过传统网络栈直接在内核处理 │ │ │ │ 性能提升 │ │ - 网络转发延迟降低 30% │ │ - CPU使用率降低 │ │ - 支持L3/L4/L7层策略 │ │ - 内置可观测性Hubble │ └─────────────────────────────────────────────────────────────────────────────┘Cilium部署代码# 添加Cilium Helm仓库 helm repo add cilium https://helm.cilium.io/ helm repo update # 安装Cilium使用eBPF替代kube-proxy helm install cilium cilium/cilium --version 1.14.0 \ --namespace kube-system \ --set kubeProxyReplacementstrict \ --set k8sServiceHost\API_SERVER_IP\ \ --set k8sServicePort6443 # 验证安装 kubectl -n kube-system exec ds/cilium -- cilium statusCilium网络策略L7层# l7-policy.yaml - 限制HTTP API访问 apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: api-restrictions namespace: production spec: endpointSelector: matchLabels: app: backend-api ingress: - fromEndpoints: - matchLabels: app: frontend toPorts: - ports: - port: 80 protocol: TCP rules: http: - method: GET path: /api/v1/users/.* - method: POST path: /api/v1/users - method: GET path: /api/v1/products/.* - fromEndpoints: - matchLabels: app: admin-dashboard toPorts: - ports: - port: 80 protocol: TCP rules: http: - method: .* # 管理员可以访问所有API path: /api/.*Cilium可观测性Hubble# 启用Hubble helm upgrade cilium cilium/cilium --version 1.14.0 \ --namespace kube-system \ --reuse-values \ --set hubble.enabledtrue \ --set hubble.relay.enabledtrue \ --set hubble.ui.enabledtrue # 查看实时流量 kubectl exec -n kube-system -t ds/cilium -- hubble observe # 输出示例 # May 15 10:23:45.123 [pod-a]:8080 - [pod-b]:8080 L3-L4 FORWARDED TCP Flags: SYN # May 15 10:23:45.125 [pod-b]:8080 - [pod-a]:8080 L3-L4 FORWARDED TCP Flags: SYN-ACKCilium的优缺点优点缺点eBPF性能提升30%内核版本要求高4.19支持L7层策略学习曲线最陡内置可观测性Hubble社区相对年轻服务网格集成Cilium Service Mesh某些旧系统可能不兼容安全性最强调试相对复杂效率技巧Cilium最适合对安全性和可观测性要求高的场景比如金融、医疗等行业。如果你的集群需要知道流量在干什么而不仅仅是通不通Cilium是不二之选。幽默一刻Cilium就像你那个会写代码的健身教练——它不仅能帮你跑得快性能还能告诉你怎么跑才对可观测性甚至能阻止你跑错地方安全策略。唯一的缺点是你得先学会听懂它说的话eBPF。CNI选型实战指南决策树┌─────────────────────────────────────────────────────────────────────────────┐ │ CNI 选型决策树 │ │ │ │ 开始选型 │ │ │ │ │ ▼ │ │ ┌─────────────────────────┐ │ │ │ 集群规模 100 节点 │ │ │ └─────────────┬───────────┘ │ │ │ │ │ ┌─────────────┴─────────────┐ │ │ ▼ ▼ │ │ 是 否 │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────────────┐ │ │ │ 需要网络策略 │ │ 需要网络策略 │ │ │ └────────┬────────┘ └───────────┬─────────────┘ │ │ │ │ │ │ ┌───────┴───────┐ ┌───────┴───────┐ │ │ ▼ ▼ ▼ ▼ │ │ 否 是 否 是 │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ │ ┌──────┐ ┌────────┐ ┌──────┐ ┌────────┐ │ │ │Flannel│ │Calico │ │Calico│ │Cilium │ │ │ │(简单) │ │(功能全)│ │(性能)│ │(安全) │ │ │ └──────┘ └────────┘ └──────┘ └────────┘ │ │ │ │ 特殊场景 │ │ - 需要服务网格 → Cilium │ │ - 需要L7层策略 → Cilium │ │ - 云厂商托管K8s → 用云厂商默认CNI如AWS VPC CNI │ │ - 混合云/多集群 → Calico BGP │ └─────────────────────────────────────────────────────────────────────────────┘选型速查表场景推荐CNI理由测试/开发环境Flannel部署简单够用就好中小规模生产500节点Flannel/CalicoFlannel简单Calico功能全大规模生产500节点Calico/CiliumBGP性能eBPF未来需要网络策略Calico/Cilium原生支持需要L7层策略Cilium唯一选择需要服务网格Cilium内置服务网格金融/医疗等高安全Cilium可观测性安全云厂商托管K8s云厂商默认与VPC集成最好⚠️避坑警告不要在一个集群中混用多个CNI这就像在一台车上装两个方向盘——理论上行得通实际上会撞墙。CSI存储界的USB接口什么是CSICSIContainer Storage Interface是Kubernetes的存储标准接口。你可以把它理解为存储界的USB接口——不管你的存储后端是AWS EBS、Ceph、NFS还是本地磁盘CSI都能让K8s插上去就能用。┌─────────────────────────────────────────────────────────────────────────────┐ │ CSI 架构 │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ Kubernetes Cluster │ │ │ │ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ Pod A │ │ Pod B │ │ Pod C │ │ Pod D │ │ │ │ │ │(有状态) │ │(有状态) │ │(有状态) │ │(有状态) │ │ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────┴──────────────┴──────────────┘ │ │ │ │ │ │ │ │ │ ┌──────┴──────┐ │ │ │ │ │ PVC (申请) │ ← 我要10G存储 │ │ │ │ └──────┬──────┘ │ │ │ │ │ │ │ │ │ ┌──────┴──────┐ │ │ │ │ │ PV (实际) │ ← 给你10G存储 │ │ │ │ └──────┬──────┘ │ │ │ │ │ │ │ │ │ ┌────────────┼────────────┐ │ │ │ │ ▼ ▼ ▼ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │CSI Driver│ │CSI Driver│ │CSI Driver│ │ │ │ │ │(AWS EBS) │ │(Ceph) │ │(NFS) │ │ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ └─────────────┼────────────┼────────────┼──────────────────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │AWS EBS │ │ Ceph │ │ NFS │ │ │ │云盘 │ │分布式存储│ │网络存储 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 核心组件 │ │ - CSI Controller负责创建/删除卷、快照、扩容等控制操作 │ │ - CSI Node负责在Node上挂载/卸载卷 │ │ - StorageClass定义存储模板类型、性能、回收策略 │ └─────────────────────────────────────────────────────────────────────────────┘为什么需要CSI在CSI出现之前K8s的存储支持是写死在代码里的——想支持新的存储后端得改K8s源码等半年发版。CSI把存储驱动从K8s核心解耦出来让存储厂商可以自己开发驱动就像USB让外设厂商自己开发驱动一样。幽默一刻没有CSI的年代K8s存储就像老式的打印机接口——每种打印机都需要专门的并口线。CSI就是那个拯救世界的USB接口终于让存储厂商和K8s可以和平共处。PersistentVolume与StorageClass核心概念概念类比说明PersistentVolume (PV)硬盘集群中的实际存储资源PersistentVolumeClaim (PVC)购买申请Pod对存储的申请StorageClass硬盘型号存储的模板定义性能、类型等VolumeSnapshot快照存储的时间点备份完整示例从StorageClass到Pod使用# 1. 定义StorageClass管理员配置 # storageclass-fast.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd annotations: storageclass.kubernetes.io/is-default-class: true # 设为默认 provisioner: ebs.csi.aws.com # AWS EBS CSI Driver parameters: type: gp3 # SSD类型 encrypted: true # 加密 iops: 3000 # IOPS throughput: 125 # 吞吐量 MiB/s volumeBindingMode: WaitForFirstConsumer # 延迟绑定优化调度 allowVolumeExpansion: true # 允许扩容 reclaimPolicy: Retain # 保留策略Delete/Retain --- # 2. 创建PVC用户申请 # pvc-app.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-data namespace: production spec: accessModes: - ReadWriteOnce # 单节点读写 storageClassName: fast-ssd resources: requests: storage: 50Gi # 申请50GB --- # 3. Pod使用PVC # pod-with-pvc.yaml apiVersion: apps/v1 kind: Deployment metadata: name: postgres namespace: production spec: replicas: 1 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:15 env: - name: POSTGRES_DB value: myapp - name: POSTGRES_USER value: dbuser - name: POSTGRES_PASSWORD valueFrom: secretKeyRef: name: db-credentials key: password ports: - containerPort: 5432 volumeMounts: - name: data mountPath: /var/lib/postgresql/data resources: requests: memory: 512Mi cpu: 500m limits: memory: 1Gi cpu: 1000m volumes: - name: data persistentVolumeClaim: claimName: app-data动态供给 vs 静态供给┌─────────────────────────────────────────────────────────────────────────────┐ │ 静态供给 vs 动态供给 │ │ │ │ 静态供给Pre-provisioned │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 管理员 │────►│ 创建PV │────►│ 用户PVC │────►绑定 │ │ │ 手动创建 │ │ (NFS等) │ │ 申请 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 动态供给Dynamic Provisioning │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 管理员 │────►│StorageClass│──►│ 用户PVC │────►│ CSI自动 │────►PV创建 │ │ │ 配置模板 │ │ (模板) │ │ 申请 │ │ 创建PV │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 推荐生产环境使用动态供给按需创建用完回收 │ └─────────────────────────────────────────────────────────────────────────────┘访问模式详解# access-modes.yaml - 不同场景的访问模式选择 --- # ReadWriteOnce (RWO) - 单节点读写 # 适用数据库、单实例应用 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: database-storage spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi --- # ReadOnlyMany (ROX) - 多节点只读 # 适用静态文件、配置文件 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: static-assets spec: accessModes: - ReadOnlyMany resources: requests: storage: 10Gi --- # ReadWriteMany (RWX) - 多节点读写 # 适用共享存储、内容管理系统 # 注意需要存储后端支持NFS、CephFS、GlusterFS等 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: shared-storage spec: accessModes: - ReadWriteMany resources: requests: storage: 500Gi数据保护快照与恢复# 创建快照 # snapshot.yaml apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: postgres-snapshot-20240515 namespace: production spec: volumeSnapshotClassName: csi-aws-vsc source: persistentVolumeClaimName: app-data --- # 从快照恢复 # restore-from-snapshot.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-data-restored namespace: production spec: storageClassName: fast-ssd dataSource: name: postgres-snapshot-20240515 kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 50Gi⚠️避坑警告使用ReadWriteMany前务必确认你的存储后端支持AWS EBS、GCP PD都只支持RWO。需要RWX时考虑使用NFS、CephFS或AWS EFS。效率技巧设置volumeBindingMode: WaitForFirstConsumer可以让PVC等到Pod调度后再绑定这样K8s可以根据Pod的资源需求选择最优的Node而不是随机分配导致调度失败。文末三件套1. 【源码获取】关注此系列获取后续更新后台回复cni获取本文所有YAML配置文件的完整源码包。2. 【思考题】你的集群需要什么样的网络插件• 是追求简单快速的Flannel• 还是功能全面的Calico• 亦或是未来感十足的Cilium在评论区分享你的选择理由点赞最高的三位读者将获得《Kubernetes网络权威指南》电子书一本3. 【系列预告】本系列持续更新中下一期主题1.容器编排与调度→ 深度解析Scheduler让你的Pod去该去的地方2.GitOps实战→ ArgoCDFlux声明式持续交付的正确姿势3.Helm进阶→ Chart开发、版本管理、私有仓库搭建CSDN标签CNIFlannelCalicoCiliumCSIPVStorageClass网络插件Kubernetes云原生本文首发于CSDN转载请注明出处。如有疑问欢迎在评论区留言交流