Kubernetes 核心机制详解：网络通信、服务暴露、存储管理与Pod调度实战

好了380

631人浏览 · 2026-02-04 22:08:14

好了380 · 2026-02-04 22:08:14 发布

最近在自学 Kubernetes，刷了不少官方文档和实验，把网络、服务、存储、调度这些核心部分啃了好几遍。说实话，刚开始看 Service 和 Volume 的时候有点懵，概念太多，各种类型和模式容易混。但多敲了几次 yaml、多跑了几次 minikube 实验后，慢慢就理清楚了。这些东西在实际部署微服务、数据库、Web 应用时特别实用，基本决定了你的集群能不能稳、能不能扩、能不能安全。

这篇笔记把这些知识点系统整理了一下，重点讲清楚“是什么”“为什么这样设计”“实际场景怎么用”，顺带分享一些我踩过的坑和心得。代码片段都直接贴了，可以复制到集群里试（我用 minikube + kind 测试过）。适合想系统复习或者刚入门的同学慢慢看，边看边练效果最好。

Pod 之间的网络通信机制
Service 的代理模式：iptables vs IPVS
Service 类型详解与实际运用
LoadBalancer 在裸金属集群的实现：MetalLB
Ingress：七层流量入口的原理与功能
Pod 健康检测：Liveness、Readiness 与 Startup Probe
Pod 优雅关闭机制
Volume 基础：emptyDir 与 hostPath
持久化存储：PV、PVC 与访问模式
Pod 调度控制：节点选择、亲和性与污点
写在最后：学习心得与建议

1. Pod 之间的网络通信机制

Kubernetes 最牛的地方之一就是默认实现了“扁平网络”：每个 Pod 都有唯一的集群内 IP，Pod 之间可以直接通过 IP 通信，不需要 NAT 转换。

背后靠的是 CNI（Container Network Interface） 插件。常见的有 Flannel、Calico、Cilium 等。集群初始化时（kubeadm init）会指定 --pod-network-cidr，CNI 插件根据这个网段为每个 Pod 分配 IP。

实际运用：
开发微服务时，根本不用关心网络拓扑，直接用 Pod IP 或 Service 名访问就行。生产环境建议用 Calico（支持网络策略）或 Cilium（eBPF 高性能）。

小贴士：minikube 默认用 kindnet，kind 用 kindnet，生产别用默认的，换个成熟插件。

2. Service 的代理模式：iptables vs IPVS

Service 是把一组 Pod 暴露为统一入口的核心抽象。后端流量转发靠 kube-proxy 实现，有两种模式：

iptables（默认）：用 Linux iptables 规则做 NAT 转发。每个 Service 和每个 Endpoint 都会生成规则。简单可靠，但 Service 数量多（上千）时规则爆炸，性能下降明显。
IPVS（推荐大集群）：用 Linux Virtual Server（LVS）实现，内核级负载均衡，支持更多算法（rr、lc、sh 等）。规则数量少，性能高很多。

切换方式：

kubectl edit cm kube-proxy -n kube-system
# 修改 mode: "ipvs"
kubectl rollout restart ds kube-proxy -n kube-system

运用心得：小集群用 iptables 够了，节点超 100、Service 超 500 就切 IPVS。我实验时切了 IPVS 后，压力测试延迟明显低。

3. Service 类型详解与实际运用

Service 有几种常见类型，各有场景：

ClusterIP（默认）：分配集群内虚拟 IP，只允许集群内部访问。适合后端服务（如数据库、缓存）。

apiVersion: v1
kind: Service
metadata:
  name: mysql-svc
spec:
  selector:
    app: mysql
  ports:
    - port: 3306
      targetPort: 3306

NodePort：在每个节点开一个静态端口（30000-32767），外部通过节点IP:NodePort 访问。适合临时暴露或没有负载均衡器时。

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30001

Headless（clusterIP: None）：不分配虚拟 IP，直接返回后端 Pod IP 列表。适合 StatefulSet（如 MySQL 集群、主从复制）需要直接访问具体 Pod。

spec:
  clusterIP: None
  selector:
    app: nginx

运用总结：内部服务用 ClusterIP，开发测试用 NodePort，状态ful 应用用 Headless。

4. LoadBalancer 在裸金属集群的实现：MetalLB

云上 LoadBalancer 类型 Service 会自动分配公网 IP，但裸金属集群没有云负载均衡器，这时用 MetalLB。

原理：

配置 IP 地址池
Layer 2 模式（默认）：选举 leader 节点，用 ARP 响应 VIP
BGP 模式：与路由器建立 BGP 会话，发布路由

安装（bare metal）：

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml

配置地址池（Layer 2 示例）：

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: my-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.240-192.168.1.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: empty
  namespace: metallb-system

运用：公司内网集群暴露服务必备。BGP 模式更适合大集群。

5. Ingress：七层流量入口的原理与功能

Ingress 是七层（HTTP/HTTPS）流量管理资源，本身不转发流量，靠 Ingress Controller（常见 Nginx、Traefik、Istio）实现。

核心功能：

基于域名/路径路由
SSL 终止
重写、限流、认证等扩展

典型 Nginx Ingress 示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

运用：统一入口管理多个服务，比多个 LoadBalancer 省 IP。生产必配 TLS。

6. Pod 健康检测：Liveness、Readiness 与 Startup Probe

kubelet 通过探针检测容器状态：

Liveness：容器活着吗？失败 → 重启容器。适合死锁、自愈场景。
Readiness：准备好接收流量吗？失败 → 从 Service 摘除。适合启动预热、滚动升级。
Startup：启动阶段专用，成功前暂停 liveness 判断。适合慢启动应用（JVM 大应用）。

示例：

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

心得：数据库类用 startup + liveness，Web 类用 readiness + liveness。

7. Pod 优雅关闭机制

Pod 删除时，K8s 会：

发送 SIGTERM
等待 terminationGracePeriodSeconds（默认 30s）
超时后 SIGKILL

配置 preStop 钩子做收尾：

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 10 && nginx -s quit"]

运用：数据库、消息队列必须优雅关闭，避免数据丢失。

8. Volume 基础：emptyDir 与 hostPath

emptyDir：Pod 生命周期内临时共享目录，重启保留，Pod 删除清空。可用内存（medium: Memory）。
hostPath：挂载节点本地路径。适合采集节点日志，但有安全风险。

运用：sidecar 模式用 emptyDir 共享文件，DaemonSet 采集日志用 hostPath。

9. 持久化存储：PV、PVC 与访问模式

PV：集群级存储资源（NFS、Ceph、云盘）
PVC：Pod 对存储的申请，绑定 PV

访问模式：

ReadWriteOnce（RWO）：单节点读写
ReadOnlyMany（ROX）：多节点只读
ReadWriteMany（RWX）：多节点读写
ReadWriteOncePod：单 Pod 读写（最严格）

回收策略：Retain（手动）、Delete（自动删）、Recycle（已废弃）

运用：StatefulSet 用 PVC 持久化，RWX 用 NFS 共享。

10. Pod 调度控制：节点选择、亲和性与污点

nodeName：直接指定节点（绕过调度器）
nodeSelector：简单标签匹配
nodeAffinity：复杂匹配（requiredDuringSchedulingIgnoredDuringExecution 硬，preferred 软）
Taints/Tolerations：节点打污点（NoSchedule、PreferNoSchedule、NoExecute），Pod 加容忍才能调度上去

运用：GPU 节点打污点，只让 AI Pod 调度；亲和性把前后端 Pod 拉到同一可用区降低延迟。