国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專(zhuān)欄INFORMATION COLUMN

為什么 kubernetes 天然適合微服務(wù) (1)

EastWoodYang / 744人閱讀

摘要:此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。所以當(dāng)我們?cè)u(píng)估大數(shù)據(jù)平臺(tái)牛不牛的時(shí)候,往往以單位時(shí)間內(nèi)跑的任務(wù)數(shù)目以及能夠處理的數(shù)據(jù)量來(lái)衡量。的問(wèn)題調(diào)度在大數(shù)據(jù)領(lǐng)域是核心中的核心,在容器平臺(tái)中是重要的,但不是全部。

此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問(wèn)網(wǎng)易云社區(qū),了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)

最近總在思考,為什么在支撐容器平臺(tái)和微服務(wù)的競(jìng)爭(zhēng)中,Kubernetes 會(huì)取得最終的勝出,事實(shí)上從很多角度出發(fā)三大容器平臺(tái)從功能方面來(lái)看,最后簡(jiǎn)直是一摸一樣。

參考

Docker, Kubernetes, DCOS 不談信仰談技術(shù)

容器平臺(tái)選型的十大模式:Docker、DC/OS、K8S誰(shuí)與當(dāng)先?

經(jīng)過(guò)一段時(shí)間的思索,以及采訪了從早期就開(kāi)始實(shí)踐 Kubernetes 的網(wǎng)易云架構(gòu)師們后,我把反思所得總結(jié)為今天的這篇文章。

一、從企業(yè)上云的三大架構(gòu)看容器平臺(tái)的三種視角

一切都從企業(yè)上云的三大架構(gòu)開(kāi)始看起

如圖所示,企業(yè)上云的三大架構(gòu)為 IT 架構(gòu)、應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu),在不同的公司,不同的人、不同的角色,關(guān)注的重點(diǎn)不同。

對(duì)大部分的企業(yè)來(lái)講,上云的訴求是從 IT 部門(mén)發(fā)起的,發(fā)起人往往是運(yùn)維部門(mén),他們關(guān)注計(jì)算、網(wǎng)絡(luò)、存儲(chǔ),試圖通過(guò)云計(jì)算服務(wù)來(lái)減輕 CAPEX 和 OPEX。

有的公司有 ToC 的業(yè)務(wù),因而累積了大量的用戶數(shù)據(jù),公司的運(yùn)營(yíng)需要通過(guò)這部分?jǐn)?shù)據(jù)進(jìn)行大數(shù)據(jù)分析和數(shù)字化運(yùn)營(yíng),因而在這些企業(yè)里面往往還需要關(guān)注數(shù)據(jù)架構(gòu)。

從事互聯(lián)網(wǎng)應(yīng)用的企業(yè),往往首先關(guān)注的是應(yīng)用架構(gòu),是否能夠滿足終端客戶的需求,帶給客戶良好的用戶體驗(yàn)。業(yè)務(wù)量上往往會(huì)有短期內(nèi)出現(xiàn)爆炸式增長(zhǎng)的現(xiàn)象,因而關(guān)注高并發(fā)應(yīng)用架構(gòu),并希望這個(gè)架構(gòu)可以快速迭代,從而搶占風(fēng)口。

在容器出現(xiàn)之前,這三種架構(gòu)往往通過(guò)虛擬機(jī)云平臺(tái)的方式解決。當(dāng)容器出現(xiàn)之后,容器的各種良好的特性讓人眼前一亮,它的輕量級(jí)、封裝、標(biāo)準(zhǔn)、易遷移、易交付的特性,使得容器技術(shù)迅速被廣泛使用。

然而一千個(gè)人心中有一千個(gè)哈姆雷特,由于原來(lái)工作的關(guān)系,三類(lèi)角色分別從自身的角度看到了容器的優(yōu)勢(shì)給自己帶來(lái)的便捷。

對(duì)于原來(lái)在機(jī)房里管計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)的 IT 運(yùn)維工程師來(lái)講,容器更像是一種輕量級(jí)的運(yùn)維模式,在他們看來(lái),容器和虛擬機(jī)的最大的區(qū)別就是輕量級(jí),啟動(dòng)速度快,他們往往更愿意推出虛擬機(jī)模式的容器。

對(duì)于數(shù)據(jù)架構(gòu)來(lái)講,他們每天都在執(zhí)行各種各樣的數(shù)據(jù)計(jì)算任務(wù),容器相對(duì)于原來(lái)的 JVM,是一種隔離性較好,資源利用率高的任務(wù)執(zhí)行模式。

從應(yīng)用架構(gòu)的角度出發(fā),容器是微服務(wù)的交付形式,容器不僅僅是做部署的,而且是做交付的,CI/CD 中的 D 的。

所以這三種視角的人,在使用容器和選擇容器平臺(tái)時(shí)方法會(huì)不一樣。

二、Kubernetes 才是微服務(wù)和 DevOps 的橋梁

Swarm:IT 運(yùn)維工程師

從 IT 運(yùn)維工程師的角度來(lái)看:容器主要是輕量級(jí)、啟動(dòng)快,并且自動(dòng)重啟,自動(dòng)關(guān)聯(lián),彈性伸縮的技術(shù),使得 IT 運(yùn)維工程師似乎不用再加班。

Swarm 的設(shè)計(jì)顯然更加符合傳統(tǒng) IT 工程師的管理模式。

他們希望能夠清晰地看到容器在不同機(jī)器的分布和狀態(tài),可以根據(jù)需要很方便地 SSH 到一個(gè)容器里面去查看情況。

容器最好能夠原地重啟,而非隨機(jī)調(diào)度一個(gè)新的容器,這樣原來(lái)在容器里面安裝的一切都是有的。

可以很方便地將某個(gè)運(yùn)行的容器打一個(gè)鏡像,而非從 Dockerfile 開(kāi)始,這樣以后啟動(dòng)就可以復(fù)用在這個(gè)容器里面手動(dòng)做的 100 項(xiàng)工作。

容器平臺(tái)的集成性要好,用這個(gè)平臺(tái)本來(lái)是為了簡(jiǎn)化運(yùn)維的,如果容器平臺(tái)本身就很復(fù)雜,像 Kubernetes 這種本身就這么多進(jìn)程,還需要考慮它的高可用和運(yùn)維成本,這個(gè)不劃算,一點(diǎn)都沒(méi)有比原來(lái)省事,而且成本還提高了。

最好薄薄的一層,像一個(gè)云管理平臺(tái)一樣,只不過(guò)更加方便做跨云管理,畢竟容器鏡像很容易跨云遷移。

Swarm 的使用方式比較讓 IT 工程師有熟悉的味道,其實(shí) OpenStack 所做的事情它都能做,速度還快。

Swarm 的問(wèn)題

然而容器作為輕量級(jí)虛擬機(jī),暴露出去給客戶使用,無(wú)論是外部客戶,還是公司內(nèi)的開(kāi)發(fā),而非 IT 人員自己使用的時(shí)候,他們以為和虛擬機(jī)一樣,但是發(fā)現(xiàn)了不一樣的部分,就會(huì)有很多的抱怨。

例如自修復(fù)功能,重啟之后,原來(lái) SSH 進(jìn)去手動(dòng)安裝的軟件不見(jiàn)了,甚至放在硬盤(pán)上的文件也不見(jiàn)了,而且應(yīng)用沒(méi)有放在 Entrypoint 里面自動(dòng)啟動(dòng),自修復(fù)之后進(jìn)程沒(méi)有跑起來(lái),還需要手動(dòng)進(jìn)去啟動(dòng)進(jìn)程,客戶會(huì)抱怨你這個(gè)自修復(fù)功能有啥用?

例如有的用戶會(huì) ps 一下,發(fā)現(xiàn)有個(gè)進(jìn)程他不認(rèn)識(shí),于是直接 kill 掉了,結(jié)果是 Entrypoint 的進(jìn)程,整個(gè)容器直接就掛了,客戶抱怨你們的容器太不穩(wěn)定,老是掛。

容器自動(dòng)調(diào)度的時(shí)候,IP 是不保持的,所以往往重啟后原來(lái)的 IP 就沒(méi)了,很多用戶會(huì)提需求,這個(gè)能不能保持啊,原來(lái)配置文件里面都配置的這個(gè) IP ,掛了重啟就變了,這個(gè)怎么用啊,還不如用虛擬機(jī),至少?zèng)]那么容易掛。

容器的系統(tǒng)盤(pán),也即操作系統(tǒng)的那個(gè)盤(pán)往往大小是固定的,雖然前期可以配置,后期很難改變,而且沒(méi)辦法每個(gè)用戶可以選擇系統(tǒng)盤(pán)的大小。有的用戶會(huì)抱怨,我們?cè)瓉?lái)本來(lái)就很多東西直接放在系統(tǒng)盤(pán)的,這個(gè)都不能調(diào)整,叫什么云計(jì)算的彈性啊。

如果給客戶說(shuō)容器掛載數(shù)據(jù)盤(pán),容器都啟動(dòng)起來(lái)了,有的客戶想像云主機(jī)一樣,再掛載一個(gè)盤(pán),容器比較難做到,也會(huì)被客戶罵。

如果容器的使用者不知道他們?cè)谟萌萜鳎?dāng)虛擬機(jī)來(lái)用,他們會(huì)覺(jué)得很難用,這個(gè)平臺(tái)一點(diǎn)都不好。

Swarm 上手雖然相對(duì)比較容易,但是當(dāng)出現(xiàn)問(wèn)題的時(shí)候,作為運(yùn)維容器平臺(tái)的人,會(huì)發(fā)現(xiàn)問(wèn)題比較難解決。

Swarm 內(nèi)置的功能太多,都耦合在了一起,一旦出現(xiàn)錯(cuò)誤,不容易 debug。如果當(dāng)前的功能不能滿足需求,很難定制化。很多功能都是耦合在 Manager 里面的,對(duì) Manager 的操作和重啟影響面太大。

Mesos:數(shù)據(jù)運(yùn)維工程師

從大數(shù)據(jù)平臺(tái)運(yùn)維的角度來(lái)講,如何更快地調(diào)度大數(shù)據(jù)處理任務(wù),在有限的時(shí)間和空間里面,更快地跑更多的任務(wù),是一個(gè)非常重要的要素。

所以當(dāng)我們?cè)u(píng)估大數(shù)據(jù)平臺(tái)牛不牛的時(shí)候,往往以單位時(shí)間內(nèi)跑的任務(wù)數(shù)目以及能夠處理的數(shù)據(jù)量來(lái)衡量。

從數(shù)據(jù)運(yùn)維的角度來(lái)講,Mesos 是一個(gè)很好的調(diào)度器。既然能夠跑任務(wù),也就能夠跑容器,Spark 和 Mesos 天然的集成,有了容器之后,可以用更加細(xì)粒度的任務(wù)執(zhí)行方式。

在沒(méi)有細(xì)粒度的任務(wù)調(diào)度之前,任務(wù)的執(zhí)行過(guò)程是這樣的。任務(wù)的執(zhí)行需要 Master 的節(jié)點(diǎn)來(lái)管理整個(gè)任務(wù)的執(zhí)行過(guò)程,需要 Worker 節(jié)點(diǎn)來(lái)執(zhí)行一個(gè)個(gè)子任務(wù)。在整個(gè)總?cè)蝿?wù)的一開(kāi)始,就分配好 Master 和所有的 Work 所占用的資源,將環(huán)境配置好,等在那里執(zhí)行子任務(wù),沒(méi)有子任務(wù)執(zhí)行的時(shí)候,這個(gè)環(huán)境的資源都是預(yù)留在那里的,顯然不是每個(gè) Work 總是全部跑滿的,存在很多的資源浪費(fèi)。

在細(xì)粒度的模式下,在整個(gè)總?cè)蝿?wù)開(kāi)始的時(shí)候,只會(huì)為 Master 分配好資源,不給 Worker 分配任何的資源,當(dāng)需要執(zhí)行一個(gè)子任務(wù)的時(shí)候,Master 才臨時(shí)向 Mesos 申請(qǐng)資源,環(huán)境沒(méi)有準(zhǔn)備好怎么辦?好在有 Docker,啟動(dòng)一個(gè) Docker,環(huán)境就都有了,在里面跑子任務(wù)。在沒(méi)有任務(wù)的時(shí)候,所有節(jié)點(diǎn)上的資源都是可被其他任務(wù)使用的,大大提升了資源利用效率。

這就是 Mesos 最大的優(yōu)勢(shì),在 Mesos 的論文中,最重要闡述的就是資源利用率的提升,而 Mesos 的雙層調(diào)度算法是核心。

號(hào)稱了解mesos雙層調(diào)度的你,先來(lái)回答下面這五個(gè)問(wèn)題!

原來(lái)大數(shù)據(jù)運(yùn)維工程師出身的,會(huì)比較容易選擇 Mesos 作為容器管理平臺(tái)。不過(guò)原來(lái)是跑短任務(wù),加上 marathon 就能跑長(zhǎng)任務(wù)。但是后來(lái) Spark 將細(xì)粒度的模式 deprecated 掉了,因?yàn)樾蔬€是比較差。

Mesos 的問(wèn)題

調(diào)度在大數(shù)據(jù)領(lǐng)域是核心中的核心,在容器平臺(tái)中是重要的,但不是全部。所以容器還需要編排,需要各種外圍組件,讓容器跑起來(lái)運(yùn)行長(zhǎng)任務(wù),并且相互訪問(wèn)。Marathon 只是萬(wàn)里長(zhǎng)征的第一步。

所以早期用 Marathon + Mesos 的廠商,多是裸用 Marathon 和 Mesos 的,由于周邊不全,因而要做各種的封裝,各家不同。大家有興趣可以到社區(qū)上去看裸用 Marathon 和 Mesos 的廠商,各有各的負(fù)載均衡方案,各有各的服務(wù)發(fā)現(xiàn)方案。

所以后來(lái)有了 DCOS,也就是在 Marathon 和 Mesos 之外,加了大量的周邊組件,補(bǔ)充一個(gè)容器平臺(tái)應(yīng)有的功能,但是很可惜,很多廠商都自己定制過(guò)了,還是裸用 Marathon 和 Mesos 的比較多。

而且 Mesos 雖然調(diào)度牛,但是只解決一部分調(diào)度,另一部分靠用戶自己寫(xiě) framework 以及里面的調(diào)度,有時(shí)候還需要開(kāi)發(fā) Executor,這個(gè)開(kāi)發(fā)起來(lái)還是很復(fù)雜的,學(xué)習(xí)成本也比較高。

雖說(shuō)后來(lái)的 DCOS 功能也比較全了,但是感覺(jué)沒(méi)有如 Kubernetes 一樣使用統(tǒng)一的語(yǔ)言,而是采取大雜燴的方式。在 DCOS 的整個(gè)生態(tài)中,Marathon 是 Scala 寫(xiě)的,Mesos 是 C++ 寫(xiě)的,Admin Router 是 Nginx+lua,Mesos-DNS 是Go,Marathon-lb 是 Python,Minuteman 是 Erlang,這樣太復(fù)雜了吧,林林總總,出現(xiàn)了 Bug 的話,比較難自己修復(fù)。

Kubernetes

而 Kubernetes 不同,初看 Kubernetes 的人覺(jué)得他是個(gè)奇葩所在,容器還沒(méi)創(chuàng)建出來(lái),概念先來(lái)一大堆,文檔先讀一大把,編排文件也復(fù)雜,組件也多,讓很多人望而卻步。我就想創(chuàng)建一個(gè)容器,怎么這么多的前置條件。如果你將 Kubernetes 的概念放在界面上,讓客戶去創(chuàng)建容器,一定會(huì)被客戶罵。

在開(kāi)發(fā)人員角度,使用 Kubernetes 絕對(duì)不是像使用虛擬機(jī)一樣,開(kāi)發(fā)除了寫(xiě)代碼,做構(gòu)建,做測(cè)試,還需要知道自己的應(yīng)用是跑在容器上的,而不是當(dāng)甩手掌柜。開(kāi)發(fā)人員需要知道,容器是和原來(lái)的部署方式不一樣的存在,你需要區(qū)分有狀態(tài)和無(wú)狀態(tài),容器掛了起來(lái),就會(huì)按照鏡像還原了。開(kāi)發(fā)人員需要寫(xiě) Dockerfile,需要關(guān)心環(huán)境的交付,需要了解太多原來(lái)不了解的東西。實(shí)話實(shí)說(shuō),一點(diǎn)都不方便。

在運(yùn)維人員角度,使用 Kubernetes 也絕對(duì)不是像運(yùn)維虛擬機(jī)一樣,我交付出來(lái)了環(huán)境,應(yīng)用之間互相怎么調(diào)用,我才不管,我就管網(wǎng)絡(luò)通不通。在運(yùn)維眼中他做了過(guò)多不該關(guān)心的事情,例如服務(wù)的發(fā)現(xiàn),配置中心,熔斷降級(jí),這都應(yīng)該是代碼層面關(guān)心的事情,應(yīng)該是 SpringCloud 和 Dubbo 關(guān)心的事情,為什么要到容器平臺(tái)層來(lái)關(guān)心這個(gè)。

Kubernetes + Docker,卻是 Dev 和 Ops 融合的一個(gè)橋梁。

Docker 是微服務(wù)的交付工具,微服務(wù)之后,服務(wù)太多了,單靠運(yùn)維根本管不過(guò)來(lái),而且很容易出錯(cuò),這就需要研發(fā)開(kāi)始關(guān)心環(huán)境交付這件事情。例如配置改了什么,創(chuàng)建了哪些目錄,如何配置權(quán)限,只有開(kāi)發(fā)最清楚,這些信息很難通過(guò)文檔的方式又及時(shí)又準(zhǔn)確地同步到運(yùn)維部門(mén)來(lái),就算是同步過(guò)來(lái)了,運(yùn)維部門(mén)的維護(hù)量也非常的大。

所以,有了容器,最大的改變是環(huán)境交付的提前,是每個(gè)開(kāi)發(fā)多花 5% 的時(shí)間,去換取運(yùn)維 200% 的勞動(dòng),并且提高穩(wěn)定性。

而另一方面,本來(lái)運(yùn)維只管交付資源,給你個(gè)虛擬機(jī),虛擬機(jī)里面的應(yīng)用如何相互訪問(wèn)我不管,你們愛(ài)咋地咋地,有了 Kubernetes 以后,運(yùn)維層要關(guān)注服務(wù)發(fā)現(xiàn),配置中心,熔斷降級(jí)。

兩者融合在了一起。在微服務(wù)化的研發(fā)的角度來(lái)講,Kubernetes 雖然復(fù)雜,但是設(shè)計(jì)的都是有道理的,符合微服務(wù)的思想。

網(wǎng)易云輕舟微服務(wù)是圍繞應(yīng)用和微服務(wù)打造的一站式 PaaS 平臺(tái),幫助用戶快速實(shí)現(xiàn)易接入、易運(yùn)維的微服務(wù)解決方案。

相關(guān)閱讀:為什么 kubernetes 天然適合微服務(wù) (1)

為什么 kubernetes 天然適合微服務(wù) (2)

為什么 kubernetes 天然適合微服務(wù) (3)

文章來(lái)源: 網(wǎng)易云社區(qū)

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/25263.html

相關(guān)文章

  • 什么 kubernetes 天然適合服務(wù) (3)

    摘要:此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。五更加適合微服務(wù)和的設(shè)計(jì)好了,說(shuō)了本身,接下來(lái)說(shuō)說(shuō)的理念設(shè)計(jì),為什么這么適合微服務(wù)。相關(guān)閱讀為什么天然適合微服務(wù)為什么天然適合微服務(wù)為什么天然適合微服務(wù)文章來(lái)源網(wǎng)易云社區(qū) 此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。 歡迎訪問(wèn)網(wǎng)易云社區(qū),了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn) 四、Kubernetes 本身就是微服務(wù)架構(gòu) 基于上面這十個(gè)設(shè)計(jì)要點(diǎn),我們?cè)倩貋?lái)看 Kube...

    nicercode 評(píng)論0 收藏0
  • 什么 kubernetes 天然適合服務(wù) (2)

    摘要:有了分布式數(shù)據(jù)庫(kù)可以使數(shù)據(jù)庫(kù)的性能可以隨著節(jié)點(diǎn)增加線性地增加。分布式數(shù)據(jù)庫(kù)最最下面是,是主備的,通過(guò)的內(nèi)核開(kāi)發(fā)能力,我們能夠?qū)崿F(xiàn)主備切換數(shù)據(jù)零丟失,所以數(shù)據(jù)落在這個(gè)里面,是非常放心的,哪怕是掛了一個(gè)節(jié)點(diǎn),切換完了以后,你的數(shù)據(jù)也是不會(huì)丟的。 此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。 歡迎訪問(wèn)網(wǎng)易云社區(qū),了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn) 三、微服務(wù)化的十個(gè)設(shè)計(jì)要點(diǎn) 微服務(wù)有哪些要點(diǎn)呢?第一張圖是...

    lentrue 評(píng)論0 收藏0
  • 什么服務(wù)架構(gòu),該從哪些方面深入理解?

    摘要:要玩好微服務(wù),微服務(wù)平臺(tái)需要的不僅僅是無(wú)侵入的服務(wù)治理能力,容器測(cè)試等服務(wù)也是必要的,這也是網(wǎng)易云輕舟微服務(wù)的產(chǎn)品設(shè)計(jì)思路。 歡迎訪問(wèn)網(wǎng)易云社區(qū),了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)。 簡(jiǎn)單地說(shuō),微服務(wù)架構(gòu)就是以業(yè)務(wù)域或業(yè)務(wù)功能為邊界,將一個(gè)大而全的應(yīng)用拆分為可以獨(dú)立開(kāi)發(fā),獨(dú)立部署,獨(dú)立測(cè)試,獨(dú)立運(yùn)行的一組小的應(yīng)用,并且使用輕量級(jí),通用的機(jī)制在這組應(yīng)用間進(jìn)行通信。 showImg(https:...

    sunny5541 評(píng)論0 收藏0
  • prometheus比zabbix好在哪點(diǎn)?

    摘要:擁有活躍的社區(qū),在上獲得的數(shù)超過(guò)了萬(wàn),符合網(wǎng)易云的選擇。當(dāng)然,也有一些不足,比如不能用于日志監(jiān)控分布式追蹤等范圍,所以網(wǎng)易云也做了很多設(shè)計(jì)和優(yōu)化。 分享網(wǎng)易云輕舟微服務(wù)選擇基于 Prometheus 開(kāi)發(fā)微服務(wù)監(jiān)控系統(tǒng)的考量: 開(kāi)源 云原生 與微服務(wù)監(jiān)控需求的匹配度很高 開(kāi)源 Prometheus是CNCF(云原生計(jì)算基金會(huì))旗下成熟的開(kāi)源項(xiàng)目,而開(kāi)源技術(shù)棧是網(wǎng)易云堅(jiān)定不移的選擇,不僅...

    skinner 評(píng)論0 收藏0
  • 樂(lè)心醫(yī)療的 Kubernetes云平臺(tái)建設(shè)實(shí)踐

    摘要:宋體自年被開(kāi)源以來(lái),很快便成為了容器編排領(lǐng)域的標(biāo)準(zhǔn)。宋體年月,樂(lè)心醫(yī)療的第一個(gè)生產(chǎn)用集群正式上線。所以于年推出后,樂(lè)心醫(yī)療的運(yùn)維團(tuán)隊(duì)在開(kāi)會(huì)討論之后一致決定盡快遷移到。Kubernetes 自 2014 年被 Google 開(kāi)源以來(lái),很快便成為了容器編排領(lǐng)域的標(biāo)準(zhǔn)。因其支持自動(dòng)化部署、大規(guī)模可伸縮和容器化管理等天然優(yōu)勢(shì),已經(jīng)被廣泛接納。但由于 Kubernetes 本身的復(fù)雜性,也讓很多企業(yè)的...

    testHs 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<