阿里云的故障打破了互联网大厂的技术神话，滴滴这持续12小时的崩溃真是把所谓互联网大厂技术光环的底裤都输没了。 2023年大厂恢复业务动不动都是小时起步了，时代变了 ！
网传大事故是K8s相关问题导致的（不要当真哦！），本期正好聊聊K8s！
一、Kubernetes 需要复杂性预算
Harness 的 Ravi Lachhman 和 DataStax 的 Frank Moley 讨论了 Kubernetes 复杂性疲劳，更重要的是，可以做些什么。
芝加哥——顶级的 Kubernetes 工程师们一致认为：K8s 对于最终用户甚至核心维护者来说都太复杂了。是时候将复杂性纳入预算了。
在今年的 Kubecon+CloudNativeCon 大会上，Kubernetes 联合创始人兼 Google 杰出软件工程师 Tim Hockin 在周四的主题演讲中回顾了 Kubernetes 的前九年（半）以及开源软件的未来。Kubernetes 可能已经开始主要为高度可扩展的 Web 应用程序提供支持，但现在它正日益成为更复杂工作（例如机器学习推理）的首选平台，这意味着将 K8s 扩展到更多用例的压力正在显着增加。
为了帮助他的演讲，Hockin 询问了云原生社区的其他人，他们认为 Kubernetes 面临的最紧迫的挑战是什么。正如您现在可能已经猜到的那样，一个反复出现的主题是努力解决部署和维护容器编排引擎有时令人生畏的复杂性。有人甚至说这是K8s的“最大的生存威胁”。
“有些东西必须给予，”霍金说。在一定时间内，我们可以将有限的复杂性吸收到项目中，“他说。越复杂，核心维护者在未来轻松进行更改的敏捷性就越低。同时，软件越复杂，用户对它的抵制就越大。
围绕 Kubernetes 的软件是社区驱动的：到目前为止，已经有超过 74,000 名贡献者加入了该项目。第一代用户对 K8s 产生了兴趣，许多人努力让它变得更好。但随着新用户的不断加入，他们将不可避免地对 Kubernetes 的工作方式产生兴趣。因此，维护者有责任让它更易于使用，Hockin指出。“我们添加的东西越复杂，我们消耗的预算就越多。当预算用完时，坏事就会发生，“他说。创新停止了，用户转向了其他解决方案。因此，Kubernetes 项目经理需要将复杂性视为可以利用的有限资源：某种“复杂性预算”。
霍金承认，他不知道如何衡量一个软件的复杂性，更不用说最终用户在处理复杂软件时的耐心了。
然而，他指出，工程师通常知道他们何时在预算上超支。因此，在考虑添加新功能时，他们必须问一个问题：我们是否有足够的复杂性预算来负担？这是我们应该花有限的预算吗？工程师工作的一部分是权衡任何决策的利弊，新功能可能带来的额外复杂性应该是要评估的一个因素。对代码库的一些增强可能会在软件的某些方面带来 5% 的性能改进，但如果它为维护者带来了更多的内部复杂性，那么它是否值得。如果一个 API 被改变以满足一个利基用例，是否值得让所有其他用户承担这种改变的负担？
“提高标准需要我们所有人愿意说不，愿意对我们真正想要的东西说不，那些不是坏主意的事情，那些本身看起来显而易见和容易的事情。老实说，公司付钱给我们的东西可能真的想要，“他说。通过对某些提案说“不”，可以在复杂性预算中留出一些空间，以处理未来更相关的项目。“我们必须对今天的事情说’不’，这样我们明天就可以做有趣的事情，”霍金说。
Kubernetes 还有很多工作要做，但这并不意味着所有工作都需要立即完成。Hockin 说，我们都习惯于总是认为越多越好，但 Kubernetes 现在可能会遇到少等于多的情况。正如有人向 Hockin 建议的那样：为了保持活力，Kubernetes 应该保持未完成。
二、如何应对 Kubernetes 复杂性疲劳
在由 TNS 创始人兼发行人 Alex Williams 主持的 The New Stack Makers 播客的这一集中，我们讨论了 Kubernetes 复杂性疲劳，更重要的是，我们可以做些什么。嘉宾包括持续集成和交付系统提供商 Harness 的布道者 Ravi Lachhman，以及数据存储提供商 DataStax 的高级技术工程经理 Frank Moley。
Kubernetes 复杂性疲劳的大部分原因可归因于 DevOps 团队在转向云原生架构时必须扩展其专业领域，通常超出他们的舒适区。基础架构团队成员必须更加符合开发人员的需求，而开发人员的工作负载越来越多地涵盖与基础架构相关的任务。
Kubernetes正在“跨越两条鸿沟，”Lachhman说。开发人员需要更加关注基础设施问题，另一方面，“运营、基础设施或系统工程人员越来越接近开发方面，因为你编写 Kubernetes 资源或 Kubernetes YAML 的方式有时会模仿软件开发，因为必须涉及迭代，”Lachhman 说。“所以，双方都必须学习比他们的舒适区更多的技能，这是我看到的疲劳。
与一般生活类似，帮助 DevOps 团队避免 Kubernetes 复杂性疲劳是要意识到你的局限性是什么，以及如何以能够实现目标的方式最好地管理差距。
“我可能会花很多钱说，真的不可能知道任何技术工具的所有知识，不仅仅是 Kubernetes——但因此，你可以知道足够多的东西，你可以弄清楚其余的，”Moley 说。“所以，我认为这是在管理对你所知道的东西的期望，以及你如何制定一个策略来学习你不知道的东西…所以，对我来说，管理复杂性包括管理你自己关于如何完成工作的个人想法和感受，就像你所知道的一样。
还需要意识到，一旦Kubernetes被采用——当然，这对大多数组织来说本身就是一项艰巨的任务——组织的所有软件问题都将无法解决。“[Kubernetes]实际上是一个相当复杂的系统，对于一些深入研究它的人来说，随着它变得越来越成熟并开始褪色，闪亮的一分钱现在变得越来越闪亮，”Lachhman说。
Kubernetes组件——尽管它们非常复杂——是组织明智地以“小块”方式购买的东西。“对于Kubernetes生态系统来说，压倒性的是它实际上是非常可插拔的，所以没有一个非常严格的定义：如果你把它与平台即服务（PaaS）进行比较，它给了你一个非常强烈的意见，Kubernetes被设计为可插拔的。
三、别抱怨K8s太复杂
很多人看着 K8s 成为最热门的开源技术，都纷纷开始学习 K8s，但也有很多人在抱怨 K8s 太复杂了。 用 CNCF 新晋 TOC 张磊的话来说：这里的根本问题在于，K8s 的定位是“平台的平台”（The Platform for Platform），所以其核心功能、服务的对象是基础平台工程师，而非业务研发人员与运维人员；它的声明式 API 设计、CRD Operator 体系，也是为了方便基础平台工程师接入和构建新基础设施能力而设计的。
四、 适合的才是最好的
需求的越多，投入的也会越多，这是更古不变的道理。在我们决定引入容器技术后，使用 K8s 之前，需要想清楚为什么需要 K8s。
但又如果我们的应用并没有那么复杂，只是朴素的希望简化应用生命周期管理和底层基础设施，保障业务的高可用，并专注在业务开发上，那么可能就不需要使用 K8s 来编排容器应用了，毕竟 K8s 是源自 Google 的 Borg，他是用来管理 Google 海量的容器应用的。
参考：
https://thenewstack.io/tim-hockin-kubernetes-needs-a-complexity-budget/
https://thenewstack.io/how-to-fight-kubernetes-complexity-fatigue/
https://zhuanlan.zhihu.com/p/421516764