<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          Kubernetes面試題超詳細(xì)總結(jié)

          共 4448字,需瀏覽 9分鐘

           ·

          2021-01-17 00:49

          一個(gè)目標(biāo):容器操作;兩地三中心;四層服務(wù)發(fā)現(xiàn);五種 Pod 共享資源;六個(gè) CNI 常用插件;七層負(fù)載均衡;八種隔離維度;九個(gè)網(wǎng)絡(luò)模型原則;十類 IP 地址;百級(jí)產(chǎn)品線;千級(jí)物理機(jī);萬級(jí)容器;相如無億,k8s 有億:億級(jí)日服務(wù)人次。


          一個(gè)目標(biāo):容器操作


          Kubernetes(k8s)是自動(dòng)化容器操作的開源平臺(tái)。這些容器操作包括:部署調(diào)度節(jié)點(diǎn)集群間擴(kuò)展


          具體功能:


          • 自動(dòng)化容器部署和復(fù)制。

          • 實(shí)時(shí)彈性收縮容器規(guī)模。

          • 容器編排成組,并提供容器間的負(fù)載均衡。

          • 調(diào)度:容器在哪個(gè)機(jī)器上運(yùn)行。


          組成:


          • kubectl:客戶端命令行工具,作為整個(gè)系統(tǒng)的操作入口。

          • kube-apiserver:以 REST API 服務(wù)形式提供接口,作為整個(gè)系統(tǒng)的控制入口。

          • kube-controller-manager:執(zhí)行整個(gè)系統(tǒng)的后臺(tái)任務(wù),包括節(jié)點(diǎn)狀態(tài)狀況、Pod 個(gè)數(shù)、Pods 和Service 的關(guān)聯(lián)等。

          • kube-scheduler:負(fù)責(zé)節(jié)點(diǎn)資源管理,接收來自 kube-apiserver 創(chuàng)建 Pods 任務(wù),并分配到某個(gè)節(jié)點(diǎn)。

          • etcd:負(fù)責(zé)節(jié)點(diǎn)間的服務(wù)發(fā)現(xiàn)和配置共享。

          • kube-proxy:運(yùn)行在每個(gè)計(jì)算節(jié)點(diǎn)上,負(fù)責(zé) Pod 網(wǎng)絡(luò)代理。定時(shí)從 etcd 獲取到 service 信息來做相應(yīng)的策略。

          • kubelet:運(yùn)行在每個(gè)計(jì)算節(jié)點(diǎn)上,作為 agent,接收分配該節(jié)點(diǎn)的 Pods 任務(wù)及管理容器,周期性獲取容器狀態(tài),反饋給 kube-apiserver。

          • DNS:一個(gè)可選的 DNS 服務(wù),用于為每個(gè) Service 對(duì)象創(chuàng)建 DNS 記錄,這樣所有的 Pod 就可以通過 DNS 訪問服務(wù)了。


          下面是 k8s 的架構(gòu)拓?fù)鋱D:



          兩地三中心


          兩地三中心包括本地生產(chǎn)中心本地災(zāi)備中心異地災(zāi)備中心



          兩地三中心要解決的一個(gè)重要問題就是數(shù)據(jù)一致性問題


          k8s 使用 etcd 組件作為一個(gè)高可用、強(qiáng)一致性的服務(wù)發(fā)現(xiàn)存儲(chǔ)倉庫。用于配置共享和服務(wù)發(fā)現(xiàn)。


          它作為一個(gè)受到 Zookeeper 和 doozer 啟發(fā)而催生的項(xiàng)目。除了擁有他們的所有功能之外,還擁有以下 4 個(gè)特點(diǎn):


          • 簡(jiǎn)單:基于 HTTP+JSON 的 API 讓你用 curl 命令就可以輕松使用。

          • 安全:可選 SSL 客戶認(rèn)證機(jī)制。

          • 快速:每個(gè)實(shí)例每秒支持一千次寫操作。

          • 可信:使用 Raft 算法充分實(shí)現(xiàn)了分布式。


          四層服務(wù)發(fā)現(xiàn)


          先一張圖解釋一下網(wǎng)絡(luò)七層協(xié)議:



          k8s 提供了兩種方式進(jìn)行服務(wù)發(fā)現(xiàn):


          • 環(huán)境變量:當(dāng)創(chuàng)建一個(gè) Pod 的時(shí)候,kubelet 會(huì)在該 Pod 中注入集群內(nèi)所有 Service 的相關(guān)環(huán)境變量。需要注意的是,要想一個(gè) Pod 中注入某個(gè) Service 的環(huán)境變量,則必須 Service 要先比該 Pod 創(chuàng)建。這一點(diǎn),幾乎使得這種方式進(jìn)行服務(wù)發(fā)現(xiàn)不可用。

            比如,一個(gè) ServiceName 為 redis-master 的 Service,對(duì)應(yīng)的 ClusterIP:Port 為 10.0.0.11:6379,則對(duì)應(yīng)的環(huán)境變量為:

          • DNS:可以通過 cluster add-on 的方式輕松的創(chuàng)建 KubeDNS 來對(duì)集群內(nèi)的 Service 進(jìn)行服務(wù)發(fā)現(xiàn)。


          以上兩種方式,一個(gè)是基于 TCP,DNS 基于 UDP,它們都是建立在四層協(xié)議之上。


          五種 Pod 共享資源


          Pod 是 k8s 最基本的操作單元,包含一個(gè)或多個(gè)緊密相關(guān)的容器。


          一個(gè) Pod 可以被一個(gè)容器化的環(huán)境看作應(yīng)用層的“邏輯宿主機(jī)”;一個(gè) Pod 中的多個(gè)容器應(yīng)用通常是緊密耦合的,Pod 在 Node 上被創(chuàng)建、啟動(dòng)或者銷毀;每個(gè) Pod 里運(yùn)行著一個(gè)特殊的被稱之為 Volume 掛載卷,因此他們之間通信和數(shù)據(jù)交換更為高效。在設(shè)計(jì)時(shí)我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進(jìn)程放入同一個(gè) Pod 中。




          同一個(gè) Pod 里的容器之間僅需通過 localhost 就能互相通信。


          一個(gè) Pod 中的應(yīng)用容器共享五種資源:


          • PID 命名空間:Pod 中的不同應(yīng)用程序可以看到其他應(yīng)用程序的進(jìn)程 ID。

          • 網(wǎng)絡(luò)命名空間:Pod 中的多個(gè)容器能夠訪問同一個(gè)IP和端口范圍。

          • IPC 命名空間:Pod 中的多個(gè)容器能夠使用 SystemV IPC 或 POSIX 消息隊(duì)列進(jìn)行通信。

          • UTS 命名空間:Pod 中的多個(gè)容器共享一個(gè)主機(jī)名。

          • Volumes(共享存儲(chǔ)卷):Pod 中的各個(gè)容器可以訪問在 Pod 級(jí)別定義的 Volumes。


          Pod 的生命周期通過 Replication Controller 來管理;通過模板進(jìn)行定義,然后分配到一個(gè) Node 上運(yùn)行,在 Pod 所包含容器運(yùn)行結(jié)束后,Pod 結(jié)束。


          Kubernetes 為 Pod 設(shè)計(jì)了一套獨(dú)特的網(wǎng)絡(luò)配置,包括為每個(gè) Pod 分配一個(gè)IP地址,使用 Pod 名作為容器間通信的主機(jī)名等。


          六個(gè) CNI 常用插件


          CNI(Container Network Interface)容器網(wǎng)絡(luò)接口是 Linux 容器網(wǎng)絡(luò)配置的一組標(biāo)準(zhǔn)和庫,用戶需要根據(jù)這些標(biāo)準(zhǔn)和庫來開發(fā)自己的容器網(wǎng)絡(luò)插件。CNI 只專注解決容器網(wǎng)絡(luò)連接和容器銷毀時(shí)的資源釋放,提供一套框架。所以 CNI 可以支持大量不同的網(wǎng)絡(luò)模式,并且容易實(shí)現(xiàn)。


          下面用一張圖表示六個(gè) CNI 常用插件:



          七層負(fù)載均衡


          提負(fù)載均衡就不得不先提服務(wù)器之間的通信。


          IDC(Internet Data Center)也可稱數(shù)據(jù)中心機(jī)房,用來放置服務(wù)器。IDC 網(wǎng)絡(luò)是服務(wù)器間通信的橋梁。


          上圖里畫了很多網(wǎng)絡(luò)設(shè)備,它們都是干啥用的呢?


          路由器、交換機(jī)、MGW/NAT 都是網(wǎng)絡(luò)設(shè)備,按照性能、內(nèi)外網(wǎng)劃分不同的角色。


          • 內(nèi)網(wǎng)接入交換機(jī):也稱為 TOR(top of rack),是服務(wù)器接入網(wǎng)絡(luò)的設(shè)備。每臺(tái)內(nèi)網(wǎng)接入交換機(jī)下聯(lián) 40-48 臺(tái)服務(wù)器,使用一個(gè)掩碼為 /24 的網(wǎng)段作為服務(wù)器內(nèi)網(wǎng)網(wǎng)段。

          • 內(nèi)網(wǎng)核心交換機(jī):負(fù)責(zé) IDC 內(nèi)各內(nèi)網(wǎng)接入交換機(jī)的流量轉(zhuǎn)發(fā)及跨 IDC 流量轉(zhuǎn)發(fā)。

          • MGW/NAT:MGW 即 LVS 用來做負(fù)載均衡,NAT 用于內(nèi)網(wǎng)設(shè)備訪問外網(wǎng)時(shí)做地址轉(zhuǎn)換。

          • 外網(wǎng)核心路由器:通過靜態(tài)互聯(lián)運(yùn)營商或 BGP 互聯(lián)美團(tuán)統(tǒng)一外網(wǎng)平臺(tái)。


          先說說各層負(fù)載均衡:


          • 二層負(fù)載均衡:基于 MAC 地址的二層負(fù)載均衡。

          • 三層負(fù)載均衡:基于 IP 地址的負(fù)載均衡。

          • 四層負(fù)載均衡:基于 IP+端口 的負(fù)載均衡。

          • 七層負(fù)載均衡:基于 URL 等應(yīng)用層信息的負(fù)載均衡。


          這里用一張圖來說說四層和七層負(fù)載均衡的區(qū)別:



          上面四層服務(wù)發(fā)現(xiàn)講的主要是 k8s?原生的 kube-proxy 方式。k8s 關(guān)于服務(wù)的暴露主要是通過 NodePort 方式,通過綁定 minion 主機(jī)的某個(gè)端口,然后進(jìn)行 Pod 的請(qǐng)求轉(zhuǎn)發(fā)和負(fù)載均衡,但這種方式有下面的缺陷:


          • Service 可能有很多個(gè),如果每個(gè)都綁定一個(gè) Node 主機(jī)端口的話,主機(jī)需要開放外圍的端口進(jìn)行服務(wù)調(diào)用,管理混亂。

          • 無法應(yīng)用很多公司要求的防火墻規(guī)則。


          理想的方式是通過一個(gè)外部的負(fù)載均衡器,綁定固定的端口,比如 80;然后根據(jù)域名或者服務(wù)名向后面的 Service IP 轉(zhuǎn)發(fā)。


          Nginx 很好的解決了這個(gè)需求,但問題是如果有的新的服務(wù)加入,如何去修改并且加載這些Nginx 配置?


          Kubernetes 給出的方案就是?Ingress。這是一個(gè)基于七層的方案。


          八種隔離維度



          k8s 集群調(diào)度這邊需要對(duì)上面從上到下從粗粒度到細(xì)粒度的隔離做相應(yīng)的調(diào)度策略。


          九個(gè)網(wǎng)絡(luò)模型原則


          k8s 網(wǎng)絡(luò)模型要符合四個(gè)基礎(chǔ)原則三個(gè)網(wǎng)絡(luò)要求原則一個(gè)架構(gòu)原則一個(gè) IP 原則


          每個(gè) Pod 都擁有一個(gè)獨(dú)立的 IP 地址,而且假定所有 Pod 都在一個(gè)可以直接連通的、扁平的網(wǎng)絡(luò)空間中,不管是否運(yùn)行在同一 Node 上都可以通過 Pod 的 IP 來訪問。


          k8s 中的 Pod 的 IP 是最小粒度 IP。同一個(gè) Pod 內(nèi)所有的容器共享一個(gè)網(wǎng)絡(luò)堆棧,該模型稱為?IP-per-Pod 模型


          • Pod 由 docker0 實(shí)際分配的 IP。

          • Pod 內(nèi)部看到的 IP 地址和端口與外部保持一致。

          • 同一個(gè) Pod 內(nèi)的不同容器共享網(wǎng)絡(luò),可以通過localhost來訪問對(duì)方的端口,類似同一個(gè)虛擬機(jī)內(nèi)不同的進(jìn)程。


          IP-per-Pod 模型從端口分配、域名解析、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、應(yīng)用配置等角度看,Pod 可以看做是一臺(tái)獨(dú)立的虛擬機(jī)或物理機(jī)。


          • 所有容器都可以不用 NAT 的方式同別的容器通信。

          • 所有節(jié)點(diǎn)都可以在不同 NAT 方式下同所有容器通信,反之亦然。

          • 容器的地址和別人看到的地址是同一個(gè)地址。


          要符合下面的架構(gòu):



          由上圖架構(gòu)引申出來 IP 概念從集群外部到集群內(nèi)部:



          十類IP地址


          大家都知道 IP 地址分為 ABCDE 類,另外還有五類特殊用途的 IP。


          第一類


          • A 類:1.0.0.0-1226.255.255.255,默認(rèn)子網(wǎng)掩碼/8,即255.0.0.0。

          • B 類:128.0.0.0-191.255.255.255,默認(rèn)子網(wǎng)掩碼/16,即255.255.0.0。

          • C 類:192.0.0.0-223.255.255.255,默認(rèn)子網(wǎng)掩碼/24,即255.255.255.0。

          • D 類:224.0.0.0-239.255.255.255,一般用于組播。

          • E 類:240.0.0.0-255.255.255.255(其中255.255.255.255為全網(wǎng)廣播地址)。E 類地址一般用于研究用途。


          第二類?


          0.0.0.0

          嚴(yán)格來說,0.0.0.0 已經(jīng)不是一個(gè)真正意義上的 IP 地址了。它表示的是這樣一個(gè)集合:所有不清楚的主機(jī)和目的網(wǎng)絡(luò)。這里的不清楚是指在本機(jī)的路由表里沒有特定條目指明如何到達(dá)。作為缺省路由。


          127.0.0.1?本機(jī)地址。


          第三類

          224.0.0.1?組播地址。


          如果你的主機(jī)開啟了IRDP(internet路由發(fā)現(xiàn),使用組播功能),那么你的主機(jī)路由表中應(yīng)該有這樣一條路由。


          第四類

          169.254.x.x


          使用了 DHCP 功能自動(dòng)獲取了 IP 的主機(jī),DHCP 服務(wù)器發(fā)生故障,或響應(yīng)時(shí)間太長(zhǎng)而超出了一個(gè)系統(tǒng)規(guī)定的時(shí)間,系統(tǒng)會(huì)為你分配這樣一個(gè) IP,代表網(wǎng)絡(luò)不能正常運(yùn)行。


          第五類

          10.xxx172.16.x.x~172.31.x.x192.168.x.x?私有地址。


          大量用于企業(yè)內(nèi)部。保留這樣的地址是為了避免亦或是哪個(gè)接入公網(wǎng)時(shí)引起地址混亂。


          源:blog.csdn.net/huakai_sun/article/details/82378856

          版權(quán)申明:內(nèi)容來源網(wǎng)絡(luò),版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn),我們都會(huì)標(biāo)明作者及出處,如有侵權(quán)煩請(qǐng)告知,我們會(huì)立即刪除并表示歉意。謝謝!





          感謝閱讀



          瀏覽 49
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  狼友五月天成人在线视频 | 91狠狠综合久久久 | 午夜日逼 | 青青草在线观看视频 | 中文字幕人妻无码系列第三区 |