云原生网络总结
什么是云原生网络
容器网络 对比 物理网路：
容器网络：集群中node、pod、工作负载、节点数量变化频率非常高。
物理网络：机器上架后就不发生大的变动。
容器网络基本特点：
- 每个pod单独的ip
- pod之间三层可达
- service、DNS、NetworkPolicy、Ingress等网络应用
但是，云原生网络最好可以实现跨平台，不应该依赖于底层的基础设施，可以在公有云、私有云、物理机随时迁移。如果网络和底层绑定（某个公有云或私有云），跨平台能力就会弱很多。云与安生网络应该是跟平台无关的，可以方便的跨云进行转移。
所以，云原生网络得具有容器网络的特性+ Service、DNS、NetworkPolicy、Ingress等，以及跨平台特性，才构成了完整的云原生网络。
云原生网络的开源实现
- CNI
- 可插拔式容器网络
- 规定容器和网络之间的交互协议 ADD/DEL
- 控制平面
- 分布式kv存储：Flannel、Kube-OVN、Cillium
- 路由协议：Calico、Kube-Router
- 底层物理设备：Macvlan、IPvlan
- Gossip协议：Weave
- 数据平面
- 封装模式：Flannel Vxlan、Kube-OVN Geneve、Calico IPIP，Cillium Vxlan
- Underlay模式：Flannel hostGateway、Kube-OVN Vlan、Calico BGP
关于开源实现，CNCF（云原生计算基金会）很早就定义了一个标准——CNI（container network interface），它实际是一个可插拔式的容器网络协议，Flannel、Clillium、Calico等都是基于CNI协议来做的。它规定了上层调度系统和底层容器网络之间的一个交互协议，交互协议定义了两个接口：ADD和DEL。
我们从控制平面和数据平面两个角度对网络插件实现进行分类。控制平面是指网络之间是如何相互发现的，容器网络相当于在物理机器的网络上面又加了一层网络，那么网络之间是如何相互学习了解的？一个节点的容器是如何发现另一节点的容器？其中的机制是怎样的？
这种实现机制大致可以分为四类：一种是所有控制信息用分布式kv进行存储，典型如Flannel、Cillium，把所有的控制信息存到etcd，然后下发到每个节点。灵雀云开源的Kube-OVN是把所有的控制信息存到OVS DB，也是一个raft协议的分布式存储。
第二种是不通过物理层面的存储，直接通过现有网络层面的路由器或者交换机上的自我发现能力，比如Calico, Kube-Router通过路由协议，有一个协议的Agent，把路由信息发布到外部路由器和交换机，外部硬件的信息就可以通过路由协议把整个控制平台的信息进行转发。
第三种是用底层物理设备，物理机的控制平面就是交换机，相当于每个机器把网络接到交换机上之后，交换机就学到了如何进行控制平面的转发。如果容器能够直接接入底层物理设备的话，可以试试这种做法，比较典型的是Macvlan，IPvlan。
还有一种比较少见但挺有意思的实现方式，Gossip协议Weave，也叫八卦协议或者流行病协议。就是一个人告诉另一个人，另外一个人再去不断告诉其他人。
从数据平面角度来看，主要分为两种：一种封装模式，比如Flannel Vxlan, Kube-OVN Geneve, CalicoIPIP, Cillium Vxlan，以及跟封装模式相对的Underlay 模式: Flannel hostGateway, Kube-OVNVlan, Calico BGP 。
云原生网络面临的挑战
-
功能
- 固定ip
- 多租户
- 加密
- 集群内外互通
-
监控和故障排查
- 网络变化复杂
- 微服务化，关系复杂
- 已有技术栈是否兼容
-
安全性
- 支持什么级别的安全策略
- 流量审计，回放
-
性能
- 控制平面的性能
- 数据平面的性能
- 应用所需的性能
云原生网络在实际落地时，也面临着一些挑战，主要分为四个方面。
第一，功能层面来看，云原生网络功能方面的能力比较少，落地时会碰到很多客户要做的新功能。
比如固定IP，当用户提出要求，只能要么网络这边改，要么应用方面改。多租户的能力，有的用户有很大的集群，有很多项目组，希望有租户管理的功能。租户不仅指计算资源的隔离，也包括网络资源的隔离。比如地址空间相对独立，网络控制独立，一些银行或其他金融机构希望流量经过交换机时是加密的，还有一些客户并非所有业务都上了K8s，这些应用需要相互之间进行交互，集群内外的网络互通也是一个问题。
第二，监控和故障排查，这是比功能层面更让人头疼的问题，上了容器网络后会发现大部分时间都是在运维这个网络，检查各种各样的网络问题。这其中最典型的可能就是网络不通。而且，如果涉及开发环境，微服务也可能一块上了，就会导致网络结构和拓扑变得特别复杂。
还有一个网络容易出现的问题–与已有技术栈的兼容。有些客户还有传统的网络监控方式，传统的网络监控已经很成熟了，但在容器网络这块是空缺的，会导致整体监控是缺失的，整体的排查经验也是缺失的，网络一旦出现问题，就会是很难解决的问题。
第三，安全性。传统方式可能采用基于黑白名单，或者基于IP划分的网络策略，但是容器在K8s上面，如果是用Networkpolicy，很多方式和传统是不一致的，会带来很多兼容性的问题。传统的流量审计流量回放会收集经过集群的所有流量，这种形式如果没有好的底层基础设施，很多安全机制相当于被架空了，这些都是落地时会碰到的问题。
第四，性能，提到性能大多数人会关注数据平面的性能。但在我们来看，现阶段比较大的问题是，用户的网络究竟能撑多大规模的集群，什么时候控制平面的性能会出现明显的衰减，这是在选型时需着重考虑的。数据平面的性能到实际应用时，很多情况下没有那么突出。它需要根据应用所需要的性能进行评估，很多情况下最大的极端的性能反而不是最需要的性能。
下面介绍一下灵雀云开源的Kube-OVN在云原生实践方面所做的一些事情，Kube-OVN根据日常实践中遇到的问题也在不断改进。
1子网模型
Kube-OVN比较大的改动是对子网模型进行了改进，把Subnet Per Node的模型改成了Subnet Per Namespace。这样做有几点好处：首先，子网可以分布在所有节点上，避免了网络地址和主机地址的绑定。进行网络扩缩容时，不需要对整个机器集群进行改动，只需要增加或减少子网。
子网跟namespace关联时，后面会有很多独立的设置，比如每个namespace可以有独立的地址空间，对应到用户那边可能是某一个项目组，或者某个租户，这样的对应就很直接，因为它可能是租户对应到namespace，租户对应到子网，是一个紧密关联的情况。子网跟namespace绑定后，可以根据租户来定义一些防火墙的策略，网关、NAT策略，子网IPv4还是IPv6，都可以按照这个子网的级别来进行设置，而不会跟节点绑死。
2固定IP
Kube-OVN还对固定IP做了全面支持。
•Pod 支持固定 IP/Mac
•Workload 类型(deployment/statefulset/dae monset/job)可通过 ippool annotation 固定 IP,保证在deployment生命周期内一直在复用IP。
•StatefulSet 支持 IP 复用，生命周期内按名字复用已分配IP 。在创建StatefulSet 时不知道IP是多少，一旦StatefulSet创建完成，pod名字和IP是固定的。
我们对StatefulSet还做了一些额外的支持，在StatefulSet里面实现了默认的固定IP。这一点其实有争议，有人觉得不该这么应用，但在我们的实践中，还是把最终的选择权留给用户。如果他不需要固定IP的功能，我们完全可以按照随机分配IP的方式去做。如果用户一些部门之间存在这样的问题，需要应用或者底层去做修改，可能应用方面不想改，但是又希望上容器，要用固定IP，我们也能提供这样的能力。
3Gateway
出网的方式，在实际中会碰到应用一部分在K8s上，一部分不在，或者关联的一些系统不在K8s上，就涉及到集群内外互访的需求。我们提供几种不同的出网方式。默认是分布式网关，它和Flannel、Calico的默认模式类似，pod如果想访问外部网络，从所在node节点直接出网。但这种方式不一定能满足所有场景。
采用这种方式如果你的pod飘移，意味着出网的地址也是飘移的，加白名单或做审计都是很困难的事情，这种情况下要把整个集群所有机器都加白名单。审计时，他也不清楚究竟审计应该从哪个节点过来流量。我们做了一个namespace级别的，这个和前面的子网是绑定的，只要配置子网的网关，就可以配置出网的方式。
每个Namespace可以设置独立的Gateway节点出网。在这个节点，所有出网的流量都通过一个特定节点，相当于通过一种固定的方式出网。在外部进行审计或加白名单时，对一个节点进行处理就可以。而且这个节点可以做高可用的，现在是主备模式，如果当前的断掉，或者故障下线，可以自动切换到下一个备用的节点。
除了这两种出网方式，我们还有一个特殊的设置，pod出网要不要进行NAT，如果进行的话，相当于是以当前主机节点IP的方式出网。如果不做NAT，就相当于集群内外的互通。我们的做法还是把所有的能力都提供出来，交给用户去选择。