Kubernetes创始人发声！K8s在被反噬！( 二 ) _Kubernetes

因此，当考虑添加新功能时，他们必须问这样的问题：我们是否有足够的复杂性预算来承担这个任务？我们应该在这方面浪费有限的预算吗？
工程师的部分工作是权衡任何决策的权衡，新功能可能带来的额外复杂性应该是需要评估的因素之一。
对代码库的一些扩充，可能会在软件的某些方面带来 5% 的性能提升，但如果这会给维护人员带来更多的内部复杂性来处理，那么还值得这样做吗？如果更改 API 以满足特定用例，是否值得让所有其他用户承担此更改带来的负担？
K8s 全部工作人员都需要提高标准，同时愿意说“不”，“愿意对我们很像要的东西说不，愿意对看起来不是坏主意的事情说不，愿意对本身看起来显而易见且容易的事情说不，愿意对贡献了我们看起来真正想要的东西说不！”
通过对某些提案说“不”，可以在复杂性预算中留下一些空间来处理未来更相关的项目。
Hockin 认为，K8s 必须对今天的事情说“不”，这样我们明天才有能力做有趣的事情。
Hockin 说，我们都习惯于总是认为越多越好，但 Kubernetes 现在可能更需要考虑“少即是多” 。而且，Kubernetes 还有很多工作要做，但这并不意味着所有这些都需要立即完成。
6、K8s 被取代的迹象K8s是Google创建的，却是并不适合所有企业。如果说前几年大家追逐新技术，为了K8s而采用K8s，那么现在已经将近十年的K8s正在产生慢慢被替代的迹象。“如果你不需要Kubernetes ，就不要采用它。”
即便在容器编排领域，由于它对开发人员并不友好，需要大量的时间和理解来部署、操作和故障排除，企业不得不花费大量时间用于管理Kubernetes 。最近两年，企业们正在寻求其他可选项。

有的选择将Kubernetes托管出去，使用一家云供应商的托管Kubernetes服务；
有的则使用可以减少K8s操作的发行版，如Red Hat的OpenShift；
有的则使用HashiCorp的Nomad这样的替代品；
或者采用亚马逊可持续发展架构副总裁Adrian Cockcroft所说的“无服务器优先方法” ，直接跳到FaaS产品，如Azure功能、亚马逊网络服务Lambda或谷歌云功能，并完全绕过Kubernetes 。

此外，市面上也诞生了诸如 cycle.io 等致力于取代 K8s 容器编排王者地位的新产品，让即使是开发运维经验有限的人，也能够描述他们想要什么，并由平台负责实现。
7、写在最后当然，持续的吸收扩展，让Kubernetes 快速在云原生时代壮大，但快速吸收新功能的“吸星大法”，也开始出现了反噬。目前， Kubernetes在容器编排领域的赛道上，正在被拖慢速度，而新对手正虎视眈眈，试图超越。
正如一位业内人士建议 Hockin 的那样“延迟满足”：为了保持活力，Kubernetes 应该保持未完成状态！

【Kubernetes创始人发声！K8s在被反噬！】