ASP站长网云原生(Cloud Native)可以认为是一套技术体系或生态，它包含2大部分：云(Cloud)和原生(Native)。云(Cloud)表示应用程序位于云中，而不是传统的数据中心;原生(Native)表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势。
 
 
 
云原生的代表技术体系包括容器(Container)、服务网格(Service Mesh)、微服务(Microservice)、不可变基础设施和声明式API。本文主要基于容器技术，解析在容器编排生态K8S中的网络流量模型，让大家能够更深刻了解容器技术在云原生生态中的应用与落地。
 
Kubernetes基于扁平地址空间，非NAT的网络结构，无需在主机和容器之间映射端口。此网络模型的主要特点是消除了在主机和容器之间映射端口的需求。我们先看下其总体架构拓扑模型：
 
Kubernetes容器网络模型解析
在容器网络中主要涉及以下几个地址：
 
Node Ip：即物理机地址。
Pod Ip：Kubernetes的最小部署单元是Pod，一个Pod 可能包含一个或多个容器，简单来讲容器没有自己单独的地址，他们共享Pod 的地址和端口区间。
ClusterIp：Service的Ip地址，外部网络无法Ping通改地址，因为它是虚拟IP地址，没有网络设备为这个地址负责，内部实现是使用Iptables规则重新定向到其本地端口，再均衡到后端Pod;只有Kubernetes集群内部访问使用。
Public Ip ：Service对象在Cluster IP range池中分配到的IP只能在内部访问，适合作为一个应用程序内部的层次。如果这个Service作为前端服务，准备为集群外的客户提供业务，我们就需要给这个服务提供公共IP。
容器网络流量模型
1、POD内容器间通信
Pod中的容器可以通过“localhost”来互相通信，他们使用同一个网络命名空间，对容器自身来说，hostname就是其Pod的名称。Pod中的所有容器共享同一个IP地址和端口空间，你需要为每个需要接收连接的容器分配不同的端口。也就是说，Pod中的应用需要自己协调端口的使用。
 
内部实现机制：同Pod内的容器实际共享同一个Namespace，因此使用相同的Ip和Port空间，该Namespace 是由一个叫Pause的小容器来实现，每当一个Pod被创建，那么首先创建一个pause容器，之后这个Pod里面的其他容器通过共享这个pause容器的网络栈，实现外部Pod进行通信,因此对于同Pod里面的所有容器来说，他们看到的网络视图是一样的，我们在容器中看的地址，也就是Pod地址实际是Pause容器的IP地址。总体模型如下：
 
Kubernetes容器网络模型解析
2、同主机POD间通信
每个节点上的每个Pod都有自己的Namespace，同主机上的Pod之间怎么通信呢?我们可以在两个Pod之间建立Vet Pair进行通信，但如果有多个容器，两两建立Veth 就会非常麻烦，假如有N 个Pod ，那么我们需要创建n(n-1)/2个Veth Pair，扩展性非常差，如果我们可以将这些Veth Pair 连接到一个集中的转发点，由它来统一转发就就会非常便捷，这个集中转发点就是我们常说的Bridge，如下所示
 
Kubernetes容器网络模型解析
3、跨主机POD间通信
对于网络上两个端点之间的互通目前主要有两种方案：一种是基于Underlay 直接互通，此模式需要双方有彼此的路由信息并且该路由信息在underlay的路径上存在。一种是基于Overlay 方案，通过隧道实现互通。Underlay 层面保证主机可达即可，代表网络方案有 Calico(Direct模式)和Macvlan，后者有Overlay，OVS，Flannel和Weave。本篇仅针对Flannel 和Calico 插件进行简要介绍。