目录
如果你关注技术新闻，那么Kubernetes似乎无处不在。它已经变得非常流行。实际上，如果不使用Kubernetes，开发人员和DevOps团队可能会觉得他们的应用程序开发流水线已经过时了。
Kubernetes是用于容器化应用程序的编排工具。从Docker容器开始，Kubernetes可以控制云应用程序和微服务的资源分配和流量管理。
这样，Kubernetes简化了面向服务的应用程序基础结构的许多方面。除了持续集成和持续部署（CI/CD），Kubernetes还提供了扩展这些应用程序的基础设施，而无需付出大量的工作。
使用Kubernetes来管理云和混合云环境有很多令人兴奋的事情。但是很多团队经常追赶热点并过早地迁移到Kubernetes，常常会造成会大量时间，金钱浪费，和开发人员的挫败感。
在本文中，我们将尝试并帮助你回答以下问题：我真的需要Kubernetes？
Kubernetes会做什么？
Kubernetes是用于容器化应用程序的编排工具。它负责：
- 部署镜像和容器
- 管理容器和集群的扩展
- 容器和集群的资源管理
- 服务的流量管理
当你的应用程序由运行在不同容器中的多个服务组成时，Kubernetes确实会带来很多好处。对于具有静态用户群的单体应用，这可能超出了必要。
构建，测试并将应用程序交付到容器仓库的任务不是Kubernetes的一部分，这些使用CI/CD工具就可以完成工作。除了CI/CD流水线，Kubernetes还可以帮助你将应用部署到生产环境中而不会造成服务停机。
改善单体应用
大多数应用程序都是以单体形式开始的--将整个应用程序放在一个地方，可以快速轻松地进行和部署更改。但是，如果你的应用程序发展壮大，你需要很快找到扩大规模的方法。
这是否意味着该是Kubernetes的时候了？可能不是。
通常，扩展更多地是关于应用程序的内部，而不是高级架构和工具。例如，你可以通过使用支持相似性标签的负载均衡器部署多个实例来扩展整体。
扩展应用程序时要考虑的第一步是测试驱动开发（TDD），它可以确保软件质量并防止随着应用程序的增长而出现问题。尽管较小的模块或服务更易于测试，但模块化也意味着对mocking需求增加，并且需要额外的工具来配置和维护。良好的测试可以使你轻松自信地构建和扩展应用程序。
当你开始扩展整体时，Chef和Ansible等配置管理工具会派上用场。你可以使用它们来自动配置新服务器，以确保它们准备好运行你的应用程序。你甚至可以更进一步，并使用Terraform之类的工具来帮助配置新的服务器VM，这样你就不必手动创建它们。
当应用程序的其他部分成为瓶颈（例如数据库）时，你也可以扩展这些部分。例如，如果数据库成为瓶颈，则可以将经常访问的数据移至高性能内存数据存储（如Redis）中，以减少数据库的负载。
无论你使用哪种配置管理和配置工具，都必须有一个良好的CI/CD流水线。第一次部署应用程序时，你可能已通过FTP将zip文件复制到服务器，但是这种方法无法扩展。简化的CI/CD流水线可确保自动构建，测试和部署你的应用程序，而无需你或你的团队进行任何额外的工作。
你甚至可以使用AWS Elastic Beanstalk，Google App Engine或Azure App Service等云服务自动缩放单体应用。与Kubernetes相比，所有这些都带来了更少的管理开销，并且它们都可以与CI/CD工具很好地协同工作。
在开发新应用程序时，请专注于开发最佳应用程序。像Kubernetes这样的复杂工具可能是管理应用程序基础结构的正确解决方案。
增强单体应用
随着应用程序的不断增长，你可能最终将无法继续添加功能到单体应用中。这通常是因为该应用，接近单个开发团队可以从事的工作的极限。
在这一点上，许多团队选择拆分单体应用并完全迁移到微服务中。尽管这是一个颇受欢迎的决定，但它既不是必需的决定，也不是灵丹妙药。组织，可以考虑从添加单体应用的功能服务开始，而不是整体替换单体应用。这些支持服务中的某些实际上可能就是微服务-因此，你可以在合理的情况下使用小型服务而受益，同时仍可利用单体应用的好处。
即使引入微服务，你可能也不需要或不想从Kubernetes开始。Kubernetes擅长运行和扩展相关服务和微服务容器的Pod。但是，采用Kubernetes的某些方面很容易被忽略，例如，Kubernetes没有用于保护Pod，节点和集群的强大内置工具，并且在多云环境中部署Kubernetes集群会增加很多复杂性。
从像Azure Service Fabric和AWS Fargate这样的单云平台开始，可以更轻松地启动和扩展服务，而不必强迫你进行Kubernetes集群的管理。
另一个选择是完全避免具有维护开销的服务，并选择功能即服务（FaaS），例如AWS Lambda或Azure Functions。FaaS是一种在向应用程序添加服务时最大程度地减少潜在基础架构开销的好方法。此外，如果你最终需要使用Kubernetes编排的集群，则可以使用FaaS功能进行增强。
不再使用单体应用
现在，想象你的单体应用已经增长得如此之快，以至于你不能采用单体应用方式，开始需要迁移到微服务架构。
慢慢地，你拥有了各种各样的服务，其中许多服务需要彼此通信。你需要确保相互依赖的服务始终处于正常运行状态并且彼此可见。
此外，你有时还需要考虑跨多个可用性区域（甚至可能跨多个云供应商）运行。
在这一点上，你可能需要像Kubernetes这样的协调器。它使你可以轻松定义相关服务的模块（Pods），并可以自动缩放应用实例并在服务之间进行负载均衡。
为了使Kubernetes发挥作用，组织需要：
- 操作几个或几十个虚拟机
- 分配人员进行Kubernetes专门的配置和维护
- 使大部分同类服务部署自动化
- 与云（或托管）提供商无关
此外，Kubernetes内置了对高可用性（Amazon RDS Multi-AZ）部署的支持，这使得提高应用程序的可靠性和可用性变得更加容易。
当然，这确实带来了开销：需要时间和工程资源来创建和管理集群，定义Pod以及创建适合部署到Kubernetes的容器化应用程序。但是，如果你的应用足够大，可以从Kubernetes中受益，那么管理开销是值得的。
结论
Kubernetes功能强大，但这并不意味着它是每个团队和每个应用程序的正确选择。与任何技术一样，它可以解决某些问题。如果你没有遇到Kubernetes想要解决的问题，那就麻烦多了。
首先，建议使用简单可用工具将应用程序快速发布。当你的应用程序达到其部署和扩展成为自身运转的一部分时，就有必要开始考虑编排，并且自然而然地将Kubernetes作为编排工具。
译文链接：https://thenewstack.io/do-i-really-need-kubernetes/
