移动端网站开发项目,做竞价的网站可以做优化吗,网站建设中服务器的搭建方式有几种,wordpress如何配置伪静态导读#xff1a;云原生时代#xff0c;Kubernetes 的重要性日益凸显。然而#xff0c;大多数互联网公司在 Kubernetes 上的探索并非想象中顺利#xff0c;Kubernetes 自带的复杂性足以让一批开发者望而却步。本文中#xff0c;阿里巴巴技术专家孙健波在接受采访时基于阿里… 导读云原生时代Kubernetes 的重要性日益凸显。然而大多数互联网公司在 Kubernetes 上的探索并非想象中顺利Kubernetes 自带的复杂性足以让一批开发者望而却步。本文中阿里巴巴技术专家孙健波在接受采访时基于阿里巴巴 Kubernetes 应用管理实践过程提供了一些经验与建议以期对开发者有所帮助。 在互联网时代开发者更多是通过顶层架构设计比如多集群部署和分布式架构的方式来实现出现资源相关问题时的快速切换做了很多事情来让弹性变得更加简单并通过混部计算任务来提高资源利用率云计算的出现则解决了从 CAPEX 到 OPEX 的转变问题。
云计算时代让开发可以聚焦在应用价值本身相较于以前开发者除了业务模块还要投入大量精力在存储、网络等基础设施如今这些基础设施都已经像水电煤一样便捷易用。云计算的基础设施具有稳定、高可用、弹性伸缩等一系列能力除此之外还配套解决了一系列应用开发“最佳实践”的问题比如监控、审计、日志分析、灰度发布等。原来一个工程师需要非常全面才能做好一个高可靠的应用现在只要了解足够多的基础设施产品这些最佳实践就可以信手拈来了。但是在面对天然复杂的 Kubernetes 时很多开发者都无能为力。
作为 Jira 和代码库 Bitbucket 背后的公司Atlassian 的 Kubernetes 团队首席工程师 Nick Young 在采访中表示 虽然当初选择 Kubernetes 的战略是正确的至少到现在也没有发现其他可能的选择解决了现阶段遇到的许多问题但部署过程异常艰辛。 那么有好的解决办法吗
太过复杂的 Kubernetes
“如果让我说 Kubernetes 存在的问题当然是‘太复杂了’”孙健波在采访中说道“不过这其实是由于 Kubernetes 本身的定位导致的。”
孙健波补充道Kubernetes 的定位是“platform for platform”。它的直接用户既不是应用开发者也不是应用运维而是“platform builder”也就是基础设施或者平台级工程师。但是长期以来我们对 Kubernetes 项目很多时候都在错位使用大量的应用运维人员、甚至应用研发都在直接围绕 Kubernetes 很底层的 API 进行协作这是导致很多人抱怨 “Kubernetes 实在是太复杂了”的根本原因之一。
这就好比一名 Java Web 工程师必须直接使用 Linux Kernel 系统调用来部署和管理业务代码自然会觉得 Linux “太反人类了”。所以目前 Kubernetes 项目实际上欠缺一层更高层次的封装来使得这个项目能够对上层的软件研发和运维人员更加友好。
如果可以理解上述的定位那么 Kubernetes 将 API 对象设计成 all-in-one 是合理的这就好比 Linux Kernel 的 API也不需要区分使用者是谁。但是当开发者真正要基于 K8s 管理应用、并对接研发、运维工程师时就必然要考虑这个问题也必然要考虑如何做到像另一层 Linux Kernel API 那样以标准、统一的方式解决这个问题这也是阿里云和微软联合开放云原生应用模型 Open Application Model OAM的原因。
有状态应用支持
除了天然的复杂性问题Kubernetes 对于有状态应用的支持也一直是众多开发者花费大量时间研究和解决的问题并不是不可以支持只是没有相对较优的解决方案。目前业内主流的针对有状态应用的解法是 Operator但是编写 Operator 其实是很困难的。
在采访中孙健波表示这是因为 Operator 本质上是一个“高级版”的 K8s 客户端但是 K8s API Server 的设计是“重客户端”的模型这当然是为了简化 API Server 本身的复杂度但也导致了无论是 K8s client 库还是以此为基础的 Operator都变的异常复杂和难以理解它们都夹杂了大量 K8s 本身的实现细节比如 reflector、cache store、informer 等。这些并不应该是 Operator 编写者需要关心的Operator 编写者应该是有状态应用本身的领域专家比如 TiDB 的工程师而不应该是 K8s 专家。这是现在 K8s 有状态应用管理最大的痛点而这可能需要一个新的 Operator 框架来解决这个问题。
另一方面复杂应用的支持不止编写 Operator 这么简单这里还需要有状态应用交付的技术支撑这是目前社区上各种持续交付项目都有意或者无意间忽略掉的事情。事实上持续交付一个基于 Operator 的有状态应用跟交付一个无状态的 K8s Deployment 的技术挑战完全不是一个量级的。这也是孙健波所在团队在 CNCF 应用交付领域小组CNCF SIG App Deliver倡导“应用交付分层模型”的重要原因如下图所示四层模型分别为“应用定义”、“应用交付”、“应用运维与自动化”、“平台层”只有通过这四个层不同能力的合力协作才能真正做到高质量和高效率的交付有状态应用。 举个例子Kubernetes API 对象的设计是“all-in-one”的 即应用管理过程中的所有参与者都必须在同一个 API 对象上进行协作。这就导致开发者会看到像 K8s Deployment 这样的 API 对象描述里 既有应用开发关注的字段也可以看到运维关注的字段还有一些字段可能还是被多方关注的。
实际上无论是应用开发、应用运维还是 HPA 这样的 K8s 自动化能力它们都有可能需要控制一个 API 对象里的同一个字段。最典型的情况就是副本数replica这种参数。但是到底谁 own 这个字段是一个非常棘手的问题。
综上既然 K8s 的定位是云时代的 Linux Kernel那么 Kubernetes 就必须在 Operator 支持、API 层以及各类接口定义的完善上不断进行突破使得更多生态参与者可以更好的基于 K8s 构建自己的能力和价值。
阿里巴巴大规模 Kubernetes 实践
如今Kubernetes 在阿里经济体的应用场景涵盖了阿里方方面面的业务包括电商、物流、离在线计算等这也是目前支撑阿里 618、双 11 等互联网级大促的主力军之一。阿里集团和蚂蚁金服内部运行了数十个超大规模的 K8s 集群其中最大的集群约 1 万个机器节点而且这其实还不是能力上限。每个集群都会服务上万个应用。在阿里云 Kubernetes 服务ACK上我们还维护了上万个用户的 K8s 集群这个规模和其中的技术挑战在全世界也是首屈一指的。
孙健波透露阿里内部早在 2011 年便开始了应用容器化当时最开始是基于 LXC 技术构建容器随后开始用自研的容器技术和编排调度系统。整套系统本身没有什么问题但是作为基础设施技术团队目标一定是希望阿里的基础技术栈能够支撑更广泛的上层生态能够不断演进和升级因此整个团队又花了一年多时间逐渐补齐了 K8s 的规模和性能短板。总体来看升级为 K8s 是一个非常自然的过程整个实践过程其实也很简单
第一解决应用容器化的问题这里需要合理利用 K8s 的容器设计模式第二解决应用定义与描述的问题这里需要合理的利用 OAMHelm 等应用定义工具和模型来实现并且要能够对接现有的应用管理能力第三构建完整的应用交付链这里可以考虑使用和集成各种持续交付能力。
如上的三步完成就具备了对接研发、运维、上层 PaaS 的能力能够讲清楚自己的平台价值。接下来就可以试点开始在不影响现有应用管理体系的前提下一步步换掉下面的基础设施。
Kubernetes 本身并不提供完整的应用管理体系这个体系是整个云原生的生态基于 K8s 构建出来的可以用下图表示 Helm 就是其中最成功的一个例子它位于整个应用管理体系的最上面也就是第 1 层还有 Kustomize 等各种 YAML 管理工具CNAB 等打包工具它们都对应在第 1.5 层。然后有 Tekton、Flagger 、Kepton 等应用交付项目对应在第 2 层。Operator 以及 K8s 的各种工作负载组件比如 Deployment、StatefulSet对应在第 3 层。最后才是 K8s 的核心功能负责对工作负载的容器进行管理封装基础设施能力对各种不同的工作负载对接底层基础设施提供 API 等。
初期整个团队最大的挑战来自于规模和性能瓶颈但这个解法也是最直接的。孙健波表示随着规模逐渐增大我们看到规模化铺开 K8s 最大的挑战实际上是如何基于 K8s 进行应用管理和对接上层生态。比如我们需要统一的管控来自数十个团队、数百个不同目的的 Controller我们需要以每天近万次的频率交付来自不同团队的生产级应用这些应用的发布、扩容策略可能完全不同我们还需要对接数十个更加复杂的上层平台混合调度和部署不同形态的作业以追求最高的资源利用率这些诉求才是阿里巴巴 Kubernetes 实践要解决的问题规模和性能只是其中一个组成部分。
除了 Kubernetes 的原生功能外在阿里巴巴内部会开发大量的基础设施以 K8s 插件的形式对接到这些功能上随着规模的扩大用统一的方式发现和管理这些能力成为了一个关键问题。
此外阿里巴巴内部也有众多存量 PaaS这些是为了满足用户不同业务场景上云所构建的比如有的用户希望上传一个 Java 的 War 包就可以运行有的用户希望上传一个镜像就可以运行。在这些需求背后阿里各团队帮用户做了许多应用管理的工作这也是存量 PaaS 出现的原因而这些存量 PaaS 与 Kubernetes 对接过程可能会产生各种问题。目前阿里正在通过 OAM 这个统一标准的应用管理模型帮助这些 PaaS 向 K8s 底盘进行对接和靠拢实现标准化和云原生化。
解耦运维和研发
通过解耦Kubernetes 项目以及对应的云服务商就可以为不同的角色暴露不同维度、更符合对应用户诉求的声明式 API。比如应用开发者只需要在 YAML 文件中声明”应用 A 要使用 5G 可读写空间“应用运维人员则只需要在对应的 YAML 文件里声明”Pod A 要挂载 5G 的可读写数据卷“。这种”让用户只关心自己所关心的事情“所带来的专注力是降低 Kubernetes 使用者学习门槛和上手难度的关键所在。
孙健波表示现在大多数的解法实际上是“悲观处理”。比如阿里内部的 PaaS 平台为了减轻研发使用的负担长期以来只开放给研发设置 5 个 Deployment 的字段。这当然是因为 K8s YAML all-in-one的设计使得完整的 YAML 对研发来说太复杂但这也导致 K8s 本身的能力绝大多数情况下对研发来说是完全没有体感的。而对 PaaS 平台运维来说他反而觉得 K8s YAML 太简单不够描述平台的运维能力所以要给 YAML 文件添加大量 annotation。
此外这里的核心问题在于对运维人员而言这种“悲观处理”的结果就是他自己太“独裁”包揽了大量细节工作还费力不讨好。比如扩容策略目前就是完全由运维一方说了算。可是研发作为编写代码的实际人员才是对应用怎么扩容最有发言权的而且研发人员也非常希望把自己的意见告诉运维好让 K8s 更加 灵活真正满足扩容需求。但这个诉求在目前的系统里是无法实现的。
所以“研发和运维解耦”并不是要把两者割裂而是要给研发提供一个标准、高效的同运维进行沟通的方式这也是 OAM 应用管理模型要解决的问题。孙健波表示OAM 的主要作用之一就是提供一套研发从自己的角度表达诉求的标准和规范然后这套标准“你知我知系统知”那么上面这些问题也就迎刃而解了。
具体来说OAM 是一个专注于描述应用的标准规范。有了这个规范应用描述就可以彻底与基础设施部署和管理应用的细节分开。这种关注点分离Seperation of Conerns的设计好处是非常明显的。举个例子在实际生产环境中无论是 Ingress、CNI 还是 Service Mesh这些表面看起来一致的运维概念在不同的 Kubernetes 集群中可谓千差万别。通过将应用定义与集群的运维能力分离我们就可以让应用开发者更专注应用本身的价值点而不是”应用部署在哪“这样的运维细节。
此外关注点分离让平台架构师可以轻松地把平台运维能力封装成可被复用的组件从而让应用开发者专注于将这些运维组件与代码进行集成从而快速、轻松地构建可信赖的应用。OAM 的目标是让简单的应用管理变得更加轻松让复杂的应用交付变得更加可控。孙健波表示未来团队将专注于将这套体系逐步向云端 ISV 和软件分发商侧推进让基于 K8s 的应用管理体系真正成为云时代的主流。 阿里云双11领亿元补贴拼手气抽iPhone 11 Pro、卫衣等好礼点此参与http://t.cn/Ai1hLLJT
原文链接 本文为云栖社区原创内容未经允许不得转载。
