k8s-kubernetes--网络策略、flannel网络插件和calico网络插件

---

一、k8s网络通信

抽象的接口层，将容器网络配置方案与容器平台方案解耦
CNI（Container Network Interface）就是这样的一个接口层，它定义了一套接口标准，提供了规范文档以及一些标准实现。采用CNI规范来设置容器网络的容器平台不需要关注网络的设置的细节，只需要按CNI规范来调用CNI接口即可实现网络的设置

k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。
  CNI插件存放位置：# cat  /etc/cni/net.d/10-flannel.conflist 
  
  插件使用的解决方案如下：
	虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
	多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
	硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。
	
  容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；
	
  pod之间的通信：
	同一节点的pod之间通过cni网桥转发数据包。(brctl show可以查看)
	不同节点的pod之间的通信需要网络插件支持。
	
  pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。
	
  pod和外网通信：iptables的MASQUERADE。
	
  Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

1.网络策略

网络策略官网：https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

前置条件
网络策略通过网络插件来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。(Flannel不支持 NetworkPolicy，所以使用Flannei网络插件是不会隔离pod的)
隔离和非隔离的 Pod
默认情况下，Pod 是非隔离的，它们接受任何来源的流量。
Pod 在被某 NetworkPolicy 选中时进入被隔离状态。 一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy 所不允许的连接。 （名字空间下其他未被 NetworkPolicy 所选择的 Pod 会继续接受所有的流量）
网络策略不会冲突，它们是累积的。 如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 入站（Ingress）/出站（Egress）规则的并集。因此评估的顺序并不会影响策略的结果。
为了允许两个 Pods 之间的网络数据流，源端 Pod 上的出站（Egress）规则和 目标端 Pod 上的入站（Ingress）规则都需要允许该流量。 如果源端的出站（Egress）规则或目标端的入站（Ingress）规则拒绝该流量， 则流量将被拒绝。

2.service和iptables的关系

service 的代理是 kube-proxy
kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上，而kube-proxy底层又是通过iptables和ipvs实现的。
iptables原理
Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。
ipvs原理
IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构(Hash表)，允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式。

在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配。

可以将ipset简单理解为一个IP(段)的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗。
kube-proxy ipvs和iptables的异同
iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构(Hash表)，允许几乎无限的规模扩张。

与iptables相比，IPVS拥有以下明显优势：

• 为大型集群提供了更好的可扩展性和性能；
• 支持比iptables更复杂的复制均衡算法(最小负载、最少连接、加权等)；
• 支持服务器健康检查和连接重试等功能；
• 可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。
  

二、pod间通信

1.同节点之间的通信

同一节点的pod之间通过cni网桥转发数据包。(brctl show可以查看)

2.不同节点的pod之间的通信需要网络插件支持(详解)

(1)Flannel vxlan模式跨主机通信原理

flannel网络

• VXLAN，即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本