Ubuntu上Kubernetes网络策略配置

Ubuntu上Kubernetes网络策略配置

一 前置条件与网络插件

• 在 Ubuntu 节点安装并初始化集群，注意将 –pod-network-cidr 与所选网络插件的 Pod 网段保持一致（如 10.244.0.0/16）。初始化完成后部署网络插件，常见选择为 Calico（支持细粒度网络策略）、Flannel（轻量 Overlay，策略能力有限）、或 Cilium（基于 eBPF，高性能且支持 L7 策略）。示例（Calico）：kubectl apply -f https://docs.projectcalico.org/manifests/tigera-operator.yaml 与 kubectl apply -f https://docs.projectcalico.org/manifests/custom-resources.yaml。部署完成后确认节点变为 Ready，插件 Pod 均为 Running。

二 策略语言与生效前提

• NetworkPolicy 属于命名空间作用域，通过 podSelector 选择被保护的 Pod，使用 policyTypes: Ingress/Egress 声明方向，规则为白名单模型（未匹配的流量默认拒绝）。from/to 支持三类来源/去向：
  • podSelector：同一命名空间内匹配标签的 Pod；
  • namespaceSelector：匹配标签的命名空间内的所有 Pod；
  • ipBlock：匹配 CIDR（常用于外部客户端或节点网段），可用 except 排除子段。
• 重要特性与注意：
  • 同一命名空间内，未匹配任何策略的 Pod 之间默认仍可互通；如需“全拒绝”，需显式创建拒绝策略或使用默认拒绝的插件/准入控制器方案。
  • 对 Service 的访问：入口策略通常应允许来自 kube-system 中 kube-proxy 所在 Pod（常见标签为 k8s-app=kube-proxy）的流量，否则 ClusterIP/NodePort 访问可能被拦截。
  • 对 LoadBalancer/ExternalIP：源地址通常是节点或负载均衡器地址，策略中常用 ipBlock 放通对应网段。
  • 跨命名空间访问 SVC：使用 ..svc.cluster.local 形式，策略需正确选择 namespaceSelector/podSelector。

三 常用网络策略模板

• 默认拒绝入站（仅放通明确来源）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

• 仅允许同命名空间访问某端口（例如 80）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-ns-http
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}   # 同命名空间任意 Pod
    ports:
    - protocol: TCP
      port: 80

• 允许来自指定命名空间与特定客户端 Pod 访问

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ns-and-client
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: myproj
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379

• 允许访问外部服务网段（出方向）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-dbnet
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: fetcher
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.1.2.0/24
    ports:
    - protocol: TCP
      port: 5432

• 放通 kube-proxy 访问 Service（保证 ClusterIP/NodePort 可用）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-kube-proxy-to-services
  namespace: kube-system
spec:
  podSelector:
    matchLabels:
      k8s-app: kube-proxy
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 443   # 访问 kube-apiserver 的 Service 端口
    - protocol: TCP
      port: 53    # CoreDNS

• 使用 ipBlock 限制来源网段（示例：仅内网网段）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.26.0/24
        except:
        - 192.168.26.71/32   # 例如禁止某个管理地址
    ports:
    - protocol: TCP
      port: 80

以上模板可直接按需组合使用；策略是按命名空间生效的，跨命名空间访问需为目标命名空间设置相应 namespaceSelector 或在目标命名空间部署对等策略。

四 验证与排错

• 快速验证步骤
  • 查看策略是否生效：kubectl get networkpolicy -A；查看被保护 Pod 标签是否匹配策略选择器。
  • 连通性测试：在被允许/被拒绝的源 Pod 中执行 curl/wget 或 nc，例如 kubectl run t -it --rm --image=busybox:1.36 --restart=Never – wget -qO- http://<目标Pod或SVC>。
  • 观察事件与日志：kubectl describe networkpolicy ；查看相关组件（如 kube-proxy、CoreDNS）日志与 Endpoints/EndpointSlice 是否正常。
• 常见问题与要点
  • 策略未生效：检查 namespace/podSelector 是否匹配、是否遗漏 policyTypes、是否未放通 kube-proxy 对 Service 的访问。
  • 使用 ipBlock 时，注意其匹配的是连接对端的源 IP；对 LoadBalancer/NodePort 场景，源 IP 常为节点或负载均衡器地址，应放通对应网段。
  • 跨命名空间访问 SVC 需使用 ..svc.cluster.local；策略中需正确选择 namespaceSelector/podSelector。
  • 若使用 Flannel，其策略能力相对有限；需要细粒度策略时优先选择 Calico/Cilium。