Calico概念

将系统微服务化后采用dubbo框架开发部署解决模块之间内部调用关系。Dubbo框架中生产者组件会自动启动一个服务端口，在DCOS平台采用弹性伸缩过程中需要考虑服务组件端口冲突和跨容器访问网络问题。于是引入calico网络方案来解决dubbo框架服务调用问题。

Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。

Calico的原理是通过修改每个主机节点上的iptables和路由表规则，实现容器间数据路由和访问控制，并通过Etcd协调节点配置信息的。因此Calico服务本身和许多分布式服务一样，需要运行在集群的每一个节点上。

常见的CNI网络插件包含以下几种：

Flannel：为Kubernetes提供叠加网络的网络插件，基于TUN/TAP隧道技术，使用UDP封装IP报文进行创建叠 加网络，借助etcd维护网络的分配情况，缺点：无法支持网络策略访问控制。
Calico：基于BGP的三层网络插件，也支持网络策略进而实现网络的访问控制；它在每台主机上都运行一个虚拟路由，利用Linux内核转发网络数据包，并借助iptables实现防火墙功能。实际上Calico最后的实现就是将每台主机都变成了一台路由器，将各个网络进行连接起来，实现跨主机通信的功能。
Canal：由Flannel和Calico联合发布的一个统一网络插件，提供CNI网络插件，并支持网络策略实现。
其他的还包括Weave Net、Contiv、OpenContrail、Romana、NSX-T、kube-router等等。而Flannel和Calico是目前最流行的选择方案。

1.全部拒绝

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: cs1
  #应用于cs1 名称空间，不写名称空间对default应用
spec:
  podSelector: {}
  ingress:
  egress:
  #定义出站规则，这里没有写任何策略，表示全部拒绝。
  policyTypes:
  - Egress
  - Ingress
  #这里面有Egress就表示要定义出站规则，不写Egress就是默认通行,Ingress是入站原理一样
  #建议大家把两个都写上去 然后使用"podSelector:" 来控制是否能通行

2.全部允许

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
  namespace: cs1
spec:
  podSelector: {}
  ingress:
  - {}
  #这样表示"ingress"方向的全部允许通行
  egress:
  - {}
  #这样表示"egress"方向的全部允许通行
  policyTypes:
  - Egress
  - Ingress

这个网络策略只对名称空间起效，宿主机依然可以访问

3.作用范围

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name:  deny-all
  namespace: default
  #只作用于 default 名称空间
spec:
  podSelector:
  #匹配pod 范围 如果匹配该名称空间的所有POD 输入"{}" 即可
    matchLabels:
      access: "true"
      #匹配POD中有 access=true的标签
  policyTypes:
  - Ingress
  - Egress
  ingress:
  egress:

4.限制IP策略

#上图每个cs容器的IP

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name:  deny-all
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
  ingress:
  egress:
    - to:
    #注意：egress用to，ingress用from
      - ipBlock:
          cidr: 192.168.0.0/16
          #放行192.168.0.0/16网络
          except:
          - 192.168.94.134/32
          #但不包括这个ip

exec进入pod 能看见ping192.168.94.134 这个IP是不通的

5.基于名称空间label限制

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-allow
  namespace: default
spec:
  policyTypes: ["Ingress"]
  podSelector: {}
  ingress:
   - from:
     - namespaceSelector:
        matchLabels:
          name: cs1
                    #表示只有打了"name=cs1"的名称空间才允许进

6.基于名称空间label限制满足多个条件

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-allow
  namespace: default
spec:
  policyTypes: ["Ingress","Egress"]
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchExpressions:
        - key: name
          operator: In
          values: ["cs1","cs2"]
          #中括号里面的可以 与default名称空间 ingress通信
                    #表示，名称空间有标签name=cs1,name=cs2 的 可以与default名称空间通信

7基于pod label

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-allow
  namespace: default
spec:
  policyTypes: ["Ingress"]
  podSelector: {}
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
   #允许pod 便签有 access=true的通行

#基于pod label 实验没成功不知道啥问题