青岛哪里有做网站的,wordpress无法超链接,广州个性化网站建设,lnmp wordpress午夜时分#xff0c;电话响起#xff0c;线上告急。你从千呼万钉中醒来#xff0c;睡眼朦胧#xff0c;手忙脚乱。
恍惚之间#xff0c;终于梳理清楚发生了什么#xff0c;一个陈年老应用突然停机#xff0c;消息堆积#xff0c;系统停摆。而你就像一个下水道小工疏通…
午夜时分电话响起线上告急。你从千呼万钉中醒来睡眼朦胧手忙脚乱。
恍惚之间终于梳理清楚发生了什么一个陈年老应用突然停机消息堆积系统停摆。而你就像一个下水道小工疏通马桶一般大力出奇迹重启机器恢复服务。只见消息队列中的堆积事件一泻千里警告消除。
次日你再也不想重现午夜凶铃决定对系统进行永久性修复加一个定时重启服务的脚本。
斗转星移许多时日过去了你也在不同的角落加了无数的脚本也好久没有半夜惊醒甚至还能悠闲享受下午茶。但是直到今天。
今天你们部门要降本增效为了避免自己成为被砍掉的成本你决定主动对线上的机器开刀合并服务裁撤机器。虽然你对机器上都部署了什么应用了然于胸但是你已经不记得都有哪些脚手架支撑着应用的运转。
重建环境难如登天你又开始难眠了。
变化的基础设施
复杂、神秘而神奇的线上环境承载了半部都市传说甚至有些公司的线上环境本身就是一本需要口耳相传的上古神话。
我虽然没有看过沙漠下暴雨但是看过没人说的清楚上面有什么的环境。我虽然没有看过大海亲吻鲨鱼但是我看过重启再也起不来的机器。
如果你能说清楚任何一台机器上都部署了什么应用以及机器上服务之间的依赖关系是什么样子的你已经击败了八成的玩家。而造成这种局面的根本原因就是基础设施的易变。
新增一个服务时“我找台机器部署一下”某一个服务出问题时“我上机器改一下”需要对某个系统配置变更时“我搞个脚本跑一跑”
看似常规运维变更有文档记录或者没有文档记录每一个环境都是如此的别致和独一无二再加上人员变动造就了无数的“祖传秘技”。
什么是不可变的基础设施
容器在被广泛接受的同时「不可变」也逐渐被潜移默化的接受。
应用容器消亡之后容器内的修改会随着容器一起不复存在不要在容器内做修改就是最朴素的不可变理念。在程序启动阶段遇到问题很少人还会把在容器内修修补补作为正经方案而会回到最一开始的阶段从容器构建阶段解决问题。 随之带来的就是大家对容器镜像无尽的信任感容器突然出现问题重建试试。换个机器跑不起来肯定是机器的问题。
容器带来了什么
大家普遍认同 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 删下看看朴实无华且有效。
作者陈海波漂石
原文链接
本文为阿里云原创内容未经允许不得转载。
