说实话，企业要搞大规模业务，Kubernetes真是绕不开的那个东西，没它挺难撑起来的

说实话，企业要搞大规模业务，Kubernetes真是绕不开的那个东西，没它挺难撑起来的，这个话不是我说的，是很多在一线实际操盘过大型系统架构的技术负责人和工程师们的普遍感受，你可以去问问那些经历过公司业务从几台服务器暴涨到成千上万台服务器的人，他们大概率会告诉你，如果没有Kubernetes,整个技术栈的复杂度和运维压力会大到难以想象。

为什么这么说呢？想象一下早期的互联网公司，业务刚开始，可能就一两台服务器，一个简单的应用加上数据库就跑起来了，这时候没什么问题，开发人员自己就能兼着运维，但随着用户量上来，一台服务器不够用了，就得加机器，一开始可能是简单地复制几台，手动部署一下应用，但再往后，业务越来越复杂，服务拆分成好多模块，比如用户中心、订单服务、支付服务、商品搜索等等，每个服务都需要多部署几个实例来保证高可用和分担压力，这时候,手动管理就变成了一场噩梦。

（来源：多位资深运维工程师在技术社区分享的从零到一搭建系统的心路历程）

你如何保证这几十上百个服务实例，在几十台甚至上百台机器上，都能正确地启动、运行，并且健康状态良好？某台机器突然宕机了，上面跑的服务怎么自动迁移到别的健康机器上？今天业务促销，流量是平时的三倍，怎么快速扩容一批服务实例，等促销结束再缩容以节省成本？版本要更新了，如何做到不停机、用户无感知地平滑升级？这些问题，在服务规模小的时候，或许还能靠人力或者一些简单的脚本勉强应付，但当规模达到一定程度，比如服务实例过千，服务器节点过百，靠人力是绝对跟不上的，错误率会急剧升高,系统会变得极其脆弱。

（来源：基于对多家互联网中大型企业技术团队负责人的访谈内容整理）

这时候，就需要一个“自动化运维管家”，而Kubernetes就是这个领域目前事实上的标准管家，它就像一个超级大脑，你只需要告诉它你的最终目标是什么（我要运行10个订单服务的实例，每个实例需要1核CPU和2G内存，遇到故障要自动重启），它就会自动去调度、管理和维护整个集群的状态,确保实际运行状态始终符合你的期望。

它解决的核心痛点就是“规模化管理”的自动化，比如说自动调度，你不用再操心把哪个服务具体部署到哪台机器上，Kubernetes会根据每台机器的资源余量和你的要求，自动选择最合适的节点去部署，再比如服务发现，服务之间要互相调用，不用再写死IP地址，Kubernetes提供了内部域名解析，服务只需要知道对方的名字就能找到，还有自愈能力，它持续监控每个服务的健康状态，一旦发现某个实例挂了，会自动重启它；如果整个节点宕机，它会把这个节点上所有健康的服务实例，自动在其它节点上重新拉起来，滚动更新功能让你可以一步步用新版本替换旧版本，万一新版本有问题，还能立刻回滚到上一个稳定版本,大大降低了发布风险。

（来源：CNCF官方文档及Kubernetes核心概念白皮书中的非技术性描述摘要）

你可能听说过Docker，它把应用程序和依赖打包成一个镜像，解决了环境一致性的问题，但Docker本身只是一个单机工具，它负责把容器跑起来，却不管成百上千的容器如何在多台机器上协同工作，而Kubernetes正是站在Docker这样的容器技术之上，解决了容器集群的管理问题，可以说，Docker让“集装箱”（容器）标准化了，而Kubernetes则构建了自动化管理成千上万个集装箱的“超级港口系统”，包括调度起重机（调度器）、安排泊位（节点）、规划路线（网络）和监控状态。

（来源：技术圈内常见的关于Docker与Kubernetes关系的通俗比喻）

现在云计算时代，无论是阿里云、腾讯云、亚马逊AWS还是谷歌云，都把Kubernetes作为其容器服务的核心引擎，这意味着，企业上云如果要采用容器化的方式来部署和管理应用，几乎不可避免地会接触到Kubernetes，它已经成为云原生架构的基石，不会Kubernetes，就像十年前不会用虚拟化技术一样,会逐渐与主流的技术体系脱节。

（来源：主流公有云厂商产品战略发布会及技术布道内容）

这并不是说Kubernetes是万能的，或者所有企业都必须立刻上Kubernetes，对于业务量很小、架构简单的初创公司，引入Kubernetes可能会带来不必要的复杂性，杀鸡用牛刀，但一旦你的业务有了规模效应，需要应对高并发、高可用、快速迭代的挑战，那么提前规划和引入Kubernetes这样的技术，几乎是一个必然的选择，因为它提供的自动化运维能力和弹性伸缩能力，是支撑业务大规模发展的关键技术保障，没它，光靠人工堆砌，效率和稳定性都很难撑得起那个量级，那句话虽然听起来有点绝对,但确实是很多过来人的真实体会。