谷歌承认Kubernetes太复杂,于是开启了容器界的Autopilot

试问上手 Kubernetes 有多难?有时候真得会让你怀疑人生。

谷歌承认 Kubernetes 太复杂,于是开启了容器界的 Autopilot

谷歌承认 Kubernetes 太复杂,于是开启了容器界的 Autopilot

过去几年,就连互联网大厂的技术砖家也得细细捋。

“尽管我们过去几年看到越来越多的企业开始拥抱 Kubernetes,但是随后就陷入了困境。”

Google Kubernetes Engine(GKE)产品负责人 Drew Bradstock 在最近的一次公开声明中说道。

Kubernetes 就像一把双刃剑,既是最佳的容器编排技术,同时也存在相当高的复杂性和应用的高门槛,这个过程中往往会导致一些常见性错误。

2019 年,知名软件开发服务商 Atlassian 在尝试部署 Kubernetes 的三年后就发现了这一点:Kubernetes 部署起来实在太复杂了。

如今,就连 Kubernetes 的创立者和核心推动者 Google 本身都承认这个问题。

为什么 Kubernetes 这么难

实际上,在国内,Kubernetes 直到 2017 年之后才开始由混乱开始逐渐走向成熟,很大程度上也源自云计算市场本身的企业用户实践大大加快。

一次采访中,阿里巴巴资深技术专家张磊分析了 Kubernetes 的本质,他指出,

“Kubernetes 本身是一个分布式系统而不是一个简单的 SDK 或者编程框架,这本身已经将其复杂度提升到了系统级分布式开源项目的位置。此外,Kubernetes 第一次将声明式 API 的思想在开源基础设施领域普及开来,并以此为基础提出了系列诸如容器设计模式和控制器模型等使用范式,这些具有一定先进性和前瞻性的设计也使得 Kubernetes 项目被大众接受是存在一定学习周期的。”

也就是说,从目前造成 Kubernetes 复杂性的原因在于两点:一是技术本身的应用难度,二是开发者的接受度,市场的认知和成熟度均有待提高。

鼻祖 Google 如何不抛弃不放弃

自 2015 年 Google 推出其云端托管 Kubernetes 服务 Google Kubernetes Engine(GKE),就一直得到外界关注和使用。在此期间,Google 也在不断释出新的版本模型以强化其应用性。

不久前,Google 推出一项新功能 Autopilot 以简化部署和管理 Kubernetes 配置过程中存在的挑战。

GKE 是一个 Kubernetes 管理平台,主要在谷歌云平台上运行,也可以在 Anthos 集群管理的其他云平台或本地部署的平台上。

这么来看,目前存在两种操作模式,一是标准的手动控制,二是自动控制 Autopilot。Autopilot 的基本原理可以解释为:一款 GKE 完全托管部署的平台,需要运行在谷歌云平台上。尽管 GKE 本身就是一项托管服务,但与 Autopilot 的区别在于,后者能够比 GKE 具备更强的自主化和自动化能力。

Kubernetes 本身涉及了集群(一组物理或虚拟服务器)、节点(单个服务器)、pod(代表节点上一个或多个容器的管理单元)和容器等方面。GKE 主要对集群进行托管,而 Autopilot 则将这点扩展至节点和 pod。

谷歌承认 Kubernetes 太复杂,于是开启了容器界的 Autopilot

谷歌云通常是一地三个或三个以上机房。如果将所有资源放在单个机房,其弹性将小于将其分散在多个机房中,同时将故障分散到多个机房又可以最大程度提升弹性能力。Autopilot 模式始终是按地域划分的,这有利于弹性伸缩能力,不过成本较高。

p.s. 通常云用 region 和 zone 两个概念来进行分区,前者主要指地理分区,后者主要指具体机房。

不过,应用 Autopilot 模式同样存在其限制条件。其中包括操作系统始终基于 Google 自家容器的 Linux“容器优化”,而不是基于 Docker,或者基于 Windows Server 服务器。而且,每个节点的 pod 最大数量为 32,而标准 GKE 为 110。

同时,定价模式上也有所不同。每个 Autopilot 集群每小时还需要支付 1 美分的费用。

究竟是 Autopilot 更贵还是 GKE 更贵,这种显而易见的问题回答起来却并不简单。“与 GKE 相比,它还有一个溢价,因为我们得到了站点可靠性工程(Site Reliability Engineering,SRE)和 SLA 的服务,这就不仅仅只是产品功能了。”

也就是说,由于难以估计计算实例的正确规范,因此未充分 GKE 标准部署的成本可能会高于 Autopilot。

整体来看,新的 Autopilot 服务为 Kubernetes 提供了更多选择范畴,可参考成本是否增加、灵活性是否降低、或者给 IT 运维人员带来的潜在挑战等等。当然,这并不包括对客户支持的满意度这一问题。

值得一提的是,软件工程师 Kevin Lin 在最近对比了亚马逊和谷歌云服务,指出 Google 的客户支持基本上没有任何帮助,相比之下亚马逊的技术服务既快又有用。Kevin Lin 曾为亚马逊公司任职,他最近描述了自己使用 AWS 和 Google 云的经历。

回到一开始雷锋网所探讨的,针对 Kubernetes 复杂性问题是一直以来困惑很多开发人员的技术问题,伴随 Kubernetes 已然成为整个云原生社区最主流的开源容器编排技术,在生产环境的采用率越来越高,可以预见其复杂度也会呈线性增长。

你有没有针对复杂性问题的一个最佳实践呢?欢迎你的解决方案。

本文链接

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注