👒 ⛓️ 👨‍👩‍👧 “让我们使用Kubernetes！” 您现在有8个问题 🛍️ 🕜 💹

如果您使用Docker，那么下一个逻辑步骤似乎是切换到Kubernetes，它是K8，对吗？好吧，假设。但是，为500名软件工程师同时开发一个应用程序而设计的解决方案与50人的解决方案完全不同。而由5个程序员组成的团队的解决方案则完全是另外一回事了。

如果您在一个小型团队中工作，那么Kubernetes很可能不适合您。这将给您带来很多痛苦，以换取极其微薄的收益。
让我们看看为什么会发生这种情况。

每个人都喜欢“运动部件”

Kubernetes的变化和变化很多：概念，子系统，流程，机器，代码...这一切都意味着很多困难。

几辆车

Kubernetes是一个分布式系统：它具有一台控制其余工人的主机。每台机器都在容器中执行工作。
因此，我们已经在讨论至少两个物理机或虚拟机，这仅是使其工作所必需的。但实际上，您得到的只是一辆车。如果要扩展（这就是狗被埋的地方！），则将需要三个，四个或多达十七个虚拟机。

非常非常多的代码

2020年3月开始的Kubernetes代码库在Go上包含了超过580,000行代码。这只是干净的代码，不包括注释，空白行和供应商软件包。《 2019年安全审查》对代码库的描述如下：
“ Kubernetes代码库有很大的改进空间。它庞大而复杂，包含大部分代码，几乎没有文档，并且有大量依赖关系，包括不属于Kubernetes的系统。同样在代码库中，有很多情况下可以重新实现逻辑，这些逻辑可以集中在支持库中，这将降低复杂性，简化更正并减少代码库各个区域中的文档负载。”
老实说，在其他许多大型项目中也可以这样说，但是如果您不希望应用程序失败，那么所有这些代码都应正确运行。

架构，操作，配置和概念上的复杂性

Kubernetes是一个综合系统，具有许多不同的服务，系统等等。
在启动唯一的应用程序之前，您将必须提供以下经过极大简化的体系结构（原始图像来自Kubernetes文档）：

K8s概念文档包括许多纯粹的“教育”内容，例如以下代码段：

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

实际上，我了解这是什么意思，但是请注意您需要学习多少个概念：EndpointSlice，Service，选择器，Pod，Endpoint。

而且-是的，大多数时候您不会使用所有这些功能。因此，大多数时候您根本不需要Kubernetes。

这是另一个随机代码段：

默认情况下，发送到ClusterIP或NodePort服务的流量可以路由到该服务的任何后端地址。从Kubernetes 1.7开始，可以将“外部”流量路由到在接收流量的节点上运行的Pod，但是ClusterIP Services不支持此功能，并且更复杂的拓扑（如分区路由）是不可能的。服务拓扑功能通过允许服务创建者基于源节点和目标节点的节点标签定义路由流量的策略来解决此问题。

以下是安全评论对此的看法：

Kubernetes — , . , Kubernetes — , , , .

您在Kubernetes上获得的知识越多，正常的开发过程就越困难：您需要所有这些概念（Pod，Deployment，Service等）才能使代码正常工作。因此，即使是仅通过虚拟机或嵌套的Docker容器进行测试，也需要升级成熟的K8s系统。

而且，由于您的应用程序在本地运行变得更加困难，因此解决此问题的方法很多，从工作台环境到将本地进程代理到集群（几年前我写过此工具），再将远程进程代理到本地计算机，使开发工作变得复杂...

您可以选择任何选项，但没有一个是完美的。根本不使用Kubernetes的最简单方法。

微服务（这是一个坏主意）

第二个问题是，由于系统允许您运行许多服务，因此您必须编写许多服务。馊主意。
分布式应用程序很难编写质量。 实际上，运动的部件越多，这些问题对工作的干扰就越大。

分布式应用程序很难调试。您将需要一种全新的调试和日志记录工具类型，它仍然比单片应用程序的日志要少。

微服务是组织中的扩展技术之一：当您有500个开发人员为一个生产性网站提供服务时，如果这允许开发团队独立工作，那么承担大规模分布式系统的成本是有意义的。因此，每个由5人组成的团队将收到一个微服务，并假装所有其他微服务都是您不应该信任的外部服务。

如果您的整个团队由5个人组成，则您有20个微服务，并且不可抗力的情况不会迫使您创建分布式系统，而这会导致计算错误。而不是像大型公司那样，每1个微服务5个人员，而是0.25个人员。

Kubernetes根本有用吗？

缩放比例

如果您需要认真的可扩展性，Kubernetes可能会派上用场。但是，让我们看看您有什么选择：

您可以在云中购买虚拟机，它们将具有多达416个虚拟CPU和8 TB RAM，即完全令人赞叹的功能。这将花费您一分钱，但操作起来非常简单。
许多简单的Web应用程序可以使用Heroku等服务以相当容易的方式进行扩展。

当然，假设可以使用的虚拟机数量也会增加：

大多数应用程序不需要显着的扩展，它们将具有足够的高质量优化。
扩展大多数Web应用程序的瓶颈是数据库，而不是Web Worker

可靠性

零件越多，发生错误的可能性就越大。
通过提高可靠性（运行状况检查，滚动部署）来增强Kubernetes的功能，在许多情况下，它们已经可以内置或实现得更加容易。例如，nginx可以对工作进程进行运行状况检查，还可以使用docker-autoheal或类似的方法自动重启这些进程。

如果你特别关心的停机时间，到会参观，你不应该首先想到“我怎么减少停机时间从1秒到1毫秒）进行部署时，但它应该是”我如何确保更改数据库架构允许回滚，如果我在某处？”
并且，如果您需要没有一台机器的可靠Web工作人员来作为故障点，那么有很多方法可以在没有Kubernetes的情况下实现这一点。

最佳实践？

实际上，自然界中不存在最佳实践。对于每种特定情况，只有最佳实践。因此，如果某种趋势在流行并且很流行，这并不意味着完全是您的正确选择。
在某些情况下，Kubernetes是最佳选择。剩下的就是浪费时间。

除非您迫切需要所有这些复杂性，否则您将有多种工具来解决问题：用于一台机器的Docker Compose，用于编排的Hashicorp的Nomad，用于扩展的Heroku和类似系统以及用于计算管道的Shakemake之类的工具。

编辑的后记

作为云提供商，我们经常遇到各种各样的客户，从小型初创企业到具有复杂业务流程和相关基础架构要求的大型组织。无论技术有多么出色，始终都有先例，其应用将导致不必要的困难。您应始终从情况出发，仔细权衡可用选项的优缺点。文章的作者在某种程度上加深了他的色彩，但他的信息很明确：有时候，为了做出正确的决定，值得远离趋势并公正地评估您的项目。这将节省开发人员的力量，并且公司资源的使用将使其更合适。

“让我们使用Kubernetes！” 您现在有8个问题