kubernetes network policy学习笔记

简介

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 出站

策略模型能够参考官方文档， 这里举个例子：

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

该例子的效果以下：
一、default namespace下label包含role=db的pod，都会被隔绝，他们只能创建“知足networkPolicy的ingress和egress描述的链接”。即2-5点：
二、全部属于172.17.0.0/16网段的IP，除了172.17.1.0/24中的ip，其余的均可以与上述pod的6379端口创建tcp链接。
三、全部包含label：project=myproject的namespace中的pod能够与上述pod的6379端口创建tcp链接；
四、全部default namespace下的label包含role=frontend的pod能够与上述pod的6379端口创建tcp链接；
五、容许上述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要作的事情，应该包含如下几点：
一、对networkpolicy进行全namespace范围的list & watch；
二、对规则原语的解析和定制。（如何将namespace、label等概念具象到iptables中？个人想法比较笨拙：使用正则表达式表述pod name的规则，同时list-watch pod并维护pod name 到pod ip的关系）
三、维护这些规则在本地的实现和记录（如iptables表）

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