为什么你的创业公司应该运行在Kubernetes上

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