转载自：https://www.cnblogs.com/centos-python/articles/10869210.html
Linux网络名词解释：
1、网络的命名空间：
Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；docker利用这一特性，实现不容器间的网络隔离。
2、Veth设备对：
Veth设备对的引入是为了实现在不同网络命名空间的通信。
3、Iptables/Netfilter：
Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核 模式中；
Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；
通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。
4、网桥：
网桥是一个二层网络设备,通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。
5、路由：
Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里
在Kubernetes网络中存在两种IP（Pod IP和Service Cluster IP），Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，Service Cluster IP它是一个虚拟IP
是由kube-proxy使用Iptables/ipvs规则重新定向到其本地端口，再均衡到后端Pod的。
下面讲讲Kubernetes Pod网络设计模型：
kubernetes网络模型
1. 基础原则
每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中，不管是否运行在同一Node上都可以通过Pod的IP来访问。
k8s中Pod的IP是最小粒度IP。同一个Pod内所有的容器共享一个网络堆栈，该模型称为IP-per-Pod模型。
Pod由docker0实际分配的IP，Pod内部看到的IP地址和端口与外部保持一致。同一个Pod内的不同容器共享网络，可以通过localhost来访问对方的端口，类似同一个VM内的不同进程。
IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看，Pod可以看作是一台独立的VM或物理机。
2. k8s对集群的网络要求
所有容器都可以不用NAT的方式同别的容器通信。
所有节点都可以在不同NAT的方式下同所有容器通信，反之亦然。
容器的地址和别人看到的地址是同一个地址。
这里我们回顾一下之前的docker 的网络基础，下图展示了Docker网络在整个Docker生态技术栈中的位置
1、单机网络模式：Bridge 、Host、Container、None，这里具体就不赘述了。
参考文章：https://blog.csdn.net/wangguohe/article/details/81535942
2、多机网络模式：
一类是 Docker 在 1.9 版本中引入Libnetwork项目，对跨节点网络的原生支持；
一类是通过插件（plugin）方式引入的第三方实现方案，比如 Flannel，Calico 等等。
k8s网络通信：
1.容器内通信
同一个Pod的容器共享同一个网络命名空间，它们之间的访问可以用localhost地址 + 容器端口就可以访问
2.Pod 通信：Pod IP <---> Pod IP
a.同一Node中Pod的默认路由都是docker0的地址，由于它们关联在同一个docker0网桥上，地址网段相同，它们之间应当是能直接通信的。
b.不同Node中Pod间通信要满足2个条件： Pod的IP不能冲突； 将Pod的IP和所在的Node的IP关联起来，通过这个关联让Pod可以互相访问, 通过第三方网络插件来创建覆盖网络，比如Flannel
3.Pod与Service通信：Pod IP <---> cluster IP
Service是一组Pod的服务抽象，相当于一组Pod的LB，负责将请求分发给对应的
Pod；Service会为这个LB提供一个IP，一般称为ClusterIP。
4.Service 与集群外部客户端的通信：实现方式：Ingress、NodePort、Loadbalance
Kubernetes网络开源组件
1、技术术语：
IPAM：IP地址管理；这个IP地址管理并不是容器所特有的，传统的网络比如说DHCP其实也是一种IPAM，到了容器时代我们谈IPAM
主流的两种方法： 基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后，上面的容器都要给它分配一个全局唯一的IP地址，这就涉及到IPAM的话题。
Overlay：在现有二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。
IPSesc：一个点对点的一个加密通信协议，一般会用到Overlay网络的数据通道里。
vxLAN：由VMware、Cisco、RedHat等联合提出的这么一个解决方案，这个解决方案最主要是解决VLAN支持虚拟网络数量（4096）过少的问题。
因为在公有云上每一个租户都有不同的VPC，4096明显不够用。就有了vxLAN，它可以支持1600万个虚拟网络，基本上公有云是够用的。
网桥Bridge： 连接两个对等网络之间的网络设备，但在今天的语境里指的是Linux Bridge，就是大名鼎鼎的Docker0这个网桥。
BGP： 主干网自治网络的路由协议，今天有了互联网，互联网由很多小的自治网络构成的，自治网络之间的三层路由是由BGP实现的。
SDN、Openflow： 软件定义网络里面的一个术语，比如说我们经常听到的流表、控制平面，或者转发平面都是Openflow里的术语。
容器网络方案：
隧道方案（ Overlay Networking ）
隧道方案在IaaS层的网络中应用也比较多，大家共识是随着节点规模的增长复杂度会提升，而且出了网络问题跟踪起来比较麻烦，大规模集群情况下这是需要考虑的一个点。
- Weave：UDP广播，本机建立新的BR，通过PCAP互通
- Open vSwitch（OVS）：基于VxLan和GRE协议，但是性能方面损失比较严重
- Flannel：UDP广播，VxLan
- Racher：IPsec
路由方案
路由方案一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也很容易排查。
- Calico：基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。
- Macvlan：从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。
3、CNM & CNI阵营：
容器网络发展到现在，形成了两大阵营，就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。
首先明确一点：
CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。
CNM（Docker LibnetworkContainer Network Model）:
Docker Libnetwork的优势就是原生，而且和Docker容器生命周期结合紧密；缺点也可以理解为是原生，被Docker“绑架”。
- Docker Swarm overlay
- Macvlan & IP networkdrivers
- Calico
- Contiv
- Weave
CNI（Container NetworkInterface）：
CNI的优势是兼容其他容器技术（e.g. rkt）及上层编排系统（Kubernetes & Mesos)，而且社区活跃势头迅猛，Kubernetes加上CoreOS主推；缺点是非Docker原生。
- Kubernetes
- Weave
- Macvlan
- Calico
- Flannel
- Contiv
- Mesos CNI
硬件交换：SR-IOV 单根IO虚拟化
这里我们用CNI
k8s加载CNI 的地方
kubelet /etc/cni/net.d/
cat /etc/cni/net.d/10-flannel.conflist