共计 3799 个字符，预计需要花费 10 分钟才能阅读完成。
作者：陈海波（漂石）
午夜时候，电话响起，线上告急。你从千呼万钉中醒来，睡眼朦胧，慌手慌脚。
恍惚之间，终于梳理分明产生了什么，一个陈年老利用忽然停机，音讯沉积，零碎停摆。而你就像一个下水道小工畅通马桶个别，鼎力出奇观，重启机器，复原服务。只见音讯队列中的沉积事件一落千丈，正告打消。
次日，你再也不想重现午夜凶铃，决定对系统进行永久性修复：加一个定时重启服务的脚本。
斗转星移，许多时日过来了，你也在不同的角落加了有数的脚本，也良久没有中午惊醒，甚至还能悠闲享受下午茶。然而，直到明天。
明天，你们部门要降本增效，为了防止本人成为被砍掉的老本，你决定被动对线上的机器开刀：合并服务，裁撤机器。尽管你对机器上都部署了什么利用了然于胸，然而你曾经不记得都有哪些脚手架撑持着利用的运行。
重建环境难如登天，你又开始难眠了。
变动的基础设施
简单、神秘而神奇的线上环境承载了半部都市传说，甚至有些公司的线上环境自身就是一本须要口耳相传的上古神话。
我尽管没有看过沙漠下暴雨，然而看过没人说的分明下面有什么的环境。我尽管没有看过大海亲吻鲨鱼，然而我看过重启再也起不来的机器。
如果你能说分明任何一台机器上都部署了什么利用，以及机器上服务之间的依赖关系是什么样子的，你曾经击败了八成的玩家。而造成这种场面的根本原因就是基础设施的易变。
- 新增一个服务时：“我找台机器部署一下”
- 某一个服务出问题时：“我上机器改一下”
- 须要对某个系统配置变更时：“我搞个脚本跑一跑”
看似惯例运维变更，有文档记录或者没有文档记录，每一个环境都是如此的别致和举世无双，再加上人员变动，造就了有数的“祖传秘技”。
什么是不可变的基础设施
容器在被宽泛承受的同时，「不可变」也逐步被耳濡目染的承受。
利用容器沦亡之后，容器内的批改会随着容器一起不复存在，不要在容器内做批改就是最奢侈的不可变理念。在程序启动阶段遇到问题，很少人还会把在容器内修修补补作为正经计划，而会回到最一开始的阶段，从容器构建阶段解决问题。
随之带来的就是大家对容器镜像无尽的信任感，容器忽然呈现问题？重建试试。换个机器跑不起来？必定是机器的问题。
容器带来了什么
大家广泛认同 Docker 或者说容器引发了一场反动。然而为何说容器是一场反动，到底革了什么的命？
有一种说法是 Docker 简化了服务的治理，停启服务更加简略，然而事实上 systemd 或者 supervisor 等老牌服务治理、运维工具在这一点上不见得比 docker 难用多少。
我认为是镜像技术引爆了反动，一个不可长期批改的、固化的、自蕴含的交付物，真正的一次构建到处运行，一个能够疾速铲掉和疾速部署的实体，再也没有「Works on my machine」，是如此的安心和可依赖。
也正是因为容器的重建是如此的快捷，使得咱们有机会对「重启试试」施展到极致，出问题了，重建容器看看？
你想尝试应用 Docker，然而你的业务如此简单，上机器重建容器和间接上机器重启服务又有什么实质差异呢。
Pet vs Cattle
随之 Kubernetes 的到来，大规模的容器治理成为可能，而划定大规模容器的治理最佳实际也成为了热门议题。
如何豢养一只猫
如果你失去了一只猫，你会如何豢养它？我记得我在领回一只猫之后，花了很长的工夫和脑细胞用来约定一个我和它都能承受的名字。
紧接着就是带着我的小猫去医院，制订疫苗打算，来保障我的小猫将来的衰弱。前面便是日复一日的铲屎和等着奴才的眷顾。
小王子通知我：正因为你为你的猫破费了工夫，这才使你的猫如此重要。
经典的运维形式和猫的豢养是一样的，咱们能够称之为宠物式运维。你会对机器和利用做详尽的布局，甚至为这个环境起一个名字，比方叫生产好了。
你也会对这个环境悉心照料，定期看看监控、做下降级颐养。你为你的环境破费了工夫，你的环境如此重要。
很难构想你的猫和你的环境忽然间离你而去的场景，兴许你会伤心的撕心裂肺和破产的撕心裂肺。
农场主入门
在取得了一只猫之后，你一不留神又取得了一家牧场。但你可能无奈像养一只猫一样养几千头牛，因为几千个名字应该是很难记住的。
你可能也不会顺次带着你的牛去医院打疫苗，何不间接零售疫苗对立接种呢。如果有小牛犊存在重大的缺点，兴许你会陪在它身边悉心照料，但更可能的是把它尽早的从流程中剔除，省的节约更多的饲料。
从此你的生存便目无全牛，只有为牛群建设足够多的保障设施，某一头牛的状态对整体又有什么影响呢。
放牧式运维
当你曾经为上千头牛建设了欠缺的豢养设施，你会惊奇的发现，即便再加 100 头牛，并不会减少太多的老本。而不像豢养猫，当你有两只猫的时候，最好能有 3 个猫砂盆，否则你将有机会体验到鸡飞狗跳。
你信心当一个牧牛人运维，再也不想给生产环境的奴才们铲屎了。拥抱 Kubernetes，像放牧一样治理你的利用。
牧养一群 Pod
你把生产环境的奴才们装进集装箱，通过容器镜像对部署形式进行标准化，谁也甭想做非标的操作，再应用 Pod 对利用进行部署，再也不去关怀利用在哪个 Node 上启动，这所有自有牧场（Kubernetes）自行处理。
一个 Pod 异样了？没关系，删掉看看，下次起来又是一个全新的利用。丝毫不会影响到牧场的失常运行。
所有丝般顺滑，岁月静好。
午夜时候，电话响起，线上告急。你从千呼万钉中醒来，睡眼朦胧，慌手慌脚。
恍惚之间，终于梳理分明产生了什么，原来是不知何处流量涌现，节点雪崩。而你就像一个下水道小工畅通马桶个别，鼎力出奇观，扩容机器，复原服务。pending Pod 隐没不见，正告打消。
次日，你再也不想重现午夜凶铃，但陷入沉思，身为牧场主的你，逐步意识到一个灯下黑的问题。
你能够轻松的同质化看待每一头牛，但你无奈同质化整个牧场。
牧养真正的基础设施
几番梳理，你找到了问题的要害：只管能够放牧式治理 Pod，然而机器的运维却还是宠物式的。
你仍然会悉心照料每个机器：提前布局、取一个名字、独自管制规格、筛选操作系统，甚至还有几台深得你爱，嘘寒问暖，日夜挂念，领有独自的外部昵称代号。
作为业界当先的牧场主，你信心革新本人的牧场，如果能像治理 Pod 一样治理 Node 是不是一个好主见？
如果 Node 异样间接删除 Node，等着弹出新的？还没想完，你后背有些发凉，你还没有像信赖容器一样信赖虚机，尽管你深知重启可解决 90% 的故障，而重装系统能够解决 99% 的故障。
思来想去，你仍然想做些尝试，稍加思考，锁定痛点有二：
- 机器按需疾速弹缩，同质治理
- OS 镜像化：疾速、平安、不可变
驯服虚机
通过调研，你发现事件并不像原来构想的那样深不可测，支流云厂商早就提供了家养工具，你只须要稍加驯服，便能够为本人的牧场服务。
云厂商们很早便推出了弹性伸缩组，能够依照负载和冀望保护虚拟机的数目。而阿里云也有本人的实现（ESS），能够无需人工干预的依据规定对 ECS 进行扩缩容。
你看到了心愿，这不就是 Node 的 Deployment 吗？然而只是扩容虚拟机对你来说并没有什么价值，你深知须要的是牛圈，而不是木材，你须要对他们进行驯服。
这时，你转头看到了你的 Kubernetes 集群，灵感蹦出，为何要直面虚拟机呢，只有新扩容出的机器能被纳管到集群中不就解决了根本问题。
说干就干，通过 AutoScaling 定义了启动命令，开机后进行标准化装置和执行 kube join 动作。当机器开机不久，就能够呈现在 Kubernetes 集群中。你感觉间隔指标进了一步。
驯服 OS
很快，你又发现了一个新的问题，传统的 OS 启动和容器切实无法比拟，明明所有的依赖都在容器外部，而且所有的利用都曾经在容器内运行，但你还是不得不为 OS 内置的、没人应用的服务买单，这些服务拖慢了启动速度，还引入了安全漏洞。
而且，总是有人意识不到同质化治理的益处，时不时有人上机器做一些不可知的批改，导致你每次想开释虚机时须要去群里喊一喊，防止碰到什么神奇的 Bug。自寻烦恼，你苦笑道。
你打算驯服 OS，对传统的 OS 进行剪裁，除了容器依赖的货色全副清理掉，说不好能大大放慢机器的启动速度。还有，最好能在啥中央加个告示，敬告大家不要在机器上做写操作，防止开释机器时文件的失落。
有天，你发现了阿里云的 ContainerOS，一个针对容器剪裁和优化的操作系统，你不须要亲自动手剪裁了，甚至都不再须要加一个告示，因为 RootFS 都是只读的，连 SSH 都不会默认关上，从根本上杜绝了非标操作。
你尝试了一下，针对容器优化的 OS 启动贼快，点完弹出，一分钟后你就能够把业务调度下来了。把 Node 当做 Pod 治理，你看到了心愿。
托管式放牧
但不久，你遇到了一个新的问题，创立机器一时爽，你的老板通知你，你手里有一批机器存在一个要紧的 CVE 安全漏洞，须要抓紧时间搞一搞，你开始头大了，因为你晓得，除了存量的节点，当初只有创立新的机器就有安全漏洞。
你有了一种若有若无的感觉：你在走向深水区。
一番探寻后，你据说有人提出应该像主动驾驶一样去托管一个集群，也看到了阿里云 ACK 的托管节点池。节点的扩缩容、节点故障的自复原、平安加固、OS 的托管，无不触动着你。你意识到应该从根本上解决问题：撒手自建的 Kubernetes，全面拥抱托管。
拥抱托管后，你恍然大悟，原来事件本应如此简略，多年的摸索好像一颗种子，在看到托管节点池后霎时发芽成绩。
从此，世界上又开始流传了新三板斧传统：等等自愈看看？Pod 删下看看？Node 删下看看？朴实无华且无效。
点击此处，查看更多托管节点池性能细节~