简述Kubernetes网络模型

Kubernetes网络模型中每个Pod都拥有一个独立的IP地址，不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问；

同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。

这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口；在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈；

简述Kubernetes CNI模型

Kubernetes CNI模型是对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。

CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。

容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件；

网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如路由器）等；

简述Kubernetes网络策略

为实现细粒度的容器间网络访问隔离策略，K8s引入Network Policy主要功能是对Pod间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端Pod列表。

Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现；

简述Kubernetes网络策略原理

Network Policy的工作原理主要为：policy controller需要实现一个API Listener，监听用户设置的Network Policy定义，并将网络访问规则通过各Node的Agent进行实际设置（Agent则需要通过CNI网络插件实现）；

简述Kubernetes中flannel的作用

1）它能协助Kubernetes，给每一个Node上的Docker容器都分配互相不冲突的IP地址；

2）它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内；

简述Kubernetes Calico网络组件实现原理

Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成，Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则；Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。

Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率；