前段時間滴滴的故障相信大家都知道了。
中斷業(yè)務(wù) 12 小時定級為 P0 級故障一點都不冤。
故障回顧
網(wǎng)上有傳言是運維人員升級 k8s 時,本來計劃是從 1.12 版本升級到 1.20,但是操作失誤選錯了版本,操作了集群降級到低版本。
從下面滴滴技術(shù)的博客中也可以看到滴滴的升級方案:
滴滴為了降低升級成本,選擇了原地升級的方式。首先升級 master,然后升級 node。我們一起看一下 k8s 官方架構(gòu):
img
master(官網(wǎng)圖中叫 CONTROL PLANE) 節(jié)點由 3 個重要的組件組成:
cloud-controller-manager:負責(zé)容器編排;
kube-api-server:為 Node 節(jié)點提供 api 注冊服務(wù);
scheduler:負責(zé)任務(wù)調(diào)度。
Node 節(jié)點向 kube-api-server 注冊成功后,才可以運行 Pod。從滴滴的博客中可以看到,采用原地升級的方式,升級了 master 之后,逐步升級 Node,Node 會有一個重新注冊的過程,不過既然選擇這個方案,運維人員應(yīng)該反復(fù)演練過,重新注冊耗時應(yīng)該非常短,用戶無感知。
但是 master 選錯版本發(fā)生降級時,會把 kube-api-server 污染,Node 節(jié)點注冊 master 失敗,又不能快速回滾,這樣 Node 節(jié)點被集群認為是非健康節(jié)點,上面的 pod 被 kill 掉,服務(wù)停止。
集群隔離
這次故障大家討論的話題還有一個比較熱門的就是 k8s 集群隔離,因為多個業(yè)務(wù)比如打車業(yè)務(wù)、單車業(yè)務(wù)同時掛,說明都在一個集群上,沒有單獨建集群來做隔離,這可能也是博客中說的“最大集群規(guī)模已經(jīng)遠遠超出了社區(qū)推薦的5千個 node 上限”的原因。
當(dāng)然也有可能當(dāng)時野蠻生長的時候,為了快速上線開展業(yè)務(wù),就多個業(yè)務(wù)建在了一個集群上,后來可能也有過拆分的想法,但發(fā)現(xiàn)業(yè)務(wù)上升空間已經(jīng)很小,現(xiàn)有集群可以維持,所以就擱置了。
拆分成多個集群好處很明顯,業(yè)務(wù)隔離,故障隔離,可靠性增加,就拿這次升級來說,先升級一個不太關(guān)鍵、業(yè)務(wù)量也比較小的集群做試點,升級成功了再逐個升級其他集群。
但缺點也很明顯,運維復(fù)雜度增加,成本增加。
升級方案
工作這些年,也參與過一些大規(guī)模的平臺重構(gòu),但原地升級真的是沒有接觸過,主要原因就是架構(gòu)師們不太愿意選擇原地升級的方案。而他們主要出于下面考慮:
業(yè)務(wù)系統(tǒng)原地重構(gòu)升級,不像推翻重做能夠更徹底地升級改造;
考慮對業(yè)務(wù)影響最小,一般是要通過灰度發(fā)布漸進地把流量切過去;
替換升級的方案,更能展現(xiàn)團隊的產(chǎn)出。
對于滴滴這樣的大公司,相信運維團隊大咖如云,無論采用哪種方案,肯定都是經(jīng)過反復(fù)驗證的,或許不要選錯版本,原地升級也沒有問題。
降本增效
看了微博上滴滴道歉的留言區(qū),好多人猜測這次事故的原因是降本增效,裁掉了一線高成本的運維,保留了成本低的新人。
從數(shù)據(jù)上來看,出于降本增效的目的,滴滴這兩年確實少了很多人,但我不相信這是造成事故的直接原因。
在快速增長的階段,確實需要投入大量的技術(shù)人員來建設(shè)系統(tǒng)。但國內(nèi)互聯(lián)網(wǎng)規(guī)模也基本見頂了,一個業(yè)務(wù)經(jīng)營這么多年,不會再有爆發(fā)式地增長,系統(tǒng)也已經(jīng)非常穩(wěn)定。這樣的背景下,公司確實用不了這么多技術(shù)人員了,留下部分人員來維護就夠了。
所以,無論哪家公司,降本增效是業(yè)務(wù)穩(wěn)定后必定會經(jīng)歷的階段。想想滴滴這次 12 小時故障的損失,能比養(yǎng) 1000 個技術(shù)人員的成本高嗎?
對于我們研發(fā)人員,如果有機會進入快速增長的公司,那就抓住機會多掙錢,被裁員的時候平常心看待就可以了,想在一家公司干到退休太難了。同時也要看到自己給公司帶來的價值,千萬不要認為我們技術(shù)厲害就比那個 PPT 工程師更有價值。
總結(jié)
本文根據(jù)網(wǎng)上流傳的滴滴故障的原因,分析了升級方案和降本增效。
最后,又快年末了,希望大家都能維護好自己的系統(tǒng),不要發(fā)生嚴重故障影響自己的年底考核。
-
節(jié)點
+關(guān)注
關(guān)注
0文章
222瀏覽量
24964 -
MASTER
+關(guān)注
關(guān)注
0文章
109瀏覽量
11734 -
滴滴
+關(guān)注
關(guān)注
1文章
194瀏覽量
13432
原文標(biāo)題:一次 k8s 升級,滴滴直接故障 12 小時?
文章出處:【微信號:小林coding,微信公眾號:小林coding】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
什么是 K8S,如何使用 K8S
全面提升,阿里云Docker/Kubernetes(K8S) 日志解決方案與選型對比
OpenStack與K8s結(jié)合的兩種方案的詳細介紹和比較
如何使用kubernetes client-go實踐一個簡單的與K8s交互過程

Docker不香嗎為什么還要用K8s
簡單說明k8s和Docker之間的關(guān)系
K8S集群服務(wù)訪問失敗怎么辦 K8S故障處理集錦

mysql部署在k8s上的實現(xiàn)方案
k8s是什么意思?kubeadm部署k8s集群(k8s部署)|PetaExpres
什么是K3s和K8s?K3s和K8s有什么區(qū)別?
k8s生態(tài)鏈包含哪些技術(shù)

k8s云原生開發(fā)要求

評論