云時代運維轉(zhuǎn)型必讀:容器運維模式的五大場景

2021-03-03    分類: 網(wǎng)站建設(shè)

其實我挺早就接觸Docker和Kubernetes,時間大概在3、4年前吧,但是由于當時所在技術(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ù)的后臺線程。邏輯上,每個控制器是一個單獨的進程,但為了降低復雜性,它們都被編譯成單個二進制文件,并在單個進程中運行。

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等容器運行時,作用當然就是用于運行容器。

對于以上的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ā)更深層次的思考,深入了解容器之后,我們會自然而然地去學習業(yè)務(wù)最主流的編排工具——Kubernetes。

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

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

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

分享名稱:云時代運維轉(zhuǎn)型必讀:容器運維模式的五大場景
文章地址:http://bm7419.com/news/104016.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站導航、關(guān)鍵詞優(yōu)化自適應(yīng)網(wǎng)站、品牌網(wǎng)站建設(shè)外貿(mào)建站、網(wǎng)站設(shè)計公司

廣告

聲明:本網(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)

成都網(wǎng)站建設(shè)公司