作者|YunZhao目前无论是运维部门还是后端架构部门，掌握Kubernetes已经是必须的，因为它解决了微服务的部署问题，已经是容器编排的事实标准。Kubernetes已成为业界家喻户晓的名字。不可否认，它是许多开发人员的理想解决方案。但是Kubernetes真的完美无缺吗？尽管开发人员对Kubernetes提供的可能性充满热情，但也有令人沮丧的一面：与Kubernetes并肩而行会“一路走来”带来许多复杂的问题。这就是为什么越来越多的组织正在寻找更易于使用的替代方案。那么，为什么Kubernetes开始被一些公司排斥了呢？Kubernetes太棒了Kubernetes最初是谷歌开发的开源版本的Borg，他们过于复杂的容器管理平台，但后来演变为全球运动（国内也出现了“开源+订阅”运动）一波团战模式）。它目前由云原生计算基金会(CNCF)拥有，并由大量贡献者社区维护。任何Kubernetes基础设施的核心都是容器，它剥离了虚拟机管理程序等不必要的部分，并将操作系统和应用程序的必要组件封装到一个简洁的包中。如今，Kubernetes已成为自动化软件部署、容器管理和基础架构扩展的事实标准。它运行带有内置默认副本和自动缩放功能的容器化应用程序，以确保应用程序的健壮性和快速扩展性。1.Kubernetes可能有点矫枉过正大多数组织的运营规模都不像谷歌或Facebook。Facebook声称拥有18个数据中心，占地4000万平方英尺，耗资200亿美元。根据Mcafee的说法，“员工人数少于1,000人的公司平均只运行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团队的依赖。他们希望为开发人员提供灵活性和自主权，让他们可以在需要时访问所需的资源。PART04Kubernetes备选方案多年来，Kubernetes一直主导着容器管理领域。对替代方案需求的充分认识导致了新解决方案的兴起，希望以更少的麻烦和更少的复杂性来做Kubernetes可以做的事情。纵观目前的容器编排领域，谁有可能满足这些需求并取代Kubernetes？许多人将注意力转向了Cycle.io。Cycle是一个为开发人员构建的低操作平台，也是Kubernetes的竞争对手。开发者看好的原因如下：Cycle将强大的容器编排与预配置服务、自动化网络、基础设施管理、完整的DNS解决方案、镜像优化等功能深度集成；服务器提供平台更新，企业可以从任何受支持的提供商部署本地基础设施。这样一来，基础架构、数据和应用程序就可以跨云服务提供商，而不会被绑定到其中任何一个；此外，Cycle完全符合OCI的理念，专注于“质量胜于数量”。当然，容器编排领域也有很多不错的工具可以作为替代，这里不再赘述。PART05写在最后许多采用Kubernetes的团队也非常满意。然而，这些团队实例中的大多数都由强大的云供应商（如谷歌或亚马逊）管理。这会给企业实际业务的开发埋下隐患：一是忽略了企业是否真的需要这些特性的考虑，二是企业和开发者不能仅仅依靠这些“代管理”的抽象来支持他们的工作。只有了解底层发生了什么，才能实现真正的可控。不要因为其他人都使用Kubernetes而使用Kubernetes。仔细评估实际业务需求：你需要弄清楚你要解决什么问题，你要解决什么痛点，你是否真的需要Kubernetes。回答完这些问题后，您应该将Kubernetes与其他更简单、更高效的选项（例如Cycle）一起考虑，并权衡每个选项的硬成本和软成本。例如，如果你计划在一个大规模的基础设施上部署一系列同构服务，那么Kubernetes可能是最好的选择。请注意额外的复杂性和运营成本。使用Kubernetes云服务环境可以避免一些成本。如果您只是在寻找易于维护和扩展的可靠编排服务，那您就大材小用了。毕竟，任何技术都是为业务所面临的问题服务的。你真的需要Kubernetes吗？参考链接：https://dzone.com/articles/the-need-for-a-kubernetes-alternativehttps://www.theregister.com/2021/02/25/google_kubernetes_autopilot/https://dzone.com/articles/图像优化-常见错误及解决方案https://zhuanlan.zhihu.com/p/346301133
