<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      回首 Kubernetes 發展,為什么如此出色?

      了解什么是 Kubernetes 以及為什么它對于可靠、可擴展的現代應用程序至關重要的初學者指南。

      如果你在 IT 行業,你可能經常聽到“Kubernetes”這個名字(在希臘語中意為“飛行員”或“舵手”)。它所做的通常被稱為容器編排,盡管人們有時指出它也不是一個準確的術語。

      那么它到底是什么?

      Kubernetes 確實很受歡迎。根據 CNCF(云原生計算基金會)發布的《 2021 年第一季度_云原生開發狀況報告》,全球有 680 萬云原生開發者(其中 560 萬使用 Kubernetes,比上一年增長 67%),運行著 1020 萬個容器。(我們稍后會解釋什么是容器。)

      CNCF 估計全球有 2680 萬開發人員,因此全球約有五分之一的開發人員目前正在使用 Kubernetes。

      要了解 Kubernetes 究竟做了什么以及為什么它在現代系統操作中如此受歡迎,我們必須快速回顧一下歷史。

      單體應用程序

      在 2000 年代末,我曾短暫地擔任過 Java 工程師。我們擁有的應用程序都是單體應用程序:它們使用 JavaServer Faces 或 Struts 來呈現網頁,并使用 Spring 和 Hibernate 來查詢數據庫。一切都必須編譯成一個巨大的.war文件才能在大型 Oracle 服務器上運行。

      在一個更大的項目中,我們有一個大約 30 人的團隊,分為系統分析師、Web 開發人員和服務開發人員。一切都在一開始就計劃好了。然后客戶決定在軟件中增加一個新的功能分支。我們實際上不得不在我們的架構中插眼,因為我們沒有時間修復它,這樣做會導致更多的錯誤和混亂。

      顧名思義,一個單體應用程序就像一塊(巨大的)石頭,所有東西都緊密耦合在一個代碼庫中。如果您有一個小型應用程序,這是一個合乎邏輯的選擇。但隨著項目規模的擴大,一切都開始失控。

      一個稱為面向服務架構 (SOA)的概念,試圖通過模塊化編程來解決這個問題:應用程序的后端與前端分離并拆分為單獨的 Web API(使用 SOAP,簡單對象訪問協議)。這至少使項目開發更容易。

      微服務時代

      維護一個龐大的單體應用程序的麻煩只是問題的一半:它們也難以擴展,或者增加服務量來處理更多的用戶和數據。當然,您可以部署更多服務器并在它們前面應用負載均衡器/反向代理,但任何更改都會使整個服務中斷一段時間。

      在最近的一篇文章中[2],Mario Izquierdo 解釋了 Twitch 如何在 2010 年代初從 Ruby on Rails 單機應用程序切換到基于 Golang 的微服務架構以解決性能瓶頸。與 SOA 服務仍然是同一后端的一部分不同,微服務本身是獨立的迷你應用程序,通常與自己的數據庫配對。

      具有諷刺意味的是,與 SOA 的 SOAP(簡單對象訪問協議)相比,最常見的微服務 API 之一 REST(表示狀態傳輸)也更容易實現且更具可擴展性。

      現在擴展很容易,您只需按需增加微服務的數量。您還可以在一臺服務器上運行多個微服務實例,因為它們需要的資源更少。

      虛擬機世界

      下一個問題是很難在同一臺服務器上運行不同的應用程序。因為您可能無法為每臺服務器購買一種類型的應用程序。

      例如:您有一個使用 Spring Boot (Java) 編寫的微服務和另一個使用 .NET Core 編寫的微服務。你有一個使用 React 構建的前端應用程序(它可能在 Node.js 中的服務器上運行)。您甚至可能擁有運行 Flask (Python) 的機器學習服務。嘗試讓它們一起工作會很麻煩,尤其是在不同類型的服務器上。

      虛擬機 (VM) :機器級虛擬化,使用稱為hypervisor的模擬器來“模擬”同一臺物理機器上的多臺機器。每個虛擬機都有自己的操作系統、內存和 CPU 資源。在 VM 中運行的任何內容都將與另一個 VM 中的應用程序完全分離。有許多云平臺提供大規模的 VM 托管。

      集裝箱化

      虛擬機很棒,但它們也需要大量資源并且啟動速度很慢。Docker 在 2013 年推廣的一個新概念 容器化就是一個解決方案。

      Docker 容器實際上是輕量級 Linux 虛擬機。不同之處在于容器通過容器運行時共享主機操作系統內核和內存,只有應用程序和文件是分開的(操作系統級虛擬化)。容器啟動速度更快,需要的資源更少,因此您可以在同一臺機器上運行更多。

      圖片

      在IBM 于 2021 年進行的一項測試中[3],具有四臺服務器(16 x 2.1 GHz 內核和 128 GB 內存)的虛擬環境可以運行 8 個 VM 或 33 個容器。多么大的不同!他們還嘗試比較 32 個虛擬機與 33 個容器的年度運營成本。后者只需前者的 25%。

      Twitch 的 Mario Izquierdo 在接下來的文章[4]中也提到了他們如何逐漸從 Amazon EC2(主機 VM)遷移到 AWS(容器)。被稱為“Tiny Bubbles”的容器化微服務分別由不同的團隊管理。

      容器引擎使面向應用程序的基礎設施成為可能:每個容器都是一個包含一個應用程序的氣泡。管理容器本質上與管理應用程序相同。由于容器可以使用鏡像進行克隆和移植,因此您幾乎可以在任何地方隨意部署和擴展任何應用程序。

      容器編排

      容器比虛擬機更容易管理,但當然,大規模手動管理任何東西并不容易。如果你必須運行 100 個微服務實例會發生什么?您必須創建 100 次微服務嗎?你怎么知道他們中有沒有掛掉的?數以萬計的容器呢?

      Kubernetes:一個開源項目,正是為此目的而設計的,它來自谷歌內部管理系統 Borg (2003) 和 Omega (2013) 的 15 年經驗:

      盡管對軟件容器的廣泛興趣是一個相對較新的現象,但在 Google,我們十多年來的三個容器管理系統已經大規模管理 Linux 容器十多年,并在那時構建了三個不同的容器管理系統。

      Google 開發的第一個統一容器管理系統是我們內部稱為 Borg 的系統。它是為管理長期運行的服務和批處理作業而構建的 Omega 是 Borg 的后代,其驅動力是希望改進 Borg 生態系統的軟件工程。

      谷歌開發的第三個容器管理系統是 Kubernetes。它是在外部開發人員對 Linux 容器越來越感興趣的世界中構思和開發的,而谷歌已經開發了一項不斷增長的銷售公共云基礎設施的業務。

      Borg:以星際迷航中虛構的外星種族命名,已經變得如此強大,以至于它已經在谷歌中以令人難以置信的規模運作:

      Google 的 Borg 系統運行來自數千個不同應用程序的數十萬個作業,跨越多個集群,每個集群擁有多達數萬臺機器。

      Kubernetes 1.0 于 2016 年發布。它已被包括亞馬遜、微軟、谷歌、IBM、甲骨文和紅帽在內的眾多云提供商廣泛采用。

      我們在開頭提到,Kubernetes 所做的被描述為容器編排:它使容器操作自動化,類似于指揮一群音樂家的指揮。

      Kubernetes 能做什么在官方文檔[5]中列出如下:

      服務發現和負載均衡

      存儲編排(添加任何本地或云服務器)

      自動部署和回滾

      自動分配 CPU/內存資源

      自我修復(需要時啟動新容器)

      Secret(安全相關信息)和配置管理

      Kubernetes 是一種聲明性工具:您不必自己運行容器。取而代之的是,您“聲明”一個部署清單(如運輸訂單)以指定在 Kubernetes 環境中運行的容器和數量。

      Kubernetes 監控容器,如果其中任何一個崩潰,將創建新容器以匹配您的清單。CPU/內存資源是自動分配的。容器作為單個 API 端點綁定在一起。Kubernetes 還提供了自己的負載均衡器,因此您可以通過簡單地更改清單來擴展您的服務。

      所以:Kubernetes 可以在幾乎沒有人為干預的情況下實現可靠、可擴展和自動化的容器操作。它還可以部署在多個物理或虛擬機上,這些物理機或虛擬機可以是云提供商或任何地方的本地服務器。它是現代信息系統大規模管理的關鍵。

      Kubernetes 也為開發者帶來了巨大的好處。部署在 Kubernetes 上的應用程序(不僅是微服務,還包括前端應用程序在內的任何應用程序)因其容器性質而具有“云原生”特性,更容易通過簡單地更新清單來交換或升級。Kubernetes 可以在不停止服務的情況下執行滾動更新。

      在云原生開發狀況報告中,33% 的開發人員報告說他們可以每天發布生產代碼,31% 每周發布。開發團隊現在可以保持競爭力,因為他們可以比其他公司更快地推出新功能。

      Kubernetes 集群的簡化概述

      我們不會在本文中過于技術化,但讓我們看看 Kubernetes 集群內部是什么,它是部署的 Kubernetes 環境的基本單元(您的應用程序將部署在其中)。根據需要,您可能有多個集群一起工作。一個集群基本上有以下幾個部分:

      控制平面——Kubernetes 集群的大腦

      工作節點——集群數據平面中虛擬機的物理節點

      Pods — 每個 Pod 由一個或多個容器組成,這些容器在一個節點中共享相同的存儲和網絡

      Kubernetes 默認使用 Docker 容器引擎,盡管還有其他選項。

      圖片

      目前,您無需過多擔心控制平面或節點中的較小組件,它們是 Kubernetes 如何管理節點和 Pod 的較低級別的細節。

      例如,kubelet是運行一個節點的代理,它就像一個向控制平面報告的組長(控制平面實際上是一個主節點的集合)。kube-proxy是每個節點的網絡代理。etcd是控制平面本身的持久化數據庫,節點控制器和 pod 調度器也在控制平面中,依此類推。

      Kubernetes 還允許您將自定義資源(CR) 添加到集群中,該集群的工作方式類似于 pod 或容器,但具有更大的靈活性。

      Pokémon GO 的成功

      Pokémon GO 是 GKE(Google Kubernete Engine)最早和最大的用戶之一。它在單個 Kubernetes 集群中運行容器化的前端應用程序和各種微服務。游戲公司 Niantic 只有一個小團隊。發布時最差的估計用戶流量是原始估計的 5 倍。

      然而到了 2016 年 7 月 6 日,游戲在澳大利亞和新西蘭上線后的 15 分鐘內,這個數字就飆升到了他們目標的50 倍。

      圖片

      Niantic 尋求 Google 的幫助。谷歌迅速將數千個節點添加到集群中,這已經成為真正的行星規模。游戲順利通過了萬眾矚目的次日美國上線和日本當月下旬上線(是美國上線的 3 倍),數以萬計甚至數十萬玩家在線,每天 5~10TB 數據。

      盡管 Niantic 沒想到會如此受歡迎,但由于游戲的容器化設計以及將其部署在云上的決定,它可以在很短的時間內擴大規模。在某些方面,你可以說他們有點預料到了意外。

      今天,企業擁有具有數千個工作節點的集群并不少見。Bayer Crop Science[6] 在 240,000 個 CPU 內核和 1.48 PiB 的 RAM 中運行一個包含 15,000 個節點(從 4,500 個節點集群擴大)的集群,以計算有前景的種子基因型。OpenAI[7]有一個 7,500 個節點集群來訓練非常復雜的圖像和文本 AI 模型。不一定是節點越多越好,但顯然是可以實現的。

      Kubernetes 為現代系統帶來了非凡的可靠性和可擴展性,因此已成為成功的代名詞。

      概括

      Google 的 Kubernetes 是一個開源項目,用于可靠、可擴展的容器操作,并已大規模應用。

      容器化是更輕松地部署和擴展應用程序(尤其是微服務)的方式。

      0
      相關文章
        漂亮的苏酥全文阅读