用上Kubernetes后,我們非常興奮,團(tuán)隊(duì)的運(yùn)作速度也變得如此之快,以至于沒(méi)有注意到新的分歧正在悄然出現(xiàn)。
K8s激增,但也帶來(lái)了分歧
Kubernetes 已經(jīng)存在近 10 年了。在過(guò)去五年中,我們看到各種規(guī)模的工程團(tuán)隊(duì)的采用率急劇增加。從靜態(tài)網(wǎng)站到成熟的微服務(wù)解決方案,部署標(biāo)準(zhǔn)化和跨類(lèi)型的應(yīng)用程序擴(kuò)展的承諾推動(dòng)了這種爆發(fā)式的增長(zhǎng)。
Kubernetes 目前正處于“炒作周期”階段。對(duì)于工程師來(lái)說(shuō),建議 Kubernetes 作為他們選擇的平臺(tái)是更容易接受的,無(wú)論他們使用的是云還是本地基礎(chǔ)設(shè)施。我們已經(jīng)看到實(shí)體零售店部署單節(jié)點(diǎn) Kubernetes 集群來(lái)管理其收銀系統(tǒng),我們還看到電子商務(wù)網(wǎng)站在數(shù)百個(gè)數(shù)據(jù)中心部署數(shù)千個(gè)節(jié)點(diǎn)來(lái)管理正常運(yùn)行時(shí)間。
毫無(wú)疑問(wèn),Kubernetes 勢(shì)不可擋,但這股熱潮消退之時(shí),我們也會(huì)發(fā)現(xiàn):Kubernetes留給我們的,即便不是一地雞毛,也是分歧良多。
有些事情是標(biāo)準(zhǔn)化不了的
人們?cè)谛麄?Kubernetes,往往避不開(kāi)這個(gè)話(huà)題:標(biāo)準(zhǔn)化。這個(gè)想法是,你運(yùn)行的所有內(nèi)容都可以容器化,使每個(gè)服務(wù)都具有標(biāo)準(zhǔn)形狀,并具有標(biāo)準(zhǔn)連接器。
的確,Kubernetes 以標(biāo)準(zhǔn)化的方式解決了大規(guī)模部署軟件的問(wèn)題。但問(wèn)題在于:它沒(méi)有解決如何知道該軟件是否正在做它應(yīng)該做的事情。我們根本無(wú)法標(biāo)準(zhǔn)化了解某件事是否正在做該做的事情,因?yàn)椴煌膽?yīng)用程序解決不同的問(wèn)題。
K8s破壞了DevOps
我是一名應(yīng)用工程師,而且,我是一名完全擁抱 DevOps 運(yùn)動(dòng)的應(yīng)用工程師。我稱(chēng)其為一場(chǎng)運(yùn)動(dòng),因?yàn)檫@對(duì)我來(lái)說(shuō)就是如此。這不是一個(gè)新角色或新職責(zé),也不是關(guān)于 CI/CD 管道或 IaC。對(duì)我來(lái)說(shuō),DevOps 就是與專(zhuān)家更密切地合作,他們?yōu)槲揖帉?xiě)的代碼提供了超越本地計(jì)算機(jī)的生命力,并與他們合作以確保我的應(yīng)用程序以最佳狀態(tài)運(yùn)行并快速到達(dá)用戶(hù)手中。
這對(duì)我來(lái)說(shuō)非常好,因?yàn)槲议_(kāi)始了解他們面臨的挑戰(zhàn),而且他們也開(kāi)始看到我所面臨的限制并可以提供解決方案。我們一起創(chuàng)建了用戶(hù)想要的應(yīng)用程序。
使用 Kubernetes,開(kāi)發(fā)團(tuán)隊(duì)的運(yùn)行速度如此之快,以至于他們沒(méi)有注意到新的分歧正在悄然出現(xiàn),當(dāng)然這一次換了一個(gè)新名字:平臺(tái)工程。現(xiàn)在,我們有 Kubernetes 管理員可以創(chuàng)建我們的集群,但他們對(duì)集群上運(yùn)行的內(nèi)容一無(wú)所知,因?yàn)槲覀円呀?jīng)標(biāo)準(zhǔn)化了容器周?chē)乃袃?nèi)容。
有人可能認(rèn)為這很棒,因?yàn)楝F(xiàn)在應(yīng)用程序(容器)和基礎(chǔ)設(shè)施(集群)之間的界限更加清晰。但對(duì)此,我不同意。因?yàn)樵谖铱磥?lái),工程師必須考慮部署、服務(wù)、sidecar、服務(wù)網(wǎng)格、節(jié)點(diǎn)、節(jié)點(diǎn)關(guān)聯(lián)性——這樣的例子不勝枚舉。
你可以說(shuō),“但這不是他們應(yīng)該擔(dān)心的,這是平臺(tái)的工作!” 但這恰恰證明上文我提到的觀點(diǎn):現(xiàn)在存在分歧。我們推動(dòng)基礎(chǔ)設(shè)施和應(yīng)用工程師一起工作,深入了解彼此的世界并了解每個(gè)部分,以便我們可以向彼此提出明智的問(wèn)題?,F(xiàn)在我們說(shuō),“把它留給別人吧;” 他們知道自己在做什么”,這就是我們 10 年前的情況。當(dāng)出現(xiàn)問(wèn)題時(shí),孤立的團(tuán)隊(duì)會(huì)互相指責(zé)。應(yīng)用工程師現(xiàn)在可以說(shuō):“它在我的機(jī)器上運(yùn)行,但在生產(chǎn)中停止運(yùn)行,因此平臺(tái)的工作就是修復(fù)它”,平臺(tái)工程師可以指著他們的儀表板說(shuō)一切正常。
不要誤會(huì)我的意思。在這些團(tuán)隊(duì)之間進(jìn)行良好的對(duì)話(huà),并意識(shí)到溝通和接受他們需要不同的工具來(lái)完成各自的任務(wù),才能讓項(xiàng)目能夠執(zhí)行下去。平臺(tái)工程師管理從自動(dòng)擴(kuò)展到網(wǎng)絡(luò)路由的所有事務(wù),應(yīng)用工程師負(fù)責(zé)產(chǎn)品功能并確??蛻?hù)獲得最佳體驗(yàn)。
然而,我們看到的是,遷移到 Kubernetes 被視為結(jié)束。但第二天呢?一旦一切都在那里運(yùn)行,我們就沒(méi)有其他事可做了,對(duì)嗎?我們不需要每年升級(jí) Kubernetes,不是嗎?
K8s來(lái)了,監(jiān)控工具也失靈了!
隨著轉(zhuǎn)向 Kubernetes,以及我們用來(lái)托管應(yīng)用程序的基礎(chǔ)設(shè)施(例如 Pod)的短暫性,我們用于監(jiān)控和調(diào)試應(yīng)用程序的方法失敗了。我們正在采用在基礎(chǔ)設(shè)施級(jí)別使用的方法,并將其應(yīng)用于應(yīng)用程序調(diào)試技術(shù),因?yàn)楝F(xiàn)在一切都是標(biāo)準(zhǔn)化的,所以一切都是基礎(chǔ)設(shè)施。這嚴(yán)重影響了在 Kubernetes 中構(gòu)建的應(yīng)用程序開(kāi)發(fā)人員,以及希望為他們提供更多系統(tǒng)上下文的平臺(tái)工程師的服務(wù)。
K8s在支持現(xiàn)代應(yīng)用程序開(kāi)發(fā)時(shí),維護(hù)的方法同樣需要進(jìn)化。Kubernetes 并沒(méi)有讓我們的應(yīng)用程序更易于觀察,只是讓它們更容易部署和迭代。這并不是一件壞事。
輕松更新應(yīng)用程序、促進(jìn)更多部署、進(jìn)行紅/綠部署和金絲雀的能力——這些都是偉大的事情,將提高應(yīng)用程序工程師支持其應(yīng)用程序的能力。它并沒(méi)有讓?xiě)?yīng)用程序開(kāi)發(fā)人員更輕松地調(diào)試他們的應(yīng)用程序。最好的情況是,在 Kubernetes 成為首選部署系統(tǒng)之前,我們就處于這樣的狀態(tài)。最壞的情況是,我們引入了更多現(xiàn)在需要調(diào)查的故障點(diǎn)。
當(dāng)我們處理的服務(wù)器數(shù)量固定時(shí),我們會(huì)將每臺(tái)服務(wù)器添加為應(yīng)用程序指標(biāo)中的一個(gè)維度。然后我們添加應(yīng)用程序的版本號(hào)。從那里,我們可以深入了解哪個(gè)版本/哪個(gè)服務(wù)器有問(wèn)題——或者是否所有服務(wù)器都有問(wèn)題。服務(wù)器名稱(chēng)和應(yīng)用程序版本的組合是低基數(shù)數(shù)據(jù),非常適合時(shí)間序列聚合數(shù)據(jù)庫(kù)。不過(guò),我們現(xiàn)在所處的情況是 Pod 可以隨時(shí)重新安排,從而導(dǎo)致可能使用新節(jié)點(diǎn)。對(duì)于每次部署,我們都有一個(gè)新的 Pod 名稱(chēng),大多數(shù)時(shí)候,這都是高基數(shù)數(shù)據(jù),傳統(tǒng)的基于指標(biāo)的系統(tǒng)很難處理。
平臺(tái)、應(yīng)用團(tuán)隊(duì)各自孤立,上下文缺失
正如我所說(shuō),用戶(hù)并不關(guān)心您的基礎(chǔ)設(shè)施。Pod只是Kubernetes中最小的資源管理組件,他們根本不關(guān)心 Pod 上的 CPU、網(wǎng)絡(luò)帶寬或者是否使用服務(wù)網(wǎng)格。他們不在乎每項(xiàng)服務(wù)是 1 個(gè)還是 10 個(gè)。他們只關(guān)心你的整個(gè)系統(tǒng)是否響應(yīng)他們的請(qǐng)求。
我們所處的情況是,除非代碼中有異常、HTTP 錯(cuò)誤或其他類(lèi)型的錯(cuò)誤,否則很可能會(huì)將其作為基礎(chǔ)設(shè)施問(wèn)題推送給平臺(tái)團(tuán)隊(duì)。任何與延遲相關(guān)的事情——或者對(duì)應(yīng)用工程師來(lái)說(shuō)沒(méi)有意義的響應(yīng)——都會(huì)被推給平臺(tái)團(tuán)隊(duì)進(jìn)行調(diào)查。此時(shí),平臺(tái)團(tuán)隊(duì)對(duì)應(yīng)用程序的信息很少,只能根據(jù)粗粒度指標(biāo)調(diào)查基礎(chǔ)設(shè)施問(wèn)題。再說(shuō)一遍,我們處于孤立的團(tuán)隊(duì)中,彼此之間不交談。
然而現(xiàn)實(shí)情況是,問(wèn)題可能是 Pod,但也可能是代碼。在此階段,我們需要能夠了解問(wèn)題是否局限于單個(gè)基礎(chǔ)設(shè)施組件(例如 Pod 或節(jié)點(diǎn)),或者是否影響到所有內(nèi)容。這就是考慮高基數(shù)數(shù)據(jù)(例如 Pod 名稱(chēng))對(duì)于應(yīng)用程序遙測(cè)變得至關(guān)重要的地方。
這就是為什么需要彌合這一差距的原因。平臺(tái)和應(yīng)用工程師需要齊心協(xié)力。他們需要有關(guān)應(yīng)用程序和基礎(chǔ)設(shè)施的上下文、深層上下文數(shù)據(jù)。他們需要將以客戶(hù)為中心的數(shù)據(jù)(例如由應(yīng)用程序工程師定制的跟蹤,以提供特定于其應(yīng)用程序的上下文)與以基礎(chǔ)設(shè)施為中心的數(shù)據(jù)(例如由平臺(tái)團(tuán)隊(duì)管理的 Kubernetes 指標(biāo))相關(guān)聯(lián),以充分了解客戶(hù)不滿(mǎn)意的原因。
寫(xiě)在最后:K8s不是靈丹妙藥
當(dāng)企業(yè)完成向 Kubernetes 的遷移并進(jìn)入運(yùn)營(yíng)模式時(shí),他們需要當(dāng)心:要避免孤立作戰(zhàn)的方法。平臺(tái)工程涉及應(yīng)用工程師的支持以及他們?nèi)绾喂餐瑸榭蛻?hù)提供最佳服務(wù)。要提供流程、工具和文化,以便這些團(tuán)隊(duì)能夠一起工作至關(guān)重要。它將確保不存在“我們和他們”的心態(tài),從而導(dǎo)致糟糕的整體客戶(hù)體驗(yàn)。
這是通過(guò)協(xié)作而不是控制來(lái)完成的。請(qǐng)記?。喝绻硞€(gè)工具,必須通過(guò)命令使用,而不是人們自發(fā)想要使用它,則該工具可能存在問(wèn)題。
要建立這些無(wú)縫協(xié)作的高績(jī)效團(tuán)隊(duì),你需要使用通用技術(shù)語(yǔ)言充當(dāng)橋梁。使用 OpenTelemetry 等工具可以通過(guò)跟蹤(以開(kāi)發(fā)人員、以客戶(hù)為中心)和指標(biāo)(以平臺(tái)基礎(chǔ)設(shè)施為中心)提供聯(lián)合思維,這將有所幫助。
平臺(tái)工程團(tuán)隊(duì)和應(yīng)用程序/產(chǎn)品工程團(tuán)隊(duì)一起才能提供最佳的客戶(hù)體驗(yàn),但這些關(guān)系是需要培養(yǎng)的,當(dāng)然這不是免費(fèi)的。
簡(jiǎn)而言之,Kubernetes 并不是讓軟件獲得獲更好性能的靈丹妙藥,幾個(gè)團(tuán)隊(duì)一起協(xié)作才是至關(guān)重要的。
編輯:黃飛
-
cpu
+關(guān)注
關(guān)注
68文章
11187瀏覽量
221288 -
服務(wù)器
+關(guān)注
關(guān)注
13文章
10000瀏覽量
90123 -
代碼
+關(guān)注
關(guān)注
30文章
4922瀏覽量
72235 -
devops
+關(guān)注
關(guān)注
0文章
130瀏覽量
12672 -
kubernetes
+關(guān)注
關(guān)注
0文章
254瀏覽量
9332
原文標(biāo)題:K8s留給我們一地雞毛!
文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
什么是 K8S,如何使用 K8S
請(qǐng)問(wèn)并聯(lián)均流有何優(yōu)缺點(diǎn)?
OpenStack與K8s結(jié)合的兩種方案的詳細(xì)介紹和比較
Docker不香嗎為什么還要用K8s
簡(jiǎn)單說(shuō)明k8s和Docker之間的關(guān)系
K8S集群服務(wù)訪(fǎng)問(wèn)失敗怎么辦 K8S故障處理集錦

切換k8s上下文有多快

k8s是什么意思?kubeadm部署k8s集群(k8s部署)|PetaExpres
什么是K3s和K8s?K3s和K8s有什么區(qū)別?
k8s生態(tài)鏈包含哪些技術(shù)

常用的k8s容器網(wǎng)絡(luò)模式有哪些?
k8s云原生開(kāi)發(fā)要求

評(píng)論