60 道常見的 Kubernetes 面試題總結

來源：https://blog.csdn.net/estarhao/article/details/114703958

簡述 ETCD 及其特點？

etcd 是 CoreOS 團隊發起的開源項目，是一個管理配置信息和服務發現（service discovery）的項目，它的目標是構建一個高可用的分佈式鍵值（key-value）數據庫，基於 Go 語言實現。

特點：

• 簡單：支持 REST 風格的 HTTP+JSON API

• 安全：支持 HTTPS 方式的訪問

• 快速：支持併發 1k/s 的寫操作

• 可靠：支持分佈式結構，基於 Raft 的一致性算法，Raft 是一套通過選舉主節點來實現分佈式系統一致性的算法。

簡述 ETCD 適應的場景？

etcd 基於其優秀的特點，可廣泛的應用於以下場景：

• 服務發現 (Service Discovery)：服務發現主要解決在同一個分佈式集羣中的進程或服務，要如何才能找到對方並建立連接。本質上來說，服務發現就是想要了解集羣中是否有進程在監聽 udp 或 tcp 端口，並且通過名字就可以查找和連接。

• 消息發佈與訂閱：在分佈式系統中，最適用的一種組件間通信方式就是消息發佈與訂閱。即構建一個配置共享中心，數據提供者在這個配置中心發佈消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息發佈，就會實時通知訂閱者。通過這種方式可以做到分佈式系統配置的集中式管理與動態更新。應用中用到的一些配置信息放到 etcd 上進行集中管理。

• 負載均衡：在分佈式系統中，爲了保證服務的高可用以及數據的一致性，通常都會把數據和服務部署多份，以此達到對等服務，即使其中的某一個服務失效了，也不影響使用。etcd 本身分佈式架構存儲的信息訪問支持負載均衡。etcd 集羣化以後，每個 etcd 的核心節點都可以處理用戶的請求。所以，把數據量小但是訪問頻繁的消息數據直接存儲到 etcd 中也可以實現負載均衡的效果。

• 分佈式通知與協調：與消息發佈和訂閱類似，都用到了 etcd 中的 Watcher 機制，通過註冊與異步通知機制，實現分佈式環境下不同系統之間的通知與協調，從而對數據變更做到實時處理。

• 分佈式鎖：因爲 etcd 使用 Raft 算法保持了數據的強一致性，某次操作存儲到集羣中的值必然是全局一致的，所以很容易實現分佈式鎖。鎖服務有兩種使用方式，一是保持獨佔，二是控制時序。

• 集羣監控與 Leader 競選：通過 etcd 來進行監控實現起來非常簡單並且實時性強。

簡述什麼是 Kubernetes？

Kubernetes 是一個全新的基於容器技術的分佈式系統支撐平臺。是 Google 開源的容器集羣管理系統（谷歌內部: Borg）。在 Docker 技術的基礎上，爲容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提高了大規模容器集羣管理的便捷性。並且具有完備的集羣管理能力，多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。

簡述 Kubernetes 和 Docker 的關係？

Docker 提供容器的生命週期管理和，Docker 鏡像構建運行時容器。它的主要優點是將將軟件 / 應用程序運行所需的設置和依賴項打包到一個容器中，從而實現了可移植性等優點。

Kubernetes 用於關聯和編排在多個主機上運行的容器。

簡述 Kubernetes 中什麼是 Minikube、Kubectl、Kubelet？

Minikube 是一種可以在本地輕鬆運行一個單節點 Kubernetes 羣集的工具。

Kubectl 是一個命令行工具，可以使用該工具控制 Kubernetes 集羣管理器，如檢查羣集資源，創建、刪除和更新組件，查看應用程序。

Kubelet 是一個代理服務，它在每個節點上運行，並使從服務器與主服務器通信。

簡述 Kubernetes 常見的部署方式？

常見的 Kubernetes 部署方式有：

• kubeadm：也是推薦的一種部署方式；

• 二進制：

• minikube：在本地輕鬆運行一個單節點 Kubernetes 羣集的工具。

簡述 Kubernetes 如何實現集羣管理？

在集羣管理方面，Kubernetes 將集羣中的機器劃分爲一個 Master 節點和一羣工作節點 Node。其中，在 Master 節點運行着集羣管理相關的一組進程 kube-apiserver、kube-controller-manager 和 kube-scheduler，這些進程實現了整個集羣的資源管理、Pod 調度、彈性伸縮、安全控制、系統監控和糾錯等管理能力，並且都是全自動完成的。

簡述 Kubernetes 的優勢、適應場景及其特點？

Kubernetes 作爲一個完備的分佈式系統支撐平臺，其主要優勢：

• 容器編排

• 輕量級

• 開源

• 彈性伸縮

• 負載均衡

Kubernetes 常見場景：

• 快速部署應用

• 快速擴展應用

• 無縫對接新的應用功能

• 節省資源，優化硬件資源的使用

Kubernetes 相關特點：

• 可移植: 支持公有云、私有云、混合雲、多重雲（multi-cloud）。

• 可擴展: 模塊化,、插件化、可掛載、可組合。

• 自動化: 自動部署、自動重啓、自動複製、自動伸縮 / 擴展。

簡述 Kubernetes 的缺點或當前的不足之處？

Kubernetes 當前存在的缺點（不足）如下：

• 安裝過程和配置相對困難複雜。

• 管理服務相對繁瑣。

• 運行和編譯需要很多時間。

• 它比其他替代品更昂貴。

• 對於簡單的應用程序來說，可能不需要涉及 Kubernetes 即可滿足。

簡述 Kubernetes 相關基礎概念？

• master：k8s 集羣的管理節點，負責管理集羣，提供集羣的資源數據訪問入口。擁有 Etcd 存儲服務（可選），運行 Api Server 進程，Controller Manager 服務進程及 Scheduler 服務進程。

• node（worker）：Node（worker）是 Kubernetes 集羣架構中運行 Pod 的服務節點，是 Kubernetes 集羣操作的單元，用來承載被分配 Pod 的運行，是 Pod 運行的宿主機。運行 docker eninge 服務，守護進程 kunelet 及負載均衡器 kube-proxy。

• pod：運行於 Node 節點上，若干相關容器的組合。Pod 內包含的容器運行在同一宿主機上，使用相同的網絡命名空間、IP 地址和端口，能夠通過 localhost 進行通信。Pod 是 Kurbernetes 進行創建、調度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個 Pod 可以包含一個容器或者多個相關容器。

• label：Kubernetes 中的 Label 實質是一系列的 Key/Value 鍵值對，其中 key 與 value 可自定義。Label 可以附加到各種資源對象上，如 Node、Pod、Service、RC 等。一個資源對象可以定義任意數量的 Label，同一個 Label 也可以被添加到任意數量的資源對象上去。Kubernetes 通過 Label Selector（標籤選擇器）查詢和篩選資源對象。

• Replication Controller：Replication Controller 用來管理 Pod 的副本，保證集羣中存在指定數量的 Pod 副本。集羣中副本的數量大於指定數量，則會停止指定數量之外的多餘容器數量。反之，則會啓動少於指定數量個數的容器，保證數量不變。Replication Controller 是實現彈性伸縮、動態擴容和滾動升級的核心。

• Deployment：Deployment 在內部使用了 RS 來實現目的，Deployment 相當於 RC 的一次升級，其最大的特色爲可以隨時獲知當前 Pod 的部署進度。

• HPA（Horizontal Pod Autoscaler）：Pod 的橫向自動擴容，也是 Kubernetes 的一種資源，通過追蹤分析 RC 控制的所有 Pod 目標的負載變化情況，來確定是否需要針對性的調整 Pod 副本數量。

• Service：Service 定義了 Pod 的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service 提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同 Label 的 Pod，用戶不需要了解後臺 Pod 是如何運行。

• Volume：Volume 是 Pod 中能夠被多個容器訪問的共享目錄，Kubernetes 中的 Volume 是定義在 Pod 上，可以被一個或多個 Pod 中的容器掛載到某個目錄下。

• Namespace：Namespace 用於實現多租戶的資源隔離，可將集羣內部的資源對象分配到不同的 Namespace 中，形成邏輯上的不同項目、小組或用戶組，便於不同的 Namespace 在共享使用整個集羣的資源的同時還能被分別管理。

簡述 Kubernetes 集羣相關組件？

Kubernetes Master 控制組件，調度管理整個系統（集羣），包含如下組件:

• Kubernetes API Server：作爲 Kubernetes 系統的入口，其封裝了核心對象的增刪改查操作，以 RESTful API 接口方式提供給外部客戶和內部組件調用，集羣內各個功能模塊之間數據交互和通信的中心樞紐。

• Kubernetes Scheduler：爲新建立的 Pod 進行節點 (node) 選擇(即分配機器)，負責集羣的資源調度。

• Kubernetes Controller：負責執行各種控制器，目前已經提供了很多控制器來保證 Kubernetes 的正常運行。

• Replication Controller：管理維護 Replication Controller，關聯 Replication Controller 和 Pod，保證 Replication Controller 定義的副本數量與實際運行 Pod 數量一致。

• Node Controller：管理維護 Node，定期檢查 Node 的健康狀態，標識出 (失效 | 未失效) 的 Node 節點。

• Namespace Controller：管理維護 Namespace，定期清理無效的 Namespace，包括 Namesapce 下的 API 對象，比如 Pod、Service 等。

• Service Controller：管理維護 Service，提供負載以及服務代理。

• EndPoints Controller：管理維護 Endpoints，關聯 Service 和 Pod，創建 Endpoints 爲 Service 的後端，當 Pod 發生變化時，實時更新 Endpoints。

• Service Account Controller：管理維護 Service Account，爲每個 Namespace 創建默認的 Service Account，同時爲 Service Account 創建 Service Account Secret。

• Persistent Volume Controller：管理維護 Persistent Volume 和 Persistent Volume Claim，爲新的 Persistent Volume Claim 分配 Persistent Volume 進行綁定，爲釋放的 Persistent Volume 執行清理回收。

• Daemon Set Controller：管理維護 Daemon Set，負責創建 Daemon Pod，保證指定的 Node 上正常的運行 Daemon Pod。

• Deployment Controller：管理維護 Deployment，關聯 Deployment 和 Replication Controller，保證運行指定數量的 Pod。當 Deployment 更新時，控制實現 Replication Controller 和 Pod 的更新。

• Job Controller：管理維護 Job，爲 Jod 創建一次性任務 Pod，保證完成 Job 指定完成的任務數目

• Pod Autoscaler Controller：實現 Pod 的自動伸縮，定時獲取監控數據，進行策略匹配，當滿足條件時執行 Pod 的伸縮動作。

簡述 Kubernetes RC 的機制？

Replication Controller 用來管理 Pod 的副本，保證集羣中存在指定數量的 Pod 副本。當定義了 RC 並提交至 Kubernetes 集羣中之後，Master 節點上的 Controller Manager 組件獲悉，並同時巡檢系統中當前存活的目標 Pod，並確保目標 Pod 實例的數量剛好等於此 RC 的期望值，若存在過多的 Pod 副本在運行，系統會停止一些 Pod，反之則自動創建一些 Pod。

簡述 Kubernetes Replica Set 和 Replication Controller 之間有什麼區別？

Replica Set 和 Replication Controller 類似，都是確保在任何給定時間運行指定數量的 Pod 副本。不同之處在於 RS 使用基於集合的選擇器，而 Replication Controller 使用基於權限的選擇器。

簡述 kube-proxy 作用？

kube-proxy 運行在所有節點上，它監聽 apiserver 中 service 和 endpoint 的變化情況，創建路由規則以提供服務 IP 和負載均衡功能。簡單理解此進程是 Service 的透明代理兼負載均衡器，其核心功能是將到某個 Service 的訪問請求轉發到後端的多個 Pod 實例上。

簡述 kube-proxy iptables 原理？

Kubernetes 從 1.2 版本開始，將 iptables 作爲 kube-proxy 的默認模式。iptables 模式下的 kube-proxy 不再起到 Proxy 的作用，其核心功能：通過 API Server 的 Watch 接口實時跟蹤 Service 與 Endpoint 的變更信息，並更新對應的 iptables 規則，Client 的請求流量則通過 iptables 的 NAT 機制 “直接路由” 到目標 Pod。

簡述 kube-proxy ipvs 原理？

IPVS 在 Kubernetes1.11 中升級爲 GA 穩定版。IPVS 則專門用於高性能負載均衡，並使用更高效的數據結構（Hash 表），允許幾乎無限的規模擴張，因此被 kube-proxy 採納爲最新模式。

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

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

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

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

與 iptables 相比，IPVS 擁有以下明顯優勢：

• 1、爲大型集羣提供了更好的可擴展性和性能；

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

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

• 4、可以動態修改 ipset 的集合，即使 iptables 的規則正在使用這個集合。

簡述 Kubernetes 中什麼是靜態 Pod？

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

簡述 Kubernetes 中 Pod 可能位於的狀態？

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

• Running：Pod 內所有容器均已創建，且至少有一個容器處於運行狀態、正在啓動狀態或正在重啓狀態。

• Succeeded：Pod 內所有容器均成功執行退出，且不會重啓。

• Failed：Pod 內所有容器均已退出，但至少有一個容器退出爲失敗狀態。

• Unknown：由於某種原因無法獲取該 Pod 狀態，可能由於網絡通信不暢導致。

簡述 Kubernetes 創建一個 Pod 的主要流程？

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

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

• 2、Apiserver 收到指令後，通知給 controller-manager 創建一個資源對象。

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

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

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

簡述 Kubernetes 中 Pod 的重啓策略？

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

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

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

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

• Never：不論容器運行狀態如何，kubelet 都不會重啓該容器。

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

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

• RC 和 DaemonSet：必須設置爲 Always，需要保證該容器持續運行；

• Job：OnFailure 或 Never，確保容器執行完成後不再重啓；

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

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

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

• LivenessProbe 探針：用於判斷容器是否存活（running 狀態），如果 LivenessProbe 探針探測到容器不健康，則 kubelet 將殺掉該容器，並根據容器的重啓策略做相應處理。若一個容器不包含 LivenessProbe 探針，kubelet 認爲該容器的 LivenessProbe 探針返回值用於是 “Success”。

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

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

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

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

• ExecAction：在容器內執行一個命令，若返回碼爲 0，則表明容器健康。

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

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

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

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

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

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

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

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

• preferredDuringSchedulingIgnoredDuringExecution：軟規則，優先調度至滿足的 Node 的節點，但不強求，多個優先級規則還可以設置權重值。

• Taints 和 Tolerations（污點和容忍）：

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

• Toleration：爲 Pod 的屬性，表示 Pod 能容忍（運行）標註了 Taint 的 Node。

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

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

簡述 Kubernetes deployment 升級過程？

• 初始創建 Deployment 時，系統創建了一個 ReplicaSet，並按用戶的需求創建了對應數量的 Pod 副本。

• 當更新 Deployment 時，系統創建了一個新的 ReplicaSet，並將其副本數量擴展到 1，然後將舊 ReplicaSet 縮減爲 2。

• 之後，系統繼續按照相同的更新策略對新舊兩個 ReplicaSet 進行逐個調整。

• 最後，新的 ReplicaSet 運行了對應個新版本 Pod 副本，舊的 ReplicaSet 副本數量則縮減爲 0。

簡述 Kubernetes deployment 升級策略？

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

• Recreate：設置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 時，會先殺掉所有正在運行的 Pod，然後創建新的 Pod。

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

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

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

它的一般使用場景如下：

• 在去做每個節點的日誌收集工作。

• 監控每個節點的的運行狀態。

簡述 Kubernetes 自動擴容機制？

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

• HPA 原理

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

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

簡述 Kubernetes Service 類型？

通過創建 Service，可以爲一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求負載分發到後端的各個容器應用上。其主要類型有：

• ClusterIP：虛擬的服務 IP 地址，該地址用於 Kubernetes 集羣內部的 Pod 訪問，在 Node 上 kube-proxy 通過設置的 iptables 規則進行轉發；

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

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

簡述 Kubernetes Service 分發後端的策略？

Service 負載分發的策略有：RoundRobin 和 SessionAffinity

• RoundRobin：默認爲輪詢模式，即輪詢將請求轉發到後端的各個 Pod 上。

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

簡述 Kubernetes Headless Service？

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

簡述 Kubernetes 外部如何訪問集羣內的服務？

對於 Kubernetes，集羣外的客戶端默認情況，無法通過 Pod 的 IP 地址或者 Service 的虛擬 IP 地址: 虛擬端口號進行訪問。通常可以通過以下方式進行訪問 Kubernetes 集羣內的服務：

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

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

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

簡述 Kubernetes ingress？

Kubernetes 的 Ingress 資源對象，用於將不同 URL 的訪問請求轉發到後端不同的 Service，以實現 HTTP 層的業務路由機制。

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

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

簡述 Kubernetes 鏡像的下載策略？

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

• Always：鏡像標籤爲 latest 時，總是從指定的倉庫中獲取鏡像。

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

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

簡述 Kubernetes 的負載均衡器？

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

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

簡述 Kubernetes 各模塊如何與 API Server 通信？

Kubernetes API Server 作爲集羣的核心，負責集羣各功能模塊之間的通信。集羣內的各個功能模塊通過 API Server 將信息存入 etcd，當需要獲取和操作這些數據時，則通過 API Server 提供的 REST 接口（用 GET、LIST 或 WATCH 方法）來實現，從而實現各模塊之間的信息交互。

如 kubelet 進程與 API Server 的交互：每個 Node 上的 kubelet 每隔一個時間週期，就會調用一次 API Server 的 REST 接口報告自身狀態，API Server 在接收到這些信息後，會將節點狀態信息更新到 etcd 中。

如 kube-controller-manager 進程與 API Server 的交互：kube-controller-manager 中的 Node Controller 模塊通過 API Server 提供的 Watch 接口實時監控 Node 的信息，並做相應處理。

如 kube-scheduler 進程與 API Server 的交互：Scheduler 通過 API Server 的 Watch 接口監聽到新建 Pod 副本的信息後，會檢索所有符合該 Pod 要求的 Node 列表，開始執行 Pod 調度邏輯，在調度成功後將 Pod 綁定到目標節點上。

簡述 Kubernetes Scheduler 作用及實現原理？

Kubernetes Scheduler 是負責 Pod 調度的重要功能模塊，Kubernetes Scheduler 在整個系統中承擔了 “承上啓下” 的重要功能，“承上”是指它負責接收 Controller Manager 創建的新 Pod，爲其調度至目標 Node；“啓下”是指調度完成後，目標 Node 上的 kubelet 服務進程接管後繼工作，負責 Pod 接下來生命週期。

Kubernetes Scheduler 的作用是將待調度的 Pod（API 新創建的 Pod、Controller Manager 爲補足副本而創建的 Pod 等）按照特定的調度算法和調度策略綁定（Binding）到集羣中某個合適的 Node 上，並將綁定信息寫入 etcd 中。

在整個調度過程中涉及三個對象，分別是待調度 Pod 列表、可用 Node 列表，以及調度算法和策略。

Kubernetes Scheduler 通過調度算法調度爲待調度 Pod 列表中的每個 Pod 從 Node 列表中選擇一個最適合的 Node 來實現 Pod 的調度。隨後，目標節點上的 kubelet 通過 API Server 監聽到 Kubernetes Scheduler 產生的 Pod 綁定事件，然後獲取對應的 Pod 清單，下載 Image 鏡像並啓動容器。

簡述 Kubernetes Scheduler 使用哪兩種算法將 Pod 綁定到 worker 節點？

Kubernetes Scheduler 根據如下兩種調度算法將 Pod 綁定到最合適的工作節點：

• 預選（Predicates）：輸入是所有節點，輸出是滿足預選條件的節點。kube-scheduler 根據預選策略過濾掉不滿足策略的 Nodes。如果某節點的資源不足或者不滿足預選策略的條件則無法通過預選。如 “Node 的 label 必須與 Pod 的 Selector 一致”。

• 優選（Priorities）：輸入是預選階段篩選出的節點，優選會根據優先策略爲通過預選的 Nodes 進行打分排名，選擇得分最高的 Node。例如，資源越富裕、負載越小的 Node 可能具有越高的排名。

簡述 Kubernetes kubelet 的作用？

在 Kubernetes 集羣中，在每個 Node（又稱 Worker）上都會啓動一個 kubelet 服務進程。該進程用於處理 Master 下發到本節點的任務，管理 Pod 及 Pod 中的容器。每個 kubelet 進程都會在 API Server 上註冊節點自身的信息，定期向 Master 彙報節點資源的使用情況，並通過 cAdvisor 監控容器和節點資源。

簡述 Kubernetes kubelet 監控 Worker 節點資源是使用什麼組件來實現的？

kubelet 使用 cAdvisor 對 worker 節點資源進行監控。在 Kubernetes 系統中，cAdvisor 已被默認集成到 kubelet 組件內，當 kubelet 服務啓動時，它會自動啓動 cAdvisor 服務，然後 cAdvisor 會實時採集所在節點的性能指標及在節點上運行的容器的性能指標。

簡述 Kubernetes 如何保證集羣的安全性？

Kubernetes 通過一系列機制來實現集羣的安全控制，主要有如下不同的維度：

• 基礎設施方面：保證容器與其所在宿主機的隔離；

• 權限方面：

• 最小權限原則：合理限制所有組件的權限，確保組件只執行它被授權的行爲，通過限制單個組件的能力來限制它的權限範圍。

• 用戶權限：劃分普通用戶和管理員的角色。

• 集羣方面：

• API Server 的認證授權：Kubernetes 集羣中所有資源的訪問和變更都是通過 Kubernetes API Server 來實現的，因此需要建議採用更安全的 HTTPS 或 Token 來識別和認證客戶端身份（Authentication），以及隨後訪問權限的授權（Authorization）環節。

• API Server 的授權管理：通過授權策略來決定一個 API 調用是否合法。對合法用戶進行授權並且隨後在用戶訪問時進行鑑權，建議採用更安全的 RBAC 方式來提升集羣安全授權。

• 敏感數據引入 Secret 機制：對於集羣敏感數據建議使用 Secret 方式進行保護。

• AdmissionControl（准入機制）：對 kubernetes api 的請求過程中，順序爲：先經過認證 & 授權，然後執行准入操作，最後對目標對象進行操作。

簡述 Kubernetes 准入機制？

在對集羣進行請求時，每個准入控制代碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求，那麼整個請求的結果將會立即返回，並提示用戶相應的 error 信息。

准入控制（AdmissionControl）准入控制本質上爲一段准入代碼，在對 kubernetes api 的請求過程中，順序爲：先經過認證 & 授權，然後執行准入操作，最後對目標對象進行操作。常用組件（控制代碼）如下：

• AlwaysAdmit：允許所有請求

• AlwaysDeny：禁止所有請求，多用於測試環境。

• ServiceAccount：它將 serviceAccounts 實現了自動化，它會輔助 serviceAccount 做一些事情，比如如果 pod 沒有 serviceAccount 屬性，它會自動添加一個 default，並確保 pod 的 serviceAccount 始終存在。

• LimitRanger：觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在 namespace 中 LimitRange 對象中。

• NamespaceExists：觀察所有的請求，如果請求嘗試創建一個不存在的 namespace，則這個請求被拒絕。

簡述 Kubernetes RBAC 及其特點（優勢）？

RBAC 是基於角色的訪問控制，是一種基於個人用戶的角色來管理對計算機或網絡資源的訪問的方法。

相對於其他授權模式，RBAC 具有如下優勢：

• 對集羣中的資源和非資源權限均有完整的覆蓋。

• 整個 RBAC 完全由幾個 API 對象完成， 同其他 API 對象一樣， 可以用 kubectl 或 API 進行操作。

• 可以在運行時進行調整，無須重新啓動 API Server。

簡述 Kubernetes Secret 作用？

Secret 對象，主要作用是保管私密數據，比如密碼、OAuth Tokens、SSH Keys 等信息。將這些私密信息放在 Secret 對象中比直接放在 Pod 或 Docker Image 中更安全，也更便於使用和分發。

簡述 Kubernetes Secret 有哪些使用方式？

創建完 secret 之後，可通過如下三種方式使用：

• 在創建 Pod 時，通過爲 Pod 指定 Service Account 來自動使用該 Secret。

• 通過掛載該 Secret 到 Pod 來使用它。

• 在 Docker 鏡像下載時使用，通過指定 Pod 的 spc.ImagePullSecrets 來引用它。

簡述 Kubernetes PodSecurityPolicy 機制？

Kubernetes PodSecurityPolicy 是爲了更精細地控制 Pod 對資源的使用方式以及提升安全策略。在開啓 PodSecurityPolicy 准入控制器後，Kubernetes 默認不允許創建任何 Pod，需要創建 PodSecurityPolicy 策略和相應的 RBAC 授權策略（Authorizing Policies），Pod 才能創建成功。

簡述 Kubernetes PodSecurityPolicy 機制能實現哪些安全策略？

在 PodSecurityPolicy 對象中可以設置不同字段來控制 Pod 運行時的各種安全策略，常見的有：

• 特權模式：privileged 是否允許 Pod 以特權模式運行。

• 宿主機資源：控制 Pod 對宿主機資源的控制，如 hostPID：是否允許 Pod 共享宿主機的進程空間。

• 用戶和組：設置運行容器的用戶 ID（範圍）或組（範圍）。

• 提升權限：AllowPrivilegeEscalation：設置容器內的子進程是否可以提升權限，通常在設置非 root 用戶（MustRunAsNonRoot）時進行設置。

• SELinux：進行 SELinux 的相關配置。

簡述 Kubernetes 網絡模型？

Kubernetes 網絡模型中每個 Pod 都擁有一個獨立的 IP 地址，並假定所有 Pod 都在一個可以直接連通的、扁平的網絡空間中。所以不管它們是否運行在同一個 Node（宿主機）中，都要求它們可以直接通過對方的 IP 進行訪問。設計這個原則的原因是，用戶不需要額外考慮如何建立 Pod 之間的連接，也不需要考慮如何將容器端口映射到主機端口等問題。

同時爲每個 Pod 都設置一個 IP 地址的模型使得同一個 Pod 內的不同容器會共享同一個網絡命名空間，也就是同一個 Linux 網絡協議棧。這就意味着同一個 Pod 內的容器可以通過 localhost 來連接對方的端口。

在 Kubernetes 的集羣裏，IP 是以 Pod 爲單位進行分配的。一個 Pod 內部的所有容器共享一個網絡堆棧（相當於一個網絡命名空間，它們的 IP 地址、網絡設備、配置等都是共享的）。

簡述 Kubernetes CNI 模型？

CNI 提供了一種應用容器的插件化網絡解決方案，定義對容器網絡進行操作和配置的規範，通過插件的形式對 CNI 接口進行實現。CNI 僅關注在創建容器時分配網絡資源，和在銷燬容器時刪除網絡資源。在 CNI 模型中只涉及兩個概念：容器和網絡。

• 容器（Container）：是擁有獨立 Linux 網絡命名空間的環境，例如使用 Docker 或 rkt 創建的容器。容器需要擁有自己的 Linux 網絡命名空間，這是加入網絡的必要條件。

• 網絡（Network）：表示可以互連的一組實體，這些實體擁有各自獨立、唯一的 IP 地址，可以是容器、物理機或者其他網絡設備（比如路由器）等。

對容器網絡的設置和操作都通過插件（Plugin）進行具體實現，CNI 插件包括兩種類型：CNI Plugin 和 IPAM（IP Address  Management）Plugin。CNI Plugin 負責爲容器配置網絡資源，IPAM Plugin 負責對容器的 IP 地址進行分配和管理。IPAM Plugin 作爲 CNI Plugin 的一部分，與 CNI Plugin 協同工作。

簡述 Kubernetes 網絡策略？

爲實現細粒度的容器間網絡訪問隔離策略，Kubernetes 引入 Network Policy。

Network Policy 的主要功能是對 Pod 間的網絡通信進行限制和准入控制，設置允許訪問或禁止訪問的客戶端 Pod 列表。Network Policy 定義網絡策略，配合策略控制器（Policy Controller）進行策略的實現。

簡述 Kubernetes 網絡策略原理？

Network Policy 的工作原理主要爲：policy controller 需要實現一個 API Listener，監聽用戶設置的 Network Policy 定義，並將網絡訪問規則通過各 Node 的 Agent 進行實際設置（Agent 則需要通過 CNI 網絡插件實現）。

簡述 Kubernetes 中 flannel 的作用？

Flannel 可以用於 Kubernetes 底層網絡的實現，主要作用有：

• 它能協助 Kubernetes，給每一個 Node 上的 Docker 容器都分配互相不衝突的 IP 地址。

• 它能在這些 IP 地址之間建立一個覆蓋網絡（Overlay Network），通過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內。

簡述 Kubernetes Calico 網絡組件實現原理？

Calico 是一個基於 BGP 的純三層的網絡方案，與 OpenStack、Kubernetes、AWS、GCE 等雲平臺都能夠良好地集成。

Calico 在每個計算節點都利用 Linux Kernel 實現了一個高效的 vRouter 來負責數據轉發。每個 vRouter 都通過 BGP 協議把在本節點上運行的容器的路由信息向整個 Calico 網絡廣播，並自動設置到達其他節點的路由轉發規則。

Calico 保證所有容器之間的數據流量都是通過 IP 路由的方式完成互聯互通的。Calico 節點組網時可以直接利用數據中心的網絡結構（L2 或者 L3），不需要額外的 NAT、隧道或者 Overlay Network，沒有額外的封包解包，能夠節約 CPU 運算，提高網絡效率。

簡述 Kubernetes 共享存儲的作用？

Kubernetes 對於有狀態的容器應用或者對數據需要持久化的應用，因此需要更加可靠的存儲來保存應用產生的重要數據，以便容器應用在重建之後仍然可以使用之前的數據。因此需要使用共享存儲。

簡述 Kubernetes 數據持久化的方式有哪些？

Kubernetes 通過數據持久化來持久化保存重要數據，常見的方式有：

• EmptyDir（空目錄）：沒有指定要掛載宿主機上的某個目錄，直接由 Pod 內保部映射到宿主機上。類似於 docker 中的 manager volume。

• 場景：

• 只需要臨時將數據保存在磁盤上，比如在合併 / 排序算法中；

• 作爲兩個容器的共享存儲。

• 特性：

• 同個 pod 裏面的不同容器，共享同一個持久化目錄，當 pod 節點刪除時，volume 的數據也會被刪除。

• emptyDir 的數據持久化的生命週期和使用的 pod 一致，一般是作爲臨時存儲使用。

• Hostpath：將宿主機上已存在的目錄或文件掛載到容器內部。類似於 docker 中的 bind mount 掛載方式。

• 特性：增加了 pod 與節點之間的耦合。

PersistentVolume（簡稱 PV）：如基於 NFS 服務的 PV，也可以基於 GFS 的 PV。它的作用是統一數據持久化目錄，方便管理。

簡述 Kubernetes PV 和 PVC？

PV 是對底層網絡共享存儲的抽象，將共享存儲定義爲一種 “資源”。

PVC 則是用戶對存儲資源的一個 “申請”。

簡述 Kubernetes PV 生命週期內的階段？

某個 PV 在生命週期中可能處於以下 4 個階段（Phaes）之一。

• Available：可用狀態，還未與某個 PVC 綁定。

• Bound：已與某個 PVC 綁定。

• Released：綁定的 PVC 已經刪除，資源已釋放，但沒有被集羣回收。

• Failed：自動資源回收失敗。

簡述 Kubernetes 所支持的存儲供應模式？

Kubernetes 支持兩種資源的存儲供應模式：靜態模式（Static）和動態模式（Dynamic）。

• 靜態模式：集羣管理員手工創建許多 PV，在定義 PV 時需要將後端存儲的特性進行設置。

• 動態模式：集羣管理員無須手工創建 PV，而是通過 StorageClass 的設置對後端存儲進行描述，標記爲某種類型。此時要求 PVC 對存儲的類型進行聲明，系統將自動完成 PV 的創建及與 PVC 的綁定。

簡述 Kubernetes CSI 模型？

Kubernetes CSI 是 Kubernetes 推出與容器對接的存儲接口標準，存儲提供方只需要基於標準接口進行存儲插件的實現，就能使用 Kubernetes 的原生存儲機制爲容器提供存儲服務。CSI 使得存儲提供方的代碼能和 Kubernetes 代碼徹底解耦，部署也與 Kubernetes 核心組件分離，顯然，存儲插件的開發由提供方自行維護，就能爲 Kubernetes 用戶提供更多的存儲功能，也更加安全可靠。

CSI 包括 CSI Controller 和 CSI Node：

• CSI Controller 的主要功能是提供存儲服務視角對存儲資源和存儲捲進行管理和操作。

• CSI Node 的主要功能是對主機（Node）上的 Volume 進行管理和操作。

簡述 Kubernetes Worker 節點加入集羣的過程？

通常需要對 Worker 節點進行擴容，從而將應用系統進行水平擴展。主要過程如下：

• 1、在該 Node 上安裝 Docker、kubelet 和 kube-proxy 服務；

• 2、然後配置 kubelet 和 kubeproxy 的啓動參數，將 Master URL 指定爲當前 Kubernetes 集羣 Master 的地址，最後啓動這些服務；

• 3、通過 kubelet 默認的自動註冊機制，新的 Worker 將會自動加入現有的 Kubernetes 集羣中；

• 4、Kubernetes Master 在接受了新 Worker 的註冊之後，會自動將其納入當前集羣的調度範圍。

簡述 Kubernetes Pod 如何實現對節點的資源控制？

Kubernetes 集羣裏的節點提供的資源主要是計算資源，計算資源是可計量的能被申請、分配和使用的基礎資源。當前 Kubernetes 集羣中的計算資源主要包括 CPU、GPU 及 Memory。CPU 與 Memory 是被 Pod 使用的，因此在配置 Pod 時可以通過參數 CPU Request 及 Memory Request 爲其中的每個容器指定所需使用的 CPU 與 Memory 量，Kubernetes 會根據 Request 的值去查找有足夠資源的 Node 來調度此 Pod。

通常，一個程序所使用的 CPU 與 Memory 是一個動態的量，確切地說，是一個範圍，跟它的負載密切相關：負載增加時，CPU 和 Memory 的使用量也會增加。

簡述 Kubernetes Requests 和 Limits 如何影響 Pod 的調度？

當一個 Pod 創建成功時，Kubernetes 調度器（Scheduler）會爲該 Pod 選擇一個節點來執行。對於每種計算資源（CPU 和 Memory）而言，每個節點都有一個能用於運行 Pod 的最大容量值。調度器在調度時，首先要確保調度後該節點上所有 Pod 的 CPU 和內存的 Requests 總和，不超過該節點能提供給 Pod 使用的 CPU 和 Memory 的最大容量值。

簡述 Kubernetes Metric Service？

在 Kubernetes 從 1.10 版本後採用 Metrics Server 作爲默認的性能數據採集和監控，主要用於提供核心指標（Core Metrics），包括 Node、Pod 的 CPU 和內存使用指標。

對其他自定義指標（Custom Metrics）的監控則由 Prometheus 等組件來完成。

簡述 Kubernetes 中，如何使用 EFK 實現日誌的統一管理？

在 Kubernetes 集羣環境中，通常一個完整的應用或服務涉及組件過多，建議對日誌系統進行集中化管理，通常採用 EFK 實現。

EFK 是 Elasticsearch、Fluentd 和 Kibana 的組合，其各組件功能如下：

• Elasticsearch：是一個搜索引擎，負責存儲日誌並提供查詢接口；

• Fluentd：負責從 Kubernetes 蒐集日誌，每個 node 節點上面的 fluentd 監控並收集該節點上面的系統日誌，並將處理過後的日誌信息發送給 Elasticsearch；

• Kibana：提供了一個 Web GUI，用戶可以瀏覽和搜索存儲在 Elasticsearch 中的日誌。

通過在每臺 node 上部署一個以 DaemonSet 方式運行的 fluentd 來收集每臺 node 上的日誌。Fluentd 將 docker 日誌目錄 / var/lib/docker/containers 和 / var/log 目錄掛載到 Pod 中，然後 Pod 會在 node 節點的 / var/log/pods 目錄中創建新的目錄，可以區別不同的容器日誌輸出，該目錄下有一個日誌文件鏈接到 / var/lib/docker/contianers 目錄下的容器日誌輸出。

簡述 Kubernetes 如何進行優雅的節點關機維護？

由於 Kubernetes 節點運行大量 Pod，因此在進行關機維護之前，建議先使用 kubectl drain 將該節點的 Pod 進行驅逐，然後進行關機維護。

簡述 Kubernetes 集羣聯邦？

Kubernetes 集羣聯邦可以將多個 Kubernetes 集羣作爲一個集羣進行管理。因此，可以在一個數據中心 / 雲中創建多個 Kubernetes 集羣，並使用集羣聯邦在一個地方控制 / 管理所有集羣。

簡述 Helm 及其優勢？

Helm 是 Kubernetes 的軟件包管理工具。類似 Ubuntu 中使用的 apt、Centos 中使用的 yum 或者 Python 中的 pip 一樣。

Helm 能夠將一組 K8S 資源打包統一管理, 是查找、共享和使用爲 Kubernetes 構建的軟件的最佳方式。

Helm 中通常每個包稱爲一個 Chart，一個 Chart 是一個目錄（一般情況下會將目錄進行打包壓縮，形成 name-version.tgz 格式的單一文件，方便傳輸和存儲）。

• Helm 優勢

在 Kubernetes 中部署一個可以使用的應用，需要涉及到很多的 Kubernetes 資源的共同協作。使用 helm 則具有如下優勢：

• 統一管理、配置和更新這些分散的 k8s 的應用資源文件；

• 分發和複用一套應用模板；

• 將應用的一系列資源當做一個軟件包管理。

• 對於應用發佈者而言，可以通過 Helm 打包應用、管理應用依賴關係、管理應用版本併發布應用到軟件倉庫。

  對於使用者而言，使用 Helm 後不用需要編寫複雜的應用部署文件，可以以簡單的方式在 Kubernetes 上查找、安裝、升級、回滾、卸載應用程序。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/m3iWYLTYqT6jOC8USsceTw