21道題幫你輕松拿捏Kubernetes面試

1.簡述 kube-proxy ipvs 原理？

IPVS 在 Kubernetes1.11 中升級為 GA 穩(wěn)定版。IPVS 則專門用于高性能負載均衡，并使用更高效的數據結構（Hash 表），允許幾乎無限的規(guī)模擴張，因此被 kube-proxy 采納為最新模式。

在 IPVS 模式下，使用 iptables 的擴展 ipset，而不是直接調用 iptables 來生成規(guī)則鏈。iptables 規(guī)則鏈是一個線性的數據結構，ipset 則引入了帶索引的數據結構，因此當規(guī)則很多時，也可以很高效地查找和匹配。

可以將 ipset 簡單理解為一個 IP（段）的集合，這個集合的內容可以是 IP 地址、IP 網段、端口等，iptables 可以直接添加規(guī)則對這個“可變的集合”進行操作，這樣做的好處在于可以大大減少 iptables 規(guī)則的數量，從而減少性能損耗。

2.簡述 kube-proxy ipvs 和 iptables 的異同？

iptables 與 IPVS 都是基于 Netfilter 實現的，但因為定位不同，二者有著本質的差別：iptables 是為防火墻而設計的；IPVS 則專門用于高性能負載均衡，并使用更高效的數據結構（Hash 表），允許幾乎無限的規(guī)模擴張。

與 iptables 相比，IPVS 擁有以下明顯優(yōu)勢：

1、為大型集群提供了更好的可擴展性和性能；

2、支持比 iptables 更復雜的復制均衡算法（最小負載、最少連接、加權等）；

3、支持服務器健康檢查和連接重試等功能；

4、可以動態(tài)修改 ipset 的集合，即使 iptables 的規(guī)則正在使用這個集合。

3.簡述 Kubernetes 中什么是靜態(tài) Pod？

靜態(tài) pod 是由 kubelet 進行管理的僅存在于特定 Node 的 Pod 上，他們不能通過 API Server 進行管理，無法與 ReplicationController、Deployment 或者DaemonSet 進行關聯，并且 kubelet 無法對他們進行健康檢查。靜態(tài) Pod 總是由kubelet 進行創(chuàng)建，并且總是在 kubelet 所在的 Node 上運行。

4.簡述 Kubernetes 中 Pod 可能位于的狀態(tài)？

●Pending：API Server 已經創(chuàng)建該 Pod，且 Pod 內還有一個或多個容器的鏡像沒有創(chuàng)建，包括正在下載鏡像的過程。

●Running：Pod 內所有容器均已創(chuàng)建，且至少有一個容器處于運行狀態(tài)、正在啟動狀態(tài)或正在重啟狀態(tài)。

●Succeeded：Pod 內所有容器均成功執(zhí)行退出，且不會重啟。

●Failed：Pod 內所有容器均已退出，但至少有一個容器退出為失敗狀態(tài)。

●Unknown：由于某種原因無法獲取該 Pod 狀態(tài)，可能由于網絡通信不暢導致。

5.簡述 Kubernetes 創(chuàng)建一個 Pod 的主要流程？

Kubernetes 中創(chuàng)建一個 Pod 涉及多個組件之間聯動，主要流程如下：

1、客戶端提交 Pod 的配置信息（可以是 yaml 文件定義的信息）到 kube-apiserver。

2、Apiserver 收到指令后，通知給 controller-manager 創(chuàng)建一個資源對象。

3、Controller-manager 通過 api-server 將 pod 的配置信息存儲到 ETCD 數據中心中。

4、Kube-scheduler 檢測到 pod 信息會開始調度預選，會先過濾掉不符合 Pod資源配置要求的節(jié)點，然后開始調度調優(yōu)，主要是挑選出更適合運行 pod 的節(jié)點，然后將 pod 的資源配置單發(fā)送到 node 節(jié)點上的 kubelet 組件上。

5、Kubelet 根據 scheduler 發(fā)來的資源配置單運行 pod，運行成功后，將 pod的運行信息返回給 scheduler，scheduler 將返回的 pod 運行狀況的信息存儲到etcd 數據中心。

6.簡述 Kubernetes 中 Pod 的重啟策略？

Pod 重啟策略（RestartPolicy）應用于 Pod 內的所有容器，并且僅在 Pod 所處的 Node 上由 kubelet 進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，kubelet 將根據 RestartPolicy 的設置來進行相應操作。

Pod 的重啟策略包括 Always、OnFailure 和 Never，默認值為 Always。

●Always：當容器失效時，由 kubelet 自動重啟該容器；

●OnFailure：當容器終止運行且退出碼不為 0 時，由 kubelet 自動重啟該容器；

●Never：不論容器運行狀態(tài)如何，kubelet 都不會重啟該容器。

同時 Pod 的重啟策略與控制方式關聯，當前可用于管理 Pod 的控制器包括ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（靜態(tài) Pod）。

不同控制器的重啟策略限制如下：

● RC 和 DaemonSet：必須設置為 Always，需要保證該容器持續(xù)運行；

● Job：OnFailure 或 Never，確保容器執(zhí)行完成后不再重啟；

● kubelet：在 Pod 失效時重啟，不論將 RestartPolicy 設置為何值，也不會對 Pod 進行健康檢查。

7.簡述 Kubernetes 中 Pod 的健康檢查方式？

對 Pod 的健康檢查可以通過兩類探針來檢查：LivenessProbe 和ReadinessProbe。

●LivenessProbe 探針：用于判斷容器是否存活（running 狀態(tài)），如果 LivenessProbe 探針探測到容器不健康，則 kubelet 將殺掉該容器，并根據容器的重啟策略做相應處理。若一個容器不包含 LivenessProbe 探針，kubelet 認為該容器的 LivenessProbe 探針返回值用于是“Success”。

●ReadineeProbe 探針：用于判斷容器是否啟動完成（ready 狀態(tài)）。如果 ReadinessProbe 探針探測到失敗，則 Pod 的狀態(tài)將被修改。Endpoint Controller 將從 Service 的 Endpoint 中刪除包含該容器所在 Pod 的 Eenpoint。

●startupProbe 探針：啟動檢查機制，應用一些啟動緩慢的業(yè)務，避免業(yè)務長時間啟動而被上面兩類探針 kill 掉。

8.簡述 Kubernetes Pod 的 LivenessProbe 探針的常見方式？

kubelet 定期執(zhí)行 LivenessProbe 探針來診斷容器的健康狀態(tài)，通常有以下三種方式：

●ExecAction：在容器內執(zhí)行一個命令，若返回碼為 0，則表明容器健康。

●TCPSocketAction：通過容器的 IP 地址和端口號執(zhí)行 TCP 檢查，若能建立 TCP 連接，則表明容器健康。

●HTTPGetAction：通過容器的 IP 地址、端口號及路徑調用 HTTP Get 方法，若響應的狀態(tài)碼大于等于 200 且小于 400，則表明容器健康。

9.簡述 Kubernetes Pod 的常見調度方式？

Kubernetes 中，Pod 通常是容器的載體，主要有如下常見調度方式：

●Deployment 或 RC：該調度策略主要功能就是自動部署一個容器應用的多份副本，以及持續(xù)監(jiān)控副本的數量，在集群內始終維持用戶指定的副本數量。

●NodeSelector：定向調度，當需要手動指定將 Pod 調度到特定 Node 上，可以通過 Node 的標簽（Label）和 Pod 的 nodeSelector 屬性相匹配。

●NodeAffinity 親和性調度：親和性調度機制極大的擴展了 Pod 的調度能力，目前有兩種節(jié)點親和力表達：

●requiredDuringSchedulingIgnoredDuringExecution：硬規(guī)則，必須滿足指定的規(guī)則，調度器才可以調度 Pod 至 Node 上（類似 nodeSelector，語法不同）。

●preferredDuringSchedulingIgnoredDuringExecution：軟規(guī)則，優(yōu)先調度至滿足的 Node 的節(jié)點，但不強求，多個優(yōu)先級規(guī)則還可以設置權重值。

●Taints 和 Tolerations（污點和容忍）

●Taint：使 Node 拒絕特定 Pod 運行；

●Toleration：為 Pod 的屬性，表示 Pod 能容忍（運行）標注了 Taint 的 Node。

10.簡述Kubernetes初始化容器（init container）？

init container 的運行方式與應用容器不同，它們必須先于應用容器執(zhí)行完成，當設置了多個 init container 時，將按順序逐個運行，并且只有前一個 init container 運行成功后才能運行后一個 init container。當所有 init container 都成功運行后，Kubernetes 才會初始化 Pod 的各種信息，并開始創(chuàng)建和運行應用容器。

11.簡述 Kubernetes deployment 升級過程？

● 初始創(chuàng)建 Deployment 時，系統(tǒng)創(chuàng)建了一個 ReplicaSet，并按用戶的需求創(chuàng)建了對應數量的 Pod 副本。

●當更新 Deployment 時，系統(tǒng)創(chuàng)建了一個新的 ReplicaSet，并將其副本數量擴展到 1，然后將舊 ReplicaSet 縮減為 2。

●之后，系統(tǒng)繼續(xù)按照相同的更新策略對新舊兩個 ReplicaSet 進行逐個調整。

●最后，新的 ReplicaSet 運行了對應個新版本 Pod 副本，舊的 ReplicaSet 副本數量則縮減為 0。

12.簡述 Kubernetes deployment 升級策略？

在 Deployment 的定義中，可以通過 spec.strategy 指定 Pod 更新的策略，目前支持兩種策略：Recreate（重建）和 RollingUpdate（滾動更新），默認值為RollingUpdate。

●Recreate：設置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod時，會先殺掉所有正在運行的 Pod，然后創(chuàng)建新的 Pod。

●RollingUpdate：設置 spec.strategy.type=RollingUpdate，表示 Deployment會以滾動更新的方式來逐個更新 Pod。同時，可以通過設置spec.strategy.rollingUpdate 下的兩個參數（maxUnavailable 和 maxSurge）來控制滾動更新的過程。

13.簡述 Kubernetes DaemonSet 類型的資源特性？

DaemonSet 資源對象會在每個 Kubernetes 集群中的節(jié)點上運行，并且每個節(jié)點只能運行一個 pod，這是它和 deployment 資源對象的最大也是唯一的區(qū)別。因此， 在定義 yaml 文件中，不支持定義 replicas。

它的一般使用場景如下：

●在去做每個節(jié)點的日志收集工作。

●監(jiān)控每個節(jié)點的的運行狀態(tài)。

14.簡述 Kubernetes 自動擴容機制？

Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器實現基于 CPU使用率進行自動 Pod 擴縮容的功能。HPA 控制器周期性地監(jiān)測目標 Pod 的資源性能指標，并與 HPA 資源對象中的擴縮容條件進行對比，在滿足條件時對 Pod 副本數量進行調整。

●HPA 原理

Kubernetes 中的某個 Metrics Server（Heapster 或自定義 Metrics Server）持續(xù)采集所有 Pod 副本的指標數據。HPA 控制器通過 Metrics Server 的 API（Heapster 的API 或聚合 API）獲取這些數據，基于用戶定義的擴縮容規(guī)則進行計算，得到目標 Pod 副本數量。

當目標 Pod 副本數量與當前副本數量不同時，HPA 控制器就向 Pod 的副本控制器 （Deployment、RC 或 ReplicaSet）發(fā)起 scale 操作，調整 Pod 的副本數量，完成擴縮容操作。

15.簡述 Kubernetes Service 類型？

通過創(chuàng)建 Service，可以為一組具有相同功能的容器應用提供一個統(tǒng)一的入口地址， 并且將請求負載分發(fā)到后端的各個容器應用上。其主要類型有：

●ClusterIP：虛擬的服務 IP 地址，該地址用于 Kubernetes 集群內部的 Pod 訪問， 在 Node 上 kube-proxy 通過設置的 iptables 規(guī)則進行轉發(fā)；

●NodePort：使用宿主機的端口，使能夠訪問各 Node 的外部客戶端通過 Node 的 IP 地址和端口號就能訪問服務；

●LoadBalancer：使用外接負載均衡器完成到服務的負載分發(fā)，需要在 spec.status.loadBalancer 字段指定外部負載均衡器的 IP 地址，通常用于公有云。

16.簡述 Kubernetes Service 分發(fā)后端的策略？

Service 負載分發(fā)的策略有：RoundRobin 和 SessionAffinity：

●RoundRobin：默認為輪詢模式，即輪詢將請求轉發(fā)到后端的各個 Pod 上。

●SessionAffinity：基于客戶端 IP 地址進行會話保持的模式，即第 1 次將某個客戶端發(fā)起的請求轉發(fā)到后端的某個 Pod 上，之后從相同的客戶端發(fā)起的請求都將被轉發(fā)到后端相同的 Pod 上。

17.簡述 Kubernetes Headless Service？

在某些應用場景中，若需要人為指定負載均衡器，不使用 Service 提供的默認負載均衡的功能，或者應用程序希望知道屬于同組服務的其他實例。Kubernetes 提供了Headless Service 來實現這種功能，即不為 Service 設置 ClusterIP（入口 IP 地址）， 僅通過 Label Selector 將后端的 Pod 列表返回給調用的客戶端。

18.簡述 Kubernetes 外部如何訪問集群內的服務？

對于 Kubernetes，集群外的客戶端默認情況，無法通過 Pod 的 IP 地址或者 Service 的虛擬 IP 地址:虛擬端口號進行訪問。通?？梢酝ㄟ^以下方式進行訪問 Kubernetes 集群內的服務：

●映射 Pod 到物理機：將 Pod 端口號映射到宿主機，即在 Pod 中采用 hostPort 方式，以使客戶端應用能夠通過物理機訪問容器應用。

●映射 Service 到物理機：將 Service 端口號映射到宿主機，即在 Service 中采用 nodePort 方式，以使客戶端應用能夠通過物理機訪問容器應用。

●映射 Sercie 到 LoadBalancer：通過設置 LoadBalancer 映射到云服務商提供的 LoadBalancer 地址。這種用法僅用于在公有云服務提供商的云平臺上設置 Service 的場景。

19.簡述 Kubernetes ingress？

Kubernetes 的 Ingress 資源對象，用于將不同 URL 的訪問請求轉發(fā)到后端不同的 Service，以實現 HTTP 層的業(yè)務路由機制。

Kubernetes 使用了 Ingress 策略和 Ingress Controller，兩者結合并實現了一個完整的 Ingress 負載均衡器。使用 Ingress 進行負載分發(fā)時，Ingress Controller 基于Ingress 規(guī)則將客戶端請求直接轉發(fā)到 Service 對應的后端 Endpoint（Pod）上，從而跳過 kube-proxy 的轉發(fā)功能，kube-proxy 不再起作用，全過程為：ingress controller + ingress 規(guī)則 ----> services。

同時當 Ingress Controller 提供的是對外服務，則實際上實現的是邊緣路由器的功能。

20.簡述 Kubernetes 鏡像的下載策略？

K8s 的鏡像下載策略有三種：Always、Never、IFNotPresent。

●Always：鏡像標簽為 latest 時，總是從指定的倉庫中獲取鏡像。

●Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。

●IfNotPresent：僅當本地沒有對應鏡像時，才從目標倉庫中下載。默認的鏡像下載策略是：當鏡像標簽是 latest 時，默認策略是 Always；當鏡像標簽是自定義時（也就是標簽不是 latest），那么默認策略是 IfNotPresent。

21.簡述 Kubernetes 的負載均衡器？

負載均衡器是暴露服務的最常見和標準方式之一。

根據工作環(huán)境使用兩種類型的負載均衡器，即內部負載均衡器或外部負載均衡器。內部負載均衡器自動平衡負載并使用所需配置分配容器，而外部負載均衡器將流量從外部負載引導至后端容器。

審核編輯 ：李倩