一、Kubernetes 网络模型初探
本文旨在介绍 Kubernetes 对网络模型的基本想法和约束。Kubernetes 对网络的具体实现方案并没有给出固定的答案，但其对容器网络是否合格却有一定的限制，可归纳为三大核心要求。
约法三章：
1. 任意两个 pod 之间应能直接通信，无需显式地使用 NAT 进行数据和地址的转换。
2. Node 与 pod 之间的通信应当直接，不需要明显的地址转换。
3. Pod 所感知的 IP 地址与外界看到的 IP 地址应一致，中间不应有地址转换。
四大目标：
在设计 Kubernetes 系统为外部世界提供服务时，需要从网络角度考虑如何让外部世界逐步连接到容器内部的应用。四大目标即是要解决以下问题：
1. 外部世界和 service 之间如何通信？
2. Service 如何与它后端的 pod 通讯？
3. Pod 和 pod 之间如何调用实现通信？
4. Pod 内部容器与容器之间的通信如何？
最终目标是实现外部世界能够无缝连接到最内部的容器，为其提供服务。
对于基本约束，我们可以理解为容器的网络发展复杂性在于其寄生在 Host 网络之上。容器网络方案大体可分为 Underlay 和 Overlay 两大派别。
为什么社区会提出 perPodperIP 这种简单武断的模型？这主要是为了方便后续的 service 管理，性能监控。因为一个 IP 一贯到底，对于各种场景都有很大的好处。
二、Netns 深度解析
Netns，即 Network Namespace，是实现容器网络隔离的关键。
在一个隔离的网络空间中，它拥有自己独立的网卡（可能是虚拟的，也可能是物理的），自己的 IP 地址、IP 表和路由表，以及自己的 TCP/IP 协议栈。这就像是拥有一个完全独立的网络世界，与主机网络隔离。但协议栈的代码还是公用的，只是数据结构不同。
每个 pod 都有独立的网络空间，而 pod net container 会共享这个网络空间。K8s 推荐使用 Loopback 接口在 pod net container 之间进行通信，所有的 container 通过 pod 的 IP 对外提供服务。对于宿主机上的 Root Netns，可以看作是一个特殊的网络空间，其 PID 为1。
三、主流网络方案概述
容器网络的复杂性在于它需要与底层 IaaS 层的网络协调，需要在性能和 IP 分配的灵活性上做出选择。下面介绍几个主要的容器网络实现方案：Flannel、Calico、C 和 WeaveNet。
Flannel 是一个较为通用的方案，提供了多种 backend 来适应不同的场景。Calico 主要采用策略路由，节点间通过 BGP 协议进行路由同步。WeaveNet 则在数据加密方面有所专长。
四、Network Policy 的应用
在 Kubernetes 中，Network Policy 用于控制 pod 之间的网络通信。通过定义规则，可以实现对进出流的精确控制。在使用 Network Policy 时，需要确保所选的网络插件支持其落地实施。配置实例中需要决定控制对象、流向以及流的特征描述。
五、思考时间
关于容器网络，有以下问题值得思考：
1. 为什么接口标准化 CNI 化了，但容器网络却没有很标准的实现内置在 K8s 里面？
2. Network Policy 为什么没有一个标准的 controller 或标准实现？
3. 是否可以完全不使用网络设备来实现容器网络，如使用 RDMA 等有别于 TCP/IP 的方案？
4. 在运维过程中，网络问题排查困难，是否有开源工具可以友好地展示从 container 到 Host 之间的网络情况，快速定位问题？
以上就是关于 Kubernetes 容器网络的基本概念及 Network Policy 的介绍。