云時(shí)代運(yùn)維轉(zhuǎn)型必讀：容器運(yùn)維模式的五大場景

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

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

1)Master

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

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

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

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

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

2)Node

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

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

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

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

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

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

3)Api-server

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

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

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

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

總結(jié)

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

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

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

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

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

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

廣告

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