超詳細！k8s 面試題總結(jié)
一個目標：容器操作；兩地三中心；四層服務(wù)發(fā)現(xiàn)；五種 Pod 共享資源；六個 CNI 常用插件；七層負載均衡；八種隔離維度；九個網(wǎng)絡(luò)模型原則；十類 IP 地址；百級產(chǎn)品線；千級物理機；萬級容器；相如無億，k8s 有億：億級日服務(wù)人次。
一個目標：容器操作
Kubernetes（k8s）是自動化容器操作的開源平臺。這些容器操作包括：部署、調(diào)度和節(jié)點集群間擴展。
具體功能：
自動化容器部署和復(fù)制。 實時彈性收縮容器規(guī)模。 容器編排成組，并提供容器間的負載均衡。 調(diào)度：容器在哪個機器上運行。
組成：
kubectl：客戶端命令行工具，作為整個系統(tǒng)的操作入口。 kube-apiserver：以 REST API 服務(wù)形式提供接口，作為整個系統(tǒng)的控制入口。 kube-controller-manager：執(zhí)行整個系統(tǒng)的后臺任務(wù)，包括節(jié)點狀態(tài)狀況、Pod 個數(shù)、Pods 和Service 的關(guān)聯(lián)等。 kube-scheduler：負責節(jié)點資源管理，接收來自 kube-apiserver 創(chuàng)建 Pods 任務(wù)，并分配到某個節(jié)點。 etcd：負責節(jié)點間的服務(wù)發(fā)現(xiàn)和配置共享。 kube-proxy：運行在每個計算節(jié)點上，負責 Pod 網(wǎng)絡(luò)代理。定時從 etcd 獲取到 service 信息來做相應(yīng)的策略。 kubelet：運行在每個計算節(jié)點上，作為 agent，接收分配該節(jié)點的 Pods 任務(wù)及管理容器，周期性獲取容器狀態(tài)，反饋給 kube-apiserver。 DNS：一個可選的 DNS 服務(wù)，用于為每個 Service 對象創(chuàng)建 DNS 記錄，這樣所有的 Pod 就可以通過 DNS 訪問服務(wù)了。
下面是 k8s 的架構(gòu)拓撲圖：
兩地三中心
兩地三中心包括本地生產(chǎn)中心、本地災(zāi)備中心、異地災(zāi)備中心。
兩地三中心要解決的一個重要問題就是數(shù)據(jù)一致性問題。
k8s 使用 etcd 組件作為一個高可用、強一致性的服務(wù)發(fā)現(xiàn)存儲倉庫。用于配置共享和服務(wù)發(fā)現(xiàn)。
它作為一個受到 Zookeeper 和 doozer 啟發(fā)而催生的項目。除了擁有他們的所有功能之外，還擁有以下 4 個特點：
簡單：基于 HTTP+JSON 的 API 讓你用 curl 命令就可以輕松使用。 安全：可選 SSL 客戶認證機制。 快速：每個實例每秒支持一千次寫操作。 可信：使用 Raft 算法充分實現(xiàn)了分布式。
四層服務(wù)發(fā)現(xiàn)
先一張圖解釋一下網(wǎng)絡(luò)七層協(xié)議：
k8s 提供了兩種方式進行服務(wù)發(fā)現(xiàn)：
環(huán)境變量：當創(chuàng)建一個 Pod 的時候，kubelet 會在該 Pod 中注入集群內(nèi)所有 Service 的相關(guān)環(huán)境變量。需要注意的是，要想一個 Pod 中注入某個 Service 的環(huán)境變量，則必須 Service 要先比該 Pod 創(chuàng)建。這一點，幾乎使得這種方式進行服務(wù)發(fā)現(xiàn)不可用。比如，一個 ServiceName 為 redis-master 的 Service，對應(yīng)的 ClusterIP:Port 為 10.0.0.11:6379，則對應(yīng)的環(huán)境變量為：
DNS：可以通過 cluster add-on 的方式輕松的創(chuàng)建 KubeDNS 來對集群內(nèi)的 Service 進行服務(wù)發(fā)現(xiàn)。
以上兩種方式，一個是基于 TCP，DNS 基于 UDP，它們都是建立在四層協(xié)議之上。
五種 Pod 共享資源
Pod 是 k8s 最基本的操作單元，包含一個或多個緊密相關(guān)的容器。
一個 Pod 可以被一個容器化的環(huán)境看作應(yīng)用層的“邏輯宿主機”；一個 Pod 中的多個容器應(yīng)用通常是緊密耦合的，Pod 在 Node 上被創(chuàng)建、啟動或者銷毀；每個 Pod 里運行著一個特殊的被稱之為 Volume 掛載卷，因此他們之間通信和數(shù)據(jù)交換更為高效。在設(shè)計時我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進程放入同一個 Pod 中。
同一個 Pod 里的容器之間僅需通過 localhost 就能互相通信。
一個 Pod 中的應(yīng)用容器共享五種資源：
PID 命名空間：Pod 中的不同應(yīng)用程序可以看到其他應(yīng)用程序的進程 ID。 網(wǎng)絡(luò)命名空間：Pod 中的多個容器能夠訪問同一個IP和端口范圍。 IPC 命名空間：Pod 中的多個容器能夠使用 SystemV IPC 或 POSIX 消息隊列進行通信。 UTS 命名空間：Pod 中的多個容器共享一個主機名。 Volumes（共享存儲卷）：Pod 中的各個容器可以訪問在 Pod 級別定義的 Volumes。
Pod 的生命周期通過 Replication Controller 來管理；通過模板進行定義，然后分配到一個 Node 上運行，在 Pod 所包含容器運行結(jié)束后，Pod 結(jié)束。
Kubernetes 為 Pod 設(shè)計了一套獨特的網(wǎng)絡(luò)配置，包括為每個 Pod 分配一個IP地址，使用 Pod 名作為容器間通信的主機名等。
六個 CNI 常用插件
CNI（Container Network Interface）容器網(wǎng)絡(luò)接口是 Linux 容器網(wǎng)絡(luò)配置的一組標準和庫，用戶需要根據(jù)這些標準和庫來開發(fā)自己的容器網(wǎng)絡(luò)插件。CNI 只專注解決容器網(wǎng)絡(luò)連接和容器銷毀時的資源釋放，提供一套框架。所以 CNI 可以支持大量不同的網(wǎng)絡(luò)模式，并且容易實現(xiàn)。
下面用一張圖表示六個 CNI 常用插件：
七層負載均衡
提負載均衡就不得不先提服務(wù)器之間的通信。
IDC（Internet Data Center）也可稱數(shù)據(jù)中心、機房，用來放置服務(wù)器。IDC 網(wǎng)絡(luò)是服務(wù)器間通信的橋梁。
上圖里畫了很多網(wǎng)絡(luò)設(shè)備，它們都是干啥用的呢？
路由器、交換機、MGW/NAT 都是網(wǎng)絡(luò)設(shè)備，按照性能、內(nèi)外網(wǎng)劃分不同的角色。
內(nèi)網(wǎng)接入交換機：也稱為 TOR（top of rack），是服務(wù)器接入網(wǎng)絡(luò)的設(shè)備。每臺內(nèi)網(wǎng)接入交換機下聯(lián) 40-48 臺服務(wù)器，使用一個掩碼為 /24 的網(wǎng)段作為服務(wù)器內(nèi)網(wǎng)網(wǎng)段。 內(nèi)網(wǎng)核心交換機：負責 IDC 內(nèi)各內(nèi)網(wǎng)接入交換機的流量轉(zhuǎn)發(fā)及跨 IDC 流量轉(zhuǎn)發(fā)。 MGW/NAT：MGW 即 LVS 用來做負載均衡，NAT 用于內(nèi)網(wǎng)設(shè)備訪問外網(wǎng)時做地址轉(zhuǎn)換。 外網(wǎng)核心路由器：通過靜態(tài)互聯(lián)運營商或 BGP 互聯(lián)美團統(tǒng)一外網(wǎng)平臺。
先說說各層負載均衡：
二層負載均衡：基于 MAC 地址的二層負載均衡。 三層負載均衡：基于 IP 地址的負載均衡。 四層負載均衡：基于 IP+端口 的負載均衡。 七層負載均衡：基于 URL 等應(yīng)用層信息的負載均衡。
這里用一張圖來說說四層和七層負載均衡的區(qū)別：
上面四層服務(wù)發(fā)現(xiàn)講的主要是 k8s 原生的 kube-proxy 方式。k8s 關(guān)于服務(wù)的暴露主要是通過 NodePort 方式，通過綁定 minion 主機的某個端口，然后進行 Pod 的請求轉(zhuǎn)發(fā)和負載均衡，但這種方式有下面的缺陷：
Service 可能有很多個，如果每個都綁定一個 Node 主機端口的話，主機需要開放外圍的端口進行服務(wù)調(diào)用，管理混亂。 無法應(yīng)用很多公司要求的防火墻規(guī)則。
理想的方式是通過一個外部的負載均衡器，綁定固定的端口，比如 80；然后根據(jù)域名或者服務(wù)名向后面的 Service IP 轉(zhuǎn)發(fā)。
Nginx 很好的解決了這個需求，但問題是如果有的新的服務(wù)加入，如何去修改并且加載這些 Nginx 配置？
Kubernetes 給出的方案就是 Ingress。這是一個基于七層的方案。
八種隔離維度
k8s 集群調(diào)度這邊需要對上面從上到下、從粗粒度到細粒度的隔離做相應(yīng)的調(diào)度策略。
九個網(wǎng)絡(luò)模型原則
k8s 網(wǎng)絡(luò)模型要符合四個基礎(chǔ)原則、三個網(wǎng)絡(luò)要求原則、一個架構(gòu)原則、一個 IP 原則。
每個 Pod 都擁有一個獨立的 IP 地址，而且假定所有 Pod 都在一個可以直接連通的、扁平的網(wǎng)絡(luò)空間中，不管是否運行在同一 Node 上都可以通過 Pod 的 IP 來訪問。
k8s 中的 Pod 的 IP 是最小粒度 IP。同一個 Pod 內(nèi)所有的容器共享一個網(wǎng)絡(luò)堆棧，該模型稱為 IP-per-Pod 模型。
Pod 由 docker0 實際分配的 IP。 Pod 內(nèi)部看到的 IP 地址和端口與外部保持一致。 同一個 Pod 內(nèi)的不同容器共享網(wǎng)絡(luò)，可以通過localhost來訪問對方的端口，類似同一個虛擬機內(nèi)不同的進程。
IP-per-Pod 模型從端口分配、域名解析、服務(wù)發(fā)現(xiàn)、負載均衡、應(yīng)用配置等角度看，Pod 可以看做是一臺獨立的虛擬機或物理機。
所有容器都可以不用 NAT 的方式同別的容器通信。 所有節(jié)點都可以在不同 NAT 方式下同所有容器通信，反之亦然。 容器的地址和別人看到的地址是同一個地址。
要符合下面的架構(gòu)：
由上圖架構(gòu)引申出來 IP 概念從集群外部到集群內(nèi)部：
十類IP地址
大家都知道 IP 地址分為 ABCDE 類，另外還有五類特殊用途的 IP。
第一類
A 類：1.0.0.0-1226.255.255.255，默認子網(wǎng)掩碼/8，即255.0.0.0。
B 類：128.0.0.0-191.255.255.255，默認子網(wǎng)掩碼/16，即255.255.0.0。
C 類：192.0.0.0-223.255.255.255，默認子網(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
嚴格來說，0.0.0.0 已經(jīng)不是一個真正意義上的 IP 地址了。它表示的是這樣一個集合：所有不清楚的主機和目的網(wǎng)絡(luò)。這里的不清楚是指在本機的路由表里沒有特定條目指明如何到達。作為缺省路由。
127.0.0.1 本機地址。
第三類
224.0.0.1 組播地址。
如果你的主機開啟了IRDP（internet路由發(fā)現(xiàn)，使用組播功能），那么你的主機路由表中應(yīng)該有這樣一條路由。
第四類
169.254.x.x
使用了 DHCP 功能自動獲取了 IP 的主機，DHCP 服務(wù)器發(fā)生故障，或響應(yīng)時間太長而超出了一個系統(tǒng)規(guī)定的時間，系統(tǒng)會為你分配這樣一個 IP，代表網(wǎng)絡(luò)不能正常運行。
第五類
10.xxx、172.16.x.x~172.31.x.x、192.168.x.x 私有地址。
大量用于企業(yè)內(nèi)部。保留這樣的地址是為了避免亦或是哪個接入公網(wǎng)時引起地址混亂。
轉(zhuǎn)自：stackpush 鏈接：blog.csdn.net/huakai_sun/article/details/82378856
喜歡的朋友歡迎關(guān)注，訂閱更多精彩內(nèi)容