Categories
程式開發

使用Kubernetes前,你應該考慮的三大因素


使用Kubernetes前,你應該考慮的三大因素 5

過去幾年,Docker成為一種非常受歡迎的應用程序構建、交付和運行方式。使用Docker,只需一次構建應用程序,即可隨處運行。雖然這是軟件開發方式的一次巨大飛躍,但它也帶來一些新挑戰。對初學者而言,在Docker容器和主機間建立網絡連接不是一件簡單的事。這與我們過去傳統的聯網方法有很大不同,它要求具備一定的技能才能做好。

另一個挑戰是存儲。默認情況下,Docker volumes被綁定到它們的主機。這意味著,如果我們希望運行一個服務的多個實例,並讓它們共享volume,就不得不設置好複製機製或配置成使用雲存儲服務。

雖然Docker被視為一項了不起的技術,但缺少一個能將所有技術聯繫在一起的組件。而Kubernetes正是那個組件。尤其是通過Azure、AWS等雲平台提供的全託管形式,Kubernetes解決了所有這些問題,並通過一系列概念將它們從最終用戶那裡抽像出來。

Kubernetes,也被稱為k8s,它由谷歌開發,用於解決在全球範圍內運行成千上萬個應用程序時所面臨的問題。最近一兩年,k8s的採用正快速增長,有越來越多的公司尋找精通k8s的工程師。 Kubernetes雖然在SpotifyING和許多其他公司的實施取得令人驚嘆的成功,但它並非所有公司的終極解決方案。事實上,在生產環境中運行Kubernetes也會帶來一些嚴重問題。在這篇文章,我們將探討在決定使用Kubernetes前應考慮的一些因素。

1.學習曲線

Kubernetes有自己的運行機制。它是圍繞幾個概念設計的,熟悉其中的大多數概念是在生產環境中運行Kubernetes的必要條件。所以,這就引入了一個相當陡峭的學習曲線。不僅是對於系統管理員,對於開發人員也是如此。

下面這個圖展示了Kubernetes架構的高級概述

使用Kubernetes前,你應該考慮的三大因素 6

Kubernetes架構(Kubernetes Components,CC-BY 4.0)

所有這些管理器、調度器和服務器負責全天候運行你的應用程序,即k8s中的工作負載。它們各司其職,並實現了Kubernetes的一個或多個概念。

在使用Docker或從事比較傳統的系統管理工作時,你不一定會用到這些概念。每次,你在集群部署一個新的應用程序時,Kubernetes都會為你的應用程序創建最少數量的以下對象:

  • 表示應用程序的Deployment對象;
  • ReplicaSet用於擴展與部署相關的Pod
  • 可選,一個或多個Service處理部署的網絡需求;
  • 表示實際容器的一個或多個Pod。這是Kubernetes架構中的最小組件。

如你所見,對一個不熟悉Kubernetes的人來說,這可能是很大的負擔。更重要的是,這些對像中的每一種都有無數種配置方式,可以極大改變它們的行為。

事實上,啟動和運行Kubernetes並正確配置它的所有組件,這需要大量時間。託管Kubernetes供應商承擔了大量底層的配置和集成,但是,有一些工作將不可避免地滲透到開發人員那裡,至少,他們需要基本熟練地使用Kubernetes才能正確完成工作。

你不一定非得需要Kubernetes來運行應用程序,它只是運行生產軟件的眾多選項之一。

你應該仔細衡量一下,遷移成本(學習曲線的增加和配置開銷)和遷移好處。

2.應用程序需要擴展嗎?

Kubernetes的一個關鍵特性是能對應用程序的各個部分進行擴展。流量會自動在各個Pod間路由和分配,如果配置完成,Kubernetes甚至可以自動為你縮放Pod

如果一個應用程序有一個或多個熱點組件需要處理突發事件,那這個特性就很有價值。例如,在推出新擴展或新特性時,在線遊戲的身份驗證服務可能會出現登錄請求突然增加的情況。或者是那些在發行後變得非常受歡迎並需要快速擴展基礎設施的遊戲,就無需擔心網絡、存儲等問題。 《精靈寶可夢Go》便是這樣一款遊戲,它在發行後不久便吸引了大量玩家。於是,它們廣泛使用Kubernetes來為全世界大量玩家提供服務。

然而,對大多數其他應用程序來說,單個服務成為整個環境的瓶頸問題,通過優化而不是擴展解決更好。當然,在這個問題上,你可以多用幾個Pod,並祈禱問題會消失——也就是說,只要沒有達到存儲層的限制,你就可以簡單地通過擴展Pod來解決問題,達到了,就不行了。

不要誤解我的意思——能動態地擴展部署是一個很大優點。但是,在我見過的絕大多數情況下,為解決瓶頸而擴大部署只是治標不治本。

此外,除了能使用Kubernetes擴展應用程序外,還有許多其他方法。 Heroku、Azure和AWS都提供了動態運行和擴展應用程序的方法。例如,Azure Web App有橫向擴展選項,這與在Kubernetes中運行多個Pod並在前置一個負載均衡器的效果是一樣的。

如果擴展能力是吸引你轉向Kubernetes的原因,那麼首先要考慮下其他不太需要維護的選項。

3.運行微服務

Kubernetes主要用於運行許多小型的工作負載,這些工作負載一起組成一個應用程序。如前一節所述,其關鍵特性之一是獨立擴展基礎設施的各個部分,而不需要擴展整個應用程序。這些架構(通常被稱為微服務架構)在Kubernetes上蓬勃發展。其架構支持簡單的服務發現,以及整個拓撲中各個組件間的輕鬆交互。

因此,這裡要考慮的不是在Kubernetes上運行微服務是否是一個好主意,而是微服務是否是特定應用程序恰當的架構原則。雖然微服務架構通常比傳統的單體架構更受歡迎,但它們也給開發人員帶來巨大負擔。比如,Uber支付體驗平台放棄微服務,轉而使用宏服務,這一事情引起網友熱議。

讓每個獨立的服務各自都有定義好的職責是一種合理的架構選擇。下一步,將這些職責劃分為不同服務似乎是合乎邏輯的,但也可以不必如此。為了讓開發人員可以分析和修復微服務環境中的Bug,他們需要能訪問構成該環境的大部分(如果不是全部的話)服務。

這讓整個應用程序更加難以有效地工作。由於開發人員不能僅在他們的開發機器上運行應用程序,因此,你需要引入一整套工具來分析解決問題。考慮每個環境的分佈式日誌記錄、消息隊列和性能監視。

這對開發人員生產力的影響不是很明顯。同樣,這樣做可能是值得的,特別是對於擁有許多開發團隊的大型組織來說,每個開發團隊都在他們自己的微服務上工作,是全局的一部分。然而,對於較小的公司和團隊,微服務架構的成本要高得多。 Kubernetes並不一定使這些問題更容易處理。事實上,它甚至可能讓情況變得更糟糕。

如果啟用微服務架構是吸引你使用Kubernetes的原因,那麼請仔細考慮一下,職責分離是不是一個可以用代碼解決的問題,而不是通過在基礎設施中引入Kubernetes等大型組件來解決它。

小結

在考慮Kubernetes是否適合你的項目或組織時,我們討論了一些需要考慮的因素。 Kubernetes最初是由谷歌設計來解決谷歌所面臨的問題。這些問題涉及到在生產環境中運行大量的工作負載,而其伸縮需求對於我們這些普通人來說是不可想像的。

谷歌只有一家。當然,除了谷歌,你可能會遇到與穀歌在設計Kubernetes時相同的問題,而你成功的機會卻很小。在決定將Kubernetes作為你的業務基礎前,你非常有必要考慮下,在一段較長時間內,它對你的組織、開發團隊和平台穩定性的影響。這項技術仍然相對較新,精通Kubernetes的工程師相對較少。

這並不是說Kuberneets是解決問題的錯誤方法。此前,我參與過一些項目,它們依賴Kubernetes向終端用戶提供價值,而且規模很大,這是其他類似技術難以匹敵的。最重要的是,儘管關於Kubernetes的許多宣傳是真的,但在引入Kubernetes時還是不能草率。

它有時候很合適——但並不總是很合適。

英文原文:

Do You Actually Need Kubernetes?