谷歌承认 Kubernetes 太繁杂，因此开启容器界的 Autopilot

不知入门 Kubernetes 有多么难？有时真的会使你开始怀疑人生。

以往两年，就连互联网大厂的技术性专家也得细细地捋。

“虽然大家以往两年见到愈来愈多的公司逐渐相拥 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。

谷歌云一般是一地三个或三个之上主机房。假如将全部資源放到单独主机房，其延展性将低于将其分散化在好几个主机房中，另外将常见故障分散化到好几个主机房又可以较大水平提高延展性工作能力。Autopilot 方式自始至终是按地区区划的，这有益于延展性伸缩式工作能力，但是成本费较高。

p.s. 一般云用 region 和 zone 2个定义来开展系统分区，前面一种关键指地理分区，后面一种关键指实际主机房。

但是，运用 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 在近期比照了amazon和谷歌云服务项目，强调 Google 的顾客适用大部分沒有一切协助，比较之下amazon的技术咨询既快又有效。Kevin Lin 曾为亚马逊平台就职，他近期叙述了自身应用 AWS 和 Google 云的历经。

返回一开始所讨论的，对于 Kubernetes 多元性难题是一直以来疑惑许多开发者的技术性难题，随着 Kubernetes 早已变成全部云原生小区最流行的开源系统器皿编辑技术性，在工作环境的利用率愈来愈高，能够预料其复杂性也会呈线性增长。

你有没有对于多元性难题的一个最佳实践呢？欢迎您的解决方法。