作者丨Rak Siva
编译丨Noe
如今，你几乎可以将任何应用程序封装在容器中以供执行。容器解决了很多问题，但它们带来了新的编排挑战。由于大量致力于构建云原生应用程序的团队对容器编排的需求不断增长，Kubernetes 作为解决这一挑战的强大工具而广受欢迎。
在管理良好的 Kubernetes 环境中构建提供了许多好处，例如自动缩放、自我修复、服务发现和负载平衡。然而，拥抱 Kubernetes 的世界通常意味着不仅仅是采用容器编排技术。团队需要战略性地考虑，“Kubernetes 是我的正确选择吗？”他们必须通过评估这个更广泛问题的几个组成部分来做到这一点。
一、我的团队组成是否适合 Kubernetes？
不乏赞扬 Kubernetes （K8s） 功能的文章，这不是我们要争论的。在许多情况下，K8s 是正确的选择。也就是说，与 K8s 的直接交互和维护并不适合所有团队和项目。
1、拥有云原生应用程序的小型初创公司：这些团队会发现 Kubernetes 的直接管理是一种复杂、耗时的分散注意力，无法实现他们发布和扩展产品的目标。鉴于他们的规模，团队将没有足够的带宽来管理 Kubernetes 集群，同时也开发他们的应用程序。
2、具有各种应用程序类型的企业团队：对于具有专业技能的大型团队，Kubernetes 是一个很好的选择。但是，仍应考虑完全托管的容器运行时或 Kubernetes 即服务产品。这些服务允许有限的 DevOps 资源专注于团队生产力、开发人员自助服务、成本管理和其他关键项目。
3、具有 DevOps 文化的中型公司：虽然这些团队为迁移到 Kubernetes 做好了更充分的准备，但这是一个重大项目，将破坏现有的工作流程。同样，托管产品无需大量投资即可释放 Kubernetes 的许多好处。
4、软件咨询：虽然这些团队适应性强，但依赖 Kubernetes 可能会限制他们为具有不同需求的客户提供服务的能力，因为它会促使咨询公司推荐它，即使它不是最合适的。
二、我的项目有多复杂？K8s 矫枉过正吗？
与其确定 K8s 是否满足你的某些要求，不如考虑确定与 Kubernetes 功能不太一致或引入不必要的复杂性的特定特征和要求。
1、最小的可扩展性需求：如果项目具有持续的低流量或可预测且稳定的资源需求，而没有显着的扩展要求，则 Kubernetes 将引入不必要的开销。在这些情况下，托管容器运行时或虚拟专用服务器 （VPS） 解决方案通常代表更好的价值。
2、简单的单片应用：如果项目是一个具有有限依赖项的整体应用程序，并且不需要独立可扩展的服务或极高的实例计数，那么 Kubernetes 对于其需求来说太复杂了。
3、静态或有限的基础结构：如果项目具有小型或静态基础设施，而资源使用没有太大变化，那么更简单的部署选项（如托管服务或 VPS）就足够了。
4、有限的开发运营资源：Kubernetes 需要容器编排方面的专业知识，这对于 DevOps 资源有限的项目或团队不愿意投资学习 Kubernetes 来说是不可行的。无需这种额外投资，仍然可以实现容器的好处。
5、原型设计和短期项目：对于开发生命周期较短或生产持续时间有限的项目，Kubernetes 开销是合理的。
6、项目成本限制：如果项目有严格的预算限制，那么设置和维护 Kubernetes 集群的额外成本将不可行。在考虑完成这项工作所需的高技能团队成员的成本时尤其如此。
7、基础设施要求：Kubernetes 可能是资源密集型的，需要强大的基础设施才能有效运行。如果你的项目是资源需求适中的中小型项目，则使用托管服务或无服务器更为合适。
仅凭需求的复杂性并不能决定 Kubernetes 对你的团队来说是完美的还是过度的;但是，它可以帮助你以一种或另一种方式倾斜。如果你直接使用 Kubernetes，它本质上不会提升你的产品。相反，它的优势在于打造一个弹性平台，让你的产品可以在此平台上蓬勃发展。
图片
其结果是，随着你承诺将自己的工作置于它之下，对产品的开发工作将进一步远离成为业务的基础。
这揭示了一个真正的问题：我们是在构建一个平台，还是在努力加快上市时间，为我们的核心业务目标提供更直接的投资回报？
三、我们有必要的技能吗？
Kubernetes 通常因其具有挑战性的学习之旅而得到认可。是什么导致了这种复杂性？为了清楚起见，我根据特定标准策划了一份主题列表，以帮助衡量提高技能所需的努力。
复杂性 | 描述 |
基本 | 基本、更简单的概念 |
中间 | 需要一些预先存在的知识的概念 |
高深 | 需要广泛知识的复杂概念 |
注意：这些复杂程度将根据个人背景和先前的经验而有所不同。
学习区 | 描述 | 复杂性 |
集装箱 | 了解容器和工具，如 Docker。 | 基本 |
Kubernetes 架构 | 了解有关 Pod、服务、部署、副本集、节点和集群的知识。 | 中间 |
Kubernetes API 和对象 | 了解 Kubernetes 的声明式方法，使用 API 和 YAML。 | 中间 |
联网 | 了解容器间通信、服务、入口、网络策略和服务网格。 | 高深 |
存储 | 了解有关卷、持久卷 （PV）、持久卷声明 （PVC） 和存储类的知识。 | 高深 |
安全 | 了解 Kubernetes 安全性，包括 RBAC、安全上下文、网络策略和 Pod 安全策略。 | 高深 |
可观察性 | 熟悉监控，日志记录和跟踪工具，如Prometheus，Grafana，Fluentd，Jaeger。 | 中间 |
Kubernetes 中的 CI/CD | 将 Kubernetes 与 CI/CD 工具（如 Jenkins、GitLab ）集成，并使用 Helm 图表进行部署。 | 中间 |
Kubernetes 最佳实践 | 熟悉使用 Kubernetes 的最佳实践和常见陷阱。 | 中级到高级 |
对于缺乏必要专业知识或学习时间的团队，整个开发和部署过程可能会变得不堪重负且缓慢，这对于时间紧迫或团队较小的项目来说并不健康。
四、成本影响是什么？
虽然 Kubernetes 本身是开源和免费的，但运行它却不是。你需要考虑与基础架构相关的费用，包括服务器、存储和网络的成本以及隐性成本。
第一个隐性成本在于其管理和维护——用于培训团队、故障排除、维护系统、维护内部工作流程和自助服务基础设施的时间和资源。
由于各种原因，在计算成熟的 Kubernetes 环境的成本时，许多人忽略了这项工作所需的高技能员工的薪水。警惕完全托管或无服务器产品与自我管理的 Kubernetes 之间的许多有缺陷的比较。他们通常无法考虑员工成本以及与 Kubernetes 时间损失相关的机会成本。
第二个隐性成本与 Kubernetes 生态系统有关。拥抱 Kubernetes 的世界通常不仅仅意味着采用容器编排平台。这就像踏上一个广阔的大陆，拥有丰富的功能以及各种供应商提供的辅助工具、服务和产品的整个宇宙，最终会带来其他成本。
五、结论
一个好的工具不在于它的炒作或受欢迎程度，而在于它如何解决你的问题并融入你的生态系统。在云原生应用程序的领域，Kubernetes在对话中占据了相当大的份额，这是可以理解的。但是，我鼓励团队考虑通过OpenShift，Docker Swarm或由Nitric等框架编排的无服务器和托管服务等解决方案实现的不同方法的权衡。
原文链接：https://thenewstack.io/kubernetes-isnt-always-the-right-choice/
