這篇文章主要介紹docker中19-k8s的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

成都創(chuàng)新互聯(lián)主營冊亨網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,成都app軟件開發(fā),冊亨h5小程序設計搭建,冊亨網(wǎng)站營銷推廣歡迎冊亨等地區(qū)企業(yè)咨詢

    Docker的第一類編排工具：

        1） docker compose（docker原生）：只能對一個主機上的容器進行編排，無法編排多個主機上的容器；

        2） docker swarm（docker原生）：可以對多個主機上的容器進行編排。

        3） docker machine（docker原生）：可以將一個主機迅速初始化到docker swarm集群里。

        以上三個稱為docker三劍客。

    Docker的第二類編排工具： 

         mesos：它不是docker的編排工具，而是資源分配工具。所以mesos必須要依賴于容器編排框架marathon。

    Docker的第三類編排工具：

        kubernetes(簡稱k8s)：這個容器編排工具占用了80%的市場份額。

        有了容器和容器編排技術，對持續(xù)集成（CI）、持續(xù)交付Delivery（CD）和持續(xù)部署Deployment（CD）的需求變?yōu)榭赡?，這也就是DevOps的理念。

        注意：DevOps并不是一種技術，而是一種運動，一種文化。

k8s的介紹

    k8s是2014年google對外開放的。

    Borg是谷歌內(nèi)部非常棒的容器編排工具，k8s就是站在Borg基礎上開發(fā)出來的，所以k8s從一出世，就吸引了太多太多人的關注，直到今天為止，它也確實沒有辜負人們的期望。

    2017年是容器技術最輝煌的一年，AWS、微軟的云技術、阿里云等云廠商開始對外宣布，他們支持k8s。

    k8s的代碼托管在github之上：https://github.com/kubernetes/kubernetes/releases

    k8s的特性：

        1）可以自動裝箱，即可以自動完成容器的部署，而不影響可用性；

        2）可以自我修復，如果容器崩潰了，可以1s內(nèi)重新啟動，有了k8s后，我們不再關注個體，而是關注群體，有一個個體壞了，把它干掉，換一個新的就行了；

        3）可以自動實現(xiàn)水平擴展，一個容器不夠，再啟動一個就是了；

        4）可以自動實現(xiàn)服務發(fā)現(xiàn)和負載均衡，也就是說可以自動發(fā)現(xiàn)每個微服務之間的關系，同時也可以自動對容器內(nèi)多個服務做負載均衡；

        5） 可以實現(xiàn)自動發(fā)布和回滾；

        6） 可以實現(xiàn)密鑰和配置管理,也就是說每個容器不是加載容器內(nèi)的配置文件，而是加載遠程服務器上（配置中心）的配置文件；

        7）可以實現(xiàn)存儲編排；

        8）可以實現(xiàn)任務的批量處理執(zhí)行。

    k8s是一個有中心節(jié)點架構的集群，由master節(jié)點（至少三個）和nodes節(jié)點(運行容器的節(jié)點)組成。客戶的啟動容器等請求會先發(fā)給master節(jié)點，master節(jié)點有個調(diào)度器會分析node節(jié)點資源(cpu、內(nèi)存)的可用狀態(tài)，找到最佳適配的node來啟動用戶請求的容器。

        

    master上的第一個組件叫調(diào)度器（Scheduler），它的工作原理有兩步：第一步調(diào)度器先做預選，即先評估到底有多少個node是符合容器需求的；第二步調(diào)度器再做優(yōu)選，即在符合的node中選擇一個最佳的node來運行容器。

    如果node宕機了，那么托管在node之上的所有容器也就不見了。此時k8s可以在其他節(jié)點上創(chuàng)建出來和宕機node上一模一樣的容器。

    另外，master上還有一個組件叫控制器，它會不停的Loop，用來周期性監(jiān)控每個node的健康狀態(tài)；控制器是有多個的（因為有至少三個master）。

    再者，master上還有一個組件叫控制器管理器(Controller-Mnager)，控制器管理器用來監(jiān)控著每個控制器的健康。

    在k8s上運行的最小單元不是容器，而是pod。pod可以理解為容器外殼，pod里面裝的就是放容器的。一個pod里面可以放多個容器，這些容器可以共享一個底層的網(wǎng)絡名稱空間、存儲卷，這樣一來，pod對外更像一個虛擬機。

    一般說來，一個pod里只放一個容器；如果一個pod必須要放多個容器，那么里面有一個是主容器，其他都是輔助容器，輔助容器主要是為了輔助主容器的主程序的某些功能而設置的。

    一個pod里面的所有容器只能運行在一個node上的。

    pod是k8s調(diào)用的原子單元，是個邏輯概念。

    最終用戶無需再關注pod運行在哪個node之上，這也就是云的概念，也就是把很多的node做為一個資源池，來進行統(tǒng)一管理。

    pod盡量由控制器管理，而不要手工管理。

    pod可以分為兩類：

        a)自主式pod：即自我管理的pod。我們創(chuàng)建Pod，首先交給Apiserver，然后調(diào)度器調(diào)度給指定的node節(jié)點，。如果容器需要啟動，由node上kubelet組件來完成；如果node發(fā)生故障，那么pod也就消失了。

        b）控制器管理的Pod(建議創(chuàng)建這種Pod)：這種Pod是有生命周期的對象。由master上的調(diào)度器將pod調(diào)度至某node進行運行或者停止。pod控制器后很多種，最早的一種叫Replicaton Controller（副本控制器），意思是當我們啟動一個pod時，如果這個pod不夠了，會再啟動一個，這叫副本。副本控制器就控制副本的數(shù)量，一旦副本少了，就會自動再加一個。如果副本多于定義的個數(shù)，會被停止。也就是副本必須精確符合人們定義的個數(shù)。副本個數(shù)至少要兩個。如果一個pod副本所在node宕機了，那么會向ApiServer重新請求，Apiserver借助調(diào)度器，到新節(jié)點創(chuàng)建一個新pod。滾動更新：比如我有個1.0版本的鏡像，現(xiàn)在又有個1.1版本的鏡像，那么控制器管理的pod就會新啟動一個1.1版本的Pod，然后刪除1.0版本的pod，這叫滾動更新。同樣，k8s也支持回滾更新。到了k8s新版本，又出現(xiàn)了Replica Set（副本集控制器），但是該控制器并不直接使用，而是使用一個聲明更新的控制器Deployment，這個也是用的最多的。但是Deployment控制器只能管理那些無狀態(tài)的應用。而有狀態(tài)的應用是由Stateful Set控制器管理。對于Deployment控制器，它還支持二級控制器，叫HPA（horizontalPodAutoscaler），該控制器可以自動水平擴展pod，也就是當一個pod壓力大時，HPA控制器會自動水平擴展加幾個新的pod來分解壓力，具體加幾個，HPA會根據(jù)當前節(jié)點的cpu、內(nèi)存負荷來計算，一旦訪問量小了，HPA還會自動減少pod個數(shù)。如果我們想在一個Node上只運行一個副本，需要用DaemonSet控制器。如果需要運行作業(yè)（如備份，清理數(shù)據(jù)等），需要conjob控制器。以上所講的都是pod的控制器，用來管理不同類型的pod。

    為了實現(xiàn)給pod分組，可以給pod打上標簽（Lablel），這樣就可以進行分組了。

    標簽選擇器（Lablel Selector）組件：是一個根據(jù)標簽來過濾符合要求的資源機制。

    客戶端是通過service來找到pod的，service是通過pod的標簽選擇器來找到pod的。service只是一個iptables方式的net地址轉(zhuǎn)換路由規(guī)則，不過到了k8s最新版本1.11，支持了ipvs方式的分發(fā)規(guī)則，支持各種調(diào)度算法，這也就實現(xiàn)了負載均衡。。裝完k8s后，就需要創(chuàng)建一個DNS pod，這是因為service的名字需要DNS服務器來進行解析。這種pod是k8s的組成部分，被稱為k8s基礎架構的pod，也被稱為k8s的附件，英文名叫AddOns。這種DNS是用來解析service名字的，而不是pod的，并且DNS名稱解析是K8s自動維護的，不需要我們?nèi)斯じ深A。

    一句話，service里面的地址存在iptables net或者ipvs里面，service是用來調(diào)度流量的，而不會啟動或者停止容器的。

    然而，pod的啟動或者關閉、創(chuàng)建等是由控制器來做的，比如我們想創(chuàng)建一個nginx pod，就先創(chuàng)建一個Nginx控制器，nginx控制器自動就會幫我們創(chuàng)建nginx pod；然后我們再創(chuàng)建一個nginx service，把nginx pod發(fā)布出去。

    service有兩種類型，一種是調(diào)度流量僅供k8s內(nèi)部來使用，還有一種可以調(diào)度流量供k8s外部來使用。

    

     上圖中，我們應該明白了service是用來分發(fā)流量給pod的，控制器是用來創(chuàng)建、啟動和停止pod的，標簽選擇器是service用來根據(jù)標簽來識別每個pod的。 

    在k8s運行中，需要三種網(wǎng)絡，第一種網(wǎng)絡是需要各pod在一個網(wǎng)絡中，而service在另外一個網(wǎng)絡，即service的地址和pod的地址是不同網(wǎng)段的，pod的地址是配置在pod內(nèi)部的網(wǎng)絡名稱空間，是可以ping通的，但service的地址虛擬的，是假地址，只存在于iptables 或者ipvs里面。另外node又存在另外一個網(wǎng)絡，這樣就有三種網(wǎng)絡。所以外部先到達node網(wǎng)絡，然后再到service網(wǎng)絡，最后才到pod網(wǎng)絡。

    那么pod之間是怎么通信的呢。同一個pod內(nèi)的多個容器間通過lo進行通信；各pod之間通過overlay network（疊加網(wǎng)絡）進行通信，即使pod之間跨主機，通信也沒問題；pod與service之間通過網(wǎng)關（也就是docker 零橋的地址）進行通信。

   node上有個組件叫kube-proxy，它負責和ApiServer進行通信，kube-proxy一旦發(fā)現(xiàn)service背后的pod地址發(fā)生變化，kube-proxy就會把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy來實現(xiàn)的。

    在master(注意，master是有多個的)上的數(shù)據(jù)并不存在master本地，而是存在共享存儲DB中，這個共享DB叫etcd。etcd里面數(shù)據(jù)是以key-value形式存儲的，集群中所有狀態(tài)信息都在etcd中，所以ectd要做冗余，一般至少三個節(jié)點。etcd是通過https方式訪問的。etcd有一個端口是用來集群內(nèi)部通信，另外 一個端口用來對ApiServer通信。這樣一來，etcd內(nèi)部通訊需要點對點的專門證書，對ApiServer通信就要另外一套證書。另外，ApiServer向客戶端提供服務，也需要另外一套證書。同樣，ApiServer和node上的kubelet組件和kube-proxy組件通信也需要CA證書。所以做K8s的部署，需要建立5個CA，這也是最難的。

    下面我們把k8s歸類為以下三類節(jié)點：master、node（上面有pod）和ectd（存儲集群狀態(tài)信息），它們彼此之間都是由http或https進行通信的。我們知道網(wǎng)絡也分為：pod網(wǎng)絡，service網(wǎng)絡和node網(wǎng)絡。所以我們要構建出三類網(wǎng)絡來，但是K8s自己不提供這三類網(wǎng)絡，而是要依賴于第三方插件CNI。

    

    k8s通過CNI（容器網(wǎng)絡接口）插件體系接入網(wǎng)絡。目前常見的CNI插件是flannel。其實網(wǎng)絡只提供兩個功能，一個是給pod、service等提供ip地址的功能，另外還需要網(wǎng)絡能提供網(wǎng)絡測試的功能，來隔離不同Pod之間的通信。

    flannel插件只支持網(wǎng)絡配置（供ip地址的功能），但不支持網(wǎng)絡策略。

    CNI里面的插件calico可以同時支持網(wǎng)絡配置和網(wǎng)絡策略，但是calico的部署和使用非常難。

    于是，又有了第三個CNI插件canel，它用flannel提供網(wǎng)絡配置，用calico提供網(wǎng)絡策略。這些插件可以作為k8s之上的守護進程運行，也可以在k8s里面的容器運行。

    名稱空間，可以實現(xiàn)不同類pod運行在不同的名稱空間中。比如可以把名稱空間分為開發(fā)名稱空間、生產(chǎn)名稱空間等。這樣通過網(wǎng)絡策略來定義名稱空間之間、同一個名稱空間的pod之間的網(wǎng)絡行為。

    本小節(jié)總結：

        1）master/node:

            a)master上包含的組件：API Server，Scheduler（調(diào)度器），Controller-Manager（控制器管理器）

            b)node上包含的組件：kubelet（用來和master通信的一個組件，并試圖啟動本node上的容器等工作；另外啟動容器是由容器引擎來操作的，最流行的容器引擎是docker）、docker引擎（也可以用其他容器引擎）、kube-proxy（負責和ApiServer進行通信，kube-proxy一旦發(fā)現(xiàn)service背后的pod地址發(fā)生變化，kube-proxy就會把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy來實現(xiàn)的）

        2）Pod：Lablel（標簽,kv格式），Lablel Selector（標簽選擇器）

 生產(chǎn)中k8s的最終架構圖（PaaS）

以上是“docker中19-k8s的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關知識，歡迎關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道！

網(wǎng)頁標題：docker中19-k8s的示例分析-創(chuàng)新互聯(lián)
當前URL：http://aaarwkj.com/article48/pphhp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設、關鍵詞優(yōu)化、企業(yè)網(wǎng)站制作、網(wǎng)站建設、ChatGPT、服務器托管

廣告

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