|
编者按：关于容器网络的解决方案业界已经有较多的讨论，笔者无意继续赘述。本文从K8S的网络实现入手，重点阐述SDN在容器网络中的应用价值。K8S及其网络模型体现了鲜明的解耦设计思想，采用SDN技术实现K8S容器网络，并与相应的生态组件形成SDN监管控一体化解决方案，可以更好地提高整个系统的运营水平，更有效地提升企业的核心竞争力。上一篇里我们介绍了K8S的机制，本篇将谈论的是容器网络的SDN实现及其价值。 SDN容器网络业界所谓的“There is no such thing called container networking”的说法更多的是从连接容器或Pod的网络的一般性而言的。或者说从二层交换、三层路由转发面的角度认为连接容器的网络与连接VM或BM等的网络没有本质的区别，即容器网络特别是其数据转发面仍遵循和适用网络技术的一般性原则与实现。在这个层面上“容器网络”有点类似“业务网络”的概念之与物理网络、虚拟网络。但另一方面，特别是从服务发现与负载均衡、管理模式与部署实施等的角度看，K8S的“容器网络”是有其特殊性的。这主要体现在Pod生命周期到服务Service映射的动态性、SDN控制器云原生模式部署、Pod挂接网络的Plugin机制、以及安全策略的实现等方面。 数据转发面与管理控制面针对当前主流的典型的容器网络解决方案的分析，特别从数据转发面特征的角度，可以认为主要包括以Calico为代表的基于经典的三层路由、Netfilter模型的实现，和以OpenShift的SDN及Neutron等为典型代表的二层SDN/OVS模型的实现等。 三层路由/Netfilter模型：这类实现的优点是网络拓扑直观易懂，扁平化结构，可扩展性强；容器间三层网络隔离，不需要解决arp风暴问题；基于经典的、成熟的Netfilter/IPtables与Linux路由技术，包转发与细粒度策略控制效率高等。 二层SDN/OVS模型：这类模式的转发面是指Overlay二层和流表流水线设计与实现采用OVS，支持与各种Underlay模式的对接，可扩展实现DVR、广播抑制特性等。这是当前比较典型和成熟的转发面SDN模式方案；三层采用网络名字空间的Linux路由器；安全策略以及NAT功能采用Netfilter/IPtables实现。 基于这种参考架构实现的方案的优点是兼容了传统网络二层交换、三层路由、策略控制，可以通过VLAN实现多租户隔离；可以采用典型的SDN套路对容器网络的访问做到细粒度控制；Overlay与Underlay的解耦设计，具备良好的混合云、公有云的互联能力；逻辑结构清晰，可适应不同场景和规模的网络方案；有成熟的开发部署运维实践经验，稳定性经过生产环境验证。这种类型的典型有OpenShitf的SDN转发面方案，从某种角度来看它与Neutron模型的转发面实现有很多类似的地方。 SDN容器网络转发面设计与实现的关键因素，特别是对于虚拟网络方案而言，是选择以Linux路由、Netfilter为基础，叠加基于OVS的多租户支持等的SDN扩展。一般而言以OVS为主体的SDN容器网络解决方案，也是需要有三层互联的功能配合的。而对于简单扁平的三层容器网络方案是可以没有二层OVS特性支持的。 图4 K8S网络平面隔离配置 相应的管理控制面的设计与实现主要也分为基于BGP的分布式管理控制面和基于SDN控制器的集中式管理控制面等。 平台扩展与云原生部署K8S实现了典型的平台与应用解耦的架构设计，提供了种针不同场景的扩展手段。除了kubelet的CNI-Plugin网络挂接扩展外，与SDN容器网络相关的扩展机制还有Operator模式和Aggregated Server模式。 Operator扩展模式：这种模式基于CRD机制和定制控制器实现。CRD是通过apiextensions-apiserver实现的。K8S集群可以动态定义并注册用户资源对象的schema，可以像操作其他内置资源对象一样通过kubectl创建和访问这些自定义对象。定制化控制器是用户可以在集群内部署的定制开发的控制器，与定制化资源CRD等结合起来解决特定的应用问题。这种模式比较适合作为SDN控制器云原生部署的实施方案。 Aggregated-server扩展模式：这种方式的设计思路是通过增加API的扩展性，使K8S的用户可以扩展自己的API服务器，而不需要更改核心代码。这种方式的优点还在于可以将开发工作分阶段进行，新的API先在单独的API服务器中开发，在稳定之后再把它集成在一起。这种模式比较适合K8S监控系统的实现与部署。apiextensions-apiserver和替代早期版本K8S监控Heapster的metrics-server都是采用这种模式实现的。 图5 SDN控制器、代理、及CNI Plugin在K8S上的部署 库函数client-go包括了访问API server的客户端，以及支持控制器实现所需的相关平台机制List-Watch的客户端informer和事件队列workqueue等。这样控制器的设计与实现只需专注应用逻辑，只需提供对象的事件回调函数和相应的队列处理功能即可。 SDN控制器部署：K8S的SDN控制器的部署首先是创建SDN控制器和节点代理及CNI-Plugin部署和运行所需的服务账号、角色和角色绑定。定义角色的访问对象涉及哪些资源以及相应许可的操作。定义访问的主体，即服务账号，在特定名字空间中对相应角色、对象的访问授权；然后以Deployment的方式在主节点上部署SDN控制器，可采用ConfigMap实现SDN控制器的相关配置管理；在每个集群工作节点上以DaemonSet的方式部署SDN代理，其中的CNI-Plugin安装脚本容器负责在部署时安装CNI-Plugin插件和相应的网络配置等；以及通过CRD机制扩展相关的资源对象管理，实现相应的定制控制器进行K8S与SDN间的封装、对接、适配。 挂接Pod到容器网络kubelet：kubelet运行在集群的每个节点上，负责节点层面的Pod管理，周期执行Pod状态的探测和上报功能，并提供相应的http服务代理的各种Pod或容器操作等功能。 在系统运行过程中，kubelet的配置协程通过监听Watch apiserver获取分配给该节点的Pod。Pod工作协程池通过事件队列接收从配置协程发来的Pod创建请求，调用相应的Pod管理、容器管理、设备管理等Manager模块，最终通过容器运行时（以及dockershim）与Docker和CNI-Plugin互动完成Pod的创建。PLEG（Pod Lifecycle Event Generator）协程会持续地通过容器运行时监视本节点Pod的状态，与相应的期望值进行比较，当发现状态变化时生成相应事件给Pod工作协程实现相应的同步处理以保证Pod正常工作。 图6 kubelet组件构成、功能、流程 除监听apiserver外，kubelet还支持监听本地静态配置文件创建Pod的功能。K8S集群主节点上的apiserver、controller-manager、scheduler以及etcd就是以这种静态Pod的方式由kubelet启动运行的。 CNI-Plugin：Docker在创建容器的过程中支持四种网络模式。bridge模式会为每个容器分配网络名字空间、IP地址等，并连接到本地的bridge上；host模式会共用主机的网络名字空间；none模式会分配给容器独立的网络名字空间，但不会对容器进行相关的网络配置；container模式是将新创建的容器和已经存在的某个容器共享网络名字空间。 kubelet在创建Pod过程中，首先通过容器运行时调用Docker以none模式创建Pod的SandBox，即pause容器，也就是在这个时间点kubelet调用CNI-plugin来进行相应的接口、IP、路由等网络相关配置任务的，即挂接Pod到容器网络上；然后调用Docker以container模式创建并运行init容器，共享SandBox的网络名字空间；最终调用Docker也是以container模式创建常规业务容器，同样共享SandBox的网络名字空间。 图7 CNI-Plugin在kubelet创建Pod时将之挂接到容器网络上 所以CNI-Plugin是在kubelet创建Pod时被直接或通过dockershim调用来为Pod的SandBox做网络配置的。原则上CNI-Plugin不包含“容器网络”主体项目租户、网络子网等的创建和管理等功能。从这个意义上我们可以理解CNI-Plugin的作用主要是kubelet在创建Pod时将之挂接到“容器网络”上。 SDN解决方案的价值广义地讲SDN的基本功能是把可形式化的、繁琐的各种网络的监管控操作自动化以支持运维人员直观便捷地获取各种信息、执行各种操作、解决各种问题。狭义地讲SDN的核心技术主要包括OpenFlow模式等交换机的转发面流表流水线设计和相应的基于SDN控制器平台的应用开发等方面。 流表流水线设计SDN转发面OpenFlow流表实际上可以理解为是对二层交换mac表、三层路由表、防火墙ACL策略表等的一种抽象。所以从原理上讲OpenFlow/OVS交换机可以特定化承载传统的二层交换、三层路由、以及各种ACL等功能。SDN这种转发面从特例到一般再到特例的演进过程中，其价值更体现在可以支持更多种千变万化的应用上，这就是SDN转发面流表流水线设计的核心。通常SDN网络解决方案的套路就是针对特定问题设计相应的流水线，并基于SDN控制器平台开发相应的应用配合起来形成整体的解决方案。OpenShift的SDN容器网络以及Neutron架构中的DVR、SFC就是比较典型的案例。而现阶段多数SDN解决方案的转发面通常是在经典的二层交换、三层路由基础之上扩展细粒度流表设计实现相应的Overlay/Underlay转发、策略、服务链功能等的。 图8 SDN控制器平台与应用 控制器平台与应用SDN控制器主要包括平台和应用两个层面。平台通常采用基于分布式内存存储的某开源方案，控制器集群遵循CAP理论约束，支持基于任务和功能的负载分割，实现相应的二层交换、三层路由、拓扑管理、规则下发、状态统计等功能。而各种应用的开发是与相应的转发面、流表流水线设计相配合实现相应的网络互联、安全隔离、服务链、网络SLA/QoS、以及监控分析可视化与闭环控制等功能。 SDN控制器的南向接口对接各种网元设备，可以是物理的、也可以是虚拟的；北向接口提供各种网络主体的管理操作，可以通过各种封装适应不同的应用场景与不同的云管平台对接；西向接口可以是与K8S各种相关资源对象的动态互动适配；而东向接口可以作为CNI-Server提供给kubelet的CNI-Plugin完成将Pod挂接到容器网络的相关操作。 SDN这种架构适用于物理Fabric网络的管控和/或服务器Overlay虚拟网络的管控；适用于OpenStack、vSphere、K8S的网络管控；适用于DCN、WAN，也适用于混合云；适用于网络主干的管控、资源池的管控，也适用于边缘互联的管控。 系统部署示例一个典型的生产环境K8S和SDN容器网络部署除划分有各个网络平面外，服务器节点也可以拆分为不同的功能组。其中主节点组承担K8S集群的Master角色，主要运行apiserver、controller-manager、scheduler组件等；基础节点组属于K8S集群的工作节点，通过设置节点标签，只用于部署系统基础服务，包括注册仓库、三层路由、监控可视化、SDN控制器等；业务节点组也属于工作节点，用于运行业务系统的各种应用容器Pod。如果以OpenStack为参照的话，主节点组对应OpenStack的控制器节点；基础节点组部分功能对应OpenStack的网络节点；业务节点组则对应OpenStack的计算节点。 图9 K8S与SDN网络生产环境部署示例 SDN解决方案包括在K8S场景下的应用可以支持业务应用弹性扩展、更新迭代；自动化可提高系统运行稳定、有效的运维排障；细粒度控制可以提高访问和数据的安全性。采用SDN技术实现K8S容器网络，SDN控制器基于K8S平台扩展机制的云原生部署，并与相应的生态组件形成SDN监管控一体化解决方案，可以更好地提高整个系统的运营水平，更有效地提升企业的核心竞争力。 |
|
|
