作者 | Itamar Turner-Trauring
策划 | 田晓旭
假如你已经在运用 Docker 了，那么下一步很天然的便是要运用 Kubernetes。
在开发同一运用程序时，5 个软件工程师规划的处理计划、与 50 个软件工程师、500 个软件工程师规划的必定不同。因而，假如你是在一个小团队中，Kubernetes 或许不是一个好的挑选，它会带来许多苦楚，但优点却微乎其微。
为什么这么说呢？
1
Kubernetes 运用存在哪些问题？
Kubernetes 有许多的活动部件——概念、子体系、进程、机器、代码，这就从另一方面代表着会有许多的问题。
多机器
Kubernetes 是一个分布式体系：有一台操控作业机器的主机器，作业被安排在不同的作业机器上。然后，每台机器在容器中运转作业。
假如你的作业只需求两台机器或许虚拟机来完结，那么运用 Kubernetes，你或许就需求扩展，需求 3 个、4 个或许更多的虚拟机。
多代码
到 2020 年 3 月初，Kubernetes 的代码库中已有超越 58 万行 Go 代码。这是实践的代码行数，没有核算注释或空白行，也没核算供货商的包。
2019 年的安全检查 这样描绘其代码库：
……Kubernetes 的代码库有很大的改善空间。该代码库巨大而杂乱，大部分代码只包括很少的文档和许多的依靠联系，包括 Kubernetes 外部的体系。在代码库中有许多逻辑从头完结的状况，能够会集到支撑库中，然后下降杂乱性，简化补丁，并削减代码库中不同区域的文档担负。
坦率来讲，Kubernetes 与其它大型项目没什么不同，假如想要运用程序不奔溃且更好的运转，那么研讨代码是有必要要做的作业。
杂乱性
Kubernetes 是一个杂乱的体系，包括许多不同的服务、体系和部件。
在运转单个运用程序之前，你需求以下高度简化的架构：
K8s 文档中的概念文档包括许多这样的解说阐明：
在 Kubernetes 中，EndpointSlice 包括对一组网络端点的引证。在指定挑选器时，EndpointSlice 操控器主动为 Kubernetes 服务创立 EndpointSlice。这些 EndpointSlices 将包括任何与服务挑选器匹配的 Pod 引证。EndpointSlice 经过仅有的服务和端口组合将网络端点分组。
在默许状况下，EndpointSlice 操控器办理的每个 EndpointSlice 的端点不超越 100 个。在这个范围内，EndpointSlice 应该与端点和服务进行 1:1 的映射，并且具有相似的功用。
只是这一段文字中就包括了许多的概念，例如 EndpointSlice、服务、挑选器、Pod 和端点。但在实践运用中，有时你底子都用不到这些功用。
默许状况下，发送到 ClusterIP 或 NodePort 服务的流量或许被路由到该服务的任何后端地址。从 Kubernetes 1.7 开端，就能够将“外部”流量路由到在接纳流量的节点上运转的 Pods，但这不支撑 ClusterIP 服务，并且，也不或许完结更杂乱的拓扑结构（如分区路由）。服务拓扑特性处理了这样的一个问题，它答应服务创立者依据源节点和方针节点的节点标签界说流量路由战略。
安全检查是这样点评 Kubernetes 的：
Kubernetes 是一个巨大的体系，操作非常杂乱。评价团队发现 Kubernetes 的装备和布置非常杂乱，某些组件的默许设置令人困惑、短少操作操控和隐式界说的安全操控。
别的，Kubernetes 的开发杂乱性也很高，当你越多的运用 Kubernetes，就会越难进行往常的开发，有必要了解各种概念之后才干运转代码，如 Pod、布置、服务等。相同测验时，也需求经过 VM 或嵌套的 Docker 容器发动完好的 Kubernetes 体系。
由于运用程序很难在本地运转，开发也就更困难了，所以各式各样的处理计划也就应运而生了，从过渡环境，到将本地进程代理到集群，再到将长途进程代理到本地机器……
尽管处理计划许多，可是有些计划也不完善，所以我以为最好也是最简略的解放计划是不运用 Kubernetes。
微服务
当体系答应运转多服务时，很简略就会编写许多服务。其实，这并不是个好主见。
首要，分布式运用程序很难编写，服务越多，问题就会越多。
其次，分布式运用程序很难调试，或许需求新的东西和日志记载来调试。
微服务其实是一种安排层面的扩展技能，当 500 名开发人员在共同开发一个网站时，不同的开发团队需求独立作业，这时付出大规模分布式体系的成本是有意义的，假如是一个 5 人团队，微服务是没有意义的。
2
Kubernetes 是不是就没用了呢？
上面讲了这么多 Kubernetes 运用时的问题，那是不是阐明 Kubernetes 彻底没用呢？当然不是。
扩展性
假如你需求大规模的扩展，Kubernetes 或许会很有用。
你能够取得最多 416 个 vCPU 和 8TiB RAM 的云 VM，尽管会很贵，但也很简略。
你能够正常的运用像 Heroku 这样的服务来扩展许多简略的 Web 运用程序。
大多数运用程序不需求扩展太多，一些合理的优化就足够了。
许多 Web 运用程序的扩展其瓶颈通常是数据库，而不是 Web 作业进程。
牢靠性
活动部件越多，就从另一方面代表着犯错的时机越多。
Kubernetes 内置了许多特性（健康检查、翻滚布置），能够使得牢靠性变得更简略，例如，Nginx 能够对作业进程履行健康检查，运用 docker-autoheal 或相似的东西主动重启进程。
假如你关怀的是停机时刻，那么第一个主见不该该是“怎么将布置停机时刻从 1 秒削减到 1 毫秒”，而应该是“怎么保证数据库形式更改不会阻碍我在作业搞砸时进行回滚”。
假如你只是想要一个牢靠的 Web 作业进程，不存在单机毛病点，那么有许多办法能做到这一点，不用运用 Kubernetes。
3
最佳实践？
没有所谓的最佳实践，只要针对特定状况的最佳实践。
咱们不能只是由于某件事很盛行，就以为它是正确的挑选。在某些状况下，Kubernetes 是一个非常好的主见，但在另一些状况下，这是一种毫无好处的时刻圈套。
在我看来，除非你的运用程序真的杂乱到有必要运用 Kubernetes，不然运用其它东西也能够很好的完结作业，例如单机 Docker Compose、相似 Heroku 的体系、用于核算管道的 Snakemake 等等。
