简述Kubernetes网络模型？
Kubernetes网络模型中每个Pod都拥有一个独立的IP地址，并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问。
设计这个原则的原因是：用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑如何将容器端口映射到主机端口等问题。
同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口。
在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈（相当于一个网络命名空间，它们的IP地址、网络设备、配置等都是共享的）。
简述Kubernetes CNI模型？
CNI 提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。
CNI仅关注在创建容器时分配网络资源和在销毁容器时删除网络资源。
在 CNI 模型中只涉及两个概念：容器和网络。
- 容器（Container）：是拥有独立Linux网络命名空间的环境；例如，使用docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件。
- 网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如：路由器）等。
对容器网络的设置和操作都通过插件（Plugin）进行具体实现，CNI插件包括两种类型：CNI Plugin和IPAM（IP Address Management）Plugin。
CNI Plugin负责为容器配置网络资源。IPAM Plugin负责对容器的IP地址进行分配和管理。
IPAM Plugin作为CNI Plugin的一部分，与CNI Plugin协同工作。
简述Kubernetes网络策略？
为实现细粒度的容器间网络访问隔离策略，Kubernetes 引入了 Network Policy。
Network Policy的主要功能是：对Pod间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端 Pod 列表。
Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现。
简述 Kubernetes 网络策略原理？
Network Policy的工作原理主要为：
Policy Controller需要实现一个 API Listener，监听用户设置的 Network Policy 定义，并将网络访问规则通过各 Node 的 Agent 进行实际设置（Agent 则需要通过 CNI 网络插件实现）。
简述 Kubernetes 中 Flannel 的作用？-todo
Flannel可以用于Kubernetes底层网络的实现，主要作用有：
- 它能协助Kubernetes，给每一个Node上的Docker容器都分配互相不冲突的IP地址。
- 它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
简述 Kubernetes Calico 网络组件实现原理？-todo
Calico 是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。
Calico 在每个计算节点都利用 Linux Kernel 实现了一个高效的vRouter来负责数据转发。 每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。
Calico 保证所有容器之间的数据流量都是通过 IP 路由的方式完成互联互通的。
Calico 节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的 NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。
