文档备案控制台登录立即注册
首页文章问答视频活动下载资源团队号镜像站
发布

Kubernetes 中如何给 NodePort 配置 NetworkPolicy

陈少文
陈少文
云原生
技术
  1. 需求背景

picture.image

如上图，业务方需要隔离 namespae 的服务，禁止 bar 空间的负载访问，而允许用户从 Load Balancer (LB) 通过 NodePort 访问服务。可以很容易地写出一个网络策略:


        
          
apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
  name: test-network-policy  
  namespace: foo  
spec:  
  podSelector:  
    matchLabels: {}  
  policyTypes:  
  - Ingress  
  ingress:  
  - from:  
    - ipBlock:  
        cidr: 10.2.3.4/32  
    - namespaceSelector:  
        matchExpressions:  
        - key: region  
          operator: NotIn  
          values:  
          - bar

然而从 LB 访问的流量被完全禁止，不符合预期。在技术社区检索得到的答案可能是，Kubernetes NetworkPolicy 主要针对的是集群内的访问策略，而外部流量经过 SNAT 之后，IP 发生变化无法命中策略。

不同的网络插件，使用不同的模式，配置会有差异。本文仅提供一个思路，以常见的 Calico IPIP 模式为例配置 NodePort 的流量访问策略。

  1. 预备知识点

2.1 Kubernetes 中的 NetworkPolicy

在文档 Kubernetes 之网络隔离(内附十多种使用场景)[1] 中，我对 Kubernetes 的 NetworkPolicy 有所描述，给出了很多示例。

NetworkPolicy 是 Kubernetes 中的网络隔离对象，用来描述网络隔离策略，具体实现依赖于网络插件。目前，Calico、Cilium、Weave Net 等网络插件都支持网络隔离功能。

2.2 Calico 的几种工作模式

  • BGP 模式

在 BGP 模式下，集群中的 BGP 客户端两两互联，同步路由信息。

  • Route Reflector 模式

在 BGP 模式下，客户端连接数量达到 N * (N - 1)，N 表示节点的数量。这种方式限制了节点的规模，社区建议不超过 100 个节点。

Route Reflector 模式下，BGP 客户端不需要两两同步路由信息，而是将路由信息同步到若干指定的 Route Reflector 。全部 BGP 客户端只需要和 Route Reflector 建立连接即可，连接数量与节点数量线性相关。

  • IPIP 模式

不同于 BGP 模式，IPIP 模式是通过 tunl0 在节点之间建立隧道，实现网络连通。下图描述了 IPIP 模式下 Pod 之间的流量。

picture.image

  1. 为什么网络策略不生效

在前面的文档 Kubernetes 中如何获取客户端真实 IP[2 中，我描述过 externalTrafficPolicy 对服务流量的影响。

picture.image

Cluster 模式下，如果访问 node-2:nodeport，流量将被转发到有服务 Pod 的节点 node-1 上。

picture.image

Local 模式下，如果访问的 node-2:nodeport，流量不会被转发，无法响应请求。

通常我们默认采用的是 Cluster 模式，而 Cluster 模式在转发流量时会进行 SNAT，也就是修改源地址。这会导致访问请求无法命中网络策略，误以为网络策略没有生效。

这里尝试两种解决办法:

  1. 将 SNAT 之后的源地址也添加到访问白名单中

  2. 使用 Local 模式。由于 LB 有探活的功能，能将流量转发到具有服务 Pod 的节点上，从而保留了源地址。

  3. NodePort 下的 NetworkPolicy 配置

4.1 测试环境

  • Kubernetes 版本

v1.19.8

  • kube-proxy 转发模式

IPVS

  • 节点信息

        
          
kubectl get node -o wide  
  
NAME    STATUS   ROLES           AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION    CONTAINER-RUNTIME  
node1   Ready    master,worker   34d   v1.19.8   10.102.123.117   <none>        CentOS Linux 7 (Core)   3.10.0-1127.el7.x86_64   docker://20.10.6  
node2   Ready    worker          34d   v1.19.8   10.102.123.104   <none>        CentOS Linux 7 (Core)   3.10.0-1127.el7.x86_64   docker://20.10.6  
node3   Ready    worker          34d   v1.19.8   10.102.123.143   <none>        CentOS Linux 7 (Core)   3.10.0-1127.el7.x86_64   docker://20.10.6
  • 测试的负载

        
          
kubectl -n tekton-pipelines get pod -o wide  
  
NAME                                          READY   STATUS    RESTARTS   AGE   IP         NODE    NOMINATED NODE   READINESS GATES  
tekton-dashboard-75c65d785b-xbgk6             1/1     Running   0          14h   10.233.96.32    node2   <none>           <none>

负载运行在 node2 节点上

  • 测试的服务

        
          
kubectl -n tekton-pipelines get svc  
  
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                              AGE  
tekton-dashboard              NodePort    10.233.5.155    <none>        9097:31602/TCP                       10m

4.2 NodePort 流量如何转发到 Pod

这里主要考虑两种情况。

  1. 访问不存在 Pod 负载的节点 node1
  • 服务转发规则

        
          
ipvsadm  -L  
  
TCP  node1:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  node1:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  node1.cluster.local:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  node1:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  localhost:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0

可以看到访问 node1:31602 的流量被转发到了 10.233.96.32:9097，也就是服务 Pod 的 IP 地址和端口。

  • IP 路由转发规则

接着看路由转发规则，10.233.96.0/24 网段的访问都会被转到 tunl0，经过隧道到达 node2 再转到服务中。


        
          
route  
  
Kernel IP routing table  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  
10.233.92.0     node3.cluster.l 255.255.255.0   UG    0      0        0 tunl0  
10.233.96.0     node2.cluster.l 255.255.255.0   UG    0      0        0 tunl0
  1. 访问存在 Pod 负载的节点 node2
  • 服务转发规则

        
          
ipvsadm  -L  
  
TCP  node2:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  node2:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  node2.cluster.local:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          1  
  
TCP  node2:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0  
  
TCP  localhost:31602 rr  
  -> 10.233.96.32:9097            Masq    1      0          0

与 node1 一样，访问 node2 上的 NodePort 服务也会被转发到服务 Pod 的 IP 地址和端口上。

  • 路由转发规则

但是路由规则不一样，目的地址为 10.233.96.32 的包会发给 cali73daeaf4b12 。而 cali73daeaf4b12 与 Pod 中的网卡构成一组 veth pair，流量会被直接发往服务 Pod 中。


        
          
route  
  
Kernel IP routing table  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  
10.233.90.0     node1.cluster.l 255.255.255.0   UG    0      0        0 tunl0  
10.233.92.0     node3.cluster.l 255.255.255.0   UG    0      0        0 tunl0  
10.233.96.32    0.0.0.0         255.255.255.255 UH    0      0        0 cali73daeaf4b12

从上面命令返回可以知道，如果访问不存在 Pod 负载的节点，流量会经过 tunl0 转发；如果访问存在 Pod 负载的节点，流量不经过 tunl0 直接被路由到 Pod 中。

4.3 方案一，将 tunl0 添加到网络策略白名单

  • 查看各个节点的 tunl0 信息

node1


        
          
ifconfig  
  
tunl0: flags=193<UP,RUNNING,NOARP>  mtu 1440  
        inet 10.233.90.0  netmask 255.255.255.255

node2


        
          
ifconfig  
  
tunl0: flags=193<UP,RUNNING,NOARP>  mtu 1440  
        inet 10.233.96.0  netmask 255.255.255.255

node3


        
          
ifconfig  
  
tunl0: flags=193<UP,RUNNING,NOARP>  mtu 1440  
        inet 10.233.92.0  netmask 255.255.255.255
  • 网络策略配置

        
          
apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
  name: test-network-policy  
  namespace: foo  
spec:  
  podSelector:  
    matchLabels: {}  
  policyTypes:  
  - Ingress  
  ingress:  
  - from:  
    - ipBlock:  
        cidr: 10.2.3.4/32  
    - ipBlock:  
        cidr: 10.233.90.0/32  
    - ipBlock:  
        cidr: 10.233.96.0/32  
    - ipBlock:  
        cidr: 10.233.92.0/32  
    - namespaceSelector:  
        matchExpressions:  
        - key: region  
          operator: NotIn  
          values:  
          - bar
  • 测试验证

不符合预期。全部经过 tunl0 的流量都会被允许。bar 命名空间的负载可以通过访问 node1:31602、node3:31602、tekton-dashboard.tekton-pipelines.svc:9097(非 node2 上的负载) 访问服务，无法对流量进行限制。

4.4 方案二，使用 Local 模式

  • 修改 svc 的 externalTrafficPolicy 为 Local 模式

        
          
kubectl -n tekton-pipelines get svc tekton-dashboard -o yaml  
  
apiVersion: v1  
kind: Service  
metadata:  
  name: tekton-dashboard  
  namespace: tekton-pipelines  
spec:  
  clusterIP: 10.233.5.155  
  externalTrafficPolicy: Local  
...
  • 拒绝全部入口流量

        
          
kind: NetworkPolicy  
apiVersion: networking.k8s.io/v1  
metadata:  
  name: test-network-policy-deny-all  
  namespace: foo  
spec:  
  podSelector:  
    matchLabels: {}  
  ingress: []
  • 添加访问白名单

        
          
apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
  name: test-network-policy  
  namespace: foo  
spec:  
  podSelector:  
    matchLabels: {}  
  policyTypes:  
  - Ingress  
  ingress:  
  - from:  
    - ipBlock:  
        cidr: 10.2.3.4/32
  • 测试验证

符合预期。使用上面的网络策略，可以满足业务需求，屏蔽 bar 命名空间的访问，允许外部通过 LB 转发到 NodePort 的访问。

  1. 总结

网络是 Kuberntes 中相对难以掌握的部分，但网络又是对业务影响范围比较大、影响程度比较深远的一个方面。因此，多花一点时间在网络上，是必要而值得的。

本文主要结合业务需求，对 Calico 的网络模式进行了更进一步的阐述，解决了因为 SNAT 导致源 IP 发生变化，最终 NetworkPolicy 不符合预期的问题。

在 Calico 的 IPIP 模式下，针对 NodePort 的访问策略需要使用 externalTrafficPolicy: Local 流量转发模式。再结合网络策略最佳实践，先禁用全部流量之后，添加白名单策略。

  1. 参考

参考资料

[1] Kubernetes 之网络隔离(内附十多种使用场景): https://www.chenshaowen.com/blog/network-policy-of-kubernetes.html

[2] Kubernetes 中如何获取客户端真实 IP: https://www.chenshaowen.com/blog/how-to-get-the-real-ip-of-client-in-kubernetes.html

0
0
0
0
关于作者
陈少文
陈少文
关于作者
陈少文
陈少文

文章

0

获赞

0

收藏

0

相关资源
CloudWeGo白皮书：字节跳动云原生微服务架构原理与开源实践
本书总结了字节跳动自2018年以来的微服务架构演进之路
点击下载 
相关产品
推荐阅读
DeepSeek 本地部署——蒸馏版、量化版和满血版实测效果对比
DeepSeek搭建个人知识库（指南）
火山引擎云上实战：一键部署 DeepSeek 大模型（蒸馏版）
DeepSeek 的联网搜索用不好就是灾难
Deep Research技术盘点！比RAG更高级的LLM应用范式
评论
未登录
看完啦，登录分享一下感受吧～
暂无评论