在我于2021年初进行的最后一次采访周期中，我与一些初创公司进行了交谈。
我总是询问初创企业的部署流程，因为它可以帮助我了解公司所处的技术复杂程度。 一些企业可以在使用SCP部署的简单PHP Web应用程序上走得更远。
其他的则达到极限，必须使用诸如Redis或Kafka之类的基础结构组件在相互之间进行通信，将系统重做为几个服务。
当他们在我的履历表上看到Kubernetes时，面试官经常问起它。 Kubernetes的经历引起了很多兴趣，但也有人担心它是否适合特定的用例。 我在上一家公司如何使用它？ 学习困难吗？ 开发团队使用它的经验是什么？ 有时，有一些关于实施不当的恐怖故事，并且担心迁移到Kubernetes是一个错误。 我经常听到一些非常合理的怀疑，以及保持简单部署的愿望和犹豫不决的想法。
因此，我将跳到这里的重点。 如果今天我要从头开始自己的创业公司，那么我很可能会从Kubernetes开始。 我现在已经在两家截然不同的公司中使用了它，这是我的（主观）结论。
简而言之，积极因素远远超过了少数不利因素，我认为它值得许多创业公司投资。 并非所有创业公司。 不一定是您的创业公司。 但是很多。
让我们来看看原因。
什么是Kubernetes？
简而言之，Kubernetes是最初由Google开发的开源容器编排系统。 它已由第三方贡献给社区，其中包含许多新的库和插件（称为运算符）。
Kubernetes不是像Amazon Web Services（AWS）或Google Cloud Platform（GCP）这样的云平台。 实际上，如果您愿意的话，您可以在自己的数据中心的自己的硬件上运行和部署Kubernetes，但是，我不建议初学者使用。
认为它更像是一种我们可以用来描述工作系统的语言。 一旦我们对系统进行了足够详细的描述，Kubernetes便可以使用其计算资源（以Kubernetes的话来说，节点，也称为计算机）来运行执行我们系统的容器。
对于初创公司而言，最大的好处是“描述工作系统”的过程可作为文档和代码的集中位置来定义基础架构。（Infrastructure as Code）
Kubernetes自己为自己买单
我不会撒谎。 EKS（亚马逊提供的托管Kubernetes解决方案）价格昂贵。 除了EC2费用外，您的管理费用为每年$ 0.20或$ 1,753.20。 它不是免费的。
但是请考虑您要花多少钱才能让工程师手动启动节点。 这些纯粹的基础架构更改所浪费的时间仅仅是在开发产品上花费时间。 如果您是一家刚想实现下一个目标的初创企业，您应该乐于付出（合理的）管理费用，以神奇地消除团队中容易出错且耗时的过程。
使用手头的Terraform工具，您还可以创建一个Kubernetes集群，该集群可以通过简单的单行更改进行扩展。 在我的上一个团队中，我们的集群从2个节点增长到4个节点，其Git提交将2更改为4。这实际上是单行更改。 添加节点后，Kubernetes会自动将资源移动到新节点上，无需进一步的工作。 然后，您可以继续解决实际问题。
部署容易
传统的Linux生产系统通常看起来像这样。 您有一些用Java，Python或Ruby编写的代码。 应用程序代码通常是由不太了解服务器的人（或者至少没有在其中使用）编写的。
假设您有一台机器，例如在Amazon EC2中，由您的运营团队中的某人管理，该人不太了解应用程序代码。 当应用程序团队完成某些工作时，他们希望能够部署这些更改。 运营团队希望确保这些更改不会破坏任何内容。
您也不希望系统在部署期间宕机。 如果出现问题，您希望能够回滚到以前的代码专科版本。 从上传数据到启动服务器的部署过程需要30分钟怎么办？ 您将使系统离线30分钟吗？
可能不会。 您可能会想出一些系统来保持版本n-1的运行，直到版本n启动为止，这时您将切换到新版本。
但是确实看起来很复杂。 有很多要记住的地方-还有很多可能出错的地方。 这些部署规则将用一系列脚本进行编写，这些脚本需要进行版本控制和维护，并且很可能本身包含错误。 而且，当我们将公司扩展为独立的团队时，他们所有人都试图一天多次部署。 你开始感到恐惧。 运维团队成员开始对系统中的客户流失感到不知所措。 随着过程变得越来越繁琐，部署开始花费的时间越来越长。
这个故事听起来很熟悉吗？
Kubernetes消除了很多复杂性。 要部署新版本的服务，我们可以简单地更新容器映像以指向新版本的代码。 我们还可以定义运行状况检查，以声明新版本正在运行。 如果未通过，则旧版本的代码将继续运行。
我们可以使用仅供内部使用的DNS名称（例如order_service）定义服务，该名称将自动对正在运行的副本进行负载平衡。 无需维护运行实例的列表。
而且，如果我们在部署后发现问题，则可以使用简单的回滚命令查找并应用先前的容器映像。 通常，这可能只需要几秒钟，然后我们回到运行软件的最新已知稳定版本。
听起来不是很好吗？
您不需要一支可以完成所有任务的独立运营团队
Kubernetes本身就是一个复杂的野兽。 但是，任何经验丰富的开发人员都可以使用它。
那是因为，Kubernetes部署不是使用一系列复杂的bash脚本，特殊的部署工具等，而是通过简单的声明性YAML文件进行管理。
那就对了。 与Kubernetes一起使用时，您需要了解的就是Ruby发烧友倡导的简单XML替换。
仅使用YAML，我们就可以定义具有自动缩放，复制和服务解析的整个工作系统。 然后，使用kubectl CLI工具，我们可以要求集群运行我们的配置。 我们从不直接告诉Kubernetes做任何事情。 相反，它将读取我们的声明性YAML并解释需要执行的操作。
您认为您的开发人员可以弄清楚如何编写YAML吗？ 我这么想。
我已经在一些复杂的系统上工作，这些系统要求管理部署的人员了解
a）Python，b）bash，c）我们正在运行的OS版本的一些细微差别，d）JVM标志（上帝帮助您），e） SCP命令（您可以在不查看文档的情况下编写有效的SCP命令吗？）……等等。
也有管理开销。 部署脚本和基础结构代码通常由运营团队管理。 但是开发人员经常需要更改部署代码，例如，在启动时设置标志，并扩大系统规模。 这在开发人员和运营人员之间造成了紧张关系，因为这两个团队相互之间提出了要求，但通常会遵循不同的目标。
所有这些复杂性和开销给您在启动过程中所做的一切增加了负担。 如果您想快速开发新功能并且能够轻松地从一个项目跳到另一个项目，那么您真的想保持尽可能小的摩擦。 Kubernetes消除了很多痛苦，让您专注于产品。
您可能不需要Kubernetes的情况
当然，没有灵丹妙药，而且在某些情况下，像Kubernetes这样的东西是过大的。
简单的WordPress网站，CMS等
如果您仅运行WordPress，则不需要Kubernetes。 如果您运行的CMS仅偶尔进行一次升级，升级库或安装插件，而实际上从未真正部署过，则不需要Kubernetes。 它确实针对管理大型，不断变化的系统进行了优化。
嵌入式系统，任何需要实时访问操作系统的东西
显然，如果您要编写需要与Linux内核接口的低级嵌入式系统或软件，那么Kubernetes不适合您。 这适用于任何容器化解决方案。
您的产品主要是数据库
Kubernetes确实具有一种称为“状态集”的资源类型，旨在运行诸如数据库和管理状态的消息代理之类的东西。 从理论上讲，运行有状态集可以允许您运行多个副本并上下缩放它们，以及附加和扩展存储。
但是这样做总是让我有些紧张。 借助应用程序服务，我希望使开发人员可以轻松调整设置并轻松进行部署。 对于数据库，我只想相反。 很难意外更改设置或将系统升级到新版本。 我也不希望我的数据库在集群中争夺CPU和内存。
如果我使用的是AWS并且可以访问RDS，那么我特别倾向于不使用Kubernetes来存储数据库。 您选择的云提供商中的RDS或其等效产品将更容易管理自动备份，扩展和监视。
结论
Kubernetes非常适合需要随时间扩展和增长的任何项目。
如果您是一家初创公司，那么几乎可以肯定您属于该类别。 您现在可能很小，但是您想要成长。 这就是您告诉投资者的原因，也是您聘请如此多的富贵论坛开发人员的原因。 您的系统将要快速更改和扩展，因此您希望以尽可能减少成本和摩擦的方式构建系统。
仅出于这个原因，我认为任何电子商务，SaaS或类似公司尽早投资Kubernetes都是很有意义的。 即使您只是在集群中部署单个简单的Web应用程序，为未来做计划也意味着精心构建基础架构，以使您的团队能够快速移动一年或三年。
感谢您的阅读，祝您好运！
