K8s网络策略深度实验：用NetworkPolicy实现微服务隔离（含Calico实战）
K8s网络策略深度实验：用NetworkPolicy实现微服务隔离（含Calico实战）
在云原生架构中，微服务间的网络隔离是安全工程师必须掌握的核心技能。当多个租户或业务线共享同一个Kubernetes集群时，不加控制的Pod间通信可能引发严重的安全问题——某个被入侵的服务可能成为攻击跳板，横向渗透整个集群。本文将带您从零构建多租户微服务环境，通过NetworkPolicy实现精细化的网络访问控制，并结合Calico插件提供生产级解决方案。
1. 实验环境准备与基础概念
在开始之前，我们需要明确几个关键概念：NetworkPolicy是Kubernetes原生的网络隔离API，它通过标签选择器定义哪些Pod可以相互通信；而Calico作为CNI插件，则是NetworkPolicy的实际执行者，负责在底层实现这些策略。
实验环境需要以下组件：
- 已启用NetworkPolicy的Kubernetes集群（1.20+版本）
- Calico网络插件（3.15+版本）
- kubectl和calicoctl命令行工具
使用kubeadm创建集群时，需指定--pod-network-cidr并安装Calico：
kubeadm init --pod-network-cidr=192.168.0.0/16 kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml验证Calico安装：
kubectl get pods -n kube-system -l k8s-app=calico-node calicoctl get nodes2. 多租户微服务场景搭建
我们模拟一个电商平台，包含以下服务：
- 前端服务（frontend）
- 用户服务（user-service）
- 订单服务（order-service）
- 支付服务（payment-service）
- 数据库（mysql）
首先创建命名空间并部署服务：
# multi-tenant-ns.yaml apiVersion: v1 kind: Namespace metadata: name: tenant-a labels: tenant: a --- apiVersion: v1 kind: Namespace metadata: name: tenant-b labels: tenant: b部署示例微服务（以用户服务为例）：
# user-service.yaml apiVersion: apps/v1 kind: Deployment metadata: name: user-service namespace: tenant-a spec: replicas: 2 selector: matchLabels: app: user-service template: metadata: labels: app: user-service tier: backend spec: containers: - name: user-service image: my-registry/user-service:v1 ports: - containerPort: 80803. NetworkPolicy核心策略编写
3.1 默认拒绝所有流量
安全最佳实践是从"默认拒绝"开始，再逐步开放必要通信：
# default-deny-all.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: tenant-a spec: podSelector: {} policyTypes: - Ingress - Egress3.2 允许前端访问用户服务
仅允许来自前端服务的HTTP流量：
# allow-frontend-to-user.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-user namespace: tenant-a spec: podSelector: matchLabels: app: user-service policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 80803.3 跨命名空间通信控制
允许tenant-a的前端访问tenant-b的API服务：
# cross-tenant-access.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-tenant-a-frontend namespace: tenant-b spec: podSelector: matchLabels: app: api-service policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: tenant: a podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 80804. Calico高级策略实战
Calico扩展了NetworkPolicy功能，支持更复杂的场景：
4.1 基于CIDR的访问控制
只允许办公网IP访问管理接口：
# allow-office-ip.yaml apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: allow-office-ip spec: selector: app == 'admin-console' ingress: - action: Allow source: nets: [ "192.168.100.0/24" ] destination: ports: [8080] - action: Deny destination: ports: [8080]4.2 微服务间依赖关系可视化
使用Calico的Flow Visualization功能：
calicoctl get globalnetworkpolicies -o wide calicoctl get networkpolicy --all-namespaces5. 策略调试与故障排查
当网络策略不生效时，按以下步骤排查：
检查策略应用状态：
kubectl describe networkpolicy -n tenant-a calicoctl get networkpolicy -n tenant-a -o yaml验证Pod标签匹配：
kubectl get pods -n tenant-a --show-labels测试网络连通性：
kubectl run -it --rm --image=nicolaka/netshoot test-pod -n tenant-a # 在测试Pod内执行 curl -v http://user-service:8080查看Calico日志：
kubectl logs -l k8s-app=calico-node -n kube-system
常见问题解决方案：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 所有流量被阻断 | 缺少默认允许DNS的策略 | 添加允许kube-dns的规则 |
| 跨命名空间不通 | 命名空间标签不匹配 | 检查namespaceSelector的标签 |
| 部分Pod无法通信 | 端口定义错误 | 确认Pod实际监听端口 |
6. 生产环境最佳实践
6.1 策略即代码管理
将NetworkPolicy纳入CI/CD流程，使用Kustomize或Helm管理：
network-policies/ ├── base │ ├── default-deny-all.yaml │ └── kustomization.yaml └── overlays ├── production │ ├── frontend-policies.yaml │ └── kustomization.yaml └── staging ├── relaxed-policies.yaml └── kustomization.yaml6.2 分层防御策略
- 基础设施层：节点网络ACL
- 集群层：NetworkPolicy
- 应用层：服务网格(mTLS)
- 运行时层：Pod安全策略
6.3 监控与告警配置
通过Prometheus监控网络策略拦截情况：
# calico-metrics.yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: calico-monitor namespace: monitoring spec: selector: matchLabels: k8s-app: calico-node endpoints: - port: calico-metrics-port关键监控指标：
felix_active_policies：活跃策略计数felix_active_selectors：活跃选择器计数felix_drops_by_policy：按策略分类的丢包数
7. 安全架构演进建议
随着业务复杂度提升，建议分阶段实施网络隔离：
- 初级阶段：命名空间隔离 + 默认拒绝
- 中级阶段：服务间最小权限通信
- 高级阶段：零信任架构 + 服务网格集成
与Service Mesh的集成方案：
# istio-integration.yaml apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: mesh-policy namespace: tenant-a spec: selector: matchLabels: app: payment-service rules: - from: - source: namespaces: ["tenant-a"] principals: ["cluster.local/ns/tenant-a/sa/frontend"] to: - operation: ports: ["8080"]在实施过程中发现，将NetworkPolicy与服务网格策略结合使用时，需要特别注意规则的执行顺序——Calico在网络层执行过滤，而Istio在应用层进行鉴权，两者形成纵深防御。