作者 | 云昭
目前，不管对于运维部门、还是后端的架构部门而言，掌握 Kubernetes 已经是必备项，因为它解决了微服务的部署问题，而且已然是容器编排的事实标准。Kubernetes 已成为界内家喻户晓的名字。不可否认，它是许多开发人员的理想解决方案。
但是 Kubernetes 真的完美无瑕吗？虽然开发者对 Kubernetes 提供的各种可能性充满热情，但也有沮丧的一面：与 Kubernetes 并肩同行，“沿途”将伴生出许多繁杂的问题。这就是为什么越来越多的组织开始寻找更易于使用的替代品的原因。
那么，Kubernetes 为什么开始被某些企业嫌弃了呢？
Kubernetes 惊艳问世
Kubernetes 最初是由 Google 作为 Borg 的开源版本开发的，Borg 是他们过于复杂的容器管理平台，但后来演变成一场全球运动（与国内而言，也掀起了一场“开源+订阅”的团队协作模式的浪潮）。它目前归属于云原生计算基金会 (CNCF)，并由大型贡献者社区维护。
任何 Kubernetes 基础设施的核心都是容器，它剥离了虚拟机管理程序等不必要的部分，并将操作系统和应用程序的必要组件封装到一个整洁的包中。
目前，Kubernetes 已成为自动化软件部署、容器管理和基础设施扩展的事实标准。它运行具有内置默认副本和自动扩展的容器化应用程序，以确保应用程序稳健运行且可以快速地扩展。
Kubernetes 遭弃之迷
1. Kubernetes 可能会矫枉过正
大多数组织的运营规模不及 Google 或 Facebook。Facebook 号称拥有 18 个数据中心，占地 4000 万平方英尺，耗资 200 亿美元。据 Mcafee 统计显示，“少于 1000 人员工规模的公司平均仅运行 22 个自定义应用程序。” 这些应用程序虽然仍需要现代技术和方法来有效地管理它们。然而，技术实力过于强大的 Kubernetes，对于这些少量应用程序而言，未免显得“杀鸡用牛刀”，甚至还会分散应用程序本身的注意力。
2. Kubernetes 配置过于复杂
Kubernetes 向来以其陡峭的学习曲线和操作复杂性而闻名。但你可能不知道 Kubernetes 的最初目的很简单——“弹性运行分布式系统”。但在目前的情况下，这个简单的目的似乎变得过于混乱。
如果公司购买云厂商，例如 AWS 或 Azure 上使用 Kubernetes 它们自然会基本上隐藏所有相关部署的复杂性。但如果在本地运行 Kubernetes ，就意味着接下来需要本地的开发人员来管理这些复杂性——包括 etcd、负载平衡、可用性、自动扩展、网络、故障部署回滚、持久存储等。
除了构建服务来处理公有云通常为您解决的上述复杂性之外，以 DIY 方式在本地部署 Kubernetes 还涉及大量核心代码修改。
即使是创造 Kubernetes 的谷歌，也不得不承认：“很难正确配置 Kubernetes”，而像 Istio 这样的工具也很难设置和开始使用。
Kubernetes 有些过犹不及，因为想解决的问题太多，而导致平台被拉向过多的发展方向。
3. 部署和维护成本高
尽管 Kubernetes 可以免费使用，但它真正实施起来却是一个昂贵的产品：隐形成本非常庞大：管理基础设施以及优化在其上运行的工作负载相当重。因此，“免费的也是昂贵的”，就部署和维护所需的时间和人力而言，Kubernetes 的成本很高。
4. 艰难繁琐的过渡
迁移到 Kubernetes 是一项艰巨而艰巨的工作。要在这方面取得成功，企业需要将原来的架构进行部分甚至完全的重构。同时，还需要一个庞大的团队来确保 Kubernetes 集群正在运行。即使您设法构建了一个维护良好的 Kubernetes 设置，从基本集群过渡到可靠的生产环境，还有大量工作要做。
光环渐消退，新需求明朗
首先，容器和云编排需要一种“秉持初心”的方法。在试图为软件世界中的所有人提供一切的过程中，Kubernetes 变得过于复杂。Kubernetes 的魅力已经开始消退，不少企业开始寻找在容器编排领域，可以提供一种“秉持初心”的替代方案。
其次，需要一种更简单的入门方法。Kubernetes 的不同部分需要额外的工具来补充它，现在已经有各种不同的工具来帮助处理和管理 Kubernetes 的复杂性。这意味着开发者必须先学会操作多个迷你工具，然后才能开始在生产 Kubernetes 集群中运行应用程序。
当尝试跨多个基础架构提供商进行部署时，这种工作负载会更加复杂。许多人希望从这个学习过程中解脱出来，并拼凑组合出趁手的新工具来使用。任何可以帮助避免这种混乱的替代方案都是可喜的变化。
再者，开发人员能够在没有 DevOps 团队的情况下进行构建。当涉及到一个以其复杂性而闻名的系统时，构建过程可能会显着减慢。这是因为对于以前没有使用过基础设施的开发人员来说，熟悉 Kubernetes 开发工作流程可能非常困难。
此外，即使是非常熟悉该框架的开发人员也需要 Kubernetes 专家和 DevOps 团队来帮助他们克服遇到的各种瓶颈。这最终会降低生产力，并延长发布周期。
因此，组织正在寻找方法来消除开发人员对 DevOps 团队的依赖。他们希望为开发人员提供在需要时访问所需资源的灵活性和自主权。
Kubernetes 的替代品
Kubernetes 已经主导了容器管理领域多年。在完全意识到对替代方案的需求之后，就会导致新解决方案的兴起，以期望可以在更少麻烦，更低的复杂性的情况下胜任 Kubernetes 可以完成的工作。
放眼当下容器编排领域，谁会有可能满足这些需求，并能取代 Kubernetes 呢？
不少人把目光投向了 Cycle.io。Cycle 是一个为开发人员构建的低运维平台，是 Kubernetes 的竞争对手。开发者看好有以下几个原因：Cycle 将强大的容器编排与预配置的服务、自动化网络、基础设施管理、完整的 DNS 解决方案、镜像优化等功能深度融合在一起；Cycle 有助于自动向所有服务器提供平台更新，企业可以从任何受支持的提供商部署本地的基础架构。这样，跨云服务提供商的基础架构、数据和应用程序，而不会被其中任何一个所束缚；此外，Cycle 完全符合 OCI，理念侧重于“质量优先于数量”。
当然容器编排领域还有许多不错的工具作为备选项，这里不一一详述。
写在最后
当下的 Kubernetes 非常流行，带来了许多令人惊叹的特性，拥趸者非常之多。许多采用 Kubernetes 的团队也非常满意。然而，这些团队的实例却大多是由谷歌或亚马逊等有实力的云厂商来代为管理。这就会为企业的实际业务的开展埋下了隐患：一个是忽略了思考公司是否真的需要这些特性，另一个就是企业和开发者不能仅仅依靠这些“代为管理”式的抽象来支撑工作， 只有了解引底层发生了什么，才能做到真正的可控。
而不要仅仅因为其他人都这么做，就使用 Kubernetes。仔细评估实际的业务需求：你需要弄清楚你想要解决什么问题，你想要解决的痛点，以及你是否真的需要 Kubernetes。回答完这些问题后，您应该将 Kubernetes 与其他更简单、更有效的选项（例如 Cycle）一起查看，并权衡每个选项的硬成本和软成本。
例如，如果计划在大规模的基础设施上部署一系列同质服务，那么 Kubernetes 可能是最佳选择。只是要意识到额外的复杂性和操作成本。有些成本可以通过使用 Kubernetes 云服务环境来避免。如果你只是在寻找一个易于维护和扩展的可靠编排服务，那就大材小用了。
毕竟，任何技术都是为业务所面临的问题而服务的。你真的需要 Kubernetes？
参考链接：
https://dzone.com/articles/the-need-for-a-kubernetes-alternative
https://www.theregister.com/2021/02/25/google_kubernetes_autopilot/
https://dzone.com/articles/image-optimization-common-mistakes-and-solutions
https://zhuanlan.zhihu.com/p/346301133
