1.簡(jiǎn)述 kube-proxy ipvs 原理？

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

在 IPVS 模式下，使用 iptables 的擴(kuò)展 ipset，而不是直接調(diào)用 iptables 來生成規(guī)則鏈。iptables 規(guī)則鏈?zhǔn)且粋€(gè)線性的數(shù)據(jù)結(jié)構(gòu)，ipset 則引入了帶索引的數(shù)據(jù)結(jié)構(gòu)，因此當(dāng)規(guī)則很多時(shí)，也可以很高效地查找和匹配。

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

2.簡(jiǎn)述 kube-proxy ipvs 和 iptables 的異同？

iptables 與 IPVS 都是基于 Netfilter 實(shí)現(xiàn)的，但因?yàn)槎ㄎ徊煌?，二者有著本質(zhì)的差別：iptables 是為防火墻而設(shè)計(jì)的；IPVS 則專門用于高性能負(fù)載均衡，并使用更高效的數(shù)據(jù)結(jié)構(gòu)（Hash 表），允許幾乎無限的規(guī)模擴(kuò)張。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3、Controller-manager 通過 api-server 將 pod 的配置信息存儲(chǔ)到 ETCD 數(shù)據(jù)中心中。

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

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

6.簡(jiǎn)述 Kubernetes 中 Pod 的重啟策略？

Pod 重啟策略（RestartPolicy）應(yīng)用于 Pod 內(nèi)的所有容器，并且僅在 Pod 所處的 Node 上由 kubelet 進(jìn)行判斷和重啟操作。當(dāng)某個(gè)容器異常退出或者健康檢查失敗時(shí)，kubelet 將根據(jù) RestartPolicy 的設(shè)置來進(jìn)行相應(yīng)操作。

Pod 的重啟策略包括 Always、OnFailure 和 Never，默認(rèn)值為 Always。

●Always：當(dāng)容器失效時(shí)，由 kubelet 自動(dòng)重啟該容器；

●OnFailure：當(dāng)容器終止運(yùn)行且退出碼不為 0 時(shí)，由 kubelet 自動(dòng)重啟該容器；

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

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

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

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

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

● kubelet：在 Pod 失效時(shí)重啟，不論將 RestartPolicy 設(shè)置為何值，也不會(huì)對(duì) Pod 進(jìn)行健康檢查。

7.簡(jiǎn)述 Kubernetes 中 Pod 的健康檢查方式？

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

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

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

●startupProbe 探針：?jiǎn)?dòng)檢查機(jī)制，應(yīng)用一些啟動(dòng)緩慢的業(yè)務(wù)，避免業(yè)務(wù)長(zhǎng)時(shí)間啟動(dòng)而被上面兩類探針 kill 掉。

8.簡(jiǎn)述 Kubernetes Pod 的 LivenessProbe 探針的常見方式？

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

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

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

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

9.簡(jiǎn)述 Kubernetes Pod 的常見調(diào)度方式？

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

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

●NodeSelector：定向調(diào)度，當(dāng)需要手動(dòng)指定將 Pod 調(diào)度到特定 Node 上，可以通過 Node 的標(biāo)簽（Label）和 Pod 的 nodeSelector 屬性相匹配。

●NodeAffinity 親和性調(diào)度：親和性調(diào)度機(jī)制極大的擴(kuò)展了 Pod 的調(diào)度能力，目前有兩種節(jié)點(diǎn)親和力表達(dá)：

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

●preferredDuringSchedulingIgnoredDuringExecution：軟規(guī)則，優(yōu)先調(diào)度至滿足的 Node 的節(jié)點(diǎn)，但不強(qiáng)求，多個(gè)優(yōu)先級(jí)規(guī)則還可以設(shè)置權(quán)重值。

●Taints 和 Tolerations（污點(diǎn)和容忍）

●Taint：使 Node 拒絕特定 Pod 運(yùn)行；

●Toleration：為 Pod 的屬性，表示 Pod 能容忍（運(yùn)行）標(biāo)注了 Taint 的 Node。

10.簡(jiǎn)述Kubernetes初始化容器（init container）？

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

11.簡(jiǎn)述 Kubernetes deployment 升級(jí)過程？

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

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

●之后，系統(tǒng)繼續(xù)按照相同的更新策略對(duì)新舊兩個(gè) ReplicaSet 進(jìn)行逐個(gè)調(diào)整。

●最后，新的 ReplicaSet 運(yùn)行了對(duì)應(yīng)個(gè)新版本 Pod 副本，舊的 ReplicaSet 副本數(shù)量則縮減為 0。

12.簡(jiǎn)述 Kubernetes deployment 升級(jí)策略？

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

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

●RollingUpdate：設(shè)置 spec.strategy.type=RollingUpdate，表示 Deployment會(huì)以滾動(dòng)更新的方式來逐個(gè)更新 Pod。同時(shí)，可以通過設(shè)置spec.strategy.rollingUpdate 下的兩個(gè)參數(shù)（maxUnavailable 和 maxSurge）來控制滾動(dòng)更新的過程。

13.簡(jiǎn)述 Kubernetes DaemonSet 類型的資源特性？

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

它的一般使用場(chǎng)景如下：

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

●監(jiān)控每個(gè)節(jié)點(diǎn)的的運(yùn)行狀態(tài)。

14.簡(jiǎn)述 Kubernetes 自動(dòng)擴(kuò)容機(jī)制？

Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器實(shí)現(xiàn)基于 CPU使用率進(jìn)行自動(dòng) Pod 擴(kuò)縮容的功能。HPA 控制器周期性地監(jiān)測(cè)目標(biāo) Pod 的資源性能指標(biāo)，并與 HPA 資源對(duì)象中的擴(kuò)縮容條件進(jìn)行對(duì)比，在滿足條件時(shí)對(duì) Pod 副本數(shù)量進(jìn)行調(diào)整。

●HPA 原理

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

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

15.簡(jiǎn)述 Kubernetes Service 類型？

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

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

●NodePort：使用宿主機(jī)的端口，使能夠訪問各 Node 的外部客戶端通過 Node 的 IP 地址和端口號(hào)就能訪問服務(wù)；

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

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

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

●RoundRobin：默認(rèn)為輪詢模式，即輪詢將請(qǐng)求轉(zhuǎn)發(fā)到后端的各個(gè) Pod 上。

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

17.簡(jiǎn)述 Kubernetes Headless Service？

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

18.簡(jiǎn)述 Kubernetes 外部如何訪問集群內(nèi)的服務(wù)？

對(duì)于 Kubernetes，集群外的客戶端默認(rèn)情況，無法通過 Pod 的 IP 地址或者 Service 的虛擬 IP 地址:虛擬端口號(hào)進(jìn)行訪問。通常可以通過以下方式進(jìn)行訪問 Kubernetes 集群內(nèi)的服務(wù)：

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

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

●映射 Sercie 到 LoadBalancer：通過設(shè)置 LoadBalancer 映射到云服務(wù)商提供的 LoadBalancer 地址。這種用法僅用于在公有云服務(wù)提供商的云平臺(tái)上設(shè)置 Service 的場(chǎng)景。

19.簡(jiǎn)述 Kubernetes ingress？

Kubernetes 的 Ingress 資源對(duì)象，用于將不同 URL 的訪問請(qǐng)求轉(zhuǎn)發(fā)到后端不同的 Service，以實(shí)現(xiàn) HTTP 層的業(yè)務(wù)路由機(jī)制。

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

同時(shí)當(dāng) Ingress Controller 提供的是對(duì)外服務(wù)，則實(shí)際上實(shí)現(xiàn)的是邊緣路由器的功能。

20.簡(jiǎn)述 Kubernetes 鏡像的下載策略？

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

●Always：鏡像標(biāo)簽為 latest 時(shí)，總是從指定的倉(cāng)庫(kù)中獲取鏡像。

●Never：禁止從倉(cāng)庫(kù)中下載鏡像，也就是說只能使用本地鏡像。

●IfNotPresent：僅當(dāng)本地沒有對(duì)應(yīng)鏡像時(shí)，才從目標(biāo)倉(cāng)庫(kù)中下載。默認(rèn)的鏡像下載策略是：當(dāng)鏡像標(biāo)簽是 latest 時(shí)，默認(rèn)策略是 Always；當(dāng)鏡像標(biāo)簽是自定義時(shí)（也就是標(biāo)簽不是 latest），那么默認(rèn)策略是 IfNotPresent。

21.簡(jiǎn)述 Kubernetes 的負(fù)載均衡器？

負(fù)載均衡器是暴露服務(wù)的最常見和標(biāo)準(zhǔn)方式之一。

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

審核編輯 ：李倩