<h5級"pgc-h-right-arrow">從寺廟開始
量子比特報告|公衆号 QbitAI</h5>
Kubernetes，谷歌在2014年推出的一個開源項目。
它是一個開源平台，用于自動執行應用程式容器的部署、擴充和操作，這些容器可以快速傳遞到真正以容器為中心的基礎架構開發環境中。
畢竟，容器是當今雲原生世界中最重要的計算資源形式。
在過去的一年裡，kubernetes 的技術發展了什麼？
也許成熟度和穩定性這個術語是最好的總結。
值得一提的是，越來越多的重量級玩家正在進入雲原生市場。
現在不再是技術狂熱的初創企業推動和聚集的時候了。
牧場主必須記住這種模式變化。
由CloudStack之父梁晟創立的Rancher Labs，早已是第一個進入該領域的。
其旗艦産品Rancher作為開源企業級Kubernetes管理平台，率先在混合雲本地資料中心集中部署和管理Kubernetes叢集，并于2020年2月在中國完成本地化和本地化。
Rancher中國首席技術官蔣鵬也有同樣的感覺，2017-2018年，越來越多的雲服務提供商将容器視為自己的服務之一，但不是最核心的服務。
但是，今天，每個參與者都将容器所代表的雲原生服務更新到核心服務類别。
當然，這種變化也集中在參與者在識别雲原生域或技術堆棧的同時，更多地思考業務"落地"的問題。
示例包括應用程式操作、微服務治理，甚至 Kubernetes 叢集的管理和安全性，包括與新技術 AI 的內建。
這樣，或許更注重生态層面的創新，更靈活地适應使用者需求的變化，通過創新項目産品解決雲原生推廣或落地過程中的諸多問題，可能是打赢雲原生戰争的關鍵。
此外，在雲原生落地方面，K8S多叢集管理、容器邊緣部署，包括與AI技術的結合等方面都是不可回避的。
如果你在容器實踐中"犯了一個錯誤"，請向下看，也許可以消除你概念意識中的一些困惑。
從焦點到響應：叢集管理意味着"有話要說"
如果我們的推斷是合理的，那麼現實世界雲原生的關鍵之一可以專注于Kubernetes叢集的管理。
就像Rancher最早的産品定位：專注于多叢集管理或混合雲，多雲多叢集管理。
究竟什麼是多叢集？
在實踐中，對于大多數剛剛開始使用雲原生或Kubernetes技術的企業來說，它不是一個單一的叢集，而是更簡單地定義為少量叢集。
例如，許多企業開發環境都有一個叢集，而生産環境中還有另一個叢集，這可能是您剛剛上線時的典型場景。
但是，随着業務量的增長和容器平台在企業中越來越被采用，使用者會發現需要将更多的應用程式遷移到叢集。
從單個資料中心部署到多資料中心的過渡甚至可能導緻多雲場景，進而導緻多叢集管理問題。
蔣鵬進一步透露，"多"在多叢集管理中不僅展現在叢集的規模上，即使在不同的團隊中，概念也會有不小的差異。
對于平台建構團隊而言，多叢集管理技術意味着更多有助于掩蓋底層基礎架構中的差異，以提供一緻的證書頒發機構以及管理、營運功能。
對于應用程式團隊而言，更重要的是以統一且一緻的方式部署和使用這些叢集，進而在不同的叢集上提供一緻的上層支援能力。更快地将監視、警報、日志收集或應用程式（包括微服務治理）部署到多個群集至關重要。
對于金融使用者豐富的資料中心來說，它是典型的兩三中心架構，對于應用團隊來說，他們的重點更集中在：能否将一些核心業務系統快速一鍵部署到資料中心，實作跨資料中心的容災或多重生活？
基于此，Rancher對其産品進行了一些增強，包括多叢集，多租戶監控功能，以及跨多Kubernetes叢集部署和管理單個應用程式。
具體而言，在定義叢集模闆的基礎上，隻需單擊一個按鈕，即可将應用商店的應用程式系統無縫部署到任意數量叢集中的多個項目。
說到安全性，一直是企業非常關心的問題，在容器叢集管理領域也不例外。
如果我們從整體平台安全性的角度來看安全性，我們通常會讨論安全問題，這必須是端到端的解決方案。
從容器平台的安全角度來看，往往關注的不僅僅是叢集本身的安全性。
相反，它涵蓋了從應用程式開發到最終傳遞容器化操作的整個生命周期中的更多安全流程。
例如，定向安全性。
使用者通常需要注意鏡像整個容器如何確定内置元件或服務中沒有安全漏洞。
在群集安全性方面，遵守業界最佳建議變得非常重要。
例如，遵循安全基準基準測試、關閉匿名通路端口、在元件之間使用雙向 TLS 加密、确定元件是否以最低權限啟動等。
此外，叢集的運作時安全性涉及叢集上層應用程式運作時的某些配置，例如容器運作時運作時。
在多租戶場景中，即使有一些專業安全供應商的技術支援，也要考慮如何在不同租戶之間進行網絡隔離。
雖然容器安全很複雜，但安全管理不容忽視。
邊緣端方案中的群集管理，哪裡有困難？
其實，容器技術在邊邊使用并不新鮮，江鵬的斷言表示贊同。
例如，微軟的Azure就是azure IoT中心配置的一個例子，長期以來，它一直是業界的客觀配置。
不同之處在于，Azure IoT 中心基于 Docker 容器技術，在此階段可能沒有使用與 Kubernetes 相同的業務流程。
更重要的是，容器技術自然是作為傳遞應用程式的一種方式或作為包裹傳遞的一種方式而存在的。
也就是說，這種"自然"适用于邊緣側等大型應用程式中的統一标準化部署。
這樣的總結更為常見。
盡管容器具有自然的性質，但部署管理過程并不像在雲、資料中心甚至異構基礎架構上部署那麼簡單。
直覺地說，邊緣的叢集規模不再是傳統資料中心中數十個或數十個叢集的情況。
相反，它可能是數千或數萬，甚至數十萬，這種叢集規模。
更重要的是，邊緣場景與傳統雲或資料中心場景的最大差別在于邊緣場景非常多樣化或碎片化。
與資料中心相比，Kubernetes 具有标準的 X86 伺服器和統一存儲，提供了一緻的 API 來支援業務的标準化操作。
但是，在邊緣方面，使用裝置本身的業務方案或所使用的協定之間存在很大差異。
"舉一個簡單的例子，一些制造客戶在他們的生産線上會有很多Windows系統，而不是Linux系統，甚至比Windows伺服器更多。如果這些裝置通過某些協定與生産線上的其他裝置進行互動，則難度是可以預測的。"
那麼，究竟應該如何管理這樣一個大型叢集呢？
目前，還沒有統一的資料中心場景或平台啟動，形成統一的規範。
在邊緣場景中，使用者要進行一些系統或應用的容器化或雲原生轉型，還需要有一個漸進的适應、轉型過程。
但蔣鵬也承認，利用集裝箱技術在邊上，确實是迫切需要發展的趨勢和需求。
"我們已經看到了是否在邊緣端使用Docker引擎，但是對于在邊緣端進行更強大的編排，看看是否将标準Kubernetes推向邊緣端仍然很重要。
根據Quantum Bits的說法，大多數參與容器的雲服務提供商更有可能在邊緣側部署标準Kubernetes以進行有效管理，但Rancher除外，這就是為什麼K3應該沒有時間的原因。
降低使用者部署和管理 Kubernetes 的複雜性，無需管理複雜的元件，隻需單擊一下即可開箱即用地部署它們。
沒有努力維護較新的鍵值資料，如ETCD。
綜上所述，減少資源消耗，讓使用者還可以在低計算資源的裝置上運作Kubernetes叢集，等等，或許K3s的優勢。
此外，最近宣布開源的Fleet是Rancher以牛的方式管理的那種子叢集，確定了大規模Kubernetes叢集的集中管理優勢體驗。
"重點不再是叢集的應用程式部署，而是從更高次元将叢集作為叢集組進行管理。
容器和 AI 究竟可以做什麼？
如今，無論是AI行業的專業廠商，還是實際的AI訓練場景應用，都有越來越多的AI企業在容器上運作，這一舉動已逐漸成為探索業務落地的重要問題之一。
例如，在AI模型的訓練中，大量通路或讀取資料、圖檔或源檔案注定了大規模的計算能力消耗，但典型的大規模計算場景正是容器所需要的。
但複雜的感覺是，人工智能實際上在集裝箱場景中着陸有點挑戰性。
例如，資源共享劃分的粒度。
今天，Kubernetes本身并不太有能力共享和排程CPU資源。
蔣鵬表示，由于英偉達官員沒有實作vGPU，導緻标準的Kubernetes或社群版的Kubernetes叢集，資源排程在粒度上比較粗糙，資源使用率也不太高。
此外，在容器化場景中，小檔案和海量檔案處理的性能可能并不理想，用于模型訓練碎片。
盡管如此，Gartner對人工智能的2019年預測顯示了"态度"。
當企業首席資訊官将人工智能作為首要考慮因素時，Kubernetes的關鍵作用不容低估。
Gartner表示，Kubernetes将成為内部AI應用程式的首選操作環境和平台。
容器和無伺服器将使機器學習模型能夠作為獨立的功能，以更低的成本運作AI應用程式，這對Kubernetes來說是一個很好的前景。
您如何看待 Kubernetes 的成熟度和穩定性？
附：面試官簡介
- 完成 -
量子位 QbitAI 頭條簽名
關注我們，搶先了解尖端技術