Kubernetesoperator的示例分析

小編給大家分享一下Kubernetes operator的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)主營江城網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,APP應(yīng)用開發(fā),江城h5微信平臺小程序開發(fā)搭建,江城網(wǎng)站營銷推廣歡迎江城等地區(qū)企業(yè)咨詢

Operator 在2016年就被引入社區(qū)了， CoreOS 推出它旨在簡化復(fù)雜有狀態(tài)應(yīng)用管理。Operator是一個(gè)感知應(yīng)用狀態(tài)的控制器，通過擴(kuò)展 Kubernetes API 來自動(dòng)創(chuàng)建、管理和配置應(yīng)用實(shí)例。 Operator 基于 CRD （Custom Resource Definition）擴(kuò)展資源對象，并通過控制器來保證應(yīng)用處于預(yù)期狀態(tài)。
下面舉個(gè)例子，比如etcd operator通過下面的三個(gè)步驟模擬了管理etcd集群的行為：
1、通過 Kubernetes API 觀察集群的當(dāng)前狀態(tài)；
2、分析當(dāng)前狀態(tài)與期望狀態(tài)的差別；
3、調(diào)用k8s API消除這些差別。

下面從不同的角度來聊聊Operator
1、operator與docker
我們先聊一聊docker。docker有非常多的優(yōu)點(diǎn)，比如隔離、執(zhí)行效率等等。但是在我看來，docker的核心價(jià)值，或者說顛覆性的成果就是設(shè)計(jì)了鏡像流程，提供標(biāo)準(zhǔn)化的交付方式。就從單個(gè)的應(yīng)用實(shí)例來講，標(biāo)準(zhǔn)化、一致性的環(huán)境解決了應(yīng)用的runtime的問題，將應(yīng)用的部署、應(yīng)用的依賴進(jìn)行了統(tǒng)一的封裝。將應(yīng)用的部署方式從手工作坊的部署方式帶入了標(biāo)準(zhǔn)化的工業(yè)時(shí)代。當(dāng)然這也帶來了一定的磁盤額外損耗。但是在硬件飛速發(fā)展的今天，這點(diǎn)磁盤損耗幾乎不成問題。而且借助于聯(lián)合文件系統(tǒng)和鏡像優(yōu)化，磁盤的損耗問題幾乎不用考慮。
時(shí)至今日，越來越少的項(xiàng)目采用源碼進(jìn)行部署。以前一個(gè)開源項(xiàng)目往往配上一篇冗長的安裝文檔，教你如何安裝、如何運(yùn)行?，F(xiàn)在，基本上活躍的開源項(xiàng)目都提供了基于容器的部署方式，你只需要拉下鏡像run一下就可以使用。docker大大提升了交付的效率，降低了使用的門檻，有效避免了部署的故障。
operator跟docker是相似的，而其主要的交付對象從單個(gè)的應(yīng)用實(shí)例，擴(kuò)展到了多實(shí)例、分布式的系統(tǒng)上。以往部署一個(gè)分布式系統(tǒng)需要啟動(dòng)多個(gè)容器，然后進(jìn)行復(fù)雜的配置，而現(xiàn)在只要?jiǎng)?chuàng)建一個(gè)CRD。operator將自動(dòng)進(jìn)行分布式系統(tǒng)中需要的各個(gè)資源的創(chuàng)建和部署。從這個(gè)角度上來說，operator的目標(biāo)是實(shí)現(xiàn)分布式系統(tǒng)的標(biāo)準(zhǔn)化交付。

2、operator與Helm
現(xiàn)在我們一般意義上的編排，也就是orchestration，還有另一種翻譯就是編配。在維基百科的定義為描述復(fù)雜計(jì)算機(jī)系統(tǒng)、中間件（middleware）和業(yè)務(wù)的自動(dòng)化的安排、協(xié)調(diào)和管理。根據(jù)我個(gè)人的經(jīng)驗(yàn)，總結(jié)編排的典型特征主要包括服務(wù)的版本管理、服務(wù)的生命周期管理、多個(gè)資源多種資源的管理、參數(shù)化以及模板化。
最早接觸編排概念，是通過openstack的heat項(xiàng)目。openstack中從計(jì)算、存儲到網(wǎng)絡(luò)有很多的系統(tǒng)。而如果部署一個(gè)完整的應(yīng)用虛擬機(jī)，需要多種資源的協(xié)同參與。heat項(xiàng)目就是為此目標(biāo)而生。其通過模板和參數(shù)對多種資源進(jìn)行編排，實(shí)現(xiàn)了對一個(gè)完整服務(wù)的創(chuàng)建、部署、修改、刪除等生命周期管理。

在k8s中，也有許多編排項(xiàng)目，目前比較熱門的是包管理工具Helm。如果說docker是奠定的單實(shí)例的標(biāo)準(zhǔn)化交付，那么Helm則是集群化多實(shí)例、多資源的標(biāo)準(zhǔn)化交付。
operator的管理不僅限于容器(pod)，也可以是多個(gè)資源(比如svc域名等等)，從這個(gè)角度上來說，operator跟Helm一樣，也是具有編排的能力的。從編排角度來看，在初學(xué)者看來，Helm跟operator有非常多的共性，很難對兩者的作用進(jìn)行區(qū)分。Helm也可以完成分布式系統(tǒng)的部署。那么operator跟Helm又有什么樣的區(qū)別呢？Helm的側(cè)重點(diǎn)在于多種多個(gè)的資源管理，而對生命周期的管理主要包括創(chuàng)建更新和刪除。Helm通過命令驅(qū)動(dòng)整個(gè)的生命周期。
而operator對于資源的管理則不僅是創(chuàng)建和交付。由于其可以通過watch的方式獲取相關(guān)資源的變化事件，因此可以實(shí)現(xiàn)高可用、可擴(kuò)展、故障恢復(fù)等運(yùn)維操作。因此operator對于生命周期的管理不僅包括創(chuàng)建，故障恢復(fù)，高可用，升級，擴(kuò)容縮容，異常處理，以及最終的清理等等。
那你說這些功能能不能用Helm來實(shí)現(xiàn)，其實(shí)我覺得有一部分功能應(yīng)該也是可以的。但是這里面就涉及到一個(gè)問題，就是這些功能無法在編排中直接實(shí)現(xiàn)，就需要通過腳本或者程序的方式固化到鏡像中。大量的運(yùn)維代碼被腳本化。會導(dǎo)致維護(hù)這些腳本的復(fù)雜度提高，可讀性變差。除此之外，還有一個(gè)潛在的風(fēng)險(xiǎn)無法解決的就是，當(dāng)這些容器實(shí)例全部掛掉的時(shí)候，則完全無法自動(dòng)恢復(fù)了，即使有備份數(shù)據(jù)。這時(shí)候最終還會依賴于人工的介入，仍然無法達(dá)到自動(dòng)化、智能化的目標(biāo)。
operator則在實(shí)現(xiàn)自動(dòng)化的同時(shí)實(shí)現(xiàn)了智能化。其主要的工作流程是根據(jù)當(dāng)前的狀態(tài)，進(jìn)行智能分析判斷，并最終進(jìn)行創(chuàng)建、恢復(fù)、升級等操作。而位于容器中的腳本，因?yàn)槿狈芏嗳值男畔?，僅靠自身是無法無法達(dá)實(shí)現(xiàn)這些全部的功能的。而處于第三方視角的operator，則可以解決這個(gè)問題。他可以通過側(cè)面的觀察，獲取所有的資源的狀態(tài)和信息，并且跟預(yù)想/聲明的狀態(tài)進(jìn)行比較。通過預(yù)置的分析流程進(jìn)行判斷，從而進(jìn)行相應(yīng)的操作，并最終達(dá)到聲明狀態(tài)的一個(gè)目的。這樣所有的運(yùn)維邏輯就從鏡像中抽取出來，集中到operator里去。層次和邏輯也就更加清楚，容易維護(hù)，也更容易交付和傳承。
如果把Helm比作rpm，那么operator就是systemd。rpm負(fù)責(zé)應(yīng)用的安裝、刪除，而systemd則負(fù)責(zé)應(yīng)用的啟動(dòng)、重啟等等操作。當(dāng)然二者并不是互斥的，目前operator一種比較便捷的部署方式就是通過Helm進(jìn)行部署。

3、operator與controller
operator可以說是另外一種controller。目前的controller manager集合的主要是基礎(chǔ)的、通用的資源概念，比如rs/deployment，而對于特定的應(yīng)用或者服務(wù)（如etcdcluster，都可以認(rèn)為是一種資源），則放權(quán)給了第三方，也就是CRD。用戶可以通過自定義的資源描述，以及自研的controller/operator進(jìn)行接入。因此controller和operator的關(guān)系有點(diǎn)類似于標(biāo)準(zhǔn)庫和第三方庫的關(guān)系。
一般來說，對于不同的應(yīng)用一般來說需要不同的operator進(jìn)行處理。這時(shí)我們再來想下，以replicaset controller為例。rs的主要功能是保持副本數(shù)。當(dāng)有pod因某種原因掛掉/刪除，對于無狀態(tài)的應(yīng)用來說，恢復(fù)的方式就是再增加對應(yīng)的pod數(shù)量。那么從這個(gè)角度來說，對于無狀態(tài)的應(yīng)用來說，rs controller其實(shí)就是無狀態(tài)應(yīng)用的operator。

operator的核心價(jià)值
我們原先常常講devops，就是運(yùn)維和開發(fā)的結(jié)合，提升開發(fā)交付的效率和質(zhì)量。這也帶來了一個(gè)趨勢，就是運(yùn)維和開發(fā)一體化。比如原來開發(fā)應(yīng)用的人，通過docker鏡像的制作，將應(yīng)用的部署啟動(dòng)等固化在了dockerfile/鏡像中，分擔(dān)了運(yùn)維的許多部署工作。但是實(shí)際上運(yùn)維的工作內(nèi)容和范圍其實(shí)非常廣，特別是現(xiàn)在的分布式的系統(tǒng)，包括集群化部署、高可用、故障恢復(fù)、系統(tǒng)升級等等工作。而這些是無法僅用dockerfile/鏡像進(jìn)行固化的。
operator提供了一種可能，或者說是提供了一個(gè)很好的框架，就是把運(yùn)維的經(jīng)驗(yàn)沉淀為代碼，實(shí)現(xiàn)運(yùn)維的代碼化、自動(dòng)化、智能化。以往的高可用、擴(kuò)展收縮，以及故障恢復(fù)等等運(yùn)維操作，都通過operator進(jìn)行沉淀下來。從長期來看，將會推進(jìn)dev、ops、devops的深度一體化。將運(yùn)維經(jīng)驗(yàn)、應(yīng)用的各種方案和功能通過代碼的方式進(jìn)行固化和傳承，減少人為故障的概率，提升整個(gè)運(yùn)維的效率。
operator的許多理念并不是現(xiàn)在才有的。在yarn中的application manager，mesos中的framework，都可以尋找到operator的一些蛛絲馬跡。而之所以說operator將可能成為docker之后的又一項(xiàng)重大變革，其另外一個(gè)重要的因素就是operator是站在kubernetes的巨人肩膀上。
kubernetes強(qiáng)化了基礎(chǔ)資源的封裝，并保持了靈活性和可定制性。kubernetes從傳統(tǒng)的資源(cpu/mem)的交付，轉(zhuǎn)為了pod/svc/pv/pvc等資源的交付，擴(kuò)展了資源的概念，將域名、負(fù)載均衡、存儲等等必要或相關(guān)的概念也都進(jìn)行了封裝。而operator這些公共的資源基礎(chǔ)上，將應(yīng)用集群也視為了一種資源，可以向用戶提供。并且借助于k8s已有的工作機(jī)制和框架，從而更為便捷靈活的實(shí)現(xiàn)。
operator的變革雖然重大，但是由于分布式應(yīng)用主要限于工業(yè)生產(chǎn)領(lǐng)域，因此對一般的開發(fā)而言可能最終使用場景有限。因此我判斷從全局看，operator的最終影響力有限，但在許多分布式應(yīng)用的垂直領(lǐng)域，會產(chǎn)生巨大的影響。

最后使用operator的前提就是可以實(shí)現(xiàn)容器化。即應(yīng)用可以使用容器來進(jìn)行應(yīng)用的自動(dòng)化的部署。operator化不僅僅是開發(fā)一個(gè)operator的程序，還需要結(jié)合鏡像的制作、交付、封裝等工作。仍然是需要大量的開發(fā)工作的。但是一旦成熟穩(wěn)定，也會帶來巨大的運(yùn)維收益和長期的效果。

以上是“Kubernetes operator的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

當(dāng)前名稱：Kubernetesoperator的示例分析
路徑分享：http://www.jiaotiyi.com/article/pspgep.html