从零构建K8s网络：CNI插件选型与网络策略实战

1. Kubernetes网络模型基础解析

第一次接触Kubernetes网络时，我被它的设计理念深深吸引。与传统的虚拟机网络不同，Kubernetes提出了一种全新的网络模型，要求所有Pod无论运行在哪个节点上，都能直接通过IP地址相互通信。这种扁平化的网络设计让服务发现和负载均衡变得异常简单。

在实际部署中，我发现Kubernetes网络模型有几个关键特性特别值得注意：

• IP-per-Pod原则：每个Pod都拥有独立的IP地址，这个IP在集群内全局可达
• 无NAT通信：Pod之间的通信不需要经过地址转换
• 跨节点直连：不同节点上的Pod可以直接通信，就像在同一个局域网内

记得去年我在部署第一个生产集群时，遇到一个典型问题：虽然Pod之间可以互相ping通，但某些服务的响应特别慢。后来发现是因为默认安装的Flannel插件使用了UDP后端，而换成VXLAN后性能立即提升了30%。这个经历让我深刻理解到，选择适合的CNI插件对集群性能有多重要。

2. 主流CNI插件深度对比

2.1 Flannel：简单易用的入门选择

Flannel是我推荐给初学者的首选插件。它的配置简单到令人发指，基本上只需要在etcd中设置一个网络范围就能工作。我最喜欢它的host-gw模式，这种模式下数据包直接通过主机路由转发，没有额外的封装开销。

不过Flannel也有明显的局限性。去年在一个金融项目上，客户要求实现细粒度的网络策略控制，这时Flannel就力不从心了。它的典型配置示例如下：

# Flannel的etcd配置示例 { "Network": "10.244.0.0/16", "SubnetLen": 24, "Backend": { "Type": "vxlan", "Directrouting": true } }

2.2 Calico：企业级网络方案

当项目需要更高级的网络功能时，我会毫不犹豫选择Calico。它不仅支持标准的Pod间通信，还提供了强大的网络策略功能。Calico使用BGP协议传播路由信息，这种设计让它在大规模集群中表现优异。

我最近在一个跨数据中心的部署中使用了Calico的IPIP隧道模式。虽然性能比纯路由模式稍差，但解决了跨机房网络隔离的问题。Calico的配置相对复杂，但带来的灵活性是值得的：

# 安装Calico kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

2.3 其他插件选型建议

除了Flannel和Calico，还有一些值得关注的CNI插件：

• Cilium：基于eBPF技术，适合高性能场景
• Weave Net：内置简单的网络策略功能
• kube-router：纯路由方案，性能极佳

选择插件时我通常会考虑这些因素：

1. 集群规模大小
2. 是否需要网络策略
3. 对网络性能的敏感度
4. 团队的技术熟悉度

3. 网络策略实战指南

3.1 基础网络策略配置

网络策略是Kubernetes中经常被忽视但极其重要的功能。记得有一次，我们的测试环境突然出现大量异常流量，后来发现是因为没有配置任何网络策略，导致所有Pod都能被任意访问。

一个基本的网络策略应该包含以下要素：

• podSelector：选择应用策略的Pod
• policyTypes：指定策略类型（Ingress/Egress）
• ingress/egress规则：定义具体的访问规则

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: basic-allow spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 80

3.2 高级策略模式

随着经验积累，我总结出几种实用的高级策略模式：

多租户隔离：在SaaS平台中，确保不同客户的Pod完全隔离

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: tenant-isolation spec: podSelector: matchLabels: tenant: acme policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: tenant: acme egress: - to: - podSelector: matchLabels: tenant: acme

数据库访问控制：只允许特定应用访问数据库

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-access spec: podSelector: matchLabels: app: mysql policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: backend ports: - protocol: TCP port: 3306

4. 生产环境最佳实践

4.1 网络性能优化技巧

经过多次性能测试，我发现这些优化措施最有效：

1. 选择合适的CNI插件后端：VXLAN适合大多数场景，host-gw在同类网络中性能更好
2. 调整MTU值：避免IP分片，通常设置为1450效果不错
3. 启用Pod就绪探测：避免流量被发送到未准备好的Pod
4. 合理设置资源限制：防止网络密集型应用占用过多带宽

4.2 故障排查经验

网络问题排查是运维Kubernetes集群的必备技能。我常用的诊断命令包括：

# 检查Pod网络配置 kubectl exec -it <pod-name> -- ip addr # 测试Pod间连通性 kubectl run -it --rm --image=alpine testpod -- ping <target-pod-ip> # 检查网络策略生效情况 kubectl describe networkpolicy <policy-name> # 查看节点路由表 ip route show

记得有一次，某个节点的Pod突然无法访问外网，经过排查发现是节点的iptables规则被误删。这个教训让我养成了定期检查网络配置的习惯。

4.3 安全加固建议

生产环境中，我通常会实施这些安全措施：

1. 默认拒绝所有流量，然后按需开放
2. 限制Pod的出站流量
3. 监控异常网络活动
4. 定期审计网络策略

# 默认拒绝所有流量的策略 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes: - Ingress - Egress

在云原生时代，网络设计直接影响着应用的可靠性和性能。从CNI插件选型到网络策略实施，每个决策都需要结合具体业务场景。经过多个项目的实践验证，我发现没有放之四海皆准的方案，只有最适合当前需求的解决方案。