kubernetes network policy学习笔记

电玩女神 2022-02-26 13:54 183阅读 0赞

## 简介 ##

network policy顾名思义就是对pod进行网络策略控制。 k8s本身并不支持，因为k8s有许多种网络的实现方式，企业内部可以使用简单的flannel、weave、kube-router等，适合公有云的方案则有calico等。不同的网络实现原理（vethpair、bridge、macvlan等）并不能统一地支持network policy。

## network policy 策略模型 ##

使用`network policy`资源可以配置pod的网络，networkPolicy是namespace scoped的，他只能影响某个namespace下的pod的网络出入站规则。

*  metadata 描述信息
 *  podSelector pod选择器，选定的pod所有的出入站流量要遵循本networkpolicy的约束
 *  policyTypes 策略类型。包括了Ingress和Egress，默认情况下一个policyTypes的值一定会包含Ingress，当有egress规则时，policyTypes的值中会包含Egress
 *  ingress 入站
 *  egress 出站

策略模型可以参考[官方文档][Link 1]， 这里举个例子：

apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: test-network-policy
      namespace: default
    spec:
      podSelector:
        matchLabels:
          role: db
      policyTypes:
      - Ingress
      - Egress
      ingress:
      - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
            - 172.17.1.0/24
        - namespaceSelector:
            matchLabels:
              project: myproject
        - podSelector:
            matchLabels:
              role: frontend
        ports:
        - protocol: TCP
          port: 6379
      egress:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/24
        ports:
        - protocol: TCP
          port: 5978

该例子的效果如下：  
1、`default` namespace下label包含`role=db`的pod，都会被隔绝，他们只能建立“满足networkPolicy的ingress和egress描述的连接”。即2-5点：  
2、所有属于`172.17.0.0/16`网段的IP，除了`172.17.1.0/24`中的ip，其他的都可以与上述pod的6379端口建立tcp连接。  
3、所有包含label：`project=myproject`的namespace中的pod可以与上述pod的6379端口建立tcp连接；  
4、所有`default` namespace下的label包含`role=frontend`的pod可以与上述pod的6379端口建立tcp连接；  
5、允许上述pod访问网段为`10.0.0.0/24`的目的IP的5978端口。

再例，如果我们想要只允许default这个namespace下label包含access=true的pod访问nginx pod（label：run=nginx）,可以对nginx pod设置入站规则：

kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: access-nginx
      namespace: default
    spec:
      podSelector:
        matchLabels:
          run: nginx
      ingress:
      - from:
        - podSelector:
            matchLabels:
              access: "true"

另外一些默认的规则：  
1.同namespace的pod，入站规则为全部禁止

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

2.同namespace的pod，入站规则为全部开放：

apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-all
    spec:
      podSelector: {}
      ingress:
      - {}

3.同namespace的pod，出站规则为全部禁止

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

4.同namespace的pod，出站规则为全部开放

apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-all
    spec:
      podSelector: {}
      egress:
      - {}
      policyTypes:
      - Egress

## network policy的实现 ##

network policy的实现仰赖CNI插件的支持，目前已经支持的cni插件包括：  
Calico 。calico本身通过BGP路由实现容器网络，network policy大致也是通过它实现的。  
Cilium  
Kube-router。 这个工具比较吸引人，因为他使用iptables实现networkpolicy，同时它也能成为kube-proxy组件的替代品。  
Romana  
Weave Net。也是通过iptables实现出入站策略。（看了社区的例子，里面针对namespace级别的控制好像要用正则表达式进行匹配）  
这些容器网络解决方案，在支持networkpolicy时，均需要在node上启动agent（可以用k8s的daemonset）

## 思考：与neutron 网络中安全组的区别 ##

其实network policy要做的事情，安全组一样可以做。但network policy可以做到namespace范围的整体控制。  
思考一个networkpolicy agent要做的事情，应该包含以下几点：  
1、对networkpolicy进行全namespace范围的list & watch；  
2、对规则原语的解析和定制。（如何将namespace、label等概念具象到iptables中？我的想法比较笨拙：使用正则表达式表述pod name的规则，同时list-watch pod并维护pod name 到pod ip的关系）  
3、维护这些规则在本地的实现和记录（如iptables表）

安全组的规则记录在上层网关，而不是每一个节点上在安全组规则上，可能需要list watch networkPolicy、namespace、pod等资源，因此实现namespace级别的策略可能会影响其性能。

[Link 1]: https://kubernetes.io/docs/concepts/services-networking/network-policies/