Kubernetes网络策略如何实现

Kubernetes网络策略实现指南

说到Kubernetes的网络隔离，NetworkPolicy绝对是绕不开的核心组件。但很多人在实际落地时，要么策略不生效，要么一上来就开“全通”，导致安全形同虚设。其实，只要理清几个关键点，再配合几个典型示例，网络策略并没有想象中那么复杂。下面咱们一步步拆解。

一、前置准备：这些条件缺一不可

在动手之前，得先把基础设施搭好。首先，需要一个正常的Kubernetes集群，通过kubeadm init初始化Master节点，再用kubeadm join加入Worker节点，确保集群跑起来。

然后是最关键的一步——部署一个支持网络策略的CNI插件。Kubernetes本身不实现网络策略的底层逻辑，这活儿得交给第三方插件。目前市面上有几个成熟的选择：

• Calico：功能全面，支持复杂策略，推荐生产环境使用。安装命令很简单：kubectl apply -f https://docs.projectcalico.org/v3.25/manifests/calico.yaml。
• Cilium：基于eBPF技术，性能强悍，适合对网络延迟敏感的场景。
• Wea ve Net：上手容易，中小型集群的实惠选择。

要注意的是，插件不支持NetworkPolicy资源，那策略写得再漂亮也是白搭。

二、核心概念：先搞懂这几个字段

NetworkPolicy是一个标准的Kubernetes资源对象，通过YAML文件定义，作用是声明Pod的流量控制规则。下面几个关键字段需要记清楚：

• podSelector：通过标签选择目标Pod。比如matchLabels: {app: backend}就只对带app=backend标签的Pod生效。如果选择器留空，表示匹配当前命名空间内的所有Pod。
• policyTypes：定义策略类型。可选Ingress（控制入站流量）、Egress（控制出站流量），或者两者都写上。
• ingress：入站规则，里面包含from（流量来源，可以是Pod标签、命名空间或IP段）和ports（允许的端口和协议）。
• egress：出站规则，包含to（流量目标）和ports。

三、常见配置示例：从简单到复杂

理论说再多，不如直接看代码。下面从“完全隔离”到“组合策略”逐步演示。

示例1：默认拒绝所有入站流量

这是最基础的安全隔离策略——先关上门，再逐个开窗。通过空的podSelector匹配当前命名空间所有Pod，仅允许显式定义的流量进入，防止未授权访问。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: default
spec:
  podSelector: {}  # 匹配所有Pod
  policyTypes:
  - Ingress        # 仅控制入站流量

应用这个策略后，所有未明确允许的入站流量都会被拒绝。

示例2：允许特定Pod间通信（微服务隔离）

假设前端服务（app: frontend）需要访问后端服务（app: backend）的8080端口。我们可以这样写：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend        # 作用于后端Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend   # 来源必须是前端Pod
    ports:
    - protocol: TCP
      port: 8080

配置好之后，只有带app: frontend标签的Pod才能访问后端服务，其他Pod一律没门。

示例3：限制出站流量到特定IP段

数据库Pod（app: db）只允许访问外部10.0.0.0/24网段的3306端口（MySQL），防止它乱连外部服务，降低数据泄露风险。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-to-external
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db             # 作用于数据库Pod
  policyTypes:
  - Egress               # 仅控制出站流量
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 3306

这个策略特别适合需要严格限制数据库访问外部IP的场景。

示例4：组合策略（入站+出站）

更复杂的情况：用户服务Pod（app: user-service）既要接收前端Pod发来的80端口请求，又要能访问外部192.168.1.0/24网段的443端口。一条策略搞定：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: combined-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: user-service   # 作用于用户服务Pod
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.0/24
    ports:
    - protocol: TCP
      port: 443

四、应用与验证：怎么确认策略生效了？

写好了YAML，接下来就是部署和测试。

部署策略：kubectl apply -f .yaml

查看策略：kubectl get networkpolicies -n ，确认策略是否已经成功部署。

验证效果：创建一个临时测试Pod（比如BusyBox），模拟真实访问。例如：

kubectl run test-pod --image=busybox -it --rm --restart=Never -- sh

然后在测试Pod里尝试访问目标Pod（比如app: backend的8080端口）：wget -qO- http://:8080。根据策略预期，未被允许的流量会被拒绝，允许的则正常返回。

五、最佳实践：这些坑别踩

• 最小权限原则：从“默认拒绝所有流量”起步，逐步添加必要的允许规则。别图省事一开始就全通，安全这事经不起“万一”。
• 标签规范化：给Pod打上清晰的标签（例如app: frontend、env: production），策略匹配才能精准。标签乱写，策略就跟猜谜一样。
• 渐进式部署：先在测试命名空间里验证策略，确认不影响业务后再推到生产环境。一上来就在线上动策略，一旦配错可能导致服务中断。
• 定期审计策略：用kubectl get networkpolicies检查当前策略覆盖率，结合Prometheus等工具监控流量日志，及时发现并删除那些没人用的规则。

网络策略说难不难，但细节确实不少。记住一点：先阻断，再放行，配合清晰的标签和严谨的测试流程，就能把Kubernetes的网络隔离做得滴水不漏。