剑网3指尖江湖职业推荐 www.1468054.com

圖0:聊一聊Kubernetes Operator的核心價值

不聊什么

在開始聊 Operator 前,先說說這篇文章里我們不聊什么。我們這里不聊 Operator 的具體實現,不聊 Operator 的由來歷史,不聊 Operator 的 hello world。如果想了解這些,其實可以從別的很多文章中可以查找到。這里我們把一些常見的概念,如 Docker、Controller、Helm、編排等,與 Operator 進行一下對比,從這些概念的不同角度來聊聊 Operator,并聊聊在我眼中的 Operator 的核心價值。

Operator 與 Docker

圖1:聊一聊Kubernetes Operator的核心價值

我們先聊一聊 Docker。Docker 有非常多的優點,比如隔離、執行效率等等。但是在我看來,Docker 的核心價值,或者說顛覆性的成果就是設計了鏡像流程,提供標準化的交付方式。就從單個的應用實例來講,標準化、一致性的環境解決了應用的 runtime 的問題,將應用的部署、應用的依賴進行了統一的封裝。將應用的部署方式從手工作坊的部署方式帶入了標準化的工業時代。當然這也帶來了一定的磁盤額外損耗。但是在硬件飛速發展的今天,這點磁盤損耗幾乎不成問題。而且借助于聯合文件系統和鏡像優化,磁盤的損耗問題幾乎不用考慮。

時至今日,越來越少的項目采用源碼進行部署。以前一個開源項目往往配上一篇冗長的安裝文檔,教你如何安裝、如何運行。現在,基本上活躍的開源項目都提供了基于容器的部署方式,你只需要拉下鏡像 run 一下就可以使用。Docker 大大提升了交付的效率,降低了使用的門檻,有效避免了部署的故障。

Operator 跟 Docker 是相似的,而其主要的交付對象從單個的應用實例,擴展到了多實例、分布式的系統上。以往部署一個分布式系統需要啟動多個容器,然后進行復雜的配置,而現在只要創建一個 CRD。Operator 將自動進行分布式系統中需要的各個資源的創建和部署。從這個角度上來說,Operator 的目標是實現分布式系統的標準化交付。

Operator 與編排 /Helm

現在我們一般意義上的編排,也就是 orchestration,還有另一種翻譯就是編配。在維基百科的定義為描述復雜計算機系統、中間件(middleware)和業務的自動化的安排、協調和管理。根據我個人的經驗,總結編排的典型特征主要包括服務的版本管理、服務的生命周期管理、多個資源多種資源的管理、參數化以及模板化。

最早接觸編排概念,是通過 OpenStack 的 Heat 項目。Openstack 中從計算、存儲到網絡有很多的系統。而如果部署一個完整的應用虛擬機,需要多種資源的協同參與。Heat 項目就是為此目標而生。其通過模板和參數對多種資源進行編排,實現了對一個完整服務的創建、部署、修改、刪除等生命周期管理。

圖2:聊一聊Kubernetes Operator的核心價值

在 Kubernetes 中,也有許多編排項目,目前比較熱門的是包管理工具 Helm。如果說 Docker 是奠定的單實例的標準化交付,那么 Helm 則是集群化多實例、多資源的標準化交付。

Operator 的管理不僅限于容器 (Pod),也可以是多個資源 (比如 SVC 域名等等),從這個角度上來說,Operator 跟 Helm 一樣,也是具有編排的能力的。從編排角度來看,在初學者看來,Helm 跟 Operator 有非常多的共性,很難對兩者的作用進行區分。Helm 也可以完成分布式系統的部署。那么 Operator 跟 Helm 又有什么樣的區別呢?Helm 的側重點在于多種多個的資源管理,而對生命周期的管理主要包括創建更新和刪除。Helm 通過命令驅動整個的生命周期。

而 Operator 對于資源的管理則不僅是創建和交付。由于其可以通過 watch 的方式獲取相關資源的變化事件,因此可以實現高可用、可擴展、故障恢復等運維操作。因此 Operator 對于生命周期的管理不僅包括創建,故障恢復,高可用,升級,擴容縮容,異常處理,以及最終的清理等等。

那你說這些功能能不能用 Helm 來實現,其實我覺得有一部分功能應該也是可以的。但是這里面就涉及到一個問題,就是這些功能無法在編排中直接實現,就需要通過腳本或者程序的方式固化到鏡像中。大量的運維代碼被腳本化?;岬賈攣ふ廡┙瘧鏡母叢傭忍岣?,可讀性變差。除此之外,還有一個潛在的風險無法解決的就是,當這些容器實例全部掛掉的時候,則完全無法自動恢復了,即使有備份數據。這時候最終還會依賴于人工的介入,仍然無法達到自動化、智能化的目標。

Operator 則在實現自動化的同時實現了智能化。其主要的工作流程是根據當前的狀態,進行智能分析判斷,并最終進行創建、恢復、升級等操作。而位于容器中的腳本,因為缺乏很多全局的信息,僅靠自身是無法無法達實現這些全部的功能的。而處于第三方視角的 Operator,則可以解決這個問題。他可以通過側面的觀察,獲取所有的資源的狀態和信息,并且跟預想 / 聲明的狀態進行比較。通過預置的分析流程進行判斷,從而進行相應的操作,并最終達到聲明狀態的一個目的。這樣所有的運維邏輯就從鏡像中抽取出來,集中到 Operator 里去。層次和邏輯也就更加清楚,容易維護,也更容易交付和傳承。

如果把 Helm 比作 RPM,那么 Operator 就是 Systemd。RPM 負責應用的安裝、刪除,而 Systemd 則負責應用的啟動、重啟等等操作。當然二者并不是互斥的,目前 Operator 一種比較便捷的部署方式就是通過 Helm 進行部署。

Operator 與 Controller

圖3:聊一聊Kubernetes Operator的核心價值

Operator 可以說是另外一種 Controller。目前的 Controller Manager 集合的主要是基礎的、通用的資源概念,比如 RS/Deployment,而對于特定的應用或者服務(如 etcdcluster,都可以認為是一種資源),則放權給了第三方,也就是 CRD。用戶可以通過自定義的資源描述,以及自研的 Controller/Operator 進行接入。因此 Controller 和 Operator 的關系有點類似于標準庫和第三方庫的關系。

一般來說,對于不同的應用一般來說需要不同的 Operator 進行處理。這時我們再來想下,以 ReplicaSet Controller 為例。RS 的主要功能是保持副本數。當有 Pod 因某種原因掛掉 / 刪除,對于無狀態的應用來說,恢復的方式就是再增加對應的 Pod 數量。那么從這個角度來說,對于無狀態的應用來說,RS Controller 其實就是無狀態應用的 Operator。

Operator 的核心價值

我們原先常常講 DevOps,就是運維和開發的結合,提升開發交付的效率和質量。這也帶來了一個趨勢,就是運維和開發一體化。比如原來開發應用的人,通過 docker 鏡像的制作,將應用的部署啟動等固化在了 dockerfile/ 鏡像中,分擔了運維的許多部署工作。但是實際上運維的工作內容和范圍其實非常廣,特別是現在的分布式的系統,包括集群化部署、高可用、故障恢復、系統升級等等工作。而這些是無法僅用 dockerfile/ 鏡像進行固化的。

Operator 提供了一種可能,或者說是提供了一個很好的框架,就是把運維的經驗沉淀為代碼,實現運維的代碼化、自動化、智能化。以往的高可用、擴展收縮,以及故障恢復等等運維操作,都通過 Operator 進行沉淀下來。從長期來看,將會推進 Dev、Ops、DevOps 的深度一體化。將運維經驗、應用的各種方案和功能通過代碼的方式進行固化和傳承,減少人為故障的概率,提升整個運維的效率。

Operator 的許多理念并不是現在才有的。在 Yarn 中的 Application Manager,Mesos 中的 Framework,都可以尋找到 Operator 的一些蛛絲馬跡。而之所以說 Operator 將可能成為 Docker 之后的又一項重大變革,其另外一個重要的因素就是Operator 是站在 Kubernetes 的巨人肩膀上。

Kubernetes 強化了基礎資源的封裝,并保持了靈活性和可定制性。Kubernetes 從傳統的資源 (CPU/MEM) 的交付,轉為了 Pod/SVC/PV/PVC 等資源的交付,擴展了資源的概念,將域名、負載均衡、存儲等等必要或相關的概念也都進行了封裝。而 Operator 這些公共的資源基礎上,將應用集群也視為了一種資源,可以向用戶提供。并且借助于 Kubernetes 已有的工作機制和框架,從而更為便捷靈活的實現。

Operator 的變革雖然重大,但是由于分布式應用主要限于工業生產領域,因此對一般的開發而言可能最終使用場景有限。因此我判斷從全局看,Operator 的最終影響力有限,但在許多分布式應用的垂直領域,會產生巨大的影響。


作者簡介

徐新坤,京東 JDOS 團隊架構師。2013 年加入京東,2014 年開始從事容器化方面工作。目前主要從事 JDOS 2.0 及阿基米德調度平臺的研發和架構,當前主要關注領域為大規模 / 超大規模的容器集群管理與調度。

余下全文(1/3)

本文最初發表在www.infoq.cn,文章內容屬作者個人觀點,不代表本站立場。

分享這篇文章:

請關注我們:

發表評論

電子郵件地址不會被公開。 必填項已用*標注