1.容器网络
每个Pod分配单独的Ip地址
使用NetworkPolicy实现访问控制
2.负载均衡（Service IP）
内部的虚拟Ip映射到后端多个容器
服务名称映射到虚拟IP(ServiceIP)并可通过DNS解析服务名
KUbe-proxy检测service的改变并更新Iptables（现在不用iptables了，用lvs），实现虚拟Ip端口到容器Ip，端口的映射
3.外部访问
外部负载均衡
Ingress的反向代理

Container Network Interface (CNI)容器网络
Kubernetes使用CNI插件来组建容器网络
当Pod的创建和销毁时，kubernetes将调用CNI插件的接口来生成网络配置
CNI插件将生成虚拟NIC，将其挂载在主机网络之上，并和Pod的namespace关联

CNI创建网络
1.kubelet runtime创建network namespace
cd /var/lib/cni
touch myns
unshare -n mount —bind /proc/self/ns/net myns
2.kubelet触发CNI插件，并传递一些配置变量

3.CNI收到配置参数后，开始创建网络
CNI插件内部先创建veth path(虚拟设备接口)
brctl addbr mynet
ip link add veth123 type veth peer name $CNI_IFNAME
brctl addif mynet veth123
ip link set $CNI_IFNAME netns $CNI_IFNAME
ip link set veth123 up

通过IPAM插件获取空闲的Ip地址
brctl addbr mynet
ip link add veth123 type veth peer name $CNI_IFNAME
brctl addif mynet veth123
ip link set $CNI_IFNAME netns $CNI_IFNAME
ip link set veth123 up

将ip配置到容器net namespace的网络设备
switch to container namespace
ip addr add 10.0.5.9/16 dev $CNI_IFNAME

实现同集群中不同节点网络互联：Calico、Flannel、NSX-t
# Calico
利用linux内核ip转发机制实现高效网络传输
基于三层路由，不依赖二层软件交换机等
通过BGP协议分发路由表
calico会在每个node上创建一个calico agent，使用自己的calico cni插件，calico plugin，这个插件会创建network namespace并分配ip地址，每个calico agent会运行各自的BGP agent，然后发现路由，从而建立起来路由表，也就实现了不同节点的network互联

Flannel
calico主要是使用第三层路由方式，而Flannel是使用overlay network方式
每个节点上，也会运行一个flannel agent
container会连接到一个叫flannel0的bridge上，fannel agent会截获这个packet，然后对这个packet进行包装，也就是把这个packet包放到udp中，不同的flannel agent之间会建立udp连接，通过udp的方式转发这个包，不同flannel之间使用tcp为总的存储，来实现不同flannet agent之间的ip包的发现和路由

Network Policy 网络策略，类似acl
基于容器标签实现网络端口的访问控制
kubernetes 1.8加入egress的控制
作用：实现不同容器间的网络隔离

Calico BGP协议 ipip(隧道方案) bgp(路由方案)
Flannel TCP协议 vlan(隧道方案) host-gw(路由方案) udp(在用户态实现的数据封装解封装，由于性能较差已经被弃用)

flannel vxlan和calico ipip模式都是隧道方案，但是calico的封装协议IPIP的header更小，
所以性能比flannel vxlan要好一点点
常见的路由方案包括了flannel的host-gw模式，以及calico的bgp模式

pod—docker0—flannel0—NAT—node
172.16.80.2/16 172.16.80.1/16 172.16.80.0/12

calico网络
calico也是业界的主流容器网络解决方案之一，同时支持CNI和CNM。calico本身也有两种模式，分别是BGP和IPIP。其中IPIP模式为overlay的方式，与flannel类似，且性能与flannel的host-gw模式相当。另一种BGP模式是基于BGP的动态路由学习。需要在每个宿主机上安装bgp的agent来实现路由学习，且需要在物理网络设备上启用bgp协议。

优点：网络性能基本无损耗，支持网络策略，安全组，多租户隔离等。
缺点：

1. 如果使用ipip模式，则面临和flannel等overlay网络方案同样的问题。
   2. 如果使用bgp模式，则需要物理网络路由支持，需要在物理网络路由器上配置表态路由转发或者bgp动态路由协议。

flannel网络
一种overlay的网络解决方案，每个主机负责一个网段，通过overlay的方式 实现容器网络的虚拟路由选路。比较灵活，应用比较广泛。flannel一共有三种模式，分别为udp、vxlan以及host-gw模式。host-gw的性能表现最好，较为接近原生网络性能。但host-gw只支持物理的大二层网络，使用有较大限制。

优点：overlay网络，灵活，使用广泛
缺点：

1. 除了host-gw，vdp和vxlan性能都比较差，但host-gw又有物理网络的使用限制
   2. overlay网络无法直接与物理网络打通
   3. 对使用者封装了网络底层，从系统设计和运维人员的角度来说，对系统底层的可控性稍差。

集群网络
flannel方案
基于calico和弹性网卡eni的terway方案
Terway 和 flannel 类似，不同的地方在于，terway 支持 Pod 弹性网卡，以及 NetworkPolicy 功能

pod可以完成四种通信：
本地通信：pod内网容器之间共享一个网络协议栈，可以通过loopback通信
同节点pod通信：通过cni0虚拟网桥内部通信，相当于二层局域网内部设备通信
跨节点pod通信：A pod发送端数据包，通过cni0网桥网关，流转到节点，经过节点的eth0发送给VPC路由，这时会查询路由表，确认数据包目的地址，并把数据包发送给对应的ECS节点。到达目的节点后，再通过cni0路由进入目的pod
pod与非pod网络实体通信：经过节点上iptables规则做snat，此规则是flanneld依据命令行—ip-masq选项做的配置

集群CIDR—VPC路由表—节点网络—节点的podCIDR—节点上的虚拟网桥cni0—pod及网桥veth
主要是三种情况配置：集群配置、节点配置、pod配置
对应对集群网络IP段的三次划分：集群CIDR—-每个节点分配podCIDR(即集群CIDR的子网段)—-在podCIDR里为每个pod分配自己的ip

负载均衡（Service IP）
kubernetes 1.8引入lvs作为实验性的kube-proxy backend
解决iptables性能问题
解决iptables无法保留源Ip地址头的问题
可提供多种不同负载均衡算法，如最少连接和加权路由等

外部访问
Kubernetes提供三种外部访问方式：
NodePort：Kubernetes将服务暴露在节点Ip地址的特定端口范围内(30000-32767)
Loadbalancer：Kubernetes使用外部laaS cloud provider动态创建负载均衡将外部请求重定向到Pods
Ingress Controller：使用Kubernetes ingress提供七层反向代理并支持tls等功能