一:网络前提条件-网络模型
user--->ingress--->service--->pod（业务都在里面 更新）
k8s组网要求
所有的Pods之间可以在不使用NAT网络地址转换的情况下相互通信
所有的Nodes之间可以在不使用NAT网络地址转换的情况下相互通信
每个Pod自己看到的自己的ip和其他Pod看到的一致k8s网络模型设计原则
每个Pod都拥有一个独立的 IP地址，而且 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中 。
不管它们是否运行在同一个 Node (宿主机)中，都要求它们可以直接通过对方的 IP 进行访问。
设计这个原则的原因是，用户不需要额外考虑如何建立 Pod 之间的连接，也不需要考虑将容器端口映射到主机端口等问题。由于 Kubemetes 的网络模型假设 Pod 之间访问时使用的是对方 Pod 的实际地址，所以一个Pod 内部的应用程序看到的自己的 IP 地址和端口与集群内其他 Pod 看到的一样。它们都是 Pod 实际分配的IP地址 (从dockerO上分配的)。将IP地址和端口在Pod内部和外部都保持一致， 我们可以不使用 NAT 来进行转换，地址空间也自然是平的。
二：各组件之间的网络互通
根据以上的一些要求，需要解决的问题
Docker容器和Docker容器之间的网络
Pod与Pod之间的网络
Pod与Service之间的网络
Internet与Service之间的网络1.容器和容器之间的网络
pod中每个docker容器和pod在一个网络命名空间内，所以ip和端口等等网络配置，都和pod一样，主要通过一种机制就是，docker的一种网络模式，container，新创建的Docker容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等
2.pod与pod之间的网络
首先pod自身拥有一个IP地址，不同pod之间直接使用IP地址进行通信即可
同一台node节点上pod和pod通信：
pod1-->pod2（同一台node上），pod1通过自身eth0网卡发送数据，eth0连接着veth0，网桥把veth0和veth1组成了一个以太网，然后数据到达veth0之后，网桥通过转发表，发送给veth1，veth1直接把数据传给pod2的eth0
不同node节点上pod和pod通信
k8s集群中，每个node节点都会被分配一个CIDR块，（把网络前缀都相同的连续地址组成的地址组称为CIDR地址块）用来给node上的pod分配IP地址，另外还需要把pod的ip和所在nodeip进行关联
比如node1上pod1和node2上的pod4进行通信
首先pod1上网卡eth0将数据发送给已经管理到root命名空间的veth0上，被虚拟网桥收到，查看自己转发表之后，并没有pod4的mac地址。
就会把包转发到默认路由，（root命名空间的eth0上，也就是已经到了node节点的往卡上）通过eth0，发送到网络中。
寻址转发后包来到了node2，首先被root命名空间的eth0设备接受，查看目标地址是发往pod4的，交给虚拟网桥路由到veth1，最终传给pod4的eth0上。
也可以借助第三方网络插件来实现，常用有calico、flannel、contiv等
第三方组件参考
3.pod与service之间的网络
pod的ip地址是不持久的，当集群中pod的规模缩减或者pod故障或者node故障重启后，新的pod的ip就可能与之前的不一样的。所以k8s中衍生出来Service来解决这个问题。
Service管理了多个Pods，每个Service有一个虚拟的ip,要访问service管理的Pod上的服务只需要访问你这个虚拟ip就可以了，这个虚拟ip是固定的，当service下的pod规模改变、故障重启、node重启时候，对使用service的用户来说是无感知的，因为他们使用的service的ip没有变。
当数据包到达Service虚拟ip后，数据包会被通过k8s给该servcie自动创建的负载均衡器路由到背后的pod容器。
在k8s里，iptables规则是由kube-proxy配置，kube-proxy监视APIserver的更改，因为集群中所有service（iptables）更改都会发送到APIserver上，所以每台kubelet-proxy监视APIserver，当对service或pod虚拟IP进行修改时，kube-proxy就会在本地更新，以便正确发送给后端pod
pod到service包的流转：
数据包从pod1所在eth0离开，通过veth对的另一端veth0传给网桥cbr0，网桥找不到service的ip对应的mac，交给了默认路由，到达了root命名空间的eth0
root命名空间的eth0接受数据包之前会经过iptables进行过滤，iptables接受数据包后使用kube-proxy在node上配置的规则响应service，然后数据包的目的ip重写为service后端指定的pod的ip了
service到pod包的流转
收到包的pod会回应数据包到源pod，源ip是发送方ip，目标IP是接收方，数据包进行回复时经过iptables，iptables使用内核机制conntrack记住它之前做的选择，又将数据包源ip重新为service的ip，目标ip不变，然后原路返回至pod1的eth0
4.Internet与service之间的网络
node主机通过iptables的nat来解决
-
数据包源自pod1网络命名空间，通过veth对连接到root网络命名空间，紧接着，转发表里没有IP对应的mac，会发送到默认路由，到达root网络命名空间的eth0
-
那么在到达root网络明明空间之前，iptables会修改数据包，现在数据包源ip是pod1的，继续传输会被Internet网关拒绝掉，因为网关NAT仅转发node的ip，解决方案：使iptables执行源NAT更改数据包源ip，让数据包看起来是来自于node而不是pod
-
iptables修改完源ip之后，数据包离开node，根据转发规则发给Internet网关，Internet网关执行另一个NAT，内网ip转为公网ip，在Internet上传输。
-
数据包回应时，也是按照：Internet网关需要将公网IP转换为私有ip，到达目标node节点，再通过iptables修改目标ip并且最终传送到pod的eth0虚拟网桥。
Internet到k8s的流量
让Internet流量进入k8s集群，这特定于配置的网络，可以在网络堆栈的不同层来实现：
（1） NodePort
（2）Service LoadBalancer
（3）Ingress控制器。
第七层流量入口：Ingress Controller
通过一个公开的ip地址来公开多个服务，第7层网络流量入口是在网络堆栈的HTTP / HTTPS协议范围内运行，并建立在service之上。
工作：客户端现针对www.1234.com执行dns解析，DNS服务器返回ingress控制器的ip，客户端拿到ip后，向ingress控制器发送http的get请求，将域名加在host头部发送。控制器接收到请求后，从host头部就知道了该访问哪一个服务，通过与该service关联的endpoint对象查询podIP地址，将请求进行转发
第7层负载均衡器的一个好处是它们具有HTTP感知能力，因此它们了解URL和路径。 这允许您按URL路径细分服务流量。 它们通常还在HTTP请求的X-Forwarded-For标头中提供原始客户端的IP地址。
