Kubernetes已成为一种通用调度器

作者：Janakiram MSV是Janakiram & Associates的创始人、负责人兼首席分析师，曾先后供职于微软、AWS和阿尔卡特-朗讯。

在计算机科学界，调度是指某种方式指定的工作被分配给能够完成该工作的资源所采用的方法。这个古老的问题自IBM S/360在20世纪60年代问世以来就存在了。

只要有可能由一组资源来完成的作业，调度就至关重要。在操作系统这个环境中，作业可能是简单的程序，而资源可能是CPU核心。与之相仿，操作系统中的调度器可能负责将代码行与某个线程或信号关联起来。

分散式计算将调度器的领域从内部进程和线程扩大到了物理机器集群。上世纪90年代，CORBA、DCOM和J2EE等分散式平台克服了对应用服务器集群中的组件进行调度这个难题。

最近，亚马逊EC2、Azure Fabric和OpenStack Nova等IaaS控制平面负责对物理主机上运行的虚拟机管理程序中的虚拟机进行调度。必须基于请求的资源将每个虚拟机放置在合适的主机上。

基于Apache Hadoop和MapReduce算法的大数据工作负载高度依赖成熟可靠的调度算法。HDFS即Hadoop的文件系统确保集群的所有节点都可以访问数据集。该架构完全专注于资源的可靠性和可用性。

Cloud Foundry和Heroku之类的PaaS系统有复杂的放置逻辑，可对隔离环境中的服务进行调度。每个服务打包并部署到虚拟机或物理主机中运行的执行环境中。

容器的兴起迫使业界重新审视资源调度器的设计。简单性和可扩展性成为了新调度器的两大考量因素。传统应用服务器面对的是少量服务器，而容器管理平台的worker节点可以少则一个、多则几千个。

Kubernetes和Mesosphere是资源调度器的现代典范。两者都旨在抽取底层基础设施，使调度任务对用户来说透明化。

Kubernetes中的调度

Kubernetes调度器是该平台的关键组件之一。它在主节点上运行，与API服务器和控制器密切配合。调度器负责匹配工作：将pod与节点匹配起来。你可以在本文中全面了解Kubernetes架构（https://thenewstack.io/kubernetes-an-overview/）。

调度器基于可用资源等多个因素为pod确定合适的节点。还可以通过节点亲和性（node affinity）来影响调度器，其中pod请求具有特定特征的节点。比如说，运行高I/O数据库的有状态pod可能向调度器请求拥有SSD存储后端的节点。还可以确保将一组pod放置在同一节点上以避免延迟。这就是pod亲和性。Kubernetes还支持自定义调度器，放置逻辑完全取决于第三方调度器。

Kubernetes调度器的最大优点在于简单性。大多数上述放置策略实现起来很简单。只需要pod和节点中适当包含或排除的一组标签和注释。一组节点和pod上的简单键/值对就能提供复杂的放置策略。

Kubernetes调度器：pod和节点之外

Kubernetes现成为我们这个时代最好的资源调度器之一。这个功能强大的调度器既简单，又可灵活扩展，让我们能够解决传统分散式系统中存在的许多问题。

Kubernetes正迅速成为在高度分散式环境中调度和管理作业的首选控制平面。这些作业可能包括将虚拟机部署到物理主机上、将容器放置到边缘设备中，或甚至将控制平面扩展到其他调度器（比如Serverless环境）。

KubeVirt是Kubernetes的虚拟机管理附件，旨在让用户可以在Kubernetes或OpenShift集群中让虚拟机与容器一同运行。它扩展Kubernetes采用的方法是，借助Kubernetes的自定义资源定义（CRD）API，为虚拟机和虚拟机集合添加资源类型。KubeVirt虚拟机在常规的Kubernetes pod中运行，它们可以访问标准的pod网络和存储资源，使用kubectl等标准的Kubernetes工具加以管理。

有了Mirantis的Virtlet项目，就可以在Kubernetes集群上运行虚拟机，好像它们是普通的pod。它使运维人员能够使用标准的kubectl命令来管理虚拟机，并将它们作为“一等公民”引入到集群网络。使用Virtlet，可以构建更高级的Kubernetes对象，包括部署、有状态服务集或守护进程集。

微软的Virtual Kubelet项目是最值得关注的利用Kubernetes的调度器。Virtual Kubelet是在外部环境中运行的代理，被注册为Kubernetes集群中的一个节点。该代理通过Kubernetes API创建节点资源。它用到了污点（taints）和容忍（tolerations）这些概念，通过调用原生API来调度外部环境中的pod。

Virtual Kubelet可与Azure Container Instances、Azure IoT Edge和AWS Fargate控制平面协同使用。

想详细了解Virtual Kubelet的架构和部署指南，请参阅我之前写的文章：https://thenewstack.io/lightning-fast-container-provisioning-with-microsofts-azure-container-instances/和https://thenewstack.io/explore-multicloud-deployments-aci-connector-kubernetes/。

未来之路－自定义调度器和自定义资源定义

上面讨论的几个项目只是冰山一角。随着Kubernetes成为现代基础设施的基础，它正准备运行各种工作负载，包括ERP和CRM等传统的业务应用软件。

应用软件开发商将高度依赖Kubernetes的两项新兴功能：自定义调度器和自定义资源定义（CRD）。

如前所述，Kubernetes中的自定义调度器让开发人员可以定义自定义调度逻辑。pod的声明可能包括自定义调度器的名称，暗示控制平面绕过默认调度器。这是一种强大的机制，可以控制集群中pod的放置。

Portworx是一家云原生存储公司，它利用自定义调度器的功能开发出了STORK（面向Kubernetes的存储调度器运行时环境）。它确保有状态的pod总是放置在拥有Portworx驱动程序和存储的节点上。这有助于实现作为容器部署的数据库工作负载的高可用性。

Kubernetes中的自定义资源将对象生命周期管理的简单性和强大功能扩展到了自定义类型。自定义资源是一种对象，可扩展Kubernetes API，或允许开发人员将自己的API添加到项目或集群。自定义资源定义（CRD）文件定义了让API服务器可以处理整个生命周期的自定义对象类型。将CRD部署到集群中促使Kubernetes API服务器开始提供指定的自定义资源。

一旦CRD创建完毕，运维人员可以使用kubectl或第三方工具来管理第三方资源的生命周期，就像他们处理Kubernetes中的pod和部署那样。独立软件开发商（ISV）可以将软件打包并部署成一组CRD。

Kubernetes的可扩展性让它成为一种通用的调度器和管理工具。