导语：如果你在一个小型团队，Kubernetes可能不适合你。
如果您使用的是Docker，那么下一个自然步骤似乎就是Kubernetes，又名K8s：这就是您在生产环境中运行事情的方式，对吗？
也许，为500名从事同一应用程序的软件工程师设计的解决方案与50名软件工程师的解决方案完全不同。两者都将不同于为5人团队设计的解决方案。
如果您是一个小型团队的一员，那么Kubernetes可能不适合您：用起来痛苦不堪，收益却很少。
了解更多开源资讯欢迎关注微信公众号“开源村OSV”
让我们看看为什么。
1.每个人都喜欢运动部件：Kubernetes有很多活动部件，包括概念，子系统，过程，机器，代码，这意味着很多问题。
2.多台机器：Kubernetes是一个分布式系统：有一台控制工作机的主机。工作安排在不同的工作计算机上。然后，每台机器都在容器中运行工作。因此，您已经在谈论两台计算机或虚拟机只是为了完成所有工作。这样就可以给您……一台机器。如果要进行扩展（整个练习），则需要三，四或十七个虚拟机。
3.很多很多的代码：截至2020年3月初，Kubernetes代码库拥有超过580,000行Go代码。那是实际的代码，它不计算注释或空白行，也不计算供应商的软件包。从2019年开始的安全审查将代码库描述如下：
“ ... Kubernetes代码库有很大的改进空间。该代码库既庞大又复杂，代码的大部分包含最少的文档和大量的依赖关系，包括Kubernetes外部的系统。代码库中有许多逻辑重新实现的案例，可以将其集中到支持库中，以降低复杂性，简化补丁程序并减轻代码库各个区域的文档负担。”
公平地说，这与许多大型项目没有什么不同，但是如果您的应用程序不会中断，那么所有这些代码都是您需要处理的。
严重的复杂度
Kubernetes是一个复杂的系统，包括架构复杂度，操作复杂度，配置复杂度和概念复杂度，还具有许多不同的服务，系统和部件。在运行单个应用程序之前，您需要以下高度简化的体系结构（Kubernetes文档中的原始源代码）：
K8s文档中的概念文档包括以下几条教育性声明：在Kubernetes中，EndpointSlice包含对一组网络端点的引用。指定选择器后，EndpointSlice控制器会自动为Kubernetes服务创建EndpointSlices。这些EndpointSlice将包含对与服务选择器匹配的所有Pod的引用。EndpointSlices通过唯一的服务和端口组合将网络端点组合在一起。
默认情况下，由EndpointSlice控制器管理的EndpointSlices每个端点不得超过100个。低于此比例时，EndpointSlices应该与Endpoints and Services 1：1映射，并且具有相似的性能。
我实际上有所了解，但是注意到需要多少个概念：EndpointSlice，Service，选择器，Pod，Endpoint。是的，在很多时候您不需要这些功能中的大多数，但是在很多时候您根本不需要Kubernetes。
另一个随机选择：默认情况下，发送到ClusterIP或NodePort服务的流量可以路由到该服务的任何后端地址。从Kubernetes 1.7开始，可以将“外部”流量路由到在接收流量的节点上运行的Pod，但是ClusterIP Services不支持此功能，并且更复杂的拓扑（如分区路由）是不可能的。服务拓扑功能通过允许服务创建者基于源节点和目标节点的节点标签定义路由流量的策略来解决此问题。
这是我上面提到的安全审查必须说的：“ Kubernetes是一个大型系统，具有很大的操作复杂性。评估团队发现，Kubernetes的配置和部署并非易事，某些组件具有令人困惑的默认设置，缺少的操作控制和隐式定义的安全控制。”
开发复杂度
您购买Kubernetes的次数越多，进行常规开发的难度就越大：您需要所有不同的概念（Pod，Deployment，Service等）来运行代码。因此，您需要启动一个完整的K8s系统，以通过VM或嵌套的Docker容器进行任何测试。
而且，由于您的应用程序很难在本地运行，因此开发也更加困难，从而导致了各种解决方案，从暂存环境到将本地进程代理到集群（我几年前就为此编写了一个工具），再到代理本地计算机上的远程进程…
有很多不完善的解决方案可供选择；最简单，最好的解决方案是不使用Kubernetes。
微服务：一个坏主意
第二个问题是，由于您拥有可以运行大量服务的系统，因此通常很想编写大量服务。这是一个坏主意。
分布式应用程序确实很难正确编写。真的。零件移动得越多，这些问题就越发挥作用。
分布式应用程序很难调试。您需要全新的检测和日志类别，以获取与单片应用程序日志不一样的理解。
微服务是一种组织扩展技术：当您有500个开发人员在一个实时网站上工作时，如果这意味着开发人员团队可以独立工作，则有必要支付大型分布式系统的费用。所以你给的5个开发团队每一个单一的微服务，以及团队的理由是微服务的其余部分是他们不能信任外部服务。
如果您是一个由5人组成的团队，并且拥有20个微服务，并且您对分布式系统的需求不是很强，那么您做错了。每次服务只有0.25人，而不是像大公司那样有5人。
但这有用吗？
缩放比例
如果您需要大量扩展，Kubernetes可能会有用。但是，让我们考虑一些替代方法：
您可以获得具有多达416个vCPU和8TiB RAM的云虚拟机，这种规模我只能用亵渎性来真正表达。是的，它会很昂贵，但是也会很简单。您可以使用Heroku等服务轻松地扩展许多简单的Web应用程序。当然，这假定增加更多的工人实际上会对您有任何好处：
大多数应用程序不需要扩展很多。一些合理的优化就足够了。许多Web应用程序的扩展通常是数据库而不是Web Worker的瓶颈。
可靠性
更多的运动部件意味着更多的出错机会。
Kubernetes提供的可靠性功能（运行状况检查，滚动部署），可以更简单地实现或在许多情况下已经内置。例如，nginx可以对工作进程进行运行状况检查，您可以使用docker-autoheal或类似的方法自动重启那些进程。
而且，如果您关心的是停机时间，那么您首先想到的不应是“如何将部署停机时间从1秒减少到1ms”，而应该是“如何确保数据库架构更改不会阻止回滚（如果我拧了一些东西）”起来。而且，如果您希望没有一台机器的可靠Web工作人员成为故障点，那么有很多方法可以做到，而无需Kubernetes。
最佳做法？
一般而言，没有最佳实践之类的东西。只有针对特定情况的最佳做法。仅仅因为时尚和流行并不意味着它是您的正确选择。在某些情况下，Kubernetes是一个非常好的主意。在其他情况下，这是一个浪费时间的浪费。
除非您真的非常需要这么大的复杂性，否则会有各种各样的工具会同样起作用：从单台机器上的Docker Compose，到编排的Hashicorp的Nomad，再到Heroku和类似的系统，再到像Snakemake这样的用于计算管道的东西。
来源：oschina
链接：https://my.oschina.net/u/3828502/blog/4290039