云原生分布式操作系统营造法式-云平台提供商视角

编者按：《100页ppt讲清楚云原生 》一文作者投稿连载，待有缘人读完。上次找的ppt不少朋友可能不志在交流，志在使用素材内部汇报等。欢迎点赞在看转发三连，幸甚！

作者介绍：

高磊(曾用花名世忠、胤禛) ，16年工作经验，原阿里巴巴、华为架构师，专注于云原生领域的产品规划设计以及技术架构。 

直接上图，下图是云原生分布式操作系统的数据模型，它是从抽象层面来表达控制逻辑的对象图。

我们都清楚K8S已经是事实的容器服务编排标准，它采用一种抽象层面的方式来纳管底层硬件资源并同时向上提供“应用”生命周期管理支持。比如K8S使用Pod对象来表达一个“服务实体”，并对应于一种Deployment的部署逻辑（控制器），并且它同时对应于一个或者多个控制器，主控制器监控API server中对象的变化并采取相应的动作。这是K8S这种复杂系统里面的最原子机制，基于这个机制实现所有自动化操作。后来又出现了Operator，使得基于CRD模型以及具体场景来拓展K8S就非常容易了。

所以上图实际上是和Pod这种对象一样的抽象，它的载体都是数据（存储在ETCD中），运行实体都是控制器，而控制器会具体调用外部模块或者系统完成具体的调整动作，比如Kubelet、或者其他外部服务（比如SaltStack）。如果我们能一开始建立正确的模型，也就是代表着有了正确的资源、应用治理的逻辑设计，对于云原生操作系统而言就成功了一半。最后基于这个模型去设计物理组件的架构就非常有章可循了。

• Region和AZone

  • 云计算资源分别在全球多个数据中心。Region代表托管的地理位置。Region内网络是高带宽和低延迟的。应用可以对等部署在多个Region中，实现异地多活的能力。

  • AZone，即可用区，AZone之间物理隔离，具备独立的电源、网络等。用以提高Region内部的故障隔离性。

• Rack和ComputeAsset

  • Rack，即机柜。其中存放的每台设备叫做ComputeAsset。一般Rack存放的是同一类型和同一型号的设备。ComputeAsset是个抽象概念，可能是计算机、也可能是路由器等设备。

• SKU和Flavor

  • SKU是服务器硬件配置的定义，比如CPU、内存、磁盘大小等。Flavor从使用者角度详细定义了服务器应该满足的资源规范。一种SKU可以支持多种Flavor。

• Cluster

  • Cluster代表一个K8S集群。每个AZone可以有多个集群。它定义了一个集群的AZone、NetworkZone、Master和Minion节点个数、使用的OsImage和Flavor等。

• Cloud

  • Cloud代表一个类似联邦的统一控制层，它可以注册多个Cluster，它代表一种先进的方向，就是多集群管理，并可以拓展成多云管理模式（多云，就是底层资源来自于不同的供应商，云中立策略有利于优化成本和解除云供应商绑定问题）。

• ComputeNode和NodePool

  • ComputeNode对应于运行了操作系统的物理机或者虚拟机。每一个ComputeNode都是K8S的一个计算节点。当新的ComputeNode对象被创建的时候，集群管理平面会根据其指定的Flavor选择合适的ComputeAsset安装和运行指定的操作系统。通过Tag来区分ComputeNode（比如，role=master或者role=minion）。

  • NodePool，定义了一组同类型ComputeNode的集合。NodePool定义了ComputeNode的副本数量和模版。NodePool控制器要负责N个ComputeNode始终保持健康，并通过重新创建或者修复有故障的计算节点来保证集群资源规模。NodePool有利于实现更高级的抽象，比如自动化伸缩组，可以基于实时资源利用率自动伸缩计算机节点池。

• Unit

  • Unit就是单元化，所谓单元化就是将一个调用完全封闭在一个服务领域中，比如下单就只能落入一个下单这个单元中，防止多服务跨域调用的开销，导致整体性能不佳。另外利用单元化可以实现特殊的扩容操作，就是一个单元包含着一组为了完成下单的不同单元业务服务，它们一起扩容（比如向公有云弹出或者弹入），使得资源利用更加充分。另外一个单元故障，并不会影响同一个单元的其他实例单元集群。Unit是垂直上的逻辑切分，而NodePool是水平的切分。

• OSImage

  • OSImage代表操作系统的家族、内核版本、发型说明以及下载地址。当创建集群的节点时，指定计算设备的操作系统，那么此ComputeAsset被外部运维系统安装好操作系统后就转换成ComputeNode，当要升级操作系统时，只需要在ComputeNode升级版本信息即可。控制器会调用外部运维系统进行升级操作的。

• K8SImage、CNIImage等

  • 类似于OSImage，在控制器命令外部运维系统初始化节点后（比如安装和运行操作系统等），其他运维控制器发现了ComputeNode对象状态的改变，就执行在此节点上安装K8S组件或者指定的CNI插件等操作。此时请注意，这是K8S的基础机制，一个控制器完成一个动作后回写对象状态，会被其他类型的控制器Watch到，然后形成一种连锁反应，这是K8S自动化的奥秘所在。

• OpsMaster和OpsMinion

  • 我们并不假定计算节点的运维一定是SaltStack，即便是Ansible也可以。不过我们把这种基于C/S架构的外部运维系统抽象成OpsMaster和OpsMinion。我们通过抽象它们来监控它们的运行状态。

• Node

  • 这是K8S标准的对象，只不过我们通过ComputeNode的控制器将其转换成了K8S的Node。那么你会发现Node似乎是底层资源和K8S之间的纽带。实际是我们需要干掉原生的Node控制器，而采用ComputeNode的控制器代替之，但是对于K8S以及它的用户没有任何差异性感知。

• App

  • 由多个Service构成，它代表了其拓扑和配置，通过服务市场或者镜像仓库可以进行集群封装式分发，提高自动化程度，降低交付成本。

以上，我们通过解释各种对象的定义含义，也同时解释了它们的核心动态关系。那么为什么这么设计呢？主要是我们在落地云原生操作系统时遇到以下的挑战

K8S对OS以及OS级别依赖的管理毫无能力，那么落地时就无法大规模部署

• • 节点手工初始化，效率太差并且容易出错。OS的升级是个可怕的噩梦。K8S本身没有运维体系支撑。K8S组件的升级，处理不好就导致服务宕机。
    

  • 网络环境差异，部署繁琐并容易出错。不同集群之间可能是不同的网络环境，比如有些支持GBP、有些支持VXLan等，集群之间存在打通的问题，还有就是入口与出口流量如何打通的问题。
    

  • 扩容集群时无法自动化同步网络组件和配置，都需要手工操作，非常繁琐并容易出错，传统ITOM系统和新型的云原生操作系统是两个独立的运维领域，需要两个团队来管理，并且之间很难根据实际业务量联动，完全靠人肉沟通和人肉资源容量评估来实施，时效慢并且成本非常高。

所以，思路就是在抽象层面上将从底层ITOM到K8S，以及K8S以上等的实体技术组件通过K8S资源对象的形式上浮到可度量、可观察、可控制的一体化机制上来，幸好K8S支持Resource Object这种抽象形式，也正好有可以自定义控制器的CRD这种拓展形式存在，我们变相的把技术实体全部变成RO形态并顺带暴露成声明行API。带来的就是我们可以从APP级别的资源负载需求通过一系列控制器的计算和转换形成了以下机制：

在集群规模不变的情况下，根据APP资源需求自动扩容或者收缩Pod，这是标准化K8S HPA控制器干的事情。

在集群中容器规模突破集群容量保护阀值时，有Cluster等控制器下发资源Offer到NodePool对象上，NodePool对象通过Flavor匹配对应的ComputeAsset并自动安装操作系统和K8S kublet等，自动加入加入集群。而无需关心对底层IaaS如何扩容的问题。并且更加精准，成本更加可视化。

NodePool和Unit对应的控制器可以保证通过间接激发OpsMinion控制器来实现扩容时自动下载和安装CNI插件（比如Calico、Cilium等）、CRI插件（Kata、Docker等等）、CSI（ceph、NFS等），并同时同步相关配置，使得集群网络、计算、存储配置保持一致。在NodePool资源隔离情况下，通过更高级控制器协调网络配置，达到混合集群之间的网络打通。比如线上集群加入线下，或者线下集群接入线上，或者自研集群接入标准化集群，或者边缘计算集群接入线上集群等等。

对于K8S上层平台，比如PaaS，一切都没有变化。照样可以集成istio、抽象应用治理能力、一体化交付等等。

我们根据以上的抽象层面的资源对象抽象，实际上已经设计了一个高度自动化的云原生操作系统一体机。而我们仅仅需要通过Operator（CRD）来完成这些拓展，对K8S本身没有侵入，保持独立性的同时（也就是说可以跟着K8S社区来做升级）满足通用化云原生底座的需求。

我们已经知道以上如何把自动化进行到底的，比如上图【基于抽象对象模型的各类控制器】就是我们的“大脑”，它把从多云、集群、资源、网络、存储等全部自动化管理起来了。剩下的就是围绕这个模型的“物理化”建设了，“精神文明和物质文明都要硬”！在接下来的第三部分文章中我们将讲述：

1. CICD Worker架构，被集成策略的CI和CD

2. 分区日志汇总机制，超大规模日志采集和存储的秘诀。

3. 各类基于上述抽象模型对象的控制器，它们是如何完全自动化的完成复杂动作的？而PaaS层只是部署一个应用镜像这么简单。（自动化一体机，或者叫做自驾驶治理机制）

4. 应用状态控制器，通过以实际应用流量预测资源来实际激发一系列自动化操作。

5. 网络打通细节，入网、线上线下打通、边缘打通等如何实现。（包治各种网络疑难杂症）

6. 外部ITOM自动化联动

7. 集群打包交付，一种完全自动化的交付体验。

8. 大规模镜像仓库实践，稳定性、吞吐量以及性能保证，尤其是安全策略对资源管理负面影响的解决方案（基于时效的自动白名单）。

未完待续

往期推荐：

• 100页ppt讲清楚云原生
  

• 我在美团的八年
  

• 我们做出了一个分布式注册中心
  

• 质量团队在急速扩张期的挑战与应对
  

•    ……

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。