柳州搜索引擎营销平台,网站优化和网站推广,网页原型图,凡科可以做社交网站吗关于Kubernetes的一些零碎想法 容器集群管理系统与容器编排系统 很多使用Kubernetes的企业可能没有认识到Kubernetes最重要的特点。许多企业将其视为一种容器集群管理系统#xff08;container management system#xff09;#xff0c;只使用其管理容器的能力。然而#x… 关于Kubernetes的一些零碎想法 容器集群管理系统与容器编排系统 很多使用Kubernetes的企业可能没有认识到Kubernetes最重要的特点。许多企业将其视为一种容器集群管理系统container management system只使用其管理容器的能力。然而这种看法是大错特错的。如果只是想管理容器Mesos可能在这方面甚至比Kubernetes做得更好。甚至只需将OpenStack的driver从虚拟机换成容器就可以实现管理容器而无需进行任何更改。甚至自行开发一个容器管理系统也比引入Kubernetes来得简单因为引入Kubernetes无疑增加了整个系统的复杂度。 实际上Kubernetes在某种程度上甚至是借鉴了Mesos的设计而Mesos本身则是借鉴了Google的Borg。相较之下Yarn则是雅虎推出的半吊子产品其集群资源管理和分布式计算框架之间的层次划分并不十分明确对容器和GPU的支持直到2018年才开始并且它并不支持镜像部署。这一切源于Yarn诞生较早大约在2005年左右当时还没有计算存储分离和不可变基础设施等概念。 Kubernetes作为容器编排系统 Kubernetes的创始人并不是将其描述为容器集群管理系统而是称其为容器编排系统container orchestration system。在我接触Kubernetes之前我曾参与IaaS虚拟机集群管理系统的开发并接触过像Yarn这样的大数据计算任务集群管理系统。我在大学实习时还涉足了Hadoop相关工作当时只是简单地编写HiveQL主要是做数仓方面的工作对于Yarn的设计并不了解。但后来我自学了Yarn认为Yarn是较好的资源管理和调度系统。 然而当我逐渐熟悉Kubernetes时我第一反应并不是容器、镜像、集群资源管理和调度等方面这些方面实际上Mesos做得更出色且更早kubelet很多代码还是参考自Mesos。真正让Kubernetes出色的地方在于其开放式API自定义资源的能力控制器模式和原生的调度和编排功能。这使得我相信统一基础设施是有可能实现的在我看来Yarn或者Mesos实际上只是一个普通的集群资源管理系统。虽然大家都说没有银弹就像编程语言一样没有绝对的银弹但我认 为Kubernetes是分布式时代最接近银弹的一枚。 我曾在单机上实现过一些多进程的Pipeline小程序发现Kubernetes中的Pod其实就是在集群之上抽象出来的进程。你不需要关注集群中的物理节点你只需要关注如何创建、监听和编排这些Pod就像以前在单机上写的编排程序一样。这是我对Kubernetes思想的第一个理解它抽象出了基本概念和接口就像操作系统的基本概念和系统调用一样而操作系统的接口几乎三十年来都没有变化这正是它设计的先进之处。 在分布式系统中有一个不可回避的话题即在多台机器上运行代码而不是在单个机器上。因此所有的分布式系统都需要一个简单的接口来实现这个功能。无论是无状态应用有状态应用只要你的服务涉及到多台实例你都会面对运维、部署、发布、弹性而这恰恰是Kubernetes给出的统一标准答案Kubernetes现在也正在的成为了事实的标准。 Yarn看到Kubernetes攻占了微服务的地盘后甚至试图进军AI和大数据的领域。因此在2019年左右Yarn开始支持Docker容器和镜像。需要注意的是Yarn中的NodeManager虽然通过分配Container的形式来为应用分配资源但之前的Container只是Yarn中的一种资源抽象并不是Docker而是直接使用Cgroup隔离启动JVM虚拟机进程并没有镜像这些概念。很可惜Yarn只强调资源分配和隔离而不强调不可变基础设施并且确实已经老态龙钟因此之前的Yarn无法在一个集群中运行不同版本的MapReduce或Spark。而在Kubernetes上每一个Spark App就是一个小型集群从最简单的Deployment集群到有状态的StatefulSet集群再到更加复杂的大型分布式应用集群且这些App可以采用不同的镜像版本而Kubernetes恰恰就特别擅长和适合用来维护管理一个个小型应用集群。Kubernetes抽象程度大于Yarn这就是为什么Yarn可以运行在Kubernetes上而不能反过来。 云原生调度和资源管理 目前大多数分布式计算框架如Spark和MapReduce都具有自己的集群资源管理和调度功能。在Kubernetes出现之前大多数企业要么自行开发这些功能要么选择使用Yarn和Mesos。然而Yarn和Mesos并不属于云原生调度。 个人而言我更偏爱全面采用Kubernetes的做法而不是采用二层甚至三层的调度。将Kubernetes视为IaaS仅用于机器分配然后部署Yarn或Mesos由它们自行管理集群我认为这种做法非常鸡肋完全没有摆脱传统的IaaS思维实际上你只是提供了一台机器完全可以不使用Kubernetes这么复杂的系统来实现容器交付。这样的问题在于每个Yarn集群只能看到自己的资源视角并不知道整个基础设施的资源情况而Yarn本身对MapReduce App的调度就没有全局资源视角。 如果去掉中间层的Yarn和Mesos让Kubernetes直接调度Spark、MapReduce App其实就会轻松很多所谓中间商赚差价过多的中间层也会消耗过多的人力和资源。不过这主要不是技术问题而是风险、人力、时间、成本和部门问题。 面向终态和控制器模式 Kubernetes中到处都是控制器模式和面向终态的设计。对大多数公司来说除了Google之外这是一种非常激进的设计以至于许多公司要么不使用它要么不敢使用它。当然Kubernetes的这种声明式设计并非独创许多编程语言和框架都支持声明式编程。 Kubernetes的控制器模式和面向终态的代码我很少写这类代码对程序员的能力要求确实很高。编写控制器最重要的是对差异的控制和理解需要非常严密的逻辑。这是因为这些代码不是过程式的它们是面向终态的代码。许多人可能不理解这之间的差异我自己开始也不是很理解毕竟我的水平有限。虽然说表面上看控制器很容易写主要原因在于面临的场景还不够复杂。 举个例子编程语言中经常会涉及两个概念Imperative命令式和Declarative声明式。Imperative描述如何执行How而Declarative描述的是要执行什么What。 这两个概念不仅存在于编程语言中目前的AI框架如TensorFlow和MXNet等都支持声明式编程。如果您有使用过这些框架的经验就会知道编写代码后它的执行并不是按顺序一行一行开始执行的而是将代码翻译成计算图来执行。从某种意义上说SQL也是一种声明式语言。 因此大家常说Kubernetes的API是声明式的这是什么意思呢 这并不是说Kubernetes的API使用了非HTTP/RPC的协议而是指它的API是声明式的。它只描述结果和终态而不描述过程。过程交给谁了交给Kubernetes中的控制器模式了。与前面提到的编程语言和AI框架类比就是您编写的YAML文件被Kubernetes解析后会以控制器模式的形式生效。举个例子如果您的Deployment需要5个Pod那么Kubernetes就会像一个机器人一样始终保持5个Pod的状态。如果您将Pod数量更改为7Kubernetes会自动调整到7个Pod。一切都按照您的指示执行。 实际上声明式编程只是人们迈向智能化的重要一步而不是表示没有代码。它只是将复杂性交给平台和框架处理Kubernetes的控制器模式和面向终态的设计则是彻底解放运维朝着自动化和智能化的方向迈进。这对于一个平台的能力保障要求就比较高。本质上这是一种能力的转移当机器有能力帮助你实现的时候你就可以解放双手去做更多更高级的事情。 不可变基础设施 不可变基础设施是什么意思 镜像让不可变成为可能镜像使得一次编译到处运行成为可能。镜像让发布部署变得非常方便。在传统基于虚拟机的IaaS架构中CI/CD流程可能是通过包部署的即代码构建后将其下载到要发布的机器上虚拟机或裸金属物理机然后进行部署运行。 然而基于Kubernetes的基础设施可以在CI/CD流程中首先将代码打包成镜像如Docker镜像然后使用Kubernetes的资源如Deployment来更新镜像进行滚动更新以实现部署。如果您的服务有状态自定义控制器还可以实现精细化的部署控制。 应用交付模型 现在大家都吹嘘以应用为中心的云原生概念其目标是推进应用交付。请注意这是应用交付而不是容器交付。这可能是一场困难的旅程因为从交付机器到交付应用研发和运维人员需要进行心智的升级。为什么我说这是心智升级我们传统的研发人员都习惯于将应用视为机器无论他们当前使用的是容器、虚拟机还是物理机他们的脑海中总是有机器的概念。在开发、测试和部署应用时他们总是需要机器。 实际上更抽象地说我们不需要机器。开发人员在开发时只需要一个代码编辑器测试时只需要控制台输出日志和调试代码部署服务只是需要将代码和环境批量复制运行时只需可观测性指标logging、tracing、metric运维和弹性扩容只需要系统自动根据算法参数调整。您可能会发现实际上不需要机器的概念。就像消费者购买个人电脑时不是为了机器本身而是为了使用上面的软件应用一样。开发者购买服务器是为了更快、更灵活、更便捷的调试、部署和运行服务。 然而由于许多基础设施在这方面尚未完善如果此时完全摈弃机器的概念只是让开发人员描述他们的需求以交付一个应用程序那么当应用出现问题时开发人员将无从下手。这也是Serverless目前推进较为困难的地方。 Serverless是当前最前卫的应用交付方式其实也没有太多统一答案该模式最大的好处是利好创业公司特别是规模体量不大的早期创业者围绕Serverless交付应用的创业公司不胜枚举目标就是为开发者提供非常方便的开发、部署体验都在不同层次上和方向微服务、AI、大数据进一步简化服务开发、部署、弹性、运维能力解放开发者。 比如以Google CloudRun 为代表的Serverless模型是一种既没有放弃镜像概念也结合了Serverless按量计费随时弹性的优点的Serverless交付模型。国内也有模仿者比如 阿里云Serverless Kubernetes、腾讯云华为云超级虚拟节点等一些创业公司搞的Serverless部署开发都属于这类服务。这是一种在Kubernetes之上往前衍生的一小步Serverless。这种模式更灵活也更能够被开发者接受。 另一个更高阶段的Serverless就是我们熟悉的云函数Serverless Function开发者只需要编写函数事件驱动的方式触发函数调用就可以完成某些功能模块。这个应用交付模型就更加激进其实云函数不会完全替代容器镜像交付它只能算一个场景补充主要原因在于大量的应用编写并不是云函数能够完全覆盖的所谓越是高级必然失去灵活性就是这个道理。 本文由 mdnice 多平台发布
