久久综合五月婷婷,一级电影网址,色婷婷视频在线,欧美成人三级,欧美成人电影视频,色婷婷小说,黄片成人片免费,AAA黄色

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

點擊文末“閱讀原文”解鎖資料

簡述etcd及其特點

etcd是CoreOS團(tuán)隊發(fā)起的開源項目，是一個管理配置信息和服務(wù)發(fā)現(xiàn)（service discovery）的項目，它的目標(biāo)是構(gòu)建一個高可用的分布式鍵值（key-value）數(shù)據(jù)庫，基于Go語言實現(xiàn)。

特點：

簡單：支持REST風(fēng)格的HTTP+JSON API
安全：支持HTTPS方式的訪問
快速：支持并發(fā)1k/s的寫操作
可靠：支持分布式結(jié)構(gòu)，基于Raft的一致性算法，Raft是一套通過選舉主節(jié)點來實現(xiàn)分布式系統(tǒng)一致性的算法。

簡述etcd適應(yīng)的場景

etcd基于其優(yōu)秀的特點，可廣泛的應(yīng)用于以下場景：

服務(wù)發(fā)現(xiàn)（Service Discovery）：服務(wù)發(fā)現(xiàn)主要解決在同一個分布式集群中的進(jìn)程或服務(wù)，要如何才能找到對方并建立連接。本質(zhì)上來說，服務(wù)發(fā)現(xiàn)就是想要了解集群中是否有進(jìn)程在監(jiān)聽UDP或TCP端口，并且通過名字就可以查找和連接。
消息發(fā)布與訂閱：在分布式系統(tǒng)中，最適用的一種組件間通信方式就是消息發(fā)布與訂閱。即構(gòu)建一個配置共享中心，數(shù)據(jù)提供者在這個配置中心發(fā)布消息，而消息使用者則訂閱他們關(guān)心的主題，一旦主題有消息發(fā)布，就會實時通知訂閱者。通過這種方式可以做到分布式系統(tǒng)配置的集中式管理與動態(tài)更新。應(yīng)用中用到的一些配置信息放到etcd上進(jìn)行集中管理。
負(fù)載均衡：在分布式系統(tǒng)中，為了保證服務(wù)的高可用以及數(shù)據(jù)的一致性，通常都會把數(shù)據(jù)和服務(wù)部署多份，以此達(dá)到對等服務(wù)，即使其中的某一個服務(wù)失效了，也不影響使用。etcd本身分布式架構(gòu)存儲的信息訪問支持負(fù)載均衡。etcd集群化以后，每個etcd的核心節(jié)點都可以處理用戶的請求。所以，把數(shù)據(jù)量小但是訪問頻繁的消息數(shù)據(jù)直接存儲到etcd中也可以實現(xiàn)負(fù)載均衡的效果。
分布式通知與協(xié)調(diào)：與消息發(fā)布和訂閱類似，都用到了etcd中的Watcher機(jī)制，通過注冊與異步通知機(jī)制，實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，從而對數(shù)據(jù)變更做到實時處理。
分布式鎖：因為etcd使用Raft算法保持了數(shù)據(jù)的強(qiáng)一致性，某次操作存儲到集群中的值必然是全局一致的，所以很容易實現(xiàn)分布式鎖。鎖服務(wù)有兩種使用方式，一是保持獨占，二是控制時序。
集群監(jiān)控與Leader競選：通過etcd來進(jìn)行監(jiān)控實現(xiàn)起來非常簡單并且實時性強(qiáng)。

簡述什么是Kubernetes

Kubernetes是一個全新的基于容器技術(shù)的分布式系統(tǒng)支撐平臺。是Google開源的容器集群管理系統(tǒng)（谷歌內(nèi)部：Borg）。在Docker技術(shù)的基礎(chǔ)上，為容器化的應(yīng)用提供部署運行、資源調(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ōu)點是將將軟件/應(yīng)用程序運行所需的設(shè)置和依賴項打包到一個容器中，從而實現(xiàn)了可移植性等優(yōu)點。

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

簡述Minikube、Kubectl、Kubelet分別是什么

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

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

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

簡述Kubernetes常見的部署方式

常見的Kubernetes部署方式有：

kubeadm，也是推薦的一種部署方式；
二進(jìn)制；
minikube，在本地輕松運行一個單節(jié)點Kubernetes群集的工具。

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

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

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

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

容器編排
輕量級
開源
彈性伸縮
負(fù)載均衡

Kubernetes常見場景：

快速部署應(yīng)用
快速擴(kuò)展應(yīng)用
無縫對接新的應(yīng)用功能
節(jié)省資源，優(yōu)化硬件資源的使用

Kubernetes相關(guān)特點：

可移植：支持公有云、私有云、混合云、多重云（multi-cloud）。
可擴(kuò)展: 模塊化,、插件化、可掛載、可組合。
自動化: 自動部署、自動重啟、自動復(fù)制、自動伸縮/擴(kuò)展。

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

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

安裝過程和配置相對困難復(fù)雜。
管理服務(wù)相對繁瑣。
運行和編譯需要很多時間。
它比其他替代品更昂貴。
對于簡單的應(yīng)用程序來說，可能不需要涉及Kubernetes即可滿足。

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

Master：Kubernetes集群的管理節(jié)點，負(fù)責(zé)管理集群，提供集群的資源數(shù)據(jù)訪問入口。擁有etcd存儲服務(wù)（可選），運行Api Server進(jìn)程，Controller Manager服務(wù)進(jìn)程及Scheduler服務(wù)進(jìn)程。
Node（worker）：Node（worker）是Kubernetes集群架構(gòu)中運行Pod的服務(wù)節(jié)點，是Kubernetes集群操作的單元，用來承載被分配Pod的運行，是Pod運行的宿主機(jī)。運行Docker Eninge服務(wù)，守護(hù)進(jìn)程kunelet及負(fù)載均衡器kube-proxy。
Pod：運行于Node節(jié)點上，若干相關(guān)容器的組合。Pod內(nèi)包含的容器運行在同一宿主機(jī)上，使用相同的網(wǎng)絡(luò)命名空間、IP地址和端口，能夠通過localhost進(jìn)行通信。Pod是Kubernetes進(jìn)行創(chuàng)建、調(diào)度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關(guān)容器。
Label：Kubernetes中的Label實質(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是實現(xiàn)彈性伸縮、動態(tài)擴(kuò)容和滾動升級的核心。
Deployment：Deployment在內(nèi)部使用了RS來實現(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的邏輯集合和訪問該集合的策略，是真實服務(wù)的抽象。Service提供了一個統(tǒng)一的服務(wù)訪問入口以及服務(wù)代理和發(fā)現(xiàn)機(jī)制，關(guān)聯(lián)多個相同Label的Pod，用戶不需要了解后臺Pod是如何運行。
Volume：Volume是Pod中能夠被多個容器訪問的共享目錄，Kubernetes中的Volume是定義在Pod上，可以被一個或多個Pod中的容器掛載到某個目錄下。
Namespace：Namespace用于實現(xiàn)多租戶的資源隔離，可將集群內(nèi)部的資源對象分配到不同的Namespace中，形成邏輯上的不同項目、小組或用戶組，便于不同的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é)點（Node）選擇（即分配機(jī)器），負(fù)責(zé)集群的資源調(diào)度。
Kubernetes Controller：負(fù)責(zé)執(zhí)行各種控制器，目前已經(jīng)提供了很多控制器來保證Kubernetes的正常運行。
Replication Controller：管理維護(hù)Replication Controller，關(guān)聯(lián)Replication Controller和Pod，保證Replication Controller定義的副本數(shù)量與實際運行Pod數(shù)量一致。
Node Controller：管理維護(hù)Node，定期檢查Node的健康狀態(tài)，標(biāo)識出（失效|未失效）的Node節(jié)點。
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ā)生變化時，實時更新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上正常的運行Daemon Pod。
Deployment Controller：管理維護(hù)Deployment，關(guān)聯(lián)Deployment和Replication Controller，保證運行指定數(shù)量的Pod。當(dāng)Deployment更新時，控制實現(xiàn)Replication Controller和Pod的更新。
Job Controller：管理維護(hù)Job，為Jod創(chuàng)建一次性任務(wù)Pod，保證完成Job指定完成的任務(wù)數(shù)目
Pod Autoscaler Controller：實現(xiàn)Pod的自動伸縮，定時獲取監(jiān)控數(shù)據(jù)，進(jìn)行策略匹配，當(dāng)滿足條件時執(zhí)行Pod的伸縮動作。

簡述Kubernetes RC的機(jī)制

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

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

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

簡述kube-proxy的作用

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

簡述kube-proxy iptables的原理

Kubernetes從1.2版本開始，將iptables作為kube-proxy的默認(rèn)模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch接口實時跟蹤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實現(xiàn)的，但因為定位不同，二者有著本質(zhì)的差別：iptables是為防火墻而設(shè)計的；IPVS則專門用于高性能負(fù)載均衡，并使用更高效的數(shù)據(jù)結(jié)構(gòu)（Hash表），允許幾乎無限的規(guī)模擴(kuò)張。

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

為大型集群提供了更好的可擴(kuò)展性和性能；
支持比iptables更復(fù)雜的復(fù)制均衡算法（最小負(fù)載、最少連接、加權(quán)等）；
支持服務(wù)器健康檢查和連接重試等功能；
可以動態(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上運行。

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

Pending：API Server已經(jīng)創(chuàng)建該Pod，且Pod內(nèi)還有一個或多個容器的鏡像沒有創(chuàng)建，包括正在下載鏡像的過程。
Running：Pod內(nèi)所有容器均已創(chuàng)建，且至少有一個容器處于運行狀態(tài)、正在啟動狀態(tài)或正在重啟狀態(tài)。
Succeeded：Pod內(nèi)所有容器均成功執(zhí)行退出，且不會重啟。
Failed：Pod內(nèi)所有容器均已退出，但至少有一個容器退出為失敗狀態(tài)。
Unknown：由于某種原因無法獲取該Pod狀態(tài)，可能由于網(wǎng)絡(luò)通信不暢導(dǎo)致。

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

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

客戶端提交Pod的配置信息（可以是yaml文件定義的信息）到kube-apiserver。
Apiserver收到指令后，通知給controller-manager創(chuàng)建一個資源對象。
Controller-manager通過api-server將Pod的配置信息存儲到etcd數(shù)據(jù)中心中。
Kube-scheduler檢測到Pod信息會開始調(diào)度預(yù)選，會先過濾掉不符合Pod資源配置要求的節(jié)點，然后開始調(diào)度調(diào)優(yōu)，主要是挑選出更適合運行Pod的節(jié)點，然后將Pod的資源配置單發(fā)送到Node節(jié)點上的kubelet組件上。
Kubelet根據(jù)scheduler發(fā)來的資源配置單運行Pod，運行成功后，將Pod的運行信息返回給scheduler，scheduler將返回的Pod運行狀況的信息存儲到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)容器終止運行且退出碼不為0時，由kubelet自動重啟該容器；
Never：不論容器運行狀態(tài)如何，kubelet都不會重啟該容器。

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

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

RC和DaemonSet：必須設(shè)置為Always，需要保證該容器持續(xù)運行；
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é)點親和力表達(dá)：

requiredDuringSchedulingIgnoredDuringExecution：硬規(guī)則，必須滿足指定的規(guī)則，調(diào)度器才可以調(diào)度Pod至Node上（類似nodeSelector，語法不同）。
preferredDuringSchedulingIgnoredDuringExecution：軟規(guī)則，優(yōu)先調(diào)度至滿足的Node的節(jié)點，但不強(qiáng)求，多個優(yōu)先級規(guī)則還可以設(shè)置權(quán)重值。

Taints和Tolerations（污點和容忍）：

Taint：使Node拒絕特定Pod運行；
Toleration：為Pod的屬性，表示Pod能容忍（運行）標(biāo)注了Taint的Node。

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

init container的運行方式與應(yīng)用容器不同，它們必須先于應(yīng)用容器執(zhí)行完成，當(dāng)設(shè)置了多個init container時，將按順序逐個運行，并且只有前一個init container運行成功后才能運行后一個init container。當(dāng)所有init container都成功運行后，Kubernetes才會初始化Pod的各種信息，并開始創(chuàng)建和運行應(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īng)個新版本Pod副本，舊的ReplicaSet副本數(shù)量則縮減為0。

簡述Kubernetes deployment升級策略

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

Recreate：設(shè)置spec.strategy.type=Recreate，表示Deployment在更新Pod時，會先殺掉所有正在運行的Pod，然后創(chuàng)建新的Pod。
RollingUpdate：設(shè)置spec.strategy.type=RollingUpdate，表示Deployment會以滾動更新的方式來逐個更新Pod。同時，可以通過設(shè)置spec.strategy.rollingUpdate下的兩個參數(shù)（maxUnavailable和maxSurge）來控制滾動更新的過程。

簡述Kubernetes DaemonSet類型的資源特性

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

它的一般使用場景如下：

在去做每個節(jié)點的日志收集工作。
監(jiān)控每個節(jié)點的的運行狀態(tài)。

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

Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實現(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)整。

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)行計算，得到目標(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ù)的其他實例。Kubernetes提供了Headless Service來實現(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，以實現(xiàn)HTTP層的業(yè)務(wù)路由機(jī)制。

Kubernetes使用了Ingress策略和Ingress Controller，兩者結(jié)合并實現(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ù)，則實際上實現(xiàn)的是邊緣路由器的功能。

簡述Kubernetes鏡像的下載策略

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

Always：鏡像標(biāo)簽為latest時，總是從指定的倉庫中獲取鏡像。
Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。
IfNotPresent：僅當(dāng)本地沒有對應(yīng)鏡像時，才從目標(biāo)倉庫中下載。默認(rèn)的鏡像下載策略是：當(dāng)鏡像標(biāo)簽是latest時，默認(rèn)策略是Always；當(dāng)鏡像標(biāo)簽是自定義時（也就是標(biāo)簽不是latest），那么默認(rèn)策略是IfNotPresent。

簡述Kubernetes的負(fù)載均衡器

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

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

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

Kubernetes API Server作為集群的核心，負(fù)責(zé)集群各功能模塊之間的通信。集群內(nèi)的各個功能模塊通過API Server將信息存入etcd，當(dāng)需要獲取和操作這些數(shù)據(jù)時，則通過API Server提供的REST接口（用GET、LIST或WATCH方法）來實現(xiàn)，從而實現(xiàn)各模塊之間的信息交互。

如kubelet進(jìn)程與API Server的交互：每個Node上的kubelet每隔一個時間周期，就會調(diào)用一次API Server的REST接口報告自身狀態(tài)，API Server在接收到這些信息后，會將節(jié)點狀態(tài)信息更新到etcd中。

如kube-controller-manager進(jìn)程與API Server的交互：kube-controller-manager中的Node Controller模塊通過API Server提供的Watch接口實時監(jiān)控Node的信息，并做相應(yīng)處理。

如kube-scheduler進(jìn)程與API Server的交互：Scheduler通過API Server的Watch接口監(jiān)聽到新建Pod副本的信息后，會檢索所有符合該Pod要求的Node列表，開始執(zhí)行Pod調(diào)度邏輯，在調(diào)度成功后將Pod綁定到目標(biāo)節(jié)點上。

簡述Kubernetes Scheduler作用及實現(xiàn)原理

Kubernetes Scheduler是負(fù)責(zé)Pod調(diào)度的重要功能模塊，Kubernetes Scheduler在整個系統(tǒng)中承擔(dān)了“承上啟下”的重要功能，“承上”是指它負(fù)責(zé)接收Controller Manager創(chuàng)建的新Pod，為其調(diào)度至目標(biāo)Node；“啟下”是指調(diào)度完成后，目標(biāo)Node上的kubelet服務(wù)進(jìn)程接管后繼工作，負(fù)責(zé)Pod接下來生命周期。

Kubernetes Scheduler的作用是將待調(diào)度的Pod（API新創(chuàng)建的Pod、Controller Manager為補(bǔ)足副本而創(chuàng)建的Pod等）按照特定的調(diào)度算法和調(diào)度策略綁定（Binding）到集群中某個合適的Node上，并將綁定信息寫入etcd中。

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

Kubernetes Scheduler通過調(diào)度算法調(diào)度為待調(diào)度Pod列表中的每個Pod從Node列表中選擇一個最適合的Node來實現(xiàn)Pod的調(diào)度。隨后，目標(biāo)節(jié)點上的kubelet通過API Server監(jiān)聽到Kubernetes Scheduler產(chǎn)生的Pod綁定事件，然后獲取對應(yīng)的Pod清單，下載Image鏡像并啟動容器。

簡述Kubernetes Scheduler使用哪兩種算法將Pod綁定到worker節(jié)點

Kubernetes Scheduler根據(jù)如下兩種調(diào)度算法將 Pod 綁定到最合適的工作節(jié)點：

預(yù)選（Predicates）：輸入是所有節(jié)點，輸出是滿足預(yù)選條件的節(jié)點。kube-scheduler根據(jù)預(yù)選策略過濾掉不滿足策略的Nodes。如果某節(jié)點的資源不足或者不滿足預(yù)選策略的條件則無法通過預(yù)選。如“Node的label必須與Pod的Selector一致”。
優(yōu)選（Priorities）：輸入是預(yù)選階段篩選出的節(jié)點，優(yōu)選會根據(jù)優(yōu)先策略為通過預(yù)選的Nodes進(jìn)行打分排名，選擇得分最高的Node。例如，資源越富裕、負(fù)載越小的Node可能具有越高的排名。

簡述Kubernetes kubelet的作用

在Kubernetes集群中，在每個Node（又稱Worker）上都會啟動一個kubelet服務(wù)進(jìn)程。該進(jìn)程用于處理Master下發(fā)到本節(jié)點的任務(wù)，管理Pod及Pod中的容器。每個kubelet進(jìn)程都會在API Server上注冊節(jié)點自身的信息，定期向Master匯報節(jié)點資源的使用情況，并通過cAdvisor監(jiān)控容器和節(jié)點資源。

簡述Kubernetes kubelet監(jiān)控Worker節(jié)點資源是使用什么組件來實現(xiàn)的

kubelet使用cAdvisor對worker節(jié)點資源進(jìn)行監(jiān)控。在Kubernetes系統(tǒng)中，cAdvisor已被默認(rèn)集成到kubelet組件內(nèi)，當(dāng)kubelet服務(wù)啟動時，它會自動啟動cAdvisor服務(wù)，然后cAdvisor會實時采集所在節(jié)點的性能指標(biāo)及在節(jié)點上運行的容器的性能指標(biāo)。

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

Kubernetes通過一系列機(jī)制來實現(xiàn)集群的安全控制，主要有如下不同的維度：

基礎(chǔ)設(shè)施方面：保證容器與其所在宿主機(jī)的隔離；
權(quán)限方面：

最小權(quán)限原則：合理限制所有組件的權(quán)限，確保組件只執(zhí)行它被授權(quán)的行為，通過限制單個組件的能力來限制它的權(quán)限范圍。
用戶權(quán)限：劃分普通用戶和管理員的角色。

集群方面：

API Server的認(rèn)證授權(quán)：Kubernetes集群中所有資源的訪問和變更都是通過Kubernetes API Server來實現(xiàn)的，因此需要建議采用更安全的HTTPS或Token來識別和認(rèn)證客戶端身份（Authentication），以及隨后訪問權(quán)限的授權(quán)（Authorization）環(huán)節(jié)。
API Server的授權(quán)管理：通過授權(quán)策略來決定一個API調(diào)用是否合法。對合法用戶進(jìn)行授權(quán)并且隨后在用戶訪問時進(jìn)行鑒權(quán)，建議采用更安全的RBAC方式來提升集群安全授權(quán)。

敏感數(shù)據(jù)引入Secret機(jī)制：對于集群敏感數(shù)據(jù)建議使用Secret方式進(jìn)行保護(hù)。
AdmissionControl（準(zhǔn)入機(jī)制）：對kubernetes api的請求過程中，順序為：先經(jīng)過認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，最后對目標(biāo)對象進(jìn)行操作。

簡述Kubernetes準(zhǔn)入機(jī)制

在對集群進(jìn)行請求時，每個準(zhǔn)入控制代碼都按照一定順序執(zhí)行。如果有一個準(zhǔn)入控制拒絕了此次請求，那么整個請求的結(jié)果將會立即返回，并提示用戶相應(yīng)的error信息。

準(zhǔn)入控制（AdmissionControl）準(zhǔn)入控制本質(zhì)上為一段準(zhǔn)入代碼，在對kubernetes api的請求過程中，順序為：先經(jīng)過認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，最后對目標(biāo)對象進(jìn)行操作。常用組件（控制代碼）如下：

AlwaysAdmit：允許所有請求
AlwaysDeny：禁止所有請求，多用于測試環(huán)境。
ServiceAccount：它將serviceAccounts實現(xiàn)了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動添加一個default，并確保pod的serviceAccount始終存在。
LimitRanger：觀察所有的請求，確保沒有違反已經(jīng)定義好的約束條件，這些條件定義在namespace中LimitRange對象中。
NamespaceExists：觀察所有的請求，如果請求嘗試創(chuàng)建一個不存在的namespace，則這個請求被拒絕。

簡述Kubernetes RBAC及其特點（優(yōu)勢）

RBAC是基于角色的訪問控制，是一種基于個人用戶的角色來管理對計算機(jī)或網(wǎng)絡(luò)資源的訪問的方法。

相對于其他授權(quán)模式，RBAC具有如下優(yōu)勢：

對集群中的資源和非資源權(quán)限均有完整的覆蓋。
整個RBAC完全由幾個API對象完成，同其他API對象一樣，可以用kubectl或API進(jìn)行操作。
可以在運行時進(jìn)行調(diào)整，無須重新啟動API Server。

簡述Kubernetes Secret作用

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

簡述Kubernetes Secret有哪些使用方式

創(chuàng)建完secret之后，可通過如下三種方式使用：

在創(chuàng)建Pod時，通過為Pod指定Service Account來自動使用該Secret。
通過掛載該Secret到Pod來使用它。
在Docker鏡像下載時使用，通過指定Pod的spc.ImagePullSecrets來引用它。

簡述Kubernetes PodSecurityPolicy機(jī)制

Kubernetes PodSecurityPolicy是為了更精細(xì)地控制Pod對資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy準(zhǔn)入控制器后，Kubernetes默認(rèn)不允許創(chuàng)建任何Pod，需要創(chuàng)建PodSecurityPolicy策略和相應(yīng)的RBAC授權(quán)策略（Authorizing Policies），Pod才能創(chuàng)建成功。

簡述Kubernetes PodSecurityPolicy機(jī)制能實現(xiàn)哪些安全策略

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

特權(quán)模式：privileged是否允許Pod以特權(quán)模式運行。
宿主機(jī)資源：控制Pod對宿主機(jī)資源的控制，如hostPID：是否允許Pod共享宿主機(jī)的進(jìn)程空間。
用戶和組：設(shè)置運行容器的用戶ID（范圍）或組（范圍）。
提升權(quán)限：AllowPrivilegeEscalation：設(shè)置容器內(nèi)的子進(jìn)程是否可以提升權(quán)限，通常在設(shè)置非root用戶（MustRunAsNonRoot）時進(jìn)行設(shè)置。
SELinux：進(jìn)行SELinux的相關(guān)配置。

簡述Kubernetes網(wǎng)絡(luò)模型

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

同時為每個Pod都設(shè)置一個IP地址的模型使得同一個Pod內(nèi)的不同容器會共享同一個網(wǎng)絡(luò)命名空間，也就是同一個Linux網(wǎng)絡(luò)協(xié)議棧。這就意味著同一個Pod內(nèi)的容器可以通過localhost來連接對方的端口。

在Kubernetes的集群里，IP是以Pod為單位進(jìn)行分配的。一個Pod內(nèi)部的所有容器共享一個網(wǎng)絡(luò)堆棧（相當(dāng)于一個網(wǎng)絡(luò)命名空間，它們的IP地址、網(wǎng)絡(luò)設(shè)備、配置等都是共享的）。

簡述Kubernetes CNI模型

CNI提供了一種應(yīng)用容器的插件化網(wǎng)絡(luò)解決方案，定義對容器網(wǎng)絡(luò)進(jìn)行操作和配置的規(guī)范，通過插件的形式對CNI接口進(jìn)行實現(xiàn)。CNI僅關(guān)注在創(chuàng)建容器時分配網(wǎng)絡(luò)資源，和在銷毀容器時刪除網(wǎng)絡(luò)資源。在CNI模型中只涉及兩個概念：容器和網(wǎng)絡(luò)。

容器（Container）：是擁有獨立Linux網(wǎng)絡(luò)命名空間的環(huán)境，例如使用Docker或rkt創(chuàng)建的容器。容器需要擁有自己的Linux網(wǎng)絡(luò)命名空間，這是加入網(wǎng)絡(luò)的必要條件。
網(wǎng)絡(luò)（Network）：表示可以互連的一組實體，這些實體擁有各自獨立、唯一的IP地址，可以是容器、物理機(jī)或者其他網(wǎng)絡(luò)設(shè)備（比如路由器）等。

對容器網(wǎng)絡(luò)的設(shè)置和操作都通過插件（Plugin）進(jìn)行具體實現(xiàn)，CNI插件包括兩種類型：CNI Plugin和IPAM（IP Address Management）Plugin。CNI Plugin負(fù)責(zé)為容器配置網(wǎng)絡(luò)資源，IPAM Plugin負(fù)責(zé)對容器的IP地址進(jìn)行分配和管理。IPAM Plugin作為CNI Plugin的一部分，與CNI Plugin協(xié)同工作。

簡述Kubernetes網(wǎng)絡(luò)策略

為實現(xiàn)細(xì)粒度的容器間網(wǎng)絡(luò)訪問隔離策略，Kubernetes引入Network Policy。

Network Policy的主要功能是對Pod間的網(wǎng)絡(luò)通信進(jìn)行限制和準(zhǔn)入控制，設(shè)置允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網(wǎng)絡(luò)策略，配合策略控制器（Policy Controller）進(jìn)行策略的實現(xiàn)。

簡述Kubernetes網(wǎng)絡(luò)策略原理

Network Policy的工作原理主要為：policy controller需要實現(xiàn)一個API Listener，監(jiān)聽用戶設(shè)置的Network Policy定義，并將網(wǎng)絡(luò)訪問規(guī)則通過各Node的Agent進(jìn)行實際設(shè)置（Agent則需要通過CNI網(wǎng)絡(luò)插件實現(xiàn)）。

簡述Kubernetes中flannel的作用

Flannel可以用于Kubernetes底層網(wǎng)絡(luò)的實現(xiàn)，主要作用有：

它能協(xié)助Kubernetes，給每一個Node上的Docker容器都分配互相不沖突的IP地址。
它能在這些IP地址之間建立一個覆蓋網(wǎng)絡(luò)（Overlay Network），通過這個覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動地傳遞到目標(biāo)容器內(nèi)。

簡述Kubernetes Calico網(wǎng)絡(luò)組件實現(xiàn)原理

Calico是一個基于BGP的純?nèi)龑拥木W(wǎng)絡(luò)方案，與OpenStack、Kubernetes、AWS、GCE等云平臺都能夠良好地集成。

Calico在每個計算節(jié)點都利用Linux Kernel實現(xiàn)了一個高效的vRouter來負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)。每個vRouter都通過BGP協(xié)議把在本節(jié)點上運行的容器的路由信息向整個Calico網(wǎng)絡(luò)廣播，并自動設(shè)置到達(dá)其他節(jié)點的路由轉(zhuǎn)發(fā)規(guī)則。

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

簡述Kubernetes共享存儲的作用

Kubernetes對于有狀態(tài)的容器應(yīng)用或者對數(shù)據(jù)需要持久化的應(yīng)用，因此需要更加可靠的存儲來保存應(yīng)用產(chǎn)生的重要數(shù)據(jù)，以便容器應(yīng)用在重建之后仍然可以使用之前的數(shù)據(jù)。因此需要使用共享存儲。

簡述Kubernetes數(shù)據(jù)持久化的方式有哪些

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

EmptyDir（空目錄）：沒有指定要掛載宿主機(jī)上的某個目錄，直接由Pod內(nèi)保部映射到宿主機(jī)上。類似于docker中的manager volume。
場景：

只需要臨時將數(shù)據(jù)保存在磁盤上，比如在合并/排序算法中；
作為兩個容器的共享存儲。

特性：

同個Pod里面的不同容器，共享同一個持久化目錄，當(dāng)Pod節(jié)點刪除時，Volume的數(shù)據(jù)也會被刪除。
EmptyDir的數(shù)據(jù)持久化的生命周期和使用的Pod一致，一般是作為臨時存儲使用。

Hostpath：將宿主機(jī)上已存在的目錄或文件掛載到容器內(nèi)部。類似于Docker中的bind mount掛載方式。
特性：增加了Pod與節(jié)點之間的耦合。
PersistentVolume（簡稱PV）：如基于NFS服務(wù)的PV，也可以基于GFS的PV。它的作用是統(tǒng)一數(shù)據(jù)持久化目錄，方便管理。

簡述Kubernetes PV和PVC

PV是對底層網(wǎng)絡(luò)共享存儲的抽象，將共享存儲定義為一種“資源”。

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

簡述Kubernetes PV生命周期內(nèi)的階段

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

Available：可用狀態(tài)，還未與某個PVC綁定。
Bound：已與某個PVC綁定。
Released：綁定的PVC已經(jīng)刪除，資源已釋放，但沒有被集群回收。
Failed：自動資源回收失敗。

簡述Kubernetes所支持的存儲供應(yīng)模式

Kubernetes支持兩種資源的存儲供應(yīng)模式：靜態(tài)模式（Static）和動態(tài)模式（Dynamic）。

靜態(tài)模式：集群管理員手工創(chuàng)建許多PV，在定義PV時需要將后端存儲的特性進(jìn)行設(shè)置。
動態(tài)模式：集群管理員無須手工創(chuàng)建PV，而是通過StorageClass的設(shè)置對后端存儲進(jìn)行描述，標(biāo)記為某種類型。此時要求PVC對存儲的類型進(jìn)行聲明，系統(tǒng)將自動完成PV的創(chuàng)建及與PVC的綁定。

簡述Kubernetes CSI模型

Kubernetes CSI是Kubernetes推出與容器對接的存儲接口標(biāo)準(zhǔn)，存儲提供方只需要基于標(biāo)準(zhǔn)接口進(jìn)行存儲插件的實現(xiàn)，就能使用Kubernetes的原生存儲機(jī)制為容器提供存儲服務(wù)。CSI使得存儲提供方的代碼能和Kubernetes代碼徹底解耦，部署也與Kubernetes核心組件分離，顯然，存儲插件的開發(fā)由提供方自行維護(hù)，就能為Kubernetes用戶提供更多的存儲功能，也更加安全可靠。

CSI包括CSI Controller和CSI Node：

CSI Controller的主要功能是提供存儲服務(wù)視角對存儲資源和存儲卷進(jìn)行管理和操作。
CSI Node的主要功能是對主機(jī)（Node）上的Volume進(jìn)行管理和操作。

簡述Kubernetes Worker節(jié)點加入集群的過程

通常需要對Worker節(jié)點進(jìn)行擴(kuò)容，從而將應(yīng)用系統(tǒng)進(jìn)行水平擴(kuò)展。主要過程如下：

在該Node上安裝Docker、kubelet和kube-proxy服務(wù)；
然后配置kubelet和kubeproxy的啟動參數(shù)，將Master URL指定為當(dāng)前Kubernetes集群Master的地址，最后啟動這些服務(wù)；
通過kubelet默認(rèn)的自動注冊機(jī)制，新的Worker將會自動加入現(xiàn)有的Kubernetes集群中；
Kubernetes Master在接受了新Worker的注冊之后，會自動將其納入當(dāng)前集群的調(diào)度范圍。

簡述Kubernetes Pod如何實現(xiàn)對節(jié)點的資源控制

Kubernetes集群里的節(jié)點提供的資源主要是計算資源，計算資源是可計量的能被申請、分配和使用的基礎(chǔ)資源。當(dāng)前Kubernetes集群中的計算資源主要包括CPU、GPU及Memory。CPU與Memory是被Pod使用的，因此在配置Pod時可以通過參數(shù)CPU Request及Memory Request為其中的每個容器指定所需使用的CPU與Memory量，Kubernetes會根據(jù)Request的值去查找有足夠資源的Node來調(diào)度此Pod。

通常，一個程序所使用的CPU與Memory是一個動態(tài)的量，確切地說，是一個范圍，跟它的負(fù)載密切相關(guān)：負(fù)載增加時，CPU和Memory的使用量也會增加。

簡述Kubernetes Requests和Limits如何影響Pod的調(diào)度

當(dāng)一個Pod創(chuàng)建成功時，Kubernetes調(diào)度器（Scheduler）會為該Pod選擇一個節(jié)點來執(zhí)行。對于每種計算資源（CPU和Memory）而言，每個節(jié)點都有一個能用于運行Pod的最大容量值。調(diào)度器在調(diào)度時，首先要確保調(diào)度后該節(jié)點上所有Pod的CPU和內(nèi)存的Requests總和，不超過該節(jié)點能提供給Pod使用的CPU和Memory的最大容量值。

簡述Kubernetes Metric Service

在Kubernetes從1.10版本后采用Metrics Server作為默認(rèn)的性能數(shù)據(jù)采集和監(jiān)控，主要用于提供核心指標(biāo)（Core Metrics），包括Node、Pod的CPU和內(nèi)存使用指標(biāo)。

對其他自定義指標(biāo)（Custom Metrics）的監(jiān)控則由Prometheus等組件來完成。

簡述Kubernetes中，如何使用EFK實現(xiàn)日志的統(tǒng)一管理

在Kubernetes集群環(huán)境中，通常一個完整的應(yīng)用或服務(wù)涉及組件過多，建議對日志系統(tǒng)進(jìn)行集中化管理，通常采用EFK實現(xiàn)。

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

Elasticsearch：是一個搜索引擎，負(fù)責(zé)存儲日志并提供查詢接口；
Fluentd：負(fù)責(zé)從 Kubernetes 搜集日志，每個Node節(jié)點上面的Fluentd監(jiān)控并收集該節(jié)點上面的系統(tǒng)日志，并將處理過后的日志信息發(fā)送給Elasticsearch；
Kibana：提供了一個 Web GUI，用戶可以瀏覽和搜索存儲在 Elasticsearch 中的日志。

通過在每臺Node上部署一個以DaemonSet方式運行的Fluentd來收集每臺Node上的日志。Fluentd將Docker日志目錄/var/lib/docker/containers和/var/log目錄掛載到Pod中，然后Pod會在Node節(jié)點的/var/log/pods目錄中創(chuàng)建新的目錄，可以區(qū)別不同的容器日志輸出，該目錄下有一個日志文件鏈接到/var/lib/docker/contianers目錄下的容器日志輸出。

簡述Kubernetes如何進(jìn)行優(yōu)雅的節(jié)點關(guān)機(jī)維護(hù)

由于Kubernetes節(jié)點運行大量Pod，因此在進(jìn)行關(guān)機(jī)維護(hù)之前，建議先使用kubectl drain將該節(jié)點的Pod進(jìn)行驅(qū)逐，然后進(jìn)行關(guān)機(jī)維護(hù)。

簡述Kubernetes集群聯(lián)邦

Kubernetes集群聯(lián)邦可以將多個Kubernetes集群作為一個集群進(jìn)行管理。因此，可以在一個數(shù)據(jù)中心/云中創(chuàng)建多個Kubernetes集群，并使用集群聯(lián)邦在一個地方控制/管理所有集群。

簡述Helm及其優(yōu)勢

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

Helm能夠?qū)⒁唤MKubernetes資源打包統(tǒng)一管理, 是查找、共享和使用為Kubernetes構(gòu)建的軟件的最佳方式。

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

在Kubernetes中部署一個可以使用的應(yīng)用，需要涉及到很多的 Kubernetes 資源的共同協(xié)作。使用Helm則具有如下優(yōu)勢：

統(tǒng)一管理、配置和更新這些分散的Kubernetes的應(yīng)用資源文件；
分發(fā)和復(fù)用一套應(yīng)用模板；
將應(yīng)用的一系列資源當(dāng)做一個軟件包管理。
對于應(yīng)用發(fā)布者而言，可以通過 Helm 打包應(yīng)用、管理應(yīng)用依賴關(guān)系、管理應(yīng)用版本并發(fā)布應(yīng)用到軟件倉庫。

對于使用者而言，使用Helm后不用需要編寫復(fù)雜的應(yīng)用部署文件，可以以簡單的方式在Kubernetes上查找、安裝、升級、回滾、卸載應(yīng)用程序。

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

60道重要的Kubernetes面試題