將企業(yè)的Kubernetes集群交給托管服務提供商感覺就像把孩子送到大學里一樣，一開始不放心，但最終需要自己要做的事情少了很多。

在過去幾年，三大公有云提供商亞馬遜云服務(AWS)、谷歌云和微軟Azure的托管Kubernetes方案(又叫Kubernetes即服務，KaaS)都取得了長足的進步，幫助客戶運行和編排他們的容器化工作負載，無需了解YAML配置文件的基本細節(jié)，也無需操心自動擴展、更新和集群管理。

[[415034]]

Stephen O'Grady是面向開發(fā)人員的調研公司RedMonk的聯(lián)合創(chuàng)始人，他說："當企業(yè)認為某個系統(tǒng)具有戰(zhàn)略意義時，本意是想自己運行。后來隨著逐漸適應，他們漸漸認識到：自己運行沒有帶來任何競爭優(yōu)勢，供應商有可能比他們運行得更好。"他補充道："每家企業(yè)都在走這條路嗎?還沒有，但是走這條路的愿望和方向似乎很明確。"

以下是考慮采用托管Kubernetes服務的六大原因：

降低管理成本

不妨先從一個顯而易見的原因說起。Sylvain Roy是旅游業(yè)技術公司艾瑪?shù)纤?Amadeus)主管技術平臺和工程的高級副總裁，他說："要弄清楚一點，我們的工作量減少了。有人替我們運行，這很重要，因為我們很難雇傭到運行Kubernetes所需的所有人。"

同樣，自2006年以來，建筑公司Strabag的一小群工程師就一直在自己運行容器，在過去四年里，他們改用了自我管理的開源Docker和Kubernetes環(huán)境?，F(xiàn)在，這群人正考慮盡可能提高集群管理的自動化程度，他們決定：更新改造現(xiàn)有的應用程序，將管理底層Kubernetes集群的任務移交給谷歌云;或者授權開發(fā)人員使用Anthos服務，在云端或混合環(huán)境中運行新的應用程序，特別是需要一些本地數(shù)據(jù)傳輸時。

Strabag的云服務團隊負責人Mario Kleinasser說："首先要移交適合移交的任務。"

金融數(shù)據(jù)巨頭彭博社計算基礎架構主管Andrey Rybka也表示，"如果沒有SRE(軟件可靠性工程)團隊或管理Kubernetes發(fā)布周期的團隊，對專注于運行應用程序、不想管理Kubernetes的那些企業(yè)來說，充分利用托管供應商是合理的舉措。"

如今，彭博社仍在本地運行大部分的Kubernetes工作負載，但它也開始在適當?shù)那闆r下將三大云供應商都用于托管的工作負載。

只需要少數(shù)專家

Kubernetes的管理技能很難獲得，且成本很高，自行編寫YAML配置文件更是如此。即便你有可以手動調整Kubernetes集群的人員，也可能需要把較為普通的工作負載集群管理任務交給供應商，而讓自己的人員騰出手來管理內部平臺或任何特別重要或棘手的工作負載。

艾瑪?shù)纤沟腞oy說："獲得和留住這些技術所需的人并非易事，這顯然是個挑戰(zhàn)。"

更好的可靠性

簡而言之，基于工程團隊的規(guī)模、客戶部署的多樣性，以及可以訪問這些部署環(huán)境底層的遙測數(shù)據(jù)，大型云供應商常常比你自己更有能力管理Kubernetes集群。

RedMonk的O'Grady說："供應商很可能更好地運行Kubernetes集群。供應商有遙測數(shù)據(jù)，其優(yōu)勢在于可以看到所有客戶運行集群的情況，而不像單個企業(yè)只有自己的數(shù)據(jù)模型可供使用。"

以彭博社為例，它在2015年的盛行期轉而采用Kubernetes，當時Kubernetes仍只是alpha測試版。等到運行結果證明：必要的持續(xù)集成、監(jiān)控、測試與預期相符，Kubernetes就在2017年進入到了生產環(huán)境。Rybka表示，雖然彭博社的工程師仍在很大程度上為本地應用程序自行管理Kubernetes集群，但是當工作負載在公有云上運行時，使用托管方案顯得越來越合理，"從可靠性的角度來看"更是如此。

不用擔心升級和補丁

對于自行管理Kubernetes的任何企業(yè)來說，升級和補丁是最枯燥乏味的兩項工作，這就是為什么托管提供商優(yōu)先考慮替您處理這些任務。

AWS計算服務副總裁Deepak Singh說："自行打補丁、更新和管理Kubernetes非常復雜，而且是完全沒有樂趣的苦差事。"

保持云發(fā)展勢頭

對于大力推行公有云優(yōu)先策略的組織而言，采用更多的托管服務有助于提升勢頭。

艾瑪?shù)纤棺罱c微軟簽署了一筆交易，就是為了做到這一點。Roy說："公有云發(fā)展迅猛，我們希望從中受益，于是我們每次都會考慮使用更多的托管服務。在我看來，這是得益于這股勢頭的途徑。"

現(xiàn)在，供應商們正將各自在Kubernetes最佳實踐方面的知識和經驗轉化為更自成一體的Kubernetes服務版本，并簡化了采用路徑，比如GKE Autopilot。

谷歌的首席工程師Kelsey Hightower說："一些人會將Autopilot視為備胎，而我將其視為安全帶。汽車行駛的速度一樣，但默認情況下更安全，這是一種萬無一失的配置。人們總是問我們有何最佳實踐、問他們要做出什么樣的決定，Autopilot給出了答案。"

同樣，AWS的Singh表示，該公司正變得更擅長運用大規(guī)模運行Kubernetes所獲得的經驗，將這種"運作經驗結合到EKS中……這讓我們的服務提供商可以將其直接集成到這些托管服務中。這是你會看到這股潮流愈演愈烈的另一個原因。"

然而，這類服務往往讓人擔心供應商鎖定。"之所以Autopilot比較難選擇，是由于這個問題：既然沒人另換供應商，為什么關注Kubernetes這個中間件層。答案是我可以撒手不管。"RedMonk的O'Grady說，"你越依賴針對特定供應商的選項，越無法做到可以撒手不管，因此這對企業(yè)而言是艱難的選擇。"

是開源、可移植的

托管提供商必須贏得開源社區(qū)和客戶的信任，客戶要確保自己使用的Kubernetes發(fā)行版盡可能接近普通開源版本，以提高可移植性，并避免鎖定現(xiàn)象。

谷歌的Hightower說："Kubernetes面市時，有人擔心它是掛羊頭賣狗肉，是供應商與開放社區(qū)搶地盤，它會演變成開放核心。差不多過了五六年，才證明并非如此。"

同樣，AWS的Singh表示，對一些客戶而言，EKS與Kubernetes的開源發(fā)行版保持關系密切很重要，"沒有會造成差異的怪異巫術。"AWS最近在GitHub上開源其EKS發(fā)行版，證明了這一點。

Kubernetes的聯(lián)合創(chuàng)始人兼VMware Tanzu的首席工程師Joe Beda承認："談到這個話題很難不提到鎖定。"他敦促做出這種購買決定的任何人都應適當評估風險。

Beda說："你離開的可能性有多大?如果離開，遷移成本會有多大?你需要重寫多少代碼、需要多少的再培訓?這方面進行投入的任何人都需要了解面臨的需求、風險和取舍。"

云原生計算基金會(CNCF)開展了一項Kubernetes認證合格計劃，該計劃確保一套安裝系統(tǒng)與下一套安裝系統(tǒng)可實現(xiàn)互操作性，不管認證的供應商是哪一家。

那么，為什么有的企業(yè)沒有選擇它?

對于艾瑪?shù)纤购团聿┥绲三嫶蟮膹碗s組織而言，無論是敏感數(shù)據(jù)安全問題、棘手的本地依賴項還是過度保護的平臺團隊想要手動調整自己的集群，可能總會有一些工作負載是你不放心交給托管服務提供商處理的。

谷歌的Hightower說："那些想要自我管理部件/組件的人會擔心數(shù)據(jù)平面;他們需要在某些方面進行定制或專門化。他們不介意托管的控制平面。"

然而實際上，自己運行Kubernetes的種種理由變得越來越缺乏說服力。

RedMonk的O'Grady說："也許你認為這是一項現(xiàn)有投入，沒有人希望將其作為沉沒成本一筆勾銷，或者偏于保守的組織對一系列工作負載或業(yè)務交給外人心存擔憂?；蛘哂腥藭橐徊糠志哂袘?zhàn)略意義的基礎設施不受自己控制而擔憂。但是當你看到同行采用托管方案時，這種擔憂就會煙消云散，你會看到更多人在獲得切實的好處。"