作者：陈海波（漂石）
午夜时分，电话响起，线上紧急。你从千呼万钉中醒来，睡眼朦胧，手忙脚乱。
恍惚之间，终于整理清楚发生了什么，一个陈年迈运用忽然停机，消息堆积，系统停摆。而你就像一个下水道小工疏通马桶一般，大力出奇观，重启机器，康复服务。只见消息行列中的堆积事情一泻千里，警告消除。
次日，你再也不想重现午夜凶铃，决议对系统进行永久性修复：加一个守时重启服务的脚本。
斗转星移，许多时日过去了，你也在不同的角落加了很多的脚本，也好久没有深夜惊醒，乃至还能悠闲享受下午茶。可是，直到今日。
今日，你们部分要降本增效，为了防止自己成为被砍掉的本钱，你决议主动对线上的机器开刀：合并服务，裁撤机器。尽管你对机器上都布置了什么运用了然于胸，可是你现已不记住都有哪些脚手架支撑着运用的工作。
重建环境难如登天，你又开端难眠了。
变化的基础设备
杂乱、奥秘而奇特的线上环境承载了半部都市传说，乃至有些公司的线上环境本身便是一本需求口耳相传的上古神话。
我尽管没有看过沙漠下暴雨，可是看过没人说的清楚上面有什么的环境。我尽管没有看过大海亲吻鲨鱼，可是我看过重启再也起不来的机器。
假如你能说清楚任何一台机器上都布置了什么运用，以及机器上服务之间的依赖关系是什么姿态的，你现已击败了多半的玩家。而形成这种局势的根本原因便是基础设备的易变。
- 新增一个服务时：“我找台机器布置一下”
- 某一个服务出问题时：“我上机器改一下”
- 需求对某个系统配置改变时：“我搞个脚本跑一跑”
看似常规运维改变，有文档记录或者没有文档记录，每一个环境都是如此的别致和独一无二，再加上人员变化，造就了很多的“祖传秘技”。
什么是不可变的基础设备
容器在被广泛承受的一起，「不可变」也逐步被潜移默化的承受。
运用容器消亡之后，容器内的修正会跟着容器一起不复存在，不要在容器内做修正便是最朴素的不可变理念。在程序发动阶段遇到问题，很少人还会把在容器内修修补补作为正经方案，而会回到最一开端的阶段，从容器构建阶段处理问题。
随之带来的便是我们对容器镜像无尽的信赖感，容器忽然出现问题？重建试试。换个机器跑不起来？肯定是机器的问题。
容器带来了什么
我们普遍认同 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 删下看看？朴实无华且有用。
点击此处，检查更多保管节点池功能细节~
