Kubernates网络方案

1. 基本原则：每个Pod都拥有一个独立的IP地址，而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中
2. 设计原因：用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端口等问题
3. 网络要求：
   • 所有的容器都可以在不用NAT的方式下同别的容器通讯
   • 所有节点都可在不用NAT的方式下同所有容器通讯
   • 容器的地址和别人看到的地址是同一个地址

1. 网络的命名空间：Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；docker利用这一特性，实现不容器间的网络隔离
2. Veth设备对：Veth设备对的引入是为了实现在不同网络命名空间的通信
3. Iptables/Netfilter：
   • Netfilter：负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核模式中
   • Iptables：在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表
   • 通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制
4. 网桥：网桥是一个二层网络设备，通过网桥可以将linux支持的不同的端口连接起来，并实现类似交换机那样的多对多的通信
5. 路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里

下图展示了Docker网络在整个Docker生态技术栈中的位置：

Docker网络实现：

1. 单机网络模式：
   • Bridge
   • Host
   • Container
   • None
2. 多机网络模式：
   • Docker 在 1.9 版本中引入Libnetwork项目，对跨节点网络的原生支持
   • 通过插件方式引入的第三方实现方案:
     • Flannel
     • Calico
     • ……

同一个Pod的容器共享同一个网络命名空间，它们之间的访问可以用localhost地址 + 容器端口就可以访问：

同一Node中Pod的默认路由都是docker0的地址，由于它们关联在同一个docker0网桥上，地址网段相同，所有它们之间应当是能直接通信的：

不同Node中Pod间通信要满足2个条件：

1. Pod的IP不能冲突

2. 将Pod的IP和所在的Node的IP关联起来，通过这个关联让Pod可以互相访问

   

Service是一组Pod的服务抽象，相当于一组Pod的LB，负责将请求分发给对应的Pod

一个简单的网络代理和负载均衡器，它的作用主要是负责Service的实现。具体来说，就是实现了内部从Pod到Service和外部的从NodePort向Service的访问

Kube-dns用来为kubernetes service分配子域名，在集群中可以通过名称访问service。通常kube-dns会为service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录，用来解析service的cluster ip

• IPAM：IP地址管理。这个IP地址管理并不是容器所特有的，传统的网络比如说DHCP其实也是一种IPAM，到了容器时代我们谈IPAM，主流的两种方法 1. 基于CIDR的IP地址段分配
  1. 精确为每一个容器分配IP

但总之一旦形成一个容器主机集群之后，上面的容器都要给它分配一个全局唯一的IP地址，这就涉及到IPAM的话题

• Overlay：在现有二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的IP地址空间、交换或者路由的实现
• IPSesc：一个点对点的一个加密通信协议，一般会用到Overlay网络的数据通道里
• vxLAN：由VMware、Cisco、RedHat等联合提出的这么一个解决方案，这个解决方案最主要是解决VLAN支持虚拟网络数量（4096）过少的问题。因为在公有云上每一个租户都有不同的VPC，4096明显不够用。就有了vxLAN，它可以支持1600万个虚拟网络，基本上公有云是够用的
• Bridge： 连接两个对等网络之间的网络设备，但在今天的语境里指的是Linux Bridge，就是大名鼎鼎的Docker0这个网桥
• BGP： 主干网自治网络的路由协议，今天有了互联网，互联网由很多小的自治网络构成的，自治网络之间的三层路由是由BGP实现的

容器网络发展到现在，形成了两大阵营，就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题

Flannel之所以可以搭建kubernets依赖的底层网络，是因为它可以实现以下两点：

1. 给每个node上的docker容器分配相互不想冲突的IP地址
2. 能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内

Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。Calico不使用重叠网络比如flannel和libnetwork重叠网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由通过BGP协议传播可达信息（路由）到剩余数据中心

Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播–小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成

Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network

Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能