Kubernetes面試必知必會（上）

點(diǎn)擊“程序員面試吧”，選擇“星標(biāo)??”

點(diǎn)擊文末“閱讀原文”解鎖資料！

資料專區(qū)：超全K8s實(shí)戰(zhàn)手冊

《深入淺出Kubernetes項(xiàng)目實(shí)戰(zhàn)手冊》，幫助你一次搞懂 6 個核心原理，吃透基礎(chǔ)理論，一次學(xué)會 6 個典型問題的華麗操作！點(diǎn)擊文末閱讀原文免費(fèi)下載

簡述什么是Kubernetes？

Kubernetes是一個全新的基于容器技術(shù)的分布式系統(tǒng)支撐平臺。是Google開源的容器集群管理系統(tǒng)（谷歌內(nèi)部:Borg）。在Docker技術(shù)的基礎(chǔ)上，為容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動態(tài)伸縮等一系列完整功能，提高了大規(guī)模容器集群管理的便捷性。并且具有完備的集群管理能力，多層次的安全防護(hù)和準(zhǔn)入機(jī)制、多租戶應(yīng)用支撐能力、透明的服務(wù)注冊和發(fā)現(xiàn)機(jī)制、內(nèi)建智能負(fù)載均衡器、強(qiáng)大的故障發(fā)現(xiàn)和自我修復(fù)能力、服務(wù)滾動升級和在線擴(kuò)容能力、可擴(kuò)展的資源自動調(diào)度機(jī)制以及多粒度的資源配額管理能力。

簡述Kubernetes和Docker的關(guān)系？

Docker 提供容器的生命周期管理和，Docker 鏡像構(gòu)建運(yùn)行時容器。它的主要優(yōu)點(diǎn)是將將軟件/應(yīng)用程序運(yùn)行所需的設(shè)置和依賴項(xiàng)打包到一個容器中，從而實(shí)現(xiàn)了可移植性等優(yōu)點(diǎn)。

Kubernetes 用于關(guān)聯(lián)和編排在多個主機(jī)上運(yùn)行的容器。

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

Minikube 是一種可以在本地輕松運(yùn)行一個單節(jié)點(diǎn) Kubernetes 群集的工具。

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

Kubelet 是一個代理服務(wù)，它在每個節(jié)點(diǎn)上運(yùn)行，并使從服務(wù)器與主服務(wù)器通信。

簡述Kubernetes常見的部署方式？

常見的Kubernetes部署方式有：

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

• 二進(jìn)制：

• minikube：在本地輕松運(yùn)行一個單節(jié)點(diǎn) Kubernetes 群集的工具。

簡述Kubernetes如何實(shí)現(xiàn)集群管理？

在集群管理方面，Kubernetes將集群中的機(jī)器劃分為一個Master節(jié)點(diǎn)和一群工作節(jié)點(diǎn)Node。其中，在Master節(jié)點(diǎn)運(yùn)行著集群管理相關(guān)的一組進(jìn)程kube-apiserver、kube-controller-manager和kube-scheduler，這些進(jìn)程實(shí)現(xiàn)了整個集群的資源管理、Pod調(diào)度、彈性伸縮、安全控制、系統(tǒng)監(jiān)控和糾錯等管理能力，并且都是全自動完成的。

簡述Kubernetes的優(yōu)勢、適應(yīng)場景及其特點(diǎn)？

Kubernetes作為一個完備的分布式系統(tǒng)支撐平臺，其主要優(yōu)勢：

• 容器編排

• 輕量級

• 開源

• 彈性伸縮

• 負(fù)載均衡

Kubernetes常見場景：

• 快速部署應(yīng)用

• 快速擴(kuò)展應(yīng)用

• 無縫對接新的應(yīng)用功能

• 節(jié)省資源，優(yōu)化硬件資源的使用

Kubernetes相關(guān)特點(diǎn)：

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

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

• 自動化: 自動部署、自動重啟、自動復(fù)制、自動伸縮/擴(kuò)展。

簡述Kubernetes的缺點(diǎn)或當(dāng)前的不足之處？

Kubernetes當(dāng)前存在的缺點(diǎn)（不足）如下：

• 安裝過程和配置相對困難復(fù)雜。

• 管理服務(wù)相對繁瑣。

• 運(yùn)行和編譯需要很多時間。

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

• 對于簡單的應(yīng)用程序來說，可能不需要涉及Kubernetes即可滿足。

簡述Kubernetes相關(guān)基礎(chǔ)概念？

• master：k8s集群的管理節(jié)點(diǎn)，負(fù)責(zé)管理集群，提供集群的資源數(shù)據(jù)訪問入口。擁有Etcd存儲服務(wù)（可選），運(yùn)行Api Server進(jìn)程，Controller Manager服務(wù)進(jìn)程及Scheduler服務(wù)進(jìn)程。

• node（worker）：Node（worker）是Kubernetes集群架構(gòu)中運(yùn)行Pod的服務(wù)節(jié)點(diǎn)，是Kubernetes集群操作的單元，用來承載被分配Pod的運(yùn)行，是Pod運(yùn)行的宿主機(jī)。運(yùn)行docker eninge服務(wù)，守護(hù)進(jìn)程kunelet及負(fù)載均衡器kube-proxy。

• pod：運(yùn)行于Node節(jié)點(diǎn)上，若干相關(guān)容器的組合。Pod內(nèi)包含的容器運(yùn)行在同一宿主機(jī)上，使用相同的網(wǎng)絡(luò)命名空間、IP地址和端口，能夠通過localhost進(jìn)行通信。Pod是Kurbernetes進(jìn)行創(chuàng)建、調(diào)度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關(guān)容器。

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

• Replication Controller：Replication Controller用來管理Pod的副本，保證集群中存在指定數(shù)量的Pod副本。集群中副本的數(shù)量大于指定數(shù)量，則會停止指定數(shù)量之外的多余容器數(shù)量。反之，則會啟動少于指定數(shù)量個數(shù)的容器，保證數(shù)量不變。Replication Controller是實(shí)現(xiàn)彈性伸縮、動態(tài)擴(kuò)容和滾動升級的核心。

• Deployment：Deployment在內(nèi)部使用了RS來實(shí)現(xiàn)目的，Deployment相當(dāng)于RC的一次升級，其最大的特色為可以隨時獲知當(dāng)前Pod的部署進(jìn)度。

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

• Service：Service定義了Pod的邏輯集合和訪問該集合的策略，是真實(shí)服務(wù)的抽象。Service提供了一個統(tǒng)一的服務(wù)訪問入口以及服務(wù)代理和發(fā)現(xiàn)機(jī)制，關(guān)聯(lián)多個相同Label的Pod，用戶不需要了解后臺Pod是如何運(yùn)行。

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

• Namespace：Namespace用于實(shí)現(xiàn)多租戶的資源隔離，可將集群內(nèi)部的資源對象分配到不同的Namespace中，形成邏輯上的不同項(xiàng)目、小組或用戶組，便于不同的Namespace在共享使用整個集群的資源的同時還能被分別管理。

簡述Kubernetes集群相關(guān)組件？

Kubernetes Master控制組件，調(diào)度管理整個系統(tǒng)（集群），包含如下組件:

• Kubernetes API Server：作為Kubernetes系統(tǒng)的入口，其封裝了核心對象的增刪改查操作，以RESTful API接口方式提供給外部客戶和內(nèi)部組件調(diào)用，集群內(nèi)各個功能模塊之間數(shù)據(jù)交互和通信的中心樞紐。

• Kubernetes Scheduler：為新建立的Pod進(jìn)行節(jié)點(diǎn)(node)選擇(即分配機(jī)器)，負(fù)責(zé)集群的資源調(diào)度。

• Kubernetes Controller：負(fù)責(zé)執(zhí)行各種控制器，目前已經(jīng)提供了很多控制器來保證Kubernetes的正常運(yùn)行。

• Replication Controller：管理維護(hù)Replication Controller，關(guān)聯(lián)Replication Controller和Pod，保證Replication Controller定義的副本數(shù)量與實(shí)際運(yùn)行Pod數(shù)量一致。

• Node Controller：管理維護(hù)Node，定期檢查Node的健康狀態(tài)，標(biāo)識出(失效|未失效)的Node節(jié)點(diǎn)。

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

• Service Controller：管理維護(hù)Service，提供負(fù)載以及服務(wù)代理。

• EndPoints Controller：管理維護(hù)Endpoints，關(guān)聯(lián)Service和Pod，創(chuàng)建Endpoints為Service的后端，當(dāng)Pod發(fā)生變化時，實(shí)時更新Endpoints。

• Service Account Controller：管理維護(hù)Service Account，為每個Namespace創(chuàng)建默認(rèn)的Service Account，同時為Service Account創(chuàng)建Service Account Secret。

• Persistent Volume Controller：管理維護(hù)Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進(jìn)行綁定，為釋放的Persistent Volume執(zhí)行清理回收。

• Daemon Set Controller：管理維護(hù)Daemon Set，負(fù)責(zé)創(chuàng)建Daemon Pod，保證指定的Node上正常的運(yùn)行Daemon Pod。

• Deployment Controller：管理維護(hù)Deployment，關(guān)聯(lián)Deployment和Replication Controller，保證運(yùn)行指定數(shù)量的Pod。當(dāng)Deployment更新時，控制實(shí)現(xiàn)Replication Controller和Pod的更新。

• Job Controller：管理維護(hù)Job，為Jod創(chuàng)建一次性任務(wù)Pod，保證完成Job指定完成的任務(wù)數(shù)目

• Pod Autoscaler Controller：實(shí)現(xiàn)Pod的自動伸縮，定時獲取監(jiān)控?cái)?shù)據(jù)，進(jìn)行策略匹配，當(dāng)滿足條件時執(zhí)行Pod的伸縮動作。

簡述Kubernetes RC的機(jī)制？

Replication Controller用來管理Pod的副本，保證集群中存在指定數(shù)量的Pod副本。當(dāng)定義了RC并提交至Kubernetes集群中之后，Master節(jié)點(diǎn)上的Controller Manager組件獲悉，并同時巡檢系統(tǒng)中當(dāng)前存活的目標(biāo)Pod，并確保目標(biāo)Pod實(shí)例的數(shù)量剛好等于此RC的期望值，若存在過多的Pod副本在運(yùn)行，系統(tǒng)會停止一些Pod，反之則自動創(chuàng)建一些Pod。

簡述Kubernetes Replica Set 和 Replication Controller 之間有什么區(qū)別？

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

簡述kube-proxy作用？

kube-proxy 運(yùn)行在所有節(jié)點(diǎn)上，它監(jiān)聽 apiserver 中 service 和 endpoint 的變化情況，創(chuàng)建路由規(guī)則以提供服務(wù) IP 和負(fù)載均衡功能。簡單理解此進(jìn)程是Service的透明代理兼負(fù)載均衡器，其核心功能是將到某個Service的訪問請求轉(zhuǎn)發(fā)到后端的多個Pod實(shí)例上。

簡述kube-proxy iptables原理？

Kubernetes從1.2版本開始，將iptables作為kube-proxy的默認(rèn)模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch接口實(shí)時跟蹤Service與Endpoint的變更信息，并更新對應(yīng)的iptables規(guī)則，Client的請求流量則通過iptables的NAT機(jī)制“直接路由”到目標(biāo)Pod。

簡述kube-proxy ipvs原理？

IPVS在Kubernetes1.11中升級為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)且粋€線性的數(shù)據(jù)結(jié)構(gòu)，ipset則引入了帶索引的數(shù)據(jù)結(jié)構(gòu)，因此當(dāng)規(guī)則很多時，也可以很高效地查找和匹配。

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

簡述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)勢：

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

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

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

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

簡述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無法對他們進(jìn)行健康檢查。靜態(tài)Pod總是由kubelet進(jìn)行創(chuàng)建，并且總是在kubelet所在的Node上運(yùn)行。

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

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

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

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

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

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

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

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

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

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

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

4. Kube-scheduler檢測到pod信息會開始調(diào)度預(yù)選，會先過濾掉不符合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)行狀況的信息存儲到etcd數(shù)據(jù)中心。

簡述Kubernetes中Pod的重啟策略？

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

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

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

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

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

同時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失效時重啟，不論將RestartPolicy設(shè)置為何值，也不會對Pod進(jìn)行健康檢查。

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

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

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

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

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

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

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

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

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

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

簡述Kubernetes Pod的常見調(diào)度方式？

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

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

• NodeSelector：定向調(diào)度，當(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，語法不同）。

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

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

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

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

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

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

簡述Kubernetes deployment升級過程？

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

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

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

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

簡述Kubernetes deployment升級策略？

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

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

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

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

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

它的一般使用場景如下：

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

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

簡述Kubernetes自動擴(kuò)容機(jī)制？

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

• HPA原理

Kubernetes中的某個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ù)量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發(fā)起scale操作，調(diào)整Pod的副本數(shù)量，完成擴(kuò)縮容操作。

簡述Kubernetes Service類型？

通過創(chuàng)建Service，可以為一組具有相同功能的容器應(yīng)用提供一個統(tǒng)一的入口地址，并且將請求負(fù)載分發(fā)到后端的各個容器應(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地址和端口號就能訪問服務(wù)；

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

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

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

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

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

簡述Kubernetes Headless Service？

在某些應(yī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)用的客戶端。

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

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

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

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

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

簡述Kubernetes ingress？

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

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

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

原文鏈接：https://www.yuque.com/docs/share/d3dd1e8e-6828-4da7-9e30-6a4f45c6fa8e

|免費(fèi)提升專區(qū)|
|掃碼直達(dá)|

點(diǎn)擊閱讀原文解鎖資料！