1

当我们谈论不可变基础设施时,我们在谈论什么

 1 year ago
source link: http://dockone.io/article/2434918
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.


午夜时分,电话响起,线上告急。你从千呼万钉中醒来,睡眼朦胧,手忙脚乱。

恍惚之间,终于梳理清楚发生了什么,一个陈年老应用突然停机,消息堆积,系统停摆。而你就像一个下水道小工疏通马桶一般,大力出奇迹,重启机器,恢复服务。只见消息队列中的堆积事件一泻千里,警告消除。

次日,你再也不想重现午夜凶铃,决定对系统进行永久性修复:加一个定时重启服务的脚本。

斗转星移,许多时日过去了,你也在不同的角落加了无数的脚本,也好久没有半夜惊醒,甚至还能悠闲享受下午茶。但是,直到今天。

今天,你们部门要降本增效,为了避免自己成为被砍掉的成本,你决定主动对线上的机器开刀:合并服务,裁撤机器。虽然你对机器上都部署了什么应用了然于胸,但是你已经不记得都有哪些脚手架支撑着应用的运转。

重建环境难如登天,你又开始难眠了。

变化的基础设施

复杂、神秘而神奇的线上环境承载了半部都市传说,甚至有些公司的线上环境本身就是一本需要口耳相传的上古神话。

我虽然没有看过沙漠下暴雨,但是看过没人说的清楚上面有什么的环境。我虽然没有看过大海亲吻鲨鱼,但是我看过重启再也起不来的机器。

如果你能说清楚任何一台机器上都部署了什么应用,以及机器上服务之间的依赖关系是什么样子的,你已经击败了八成的玩家。而造成这种局面的根本原因就是基础设施的易变。

  • 新增一个服务时:“我找台机器部署一下”
  • 某一个服务出问题时:“我上机器改一下”
  • 需要对某个系统配置变更时:“我搞个脚本跑一跑”

看似常规运维变更,有文档记录或者没有文档记录,每一个环境都是如此的别致和独一无二,再加上人员变动,造就了无数的“祖传秘技”。

什么是不可变的基础设施

容器在被广泛接受的同时,「不可变」也逐渐被潜移默化的接受。

应用容器消亡之后,容器内的修改会随着容器一起不复存在,不要在容器内做修改就是最朴素的不可变理念。在程序启动阶段遇到问题,很少人还会把在容器内修修补补作为正经方案,而会回到最一开始的阶段,从容器构建阶段解决问题。

随之带来的就是大家对容器镜像无尽的信任感,容器突然出现问题?重建试试。换个机器跑不起来?肯定是机器的问题。

容器带来了什么

大家普遍认同 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% 的故障。

思来想去,你依然想做些尝试,稍加思考,锁定痛点有二:
1. 机器按需快速弹缩,同质管理
2. OS 镜像化:快速、安全、不可变

经过调研,你发现事情并不像原来设想的那样深不可测,主流云厂商早就提供了野生工具,你只需要稍加驯服,便可以为自己的牧场服务。

AWS 很早便推出了 AutoScaling,可以按照负载和期望维护 EC2 的数目。而阿里云也有自己的实现(ESS),可以无需人工干预的根据规则对 ECS 进行扩缩容。

你看到了希望,这不就是 Node 的 Deployment 吗?但是只是扩容虚拟机对你来说并没有什么价值,你深知需要的是牛圈,而不是木材,你需要对他们进行驯服。

这时,你转头看到了你的 Kubernetes 集群,灵感蹦出,为何要直面虚拟机呢,只要新扩容出的机器能被纳管到集群中不就解决了基本问题。

说干就干,通过 AutoScaling 定义了启动命令,开机后进行标准化安装和执行 kube join 动作。当机器开机不久,就可以出现在 Kubernetes 集群中。你感觉距离目标进了一步。

很快,你又发现了一个新的问题,传统的 OS 启动和容器实在无法比拟,明明所有的依赖都在容器内部,而且所有的应用都已经在容器内运行,但你还是不得不为 OS 内置的、没人使用的服务买单,这些服务拖慢了启动速度,还引入了安全漏洞。

而且,总是有人意识不到同质化管理的好处,时不时有人上机器做一些不可知的修改,导致你每次想释放虚机时需要去群里喊一喊,避免碰到什么神奇的 Bug。自寻烦恼,你苦笑道。

你打算驯服 OS,对传统的 OS 进行剪裁,除了容器依赖的东西全部清理掉,说不好能大大加快机器的启动速度。还有,最好能在啥地方加个告示,敬告大家不要在机器上做写操作,避免释放机器时文件的丢失。

有天,你发现了 AWS 的 bottlerocket 和阿里云的 ContainerOS,一个针对容器剪裁和优化的操作系统,你不需要亲自动手剪裁了,甚至都不再需要加一个告示,因为他们的 RootFS 都是只读的,连 SSH 都不会默认打开,从根本上杜绝了非标操作。

e6c9d24ely1h3f4c2o4qkj215d0u0gq6.jpg

你尝试了一下,针对容器优化的 OS 启动贼快,点完弹出,一分钟后你就可以把业务调度上去了。把 Node 当做 Pod 管理,你看到了希望。

托管式放牧

但不久,你遇到了一个新的问题,创建机器一时爽,你的老板告诉你,你手里有一批机器存在一个要紧的 CVE 安全漏洞,需要抓紧时间搞一搞,你开始头大了,因为你知道,除了存量的节点,现在只要创建新的机器就有安全漏洞。

你有了一种若隐若现的感觉:你在走向深水区。

从放牧到自动放牧

一番探寻后,你看到了 Google 提出的 AutoPilot,也看到了阿里云 ACK 的托管节点池。节点的扩缩容、节点故障的自恢复、安全加固、OS 的托管,无不触动着你。你意识到应该从根本上解决问题:放手自建的 Kubernetes,全面拥抱托管。

2022-06-19-CleanShot%202022-06-19%20at%2023.53.25%402x.png

拥抱托管后,你豁然开朗,原来事情本应如此简单,多年的摸索仿佛一颗种子,在看到托管节点池后瞬间发芽成果。

从此,世界上又开始流传了新三板斧传统:等等自愈看看?Pod 删下看看?Node 删下看看?朴实无华且有效。

文章最早发布在:当我们谈论不可变基础设施时,我们在谈论什么 - 梦旭随想


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK