Kubernetes是否存在“杀敌一千,自损八百”的问题?

  • 时间:
  • 浏览:0
  • 来源:5分快乐8_5分快乐8官网

原文标题:Kubernetes有无指在“杀敌一千,自损八百”的大疑问?

但这正是大疑问所在:不须所有的基础架构都时需进行由数十到数千的大规模节点扩展(而且 ,亲戚朋友最少时需一个多多节点,从而尽可能降低宕机事故的可能)。千万别被扩展性所误导——Kubernetes的优势绝不仅限于扩展性。对于新手来讲,可能你的Rails应用内存不够并引发宕机,则运行在普通EC2的实例上的此类程序将不必自动重启; 这是因为运维人员时需随时待命以处里大疑问。另外,Kubernetes拥有自动运行清况 检查机制,而且 可能你的程序因三种生活是因为而无法响应——包括运行时内存不够可能遭遇锁死,Kubernetes都在自动进行重启。Kubernetes还并能轻松基于分支环境进行开发,這個于于 点在EC2实例当中同样几乎无法实现。思考一下——您打算怎样运用更高可用性、自动扩展性以及更为富足的功能等重要优势?

意外冗杂性与必要冗杂性

中小型公司拒绝Kubernetes的这麼 是因为在于冗杂性。

【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。Kubernetes有无指在“杀敌一千,自损八百”的大疑问?好多好多 亲戚朋友可能都思考过這個于于 大疑问,有点痛 是考虑到大累积中型SaaS、网络及电子商务企业早晚要放弃HeroKu(一款支持多种编程语言的云平台),(每被委托人最终都将放弃Heroku。)而最终决定到底该选者AWS、Docker Swarm可能是其它更为“简单”的处里方案——当然,也包括直接投向Kubernetes的怀抱。由Heroku迁移至AWS、Docker Swarm可能是其它自主开发型处里方案的作法,往往会给亲戚朋友带来许多自寻麻烦且本可处里的常见陷阱。这是可能上述处里方案初看起来似乎比Kubernetes更为简单,但从长远的深度讲却常会带来更严重的局限性、更难以处里的挑战以及更为可观的开销。可能单纯逃离Heroku不须够以帮助亲戚朋友摆脱這個于于 恐怖的噩梦,而且 目前好多好多 公司事先开始英语 在犹豫当中选者Kubernetes。下面,亲戚朋友将对是因为作出具体阐述。

Kubernetes:一切源自可扩展性

中小型企业好的反义词拒绝选者Kubernetes,一个多多很普遍的是因为可是 其可扩展性。CTO可能会说,“我只拥有一款Rails程序,一套简单的传统EC2虚拟机就足以处里大疑问。Kubernetes处处都在考虑扩展——而我不时需这麼 夸张的可扩展能力。”

事实上,Kubernetes实在相当冗杂。不可签署,Kubernetes的启动与运行皆难于上手。但這個于于 冗杂性也从这麼 侧面反映出Kubernetes的倾向性。早在191000年代,弗雷德·布鲁克斯(Fred Brooks)立足计算机科学领域撰写了一本名为《人月神话》的开创性著作。在书中,他讨论了他的团队在构建IBM大型机OS/31000系统时的所见所感。他提到了三种生活系统性冗杂因素:意外冗杂性与必要冗杂性。意外冗杂性属于一类随机介入的因素(属于负面类型),而必要冗杂性则属于完成工作所必需的因素(正面类型)。ECS与Docker Swarm棘层上看起来更简单,但却皆具有更多的意外冗杂性,并会将這個于于 冗杂性直接传递给用户。這個于于 冗杂性在初始阶段往往不须明显。这麼 這個于于 意外冗杂性到底有何表现?首先,亲戚朋友时需弥补系统在能力方面的缺失。比如:ECS要求用户编写少许代码以实现可用性(有时时需成百上千行代码)。這個于于 工具的使用还受到架构层面的限制,一块儿带来陡峭的学习曲线。在被委托人面,Kubernetes的意外冗杂性很低而必要冗杂性很高(实现用户实际愿意 实现的目标所时需的冗杂性)。Kubernetes好的反义词这麼 强大,是可能它可能是谷歌的第三代容器管理技术——而Swarm与ECS还可是 第一代。

Kubernetes的“税收”

累积企业不须担心Kubernetes的冗杂性,可是 担心這個于于 冗杂性无法带来应有的回报。亲戚朋友担心技术团队在Kubernetes上付出很高的“税收”,但最终却真难而且 获得足够的价值。

本文作者:kl2422

运维服务:与专家商务企业合作维护你的运维平台,一块儿负责各类日常运营大疑问——这是因为您不再时需招聘全职运维人员进行产品开发与交付。

原文链接:Is Kubernetes Overkill?(翻译:康良)

原文发布时间为:2017-08-1000

本文来自云栖社区商务企业合作伙伴Dockerone.io,了解相关信息可不可不可否关注Dockerone.io。

为了处里這個于于 “税收”,亲戚朋友会雇佣一支技术水平高超的运维团队并希望其能带来理想结果。毫无大疑问,可能给予亲戚朋友充分的发挥空间,亲戚朋友都在选者自行构建一套基于Kubernetes的平台。但可能权限不够,亲戚朋友会尝试从零事先开始英语 构建起這個于于Kubernetes的处里方案(亲戚朋友将其称为‘伪Kubernetes’),而这显然会给公司带来技术债务。(可能在自行构建时,亲戚朋友最终得到的一定可是 是一套错误且成本更为高昂的Heroku变种。這個于于 点可能在云基础架构的第十条法则中进行过充分论证。)当你的目标是构建产品时,怎样会儿 要将有限的资源浪费在运营任务身上呢?可能你不时需可能最少不须从零事先开始英语 构建被委托人的Heroku,怎样会儿 要雇佣这麼 多运维工程师呢?亲戚朋友将在本系列的下一篇文章中就這個于于 话题展开探讨,即:你的开发人员是怎样变“坏”的。

内容展望?

运维咨询:利用亲戚朋友数十年的运维专业知识帮助您完成云端迁移,让我的架构拥有自动化能力并将你的SaaS与Web应用提升至新的水平。