Kubernetes构架的八个难题

2021-03-30 13:42 jianzhan

Kubernetes的构架十分合适规模性的机构,可是针对中小型机构来讲,它将会会过度繁杂。

做为开源系统器皿编辑器,Kubernetes早已变成机构布署器皿化运用程序的具体处理计划方案。这在其中有一些充足的原因,在其中包含Kubernetes出示高宽比的靠谱性、全自动化、扩展性的客观事实。虽然这般,有此番业人员還是觉得Kubernetes构架过度繁杂。尽管早已有六年之上的运用历史时间,但它還是有很多缺陷。在其中一些缺陷是Kubernetes自身所原有的,而另外一些缺陷则是紧紧围绕该服务平台发展起來的绿色生态系统软件的物质。

在布署Kubernetes以前,公司必须考虑到下列开源系统器皿编辑器的一些难题。

1. Kubernetes是为规模性的企业设计方案的

最先,Kubernetes构架自始至终是为必须管理方法超大型经营规模运用程序自然环境的机构而搭建的。针对Google企业来讲(Borg编辑者组成了变成开源系统Kubernetes新项目的基本),Kubernetes是一个非常好的专用工具。而针对有着数十数量据管理中心及其千余个遍布在这其中的运用程序和服务的Netflix、Facebook、AWS等别的规模性的企业来讲,也是这般。

可是假如是一个经营规模较小的机构,而且仅有一个将会只布署十好多个运用程序的数据信息管理中心,那麼Kubernetes构架毫无疑问经营规模过度巨大,这将会如同安全驾驶挖掘机为后院花苑翻土一样屈才。除非是是规模性应用,不然配备和管理方法它必须处理很多的难题。

2. Kubernetes有许多发售版

Kubernetes构架的另外一个难题是,Kubernetes有许多发售版,及其很多两者之间有关的不一样的专用工具、核心理念和见解。

自然,在某类水平上,一切开源系统绿色生态系统软件上都会产生瓦解。比如,RedHat Linux与Ubuntu Linux具备不一样的手机软件检修口理器、管理方法专用工具等。可是,RedHat和Ubuntu的类似的地方宏大于差别。针对应用Red Hat系统软件的管理方法员来讲,假如要转移到Ubuntu,则不用花销六个月的時间通过自学新专用工具。

制造行业权威专家其实不觉得Kubernetes也是这般。假如如今已经应用OpenShift,但又想转换到VMware Tanzu,则其学习培训全过程将十分严峻。虽然这2个Kubernetes发售版都应用同样的基本服务平台Kubernetes,可是他们加上的方式和专用工具却迥然不一样。

根据云计算技术的Kubernetes服务也是有相近的瓦解。Google Kubernetes Engine(GKE)与Amazon EKS(非常于AWS云)等服务平台对比,具备迥然不一样的客户感受和管理方法专用工具模块。

自然,这其实不是Kubernetes构架自身的错,只是不一样供货商试着使其Kubernetes商品完成差别化的結果。可是从Kubernetes客户的视角看来,这依然是一个实际难题。

3. Kubernetes是好几个一部分构成的服务平台

大家将Kubernetes作为一个服务平台,但具体上它由6个之上的不一样部件构成。这寓意着当安裝或升级Kubernetes时,务必各自解决每一个部件。并且大多数数Kubernetes发售版都欠缺实行这种实际操作的全自动解决决计划方案。

自然,Kubernetes是一个繁杂的服务平台,它必须好几个一部分组成才可以工作中。可是两者之间他繁杂服务平台对比,Kubernetes在将其每个一部分集成化到一个便于管理方法的总体层面做得非常不尽人意。典型性Linux发售版也包括很多不一样的手机软件。可是客户可以以集中化、简单化的方法安裝和管理方法他们。Kubernetes构架并不是这般。

4. Kubernetes不容易全自动地确保高能用性

应用Kubernetes的最经常被谈及的缘故之一是,它以一种奇异的方法管理方法运用程序,确保他们始终不容易不成功,即便一部分基本设备出現常见故障。

的确,Kubernetes构架能够作出聪明的全自动管理决策,以决策将工作中负荷置放在群集中的部位。可是,Kubernetes其实不是完成高能用性的神丹妙药。比如,它将在仅有一个主连接点的生产制造自然环境中运作,它是关掉全部群集的方式(假如关键网络服务器出現常见故障,则全部群集将大部分终止运作)。

Kubernetes都不能全自动确保在群集中运作的不一样工作中负荷中间恰当分派資源。要开展设定,客户必须人力设定資源配额。

5.难以人力操纵Kubernetes

虽然Kubernetes必须很多的人力干涉才可以出示高能用性,可是假如的确要那样做,它会让人工业自动化制越来越非常艰难。

能够毫无疑问的是,有一些方式能够改动Kubernetes实行的检测時间,以明确器皿是不是一切正常运作,或是强制性工作中负荷在群集中的特殊网络服务器上运作。可是,Kubernetes构架的设计方案其实不期待管理方法员会开展这种人力变更。

如上上述,Kubernetes最先是对于Web经营规模的布署,它是有些道理的。假如客户了解千台网络服务器和数以百计工作中负荷,将不容易人力配备很多物品。可是假如是一家经营规模较小的企业,而且要想更强地操纵群集中工作中负荷的构造方法,那麼选用Kubernetes难以保证这一点。

6. Kubernetes监控和特性提升遭遇挑戰

Kubernetes尝试在维持工作中负荷一切正常运作层面做得非常好(虽然如上上述,其工作能力在于例如客户设定的管理方法者总数及其怎样机构資源分派等要素)。

可是Kubernetes构架其实不能协助客户监控工作中负荷或保证他们主要表现最好。它不容易在出現难题时向客户传出报警,并且从群集中搜集监控数据信息都不太非常容易。Kubernetes发售版随附的大多数数监控仪表盘板也没法出示对自然环境的深层次由此可见性。选用第三方专用工具可使客户得到由此可见性,可是假如要运作Kubernetes,则务必设定、学习培训和管理方法这种专用工具。

一样,Kubernetes都不善于协助客户提升成本费。它不容易通告客户群集中的网络服务器是不是仅以20%的容积应用,这将会寓意着客户在过多配备的基本设备层面消耗了资产。一样,第三方专用工具能够协助客户解决例如该类的挑戰,但他们会提升繁杂性。

7. Kubernetes将全部內容简单化为编码

在Kubernetes中,进行基本上全部每日任务都必须客户撰写编码。一般状况下,其编码选用YAML文档的方式,随后务必在Kubernetes指令行上运用他们。

很多人要把Kubernetes构架的全部编码规定做为作用而并不是不正确。但是,尽管应用单一方式和专用工具(即YAML文档)能够管理方法全部服务平台,但的确期待Kubernetes能为必须他们的人出示别的挑选。

有时候候,客户不愿撰写一个较长的YAML文档(或从GitHub中获取一个文档,随后人力调节在其中的任意一部分以合适其自然环境)来布署简易的工作中负荷。客户期待按住一个按键或运作一个简易的指令(这指的不是必须十好多个主要参数的kubectl指令,在其中很多主要参数都配备有务必拷贝和黏贴的数据信息串)。必须在Kubernetes中做一些简易的事儿。可是这类状况非常少产生。

8. Kubernetes期待操纵一切

Kubernetes的最终一个难题是,它的设计方案其实不能非常好地两者之间他种类的系统软件相互配合。它期待变成客户用于布署和管理方法运用程序的唯一服务平台。

假如客户的全部工作中负荷全是器皿化的,而且能够由Kubernetes开展融洽,它是一个非常好的結果。可是,假如客户有着没法做为器皿运作的原来运用程序如何办?或是,假如想在Kubernetes群集上运作一一部分工作中负荷,而又有一一部分出外部运作呢?Kubernetes不出示实行这种实际操作的原生态作用。其设计方案的前提条件是期待一直在器皿中运作全部內容。

结果

Kubernetes实际上是编辑大中型器皿化运用程序的强劲专用工具。 Kubernetes有许多合适的测试用例。

可是Kubernetes构架也是有一些缺陷。整体来讲,假如客户要管理方法原来的工作中负荷或布署经营规模不够以证实Kubernetes产生的全部繁杂性,那麼也不是一个非常好的处理计划方案。以便证实它的所有使用价值,Kubernetes应当处理这种难题,便于它能够彻底配对其在IT绿色生态系统软件一些行业中具有的信誉。