如何选择使用flannel或calico作为k8s集群的CNI

📊 Flannel 与 Calico 核心对比

特性维度	Flannel​	Calico​
核心定位​	轻量级“网络打通器”，专注于基础连通性	企业级网络方案，以路由为核心，提供高性能和高级功能
实现原理​	Overlay网络（默认VXLAN），通过隧道封装跨节点流量。也支持 Host-GW（主机网关）模式	BGP路由（无封装，性能最佳）。也支持 IPIP、VXLAN​ 等隧道模式以适应复杂网络
性能​	中等。VXLAN模式有封装开销；Host-GW模式性能接近原生，但要求节点在同一二层网络	优秀。BGP模式无封装，性能接近物理网络，尤其擅长东西向流量
网络策略​	不支持​ Kubernetes原生NetworkPolicy	原生支持​ Kubernetes NetworkPolicy，并提供更细粒度的Calico策略，可实现Pod间精细的访问控制
部署与运维​	极简，配置简单，适合快速上手和运维	中等复杂度，需要理解BGP或隧道配置，但社区成熟，文档丰富
适用规模​	中小规模集群（通常建议50节点以下）	大规模生产集群（支持数百至上万节点）
高级功能​	功能单一，主要提供网络连通性	功能全面，支持网络加密（IPsec）、服务负载均衡、流量可视化、IPv6等

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

如何理解K8S中的NetworkPolicy?

Kubernetes NetworkPolicy​ 是一种用于控制 Pod 之间以及 Pod 与外部网络端点之间通信流量的资源对象。它本质上是一个基于标签的、声明式的防火墙规则，允许您在集群内部实现精细化的网络隔离和安全策略。

🎯 核心目标

• Pod 间隔离：默认情况下，Kubernetes 集群内的所有 Pod 可以相互通信。NetworkPolicy 打破了这种“全通”模式，实现了“最小权限”原则。

• 流量控制：定义哪些 Pod 可以相互通信（入站/出站），以及可以访问哪些端口。

📝 关键概念与工作原理

1. 选择器（Selector）：NetworkPolicy 通过 podSelector选择一组 Pod 作为规则的作用对象（目标 Pod）。

2. 策略类型（PolicyTypes）：

   • Ingress：控制进入目标 Pod 的流量（谁可以访问我）。

   • Egress：控制离开目标 Pod 的流量（我可以访问谁）。

3. 规则（Rules）：在 ingress或 egress字段下定义具体的允许规则。

   • from/ to：指定流量的来源或目的地。可以是：

     • podSelector：匹配另一组 Pod。

     • namespaceSelector：匹配特定命名空间中的所有 Pod。

     • ipBlock：指定 CIDR 范围的 IP 地址块。

   • ports：指定允许访问的端口和协议（如 TCP 80 端口）。

⚙️ 生效前提（非常重要！）

NetworkPolicy 本身只是一个声明，它的实际执行依赖于网络插件（CNI）。只有支持 Kubernetes NetworkPolicy 的 CNI 插件才能实现这些规则。例如：

• 支持：Calico、Cilium、Weave Net、Antrea​ 等。

• 不支持：Flannel（默认安装）不支持。如果使用 Flannel 并需要策略，通常需额外部署 Calico 等插件。

📄 配置示例

以下是一个典型的 NetworkPolicy 定义示例，它允许来自特定标签的 Pod 访问目标 Pod 的特定端口。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  # 1. 此策略应用于哪些Pod？（目标Pod）
  podSelector:
    matchLabels:
      app: backend-api
  # 2. 策略类型：同时控制入站和出站
  policyTypes:
  - Ingress
  - Egress
  # 3. 入站规则：允许来自特定Pod的流量
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend-web
    ports:
    - protocol: TCP
      port: 8080
  # 4. 出站规则：允许目标Pod访问外部DNS
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

 

🛡️ 典型应用场景

1. 微服务隔离：例如，只允许前端服务 Pod 访问后端 API Pod，禁止数据库 Pod 被前端直接访问。

2. 命名空间隔离：限制 production命名空间中的 Pod 不能被 development命名空间的 Pod 访问。

3. 外部访问控制：限制某些 Pod 只能访问特定的外部 IP 或域名。

4. 默认拒绝策略：创建一个“默认拒绝所有”的 Policy，然后逐步添加允许规则，构建零信任网络模型。

💡 最佳实践与注意事项

• 策略是累加的：如果一个 Pod 被多个 NetworkPolicy 选中，这些策略的规则是叠加（取并集）的。不存在“拒绝”规则，只有“允许”规则；未明确允许的流量将被拒绝。

• 命名空间范围：NetworkPolicy 是命名空间级别的资源。定义时需要明确其所属的命名空间。

• 谨慎使用空选择器：podSelector: {}表示选择当前命名空间下的所有 Pod。

• 测试与验证：应用策略后，务必使用 kubectl exec或网络测试工具（如 curl、nc）验证策略是否按预期生效。

总之，NetworkPolicy 是 Kubernetes 安全架构中至关重要的一环，是实现服务网格安全、合规性要求（如 PCI DSS）和多租户隔离的基础工具。