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

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

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

下面從不同的角度來(lái)聊聊Operator
1、operator與docker
我們先聊一聊docker。docker有非常多的優(yōu)點(diǎn)，比如隔離、執(zhí)行效率等等。但是在我看來(lái)，docker的核心價(jià)值，或者說(shuō)顛覆性的成果就是設(shè)計(jì)了鏡像流程，提供標(biāo)準(zhǔn)化的交付方式。就從單個(gè)的應(yīng)用實(shí)例來(lái)講，標(biāo)準(zhǔn)化、一致性的環(huán)境解決了應(yīng)用的runtime的問(wèn)題，將應(yīng)用的部署、應(yīng)用的依賴(lài)進(jìn)行了統(tǒng)一的封裝。將應(yīng)用的部署方式從手工作坊的部署方式帶入了標(biāo)準(zhǔn)化的工業(yè)時(shí)代。當(dāng)然這也帶來(lái)了一定的磁盤(pán)額外損耗。但是在硬件飛速發(fā)展的今天，這點(diǎn)磁盤(pán)損耗幾乎不成問(wèn)題。而且借助于聯(lián)合文件系統(tǒng)和鏡像優(yōu)化，磁盤(pán)的損耗問(wèn)題幾乎不用考慮。
時(shí)至今日，越來(lái)越少的項(xiàng)目采用源碼進(jìn)行部署。以前一個(gè)開(kāi)源項(xiàng)目往往配上一篇冗長(zhǎng)的安裝文檔，教你如何安裝、如何運(yùn)行?，F(xiàn)在，基本上活躍的開(kāi)源項(xiàng)目都提供了基于容器的部署方式，你只需要拉下鏡像run一下就可以使用。docker大大提升了交付的效率，降低了使用的門(mén)檻，有效避免了部署的故障。
operator跟docker是相似的，而其主要的交付對(duì)象從單個(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è)角度上來(lái)說(shuō)，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ù)化以及模板化。
最早接觸編排概念，是通過(guò)openstack的heat項(xiàng)目。openstack中從計(jì)算、存儲(chǔ)到網(wǎng)絡(luò)有很多的系統(tǒng)。而如果部署一個(gè)完整的應(yīng)用虛擬機(jī)，需要多種資源的協(xié)同參與。heat項(xiàng)目就是為此目標(biāo)而生。其通過(guò)模板和參數(shù)對(duì)多種資源進(jìn)行編排，實(shí)現(xiàn)了對(duì)一個(gè)完整服務(wù)的創(chuàng)建、部署、修改、刪除等生命周期管理。

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

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

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

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

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

本文題目：Kubernetesoperator的示例分析
分享地址：http://jinyejixie.com/article48/pspgep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、關(guān)鍵詞優(yōu)化、網(wǎng)站策劃、小程序開(kāi)發(fā)、品牌網(wǎng)站建設(shè)、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)