Ubuntu Overlay配置中如何管理网络策略 - 问答

Ubuntu Overlay网络策略管理指南

一、先明确你的Overlay类型

Docker Swarm Overlay：用于跨主机容器通信，依赖Docker Swarm管理面，创建网络后由Swarm内置控制面分发与维护。适合在Ubuntu上快速启用多主机容器网络。
Kubernetes/Calico Overlay：在K8s中通过CNI插件（如Calico）提供Overlay数据面，网络策略以K8s资源（如GlobalNetworkPolicy/NetworkPolicy）声明式管理，适合需要精细化策略与大规模集群的场景。
若只是单机环境，Overlay意义有限，优先使用bridge或host网络。

二、Docker Swarm场景的策略管理

前置条件与网络创建
- 初始化Swarm并加入节点（跨主机通信的前提）：docker swarm init / docker swarm join --token <TOKEN> <MANAGER_IP>:2377。
- 创建Overlay网络（可按需指定子网与网关）：docker network create --driver overlay --subnet=10.0.0.0/24 --gateway=10.0.0.1 my_overlay_network。
连接工作负载
- 部署服务时指定网络：docker service create --name web --network my_overlay_network nginx。
策略与隔离要点
- Swarm的“隔离”主要通过网络划分与服务发布端口实现：仅将需要对外暴露的服务以--publish发布到主机端口，其余服务默认仅在Overlay内可达。
- 细粒度访问控制建议结合入口/出口防火墙（见第四部分）限制Overlay子网与服务端口的访问。
验证与排障
- 查看网络与服务：docker network ls/inspect my_overlay_network、docker service ls/ps web。
- 进入容器验证连通性：docker exec -it <容器名> bash 后 ping 对端IP或解析服务名。

三、Kubernetes Calico场景的策略管理

部署与网络
- 使用Calico作为CNI（示例）：kubectl apply -f https://docs.projectcalico.org/v3.25/manifests/calico.yaml。

策略模型与示例

以GlobalNetworkPolicy或NetworkPolicy声明规则，按Pod选择器（selector）与命名空间控制E/W向流量。

示例（仅允许default命名空间内Pod访问某服务端口，其余默认拒绝）：

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-default-to-svc
  namespace: default
spec:
  selector: app == 'myapp'
  ingress:
  - action: Allow
    source:
      namespaceSelector: name == 'default'
    destination:
      ports:
      - protocol: TCP
        port: 80
  egress:
  - action: Allow

示例（全局默认拒绝并仅放行业务所需出站）：

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny-egress
spec:
  selector: all()
  types:
  - Egress
  egress:
  - action: Allow
    protocol: TCP
    destination:
      nets:
      - 10.0.0.0/16

验证与排障
- 查看策略生效：kubectl get networkpolicy -A、kubectl describe networkpolicy <name> -n <ns>。
- 结合Pod日志与calicoctl（如已安装）查看策略命中与流量审计。

四、主机与边界防火墙策略

UFW示例（限制Overlay子网访问）
- 仅允许Overlay子网访问SSH：sudo ufw enable、sudo ufw allow from 10.0.0.0/24 to any port 22。

nftables示例（按Overlay接口与子网精细化放行）

假设Overlay封装接口为vxlan0，仅放行Overlay网段与控制面端口：

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iifname "lo" accept
    ct state established,related accept
    udp dport 4789 accept  # VXLAN
    tcp dport 22 accept     # 管理
    ip saddr 10.0.0.0/24 accept
    counter
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    iifname "vxlan0" ip saddr 10.0.0.0/24 ip daddr 10.0.0.0/24 accept
    counter
  }
}

提示
- 避免与Docker/K8s的iptables/nftables规则冲突；变更前备份规则并在维护窗口操作。
- 云环境需同时检查安全组/NACL是否放行Overlay相关端口（如4789/UDP）。

五、实践建议与排障清单

规划与设计
- 明确网段划分（如10.0.0.0/24）、服务发布面与最小暴露原则；按命名空间/业务域拆分网络与策略。
运维与验证
- 定期导出与审计策略：docker network inspect、kubectl get networkpolicy -A -o yaml；变更遵循灰度与回滚。
- 常见故障排查：节点未加入Swarm导致Overlay不通；VXLAN端口被阻断；策略selector不匹配；主机/云安全组未放行。
适用边界
- Docker Swarm侧重网络与发布端口的“轻量隔离”；Kubernetes/Calico适合细粒度、可审计的策略治理与大规模生产场景。

0 赞

0 踩