K8S容器编排之NetWorkPolicy个人常用实例

之前我们写过关于NetworkPolicy的官方实例,这篇文章我们会讲一下我们日常使用的一些常用例子。

简介

首先,我们来回顾一下我们之前关于Networkpolicy的基本概念。network policy顾名思义就是对pod进行网络策略控制。 k8s本身并不支持,因为k8s有许多种网络的实现方式,企业内部可以使用简单的flannelweavekube-router等,适合公有云的方案则有calico等。不同的网络实现原理(vethpair、bridge、macvlan等)并不能统一地支持network policy。

network policy 策略模型

使用network policy资源可以配置pod的网络,networkPolicynamespace scoped的,也就是作用域只是在某个namespace,它只能影响某个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

该例子的效果如下:
1、default namespace下label包含role=dbpod,都会被隔绝,他们只能建立“满足networkPolicy的ingress和egress描述的连接”。即2-5点:
2、所有属于172.17.0.0/16网段的IP,除了172.17.1.0/24中的ip,其他的都可以与上述pod的6379端口建立tcp连接。
3、所有包含label:project=myprojectnamespace中的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大致也是通过它实现的。
Kube-router。 这个工具比较吸引人,因为他使用iptables实现networkpolicy,同时它也能成为kube-proxy组件的替代品。
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级别的策略可能会影响其性能。

你可能感兴趣的:(K8S容器编排之NetWorkPolicy个人常用实例)