其實我挺早就接觸Docker和Kubernetes，時間大概在3、4年前吧，但是由于當(dāng)時所在技術(shù)團隊的業(yè)務(wù)模式所限制，還沒有真正對容器云有技術(shù)需求，所以我更多還是以一種技術(shù)玩具的心態(tài)接觸容器技術(shù)。

直到去年開始才正式接觸基于容器云平臺的技術(shù)架構(gòu)，我從業(yè)務(wù)運維和DevOps的角度來看，容器云平臺與之前的物理機和虛擬機等IaaS層基礎(chǔ)上的運維模式有著非常大的差異。

1)Master

區(qū)別于物理組件，邏輯組件是指在程序內(nèi)的虛擬概念，例如運行在Master的邏輯組件有kube-apiserver、kube-controller-manager、kube-scheduler。

kube-apiserver用于暴露Kubernetes API。任何的資源請求/調(diào)用操作都是通過kube-apiserver提供的接口進行。

kube-controller-manager運行管理控制器，它們是集群中處理常規(guī)任務(wù)的后臺線程。邏輯上，每個控制器是一個單獨的進程，但為了降低復(fù)雜性，它們都被編譯成單個二進制文件，并在單個進程中運行。

kube-scheduler監(jiān)視新創(chuàng)建沒有分配到Node的Pod，為Pod選擇一個Node。

這幾個組件的用途不作特別展開，我們后面將詳細聊聊Apiserver。

2)Node

Node是Kubernetes中的工作節(jié)點，最開始被稱為minion。一個Node可以是VM或物理機。每個Node(節(jié)點)具有運行pod的一些必要服務(wù)，并由Master組件進行管理。

然后介紹運行于Node節(jié)點的組件：kubelet、kube-proxy、CRI(一般是docker)。

kubelet是主要的節(jié)點代理，它會監(jiān)視已分配給節(jié)點的pod，具體功能如：安裝Pod所需的volume;下載Pod的Secrets;Pod中運行的docker(或experimentally，rkt)容器;定期執(zhí)行容器健康檢查等等。

kube-proxy通過在主機上維護網(wǎng)絡(luò)規(guī)則并執(zhí)行連接轉(zhuǎn)發(fā)來實現(xiàn)Kubernetes服務(wù)抽象。

Docker等容器運行時，作用當(dāng)然就是用于運行容器。

對于以上的Kubernetes的Master和Node的節(jié)點模式，在很多支持分布式架構(gòu)的軟件中都是類似的，如Hadoop等。他們的Master節(jié)點往往需要有3個以上，以實現(xiàn)高可用架構(gòu)。很多軟件架構(gòu)也采取了這樣的設(shè)計方式，都是為了生產(chǎn)環(huán)境所需的高可用性服務(wù)。

3)Api-server

前面介紹過Master和Node，它們之間從Master (apiserver)到集群有兩個主要的通信路徑。第一個是從Apiserver到在集群中的每個節(jié)點上運行的kubelet進程。第二個是通過Apiserver的代理功能從Apiserver到任何Node、pod或service。

所以說Apiserver對于Master-Node模式來說是非常重要的溝通橋梁。

從Apiserver到kubelet的連接用于獲取pod的日志，通過kubectl來運行pod，并使用kubelet的端口轉(zhuǎn)發(fā)功能。這些連接在kubelet的HTTPS終端處終止。

從Apiserver到Node、Pod或Service的連接默認為HTTP連接，因此不需進行認證加密。也可以通過HTTPS的安全連接，但是它們不會驗證HTTPS端口提供的證書，也不提供客戶端憑據(jù)，因此連接將被加密但不會提供任何誠信的保證。這些連接不可以在不受信任/或公共網(wǎng)絡(luò)上運行。

總結(jié)

從過去的【單體式應(yīng)用+物理機】，到現(xiàn)在【微服務(wù)應(yīng)用+容器云】的運行環(huán)境的變革，需要運維工程師同步改變以往的運維技術(shù)思維。新技術(shù)的應(yīng)用，會引發(fā)更深層次的思考，深入了解容器之后，我們會自然而然地去學(xué)習(xí)業(yè)務(wù)最主流的編排工具——Kubernetes。

Kubernetes前身是谷歌的Borg容器編排管理平臺，它充分體現(xiàn)了谷歌公司多年對編排技術(shù)的好實踐。而容器云字面意思就是容器的云，實際指的是以容器為單位，封裝環(huán)境、提供構(gòu)建、發(fā)布、運行分布式應(yīng)用平臺。

而運維工程師在面對業(yè)界更新迭代極快的技術(shù)潮流下，需要選定一個方向進行深耕，無疑，Kubernetes是值得我們?nèi)ド钊雽W(xué)習(xí)的，畢竟它戰(zhàn)勝了幾乎所有的編排調(diào)度工具，成為業(yè)內(nèi)編排標(biāo)準(zhǔn)。

我們通過搭建容器云環(huán)境下的應(yīng)用運行平臺，并實現(xiàn)運維自動化，快速部署應(yīng)用、彈性伸縮和動態(tài)調(diào)整應(yīng)用環(huán)境資源，提高研發(fā)運營效率，最終實現(xiàn)自身的運維價值。

本文名稱：云時代運維轉(zhuǎn)型必讀：容器運維模式的五大場景
網(wǎng)頁網(wǎng)址：http://jinyejixie.com/news16/104016.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機、微信公眾號、響應(yīng)式網(wǎng)站、小程序開發(fā)、軟件開發(fā)、自適應(yīng)網(wǎng)站

廣告

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