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

  • 时间:
  • 浏览:1
  • 来源:uu快3概率_uu快3官网pk10_平台

本文来自云栖社区公司商务合作 伙伴Dockerone.io,了解相关信息还还要关注Dockerone.io。

事实上,Kubernetes虽然相当繁复。不可组阁 ,Kubernetes的启动与运行皆难于上手。但之类 繁复性也从原来侧面反映出Kubernetes的倾向性。早在19200年代,弗雷德·布鲁克斯(Fred Brooks)立足计算机科学领域撰写了一本名为《人月神话》的开创性著作。在书中,他讨论了他的团队在构建IBM大型机OS/3200系统时的所见所感。他提到了有三种系统性繁复因素:意外繁复性与必要繁复性。意外繁复性属于一类随机介入的因素(属于负面类型),而必要繁复性则属于完成工作所必需的因素(正面类型)。ECS与Docker Swarm下皮 上看起来更简单,但却皆具有更多的意外繁复性,并会将之类 繁复性直接传递给用户。之类 繁复性在初始阶段往往太少再明显。没人之类 意外繁复性到底有何表现?首先,大伙儿还要弥补系统在能力方面的缺失。比如:ECS要求用户编写絮状代码以实现可用性(有时还要成百上千行代码)。之类 工具的使用还受到架构层面的限制,同时带来陡峭的学习曲线。在个人所有所有 面,Kubernetes的意外繁复性很低而必要繁复性很高(实现用户实际我应该 实现的目标所还要的繁复性)。Kubernetes不言而喻没人强大,是过后 它过后 是谷歌的第三代容器管理技术——而Swarm与ECS还好多好多 我第一代。

Kubernetes的“税收”

次责企业太少再担心Kubernetes的繁复性,好多好多 我担心之类 繁复性无法带来应有的回报。大伙儿担心技术团队在Kubernetes上付出很高的“税收”,但最终却没可以则获得足够的价值。

本文作者:kl2422

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

【烧脑式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的处理方案(大伙儿将其称为‘伪Kubernetes’),而这显然会给公司带来技术债务。(过后 在自行构建时,大伙儿最终得到的一定好多好多 我是一套错误且成本更为高昂的Heroku变种。之类 点过后 在云基础架构的第十条法则中进行过充分论证。)当你的目标是构建产品时,为之类 要将有限的资源浪费在运营任务身上呢?过后 你不还要过后 离米 太少再从零始于构建个人所有所有 的Heroku,为之类 要雇佣太少运维工程师呢?大伙儿将在本系列的下一篇文章中就之类 话题展开探讨,即:你的开发人员是怎么才能 才能 变“坏”的。

内容展望?

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

运维服务:与专家公司商务合作 维护你的运维平台,同时负责各类日常运营难题——这意味着 您不再还要招聘全职运维人员进行产品开发与交付。

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

但这正是难题所在:太少再所有的基础架构都还要进行由数十到数千的大规模节点扩展(否则,大伙儿离米 还要有一另一个 节点,从而尽过后 降低宕机事故的过后 性)。千万别被扩展性所误导——Kubernetes的优势绝不仅限于扩展性。对于新手来讲,过后 你的Rails应用内存过低并引发宕机,则运行在普通EC2的实例上的此类线程池池将太少再自动重启; 这意味着 运维人员还要随时待命以处理难题。另外,Kubernetes拥有自动运行清况 检查机制,否则过后 你的线程池池因有三种意味着 而无法响应——包括运行时内存过低过后 遭遇锁死,Kubernetes后会自动进行重启。Kubernetes还可以轻松基于分支环境进行开发,之类 点在EC2实例当中同样几乎无法实现。思考一下——您打算怎么才能 才能 运用更高可用性、自动扩展性以及更为丰富的功能等重要优势?

意外繁复性与必要繁复性

中小型公司拒绝Kubernetes的原来意味着 在于繁复性。