【面朝大廠】k8s面試問(wèn)什么？
1、 k8s是什么？請(qǐng)說(shuō)出你的了解？ 2、 K8s架構(gòu)的組成是什么？ 3、 容器和主機(jī)部署應(yīng)用的區(qū)別是什么？ 4、請(qǐng)你說(shuō)一下kubenetes針對(duì)pod資源對(duì)象的健康監(jiān)測(cè)機(jī)制？ 5、 如何控制滾動(dòng)更新過(guò)程？ 6、K8s中鏡像的下載策略是什么？ 7、 image的狀態(tài)有哪些？ 8、 pod的重啟策略是什么？ 9、 Service這種資源對(duì)象的作用是什么？ 10、版本回滾相關(guān)的命令？ 11、 標(biāo)簽與標(biāo)簽選擇器的作用是什么？ 12、 常用的標(biāo)簽分類有哪些？ 13、 有幾種查看標(biāo)簽的方式？ 14、 添加、修改、刪除標(biāo)簽的命令？ 15、 DaemonSet資源對(duì)象的特性？ 16、 說(shuō)說(shuō)你對(duì)Job這種資源對(duì)象的了解？ 17、描述一下pod的生命周期有哪些狀態(tài)？ 18、 創(chuàng)建一個(gè)pod的流程是什么？ 19、 刪除一個(gè)Pod會(huì)發(fā)生什么事情？ 20、 K8s的Service是什么？ 21、 k8s是怎么進(jìn)行服務(wù)注冊(cè)的？ 22、 k8s集群外流量怎么訪問(wèn)Pod？ 23、 k8s數(shù)據(jù)持久化的方式有哪些？
注：以下所有問(wèn)題，均為自己總結(jié)，若有錯(cuò)誤之處，還請(qǐng)指出。
1、 k8s是什么？請(qǐng)說(shuō)出你的了解？
答：Kubenetes是一個(gè)針對(duì)容器應(yīng)用，進(jìn)行自動(dòng)部署，彈性伸縮和管理的開(kāi)源系統(tǒng)。主要功能是生產(chǎn)環(huán)境中的容器編排。
K8S是Google公司推出的，它來(lái)源于由Google公司內(nèi)部使用了15年的Borg系統(tǒng)，集結(jié)了Borg的精華。
2、 K8s架構(gòu)的組成是什么？
答：和大多數(shù)分布式系統(tǒng)一樣，K8S集群至少需要一個(gè)主節(jié)點(diǎn)（Master）和多個(gè)計(jì)算節(jié)點(diǎn)（Node）。
主節(jié)點(diǎn)主要用于暴露API，調(diào)度部署和節(jié)點(diǎn)的管理； 計(jì)算節(jié)點(diǎn)運(yùn)行一個(gè)容器運(yùn)行環(huán)境，一般是docker環(huán)境（類似docker環(huán)境的還有rkt），同時(shí)運(yùn)行一個(gè)K8s的代理（kubelet）用于和master通信。計(jì)算節(jié)點(diǎn)也會(huì)運(yùn)行一些額外的組件，像記錄日志，節(jié)點(diǎn)監(jiān)控，服務(wù)發(fā)現(xiàn)等等。計(jì)算節(jié)點(diǎn)是k8s集群中真正工作的節(jié)點(diǎn)。
K8S架構(gòu)細(xì)分：
1、Master節(jié)點(diǎn)（默認(rèn)不參加實(shí)際工作）：
Kubectl：客戶端命令行工具，作為整個(gè)K8s集群的操作入口； Api Server：在K8s架構(gòu)中承擔(dān)的是“橋梁”的角色，作為資源操作的唯一入口，它提供了認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制?？蛻舳伺ck8s群集及K8s內(nèi)部組件的通信，都要通過(guò)Api Server這個(gè)組件； Controller-manager：負(fù)責(zé)維護(hù)群集的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等； Scheduler：負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將pod調(diào)度到相應(yīng)的node節(jié)點(diǎn)上； Etcd：擔(dān)任數(shù)據(jù)中心的角色，保存了整個(gè)群集的狀態(tài)；
2、Node節(jié)點(diǎn)：
Kubelet：負(fù)責(zé)維護(hù)容器的生命周期，同時(shí)也負(fù)責(zé)Volume和網(wǎng)絡(luò)的管理，一般運(yùn)行在所有的節(jié)點(diǎn)，是Node節(jié)點(diǎn)的代理，當(dāng)Scheduler確定某個(gè)node上運(yùn)行pod之后，會(huì)將pod的具體信息（image，volume）等發(fā)送給該節(jié)點(diǎn)的kubelet，kubelet根據(jù)這些信息創(chuàng)建和運(yùn)行容器，并向master返回運(yùn)行狀態(tài)。（自動(dòng)修復(fù)功能：如果某個(gè)節(jié)點(diǎn)中的容器宕機(jī)，它會(huì)嘗試重啟該容器，若重啟無(wú)效，則會(huì)將該pod殺死，然后重新創(chuàng)建一個(gè)容器）； Kube-proxy：Service在邏輯上代表了后端的多個(gè)pod。負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡（外界通過(guò)Service訪問(wèn)pod提供的服務(wù)時(shí)，Service接收到的請(qǐng)求后就是通過(guò)kube-proxy來(lái)轉(zhuǎn)發(fā)到pod上的）； container-runtime：是負(fù)責(zé)管理運(yùn)行容器的軟件，比如docker Pod：是k8s集群里面最小的單位。每個(gè)pod里邊可以運(yùn)行一個(gè)或多個(gè)container（容器），如果一個(gè)pod中有兩個(gè)container，那么container的USR（用戶）、MNT（掛載點(diǎn)）、PID（進(jìn)程號(hào)）是相互隔離的，UTS（主機(jī)名和域名）、IPC（消息隊(duì)列）、NET（網(wǎng)絡(luò)棧）是相互共享的。我比較喜歡把pod來(lái)當(dāng)做豌豆夾，而豌豆就是pod中的container；
3、 容器和主機(jī)部署應(yīng)用的區(qū)別是什么？
答：容器的中心思想就是秒級(jí)啟動(dòng)；一次封裝、到處運(yùn)行；這是主機(jī)部署應(yīng)用無(wú)法達(dá)到的效果，但同時(shí)也更應(yīng)該注重容器的數(shù)據(jù)持久化問(wèn)題。
另外，容器部署可以將各個(gè)服務(wù)進(jìn)行隔離，互不影響，這也是容器的另一個(gè)核心概念。
4、請(qǐng)你說(shuō)一下kubenetes針對(duì)pod資源對(duì)象的健康監(jiān)測(cè)機(jī)制？
答：K8s中對(duì)于pod資源對(duì)象的健康狀態(tài)檢測(cè)，提供了三類probe（探針）來(lái)執(zhí)行對(duì)pod的健康監(jiān)測(cè)：
1） livenessProbe探針
可以根據(jù)用戶自定義規(guī)則來(lái)判定pod是否健康，如果livenessProbe探針探測(cè)到容器不健康，則kubelet會(huì)根據(jù)其重啟策略來(lái)決定是否重啟，如果一個(gè)容器不包含livenessProbe探針，則kubelet會(huì)認(rèn)為容器的livenessProbe探針的返回值永遠(yuǎn)成功。
2） ReadinessProbe探針
同樣是可以根據(jù)用戶自定義規(guī)則來(lái)判斷pod是否健康，如果探測(cè)失敗，控制器會(huì)將此pod從對(duì)應(yīng)service的endpoint列表中移除，從此不再將任何請(qǐng)求調(diào)度到此Pod上，直到下次探測(cè)成功。
3） startupProbe探針
啟動(dòng)檢查機(jī)制，應(yīng)用一些啟動(dòng)緩慢的業(yè)務(wù)，避免業(yè)務(wù)長(zhǎng)時(shí)間啟動(dòng)而被上面兩類探針kill掉，這個(gè)問(wèn)題也可以換另一種方式解決，就是定義上面兩類探針機(jī)制時(shí)，初始化時(shí)間定義的長(zhǎng)一些即可。
每種探測(cè)方法能支持以下幾個(gè)相同的檢查參數(shù)，用于設(shè)置控制檢查時(shí)間：
initialDelaySeconds：初始第一次探測(cè)間隔，用于應(yīng)用啟動(dòng)的時(shí)間，防止應(yīng)用還沒(méi)啟動(dòng)而健康檢查失敗 periodSeconds：檢查間隔，多久執(zhí)行probe檢查，默認(rèn)為10s； timeoutSeconds：檢查超時(shí)時(shí)長(zhǎng)，探測(cè)應(yīng)用timeout后為失敗； successThreshold：成功探測(cè)閾值，表示探測(cè)多少次為健康正常，默認(rèn)探測(cè)1次。
上面兩種探針都支持以下三種探測(cè)方法：
1）Exec：?通過(guò)執(zhí)行命令的方式來(lái)檢查服務(wù)是否正常，比如使用cat命令查看pod中的某個(gè)重要配置文件是否存在，若存在，則表示pod健康。反之異常。
Exec探測(cè)方式的yaml文件語(yǔ)法如下：
spec:
??containers:
??-?name:?liveness
????image:?k8s.gcr.io/busybox
????args:
????-?/bin/sh
????-?-c
????-?touch?/tmp/healthy;?sleep?30;?rm?-rf?/tmp/healthy;?sleep?600
????livenessProbe:?????????#選擇livenessProbe的探測(cè)機(jī)制
??????exec:??????????????????????#執(zhí)行以下命令
????????command:
????????-?cat
????????-?/tmp/healthy
??????initialDelaySeconds:?5??????????#在容器運(yùn)行五秒后開(kāi)始探測(cè)
??????periodSeconds:?5???????????????#每次探測(cè)的時(shí)間間隔為5秒
在上面的配置文件中，探測(cè)機(jī)制為在容器運(yùn)行5秒后，每隔五秒探測(cè)一次，如果cat命令返回的值為“0”，則表示健康，如果為非0，則表示異常。
2）Httpget：?通過(guò)發(fā)送http/htps請(qǐng)求檢查服務(wù)是否正常，返回的狀態(tài)碼為200-399則表示容器健康（注http get類似于命令curl -I）。
Httpget探測(cè)方式的yaml文件語(yǔ)法如下：
spec:
??containers:
??-?name:?liveness
????image:?k8s.gcr.io/liveness
????livenessProbe:??????????????#采用livenessProbe機(jī)制探測(cè)
??????httpGet:??????????????????#采用httpget的方式
????scheme:HTTP?????????#指定協(xié)議，也支持https
????????path:?/healthz??????????#檢測(cè)是否可以訪問(wèn)到網(wǎng)頁(yè)根目錄下的healthz網(wǎng)頁(yè)文件
????????port:?8080??????????????#監(jiān)聽(tīng)端口是8080
??????initialDelaySeconds:?3?????#容器運(yùn)行3秒后開(kāi)始探測(cè)
??????periodSeconds:?3????????????????#探測(cè)頻率為3秒
上述配置文件中，探測(cè)方式為項(xiàng)容器發(fā)送HTTP GET請(qǐng)求，請(qǐng)求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的狀態(tài)碼表示成功。任何其他代碼表示異常。
3）tcpSocket：?通過(guò)容器的IP和Port執(zhí)行TCP檢查，如果能夠建立TCP連接，則表明容器健康，這種方式與HTTPget的探測(cè)機(jī)制有些類似，tcpsocket健康檢查適用于TCP業(yè)務(wù)。
tcpSocket探測(cè)方式的yaml文件語(yǔ)法如下：
spec:
??containers:
??-?name:?goproxy
????image:?k8s.gcr.io/goproxy:0.1
????ports:
-?containerPort:?8080
#這里兩種探測(cè)機(jī)制都用上了，都是為了和容器的8080端口建立TCP連接
????readinessProbe:
??????tcpSocket:
????????port:?8080
??????initialDelaySeconds:?5
??????periodSeconds:?10
????livenessProbe:
??????tcpSocket:
????????port:?8080
??????initialDelaySeconds:?15
??????periodSeconds:?20
在上述的yaml配置文件中，兩類探針都使用了，在容器啟動(dòng)5秒后，kubelet將發(fā)送第一個(gè)readinessProbe探針，這將連接容器的8080端口，如果探測(cè)成功，則該pod為健康，十秒后，kubelet將進(jìn)行第二次連接。
除了readinessProbe探針外，在容器啟動(dòng)15秒后，kubelet將發(fā)送第一個(gè)livenessProbe探針，仍然嘗試連接容器的8080端口，如果連接失敗，則重啟容器。
探針探測(cè)的結(jié)果無(wú)外乎以下三者之一：
Success：Container通過(guò)了檢查； Failure：Container沒(méi)有通過(guò)檢查； Unknown：沒(méi)有執(zhí)行檢查，因此不采取任何措施（通常是我們沒(méi)有定義探針檢測(cè)，默認(rèn)為成功）。
若覺(jué)得上面還不夠透徹，可以移步其官網(wǎng)文檔：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
5、 如何控制滾動(dòng)更新過(guò)程？
答：可以通過(guò)下面的命令查看到更新時(shí)可以控制的參數(shù)：
[root@master?yaml]#?kubectl?explain?deploy.spec.strategy.rollingUpdate
maxSurge：? 此參數(shù)控制滾動(dòng)更新過(guò)程，副本總數(shù)超過(guò)預(yù)期pod數(shù)量的上限?？梢允前俜直龋部梢允蔷唧w的值。默認(rèn)為1。
（上述參數(shù)的作用就是在更新過(guò)程中，值若為3，那么不管三七二一，先運(yùn)行三個(gè)pod，用于替換舊的pod，以此類推）
maxUnavailable：?此參數(shù)控制滾動(dòng)更新過(guò)程中，不可用的Pod的數(shù)量。
（這個(gè)值和上面的值沒(méi)有任何關(guān)系，舉個(gè)例子：我有十個(gè)pod，但是在更新的過(guò)程中，我允許這十個(gè)pod中最多有三個(gè)不可用，那么就將這個(gè)參數(shù)的值設(shè)置為3，在更新的過(guò)程中，只要不可用的pod數(shù)量小于或等于3，那么更新過(guò)程就不會(huì)停止）。
6、K8s中鏡像的下載策略是什么？
答：可通過(guò)命令“kubectl explain pod.spec.containers”來(lái)查看imagePullPolicy這行的解釋。
K8s的鏡像下載策略有三種：Always、Never、IFNotPresent；
Always：鏡像標(biāo)簽為latest時(shí)，總是從指定的倉(cāng)庫(kù)中獲取鏡像； Never：禁止從倉(cāng)庫(kù)中下載鏡像，也就是說(shuō)只能使用本地鏡像； IfNotPresent：僅當(dāng)本地沒(méi)有對(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。
7、 image的狀態(tài)有哪些？
Running：Pod所需的容器已經(jīng)被成功調(diào)度到某個(gè)節(jié)點(diǎn)，且已經(jīng)成功運(yùn)行， Pending：APIserver創(chuàng)建了pod資源對(duì)象，并且已經(jīng)存入etcd中，但它尚未被調(diào)度完成或者仍然處于倉(cāng)庫(kù)中下載鏡像的過(guò)程 Unknown：APIserver無(wú)法正常獲取到pod對(duì)象的狀態(tài)，通常是其無(wú)法與所在工作節(jié)點(diǎn)的kubelet通信所致。
8、 pod的重啟策略是什么？
答：可以通過(guò)命令“kubectl explain pod.spec”查看pod的重啟策略。（restartPolicy字段）
Always：但凡pod對(duì)象終止就重啟，此為默認(rèn)策略。 OnFailure：僅在pod對(duì)象出現(xiàn)錯(cuò)誤時(shí)才重啟
9、 Service這種資源對(duì)象的作用是什么？
答：用來(lái)給相同的多個(gè)pod對(duì)象提供一個(gè)固定的統(tǒng)一訪問(wèn)接口，常用于服務(wù)發(fā)現(xiàn)和服務(wù)訪問(wèn)。
10、版本回滾相關(guān)的命令？
[root@master?httpd-web]#?kubectl?apply?-f?httpd2-deploy1.yaml??--record
#運(yùn)行yaml文件，并記錄版本信息；
[root@master?httpd-web]#?kubectl?rollout?history?deployment?httpd-devploy1
#查看該deployment的歷史版本
[root@master?httpd-web]#?kubectl?rollout?undo?deployment?httpd-devploy1?--to-revision=1
#執(zhí)行回滾操作，指定回滾到版本1
#在yaml文件的spec字段中，可以寫以下選項(xiàng)（用于限制最多記錄多少個(gè)歷史版本）：
spec:
??revisionHistoryLimit:?5
#這個(gè)字段通過(guò)?kubectl?explain?deploy.spec??命令找到revisionHistoryLimit???行獲得
11、 標(biāo)簽與標(biāo)簽選擇器的作用是什么？
標(biāo)簽：是當(dāng)相同類型的資源對(duì)象越來(lái)越多的時(shí)候，為了更好的管理，可以按照標(biāo)簽將其分為一個(gè)組，為的是提升資源對(duì)象的管理效率。
標(biāo)簽選擇器：就是標(biāo)簽的查詢過(guò)濾條件。目前API支持兩種標(biāo)簽選擇器：
基于等值關(guān)系的，如：“=”、“”“==”、“！=”（注：“==”也是等于的意思，yaml文件中的matchLabels字段）； 基于集合的，如：in、notin、exists（yaml文件中的matchExpressions字段）；
注：in:在這個(gè)集合中；notin：不在這個(gè)集合中；exists：要么全在（exists）這個(gè)集合中，要么都不在（notexists）；
使用標(biāo)簽選擇器的操作邏輯：
在使用基于集合的標(biāo)簽選擇器同時(shí)指定多個(gè)選擇器之間的邏輯關(guān)系為“與”操作（比如：- {key: name,operator: In,values: [zhangsan,lisi]} ，那么只要擁有這兩個(gè)值的資源，都會(huì)被選中）； 使用空值的標(biāo)簽選擇器，意味著每個(gè)資源對(duì)象都被選中（如：標(biāo)簽選擇器的鍵是“A”，兩個(gè)資源對(duì)象同時(shí)擁有A這個(gè)鍵，但是值不一樣，這種情況下，如果使用空值的標(biāo)簽選擇器，那么將同時(shí)選中這兩個(gè)資源對(duì)象） 空的標(biāo)簽選擇器（注意不是上面說(shuō)的空值，而是空的，都沒(méi)有定義鍵的名稱），將無(wú)法選擇出任何資源；
在基于集合的選擇器中，使用“In”或者“Notin”操作時(shí)，其values可以為空，但是如果為空，這個(gè)標(biāo)簽選擇器，就沒(méi)有任何意義了。
兩種標(biāo)簽選擇器類型（基于等值、基于集合的書(shū)寫方法）：
selector:
??matchLabels:???????????#基于等值
????app:?nginx
??matchExpressions:?????????#基于集合
????-?{key:?name,operator:?In,values:?[zhangsan,lisi]}?????#key、operator、values這三個(gè)字段是固定的
????-?{key:?age,operator:?Exists,values:}???#如果指定為exists，那么values的值一定要為空
12、 常用的標(biāo)簽分類有哪些？
標(biāo)簽分類是可以自定義的，但是為了能使他人可以達(dá)到一目了然的效果，一般會(huì)使用以下一些分類：
版本類標(biāo)簽（release）：stable（穩(wěn)定版）、canary（金絲雀版本，可以將其稱之為測(cè)試版中的測(cè)試版）、beta（測(cè)試版）； 環(huán)境類標(biāo)簽（environment）：dev（開(kāi)發(fā)）、qa（測(cè)試）、production（生產(chǎn)）、op（運(yùn)維）； 應(yīng)用類（app）：ui、as、pc、sc； 架構(gòu)類（tier）：frontend（前端）、backend（后端）、cache（緩存）； 分區(qū)標(biāo)簽（partition）：customerA（客戶A）、customerB（客戶B）； 品控級(jí)別（Track）：daily（每天）、weekly（每周）。
13、 有幾種查看標(biāo)簽的方式？
答：常用的有以下三種查看方式：
[root@master?~]#?kubectl?get?pod?--show-labels????#查看pod，并且顯示標(biāo)簽內(nèi)容
[root@master?~]#?kubectl?get?pod?-L?env,tier??????#顯示資源對(duì)象標(biāo)簽的值
[root@master?~]#?kubectl?get?pod?-l?env,tier??????#只顯示符合鍵值資源對(duì)象的pod，而“-L”是顯示所有的pod
14、 添加、修改、刪除標(biāo)簽的命令？
#對(duì)pod標(biāo)簽的操作
[root@master?~]#?kubectl?label?pod?label-pod?abc=123?????#給名為label-pod的pod添加標(biāo)簽
[root@master?~]#?kubectl?label?pod?label-pod?abc=456?--overwrite???????#修改名為label-pod的標(biāo)簽
[root@master?~]#?kubectl?label?pod?label-pod?abc-?????????????#刪除名為label-pod的標(biāo)簽
[root@master?~]#?kubectl?get?pod?--show-labels
#對(duì)node節(jié)點(diǎn)的標(biāo)簽操作
[root@master?~]#?kubectl?label?nodes?node01?disk=ssd??????#給節(jié)點(diǎn)node01添加disk標(biāo)簽
[root@master?~]#?kubectl?label?nodes?node01?disk=sss?–overwrite????#修改節(jié)點(diǎn)node01的標(biāo)簽
[root@master?~]#?kubectl?label?nodes?node01?disk-?????????#刪除節(jié)點(diǎn)node01的disk標(biāo)簽
15、 DaemonSet資源對(duì)象的特性？
DaemonSet這種資源對(duì)象會(huì)在每個(gè)k8s集群中的節(jié)點(diǎn)上運(yùn)行，并且每個(gè)節(jié)點(diǎn)只能運(yùn)行一個(gè)pod，這是它和deployment資源對(duì)象的最大也是唯一的區(qū)別。所以，在其yaml文件中，不支持定義replicas，除此之外，與Deployment、RS等資源對(duì)象的寫法相同。
它的一般使用場(chǎng)景如下：
在去做每個(gè)節(jié)點(diǎn)的日志收集工作； 監(jiān)控每個(gè)節(jié)點(diǎn)的的運(yùn)行狀態(tài)；
16、 說(shuō)說(shuō)你對(duì)Job這種資源對(duì)象的了解？
答：Job與其他服務(wù)類容器不同，Job是一種工作類容器（一般用于做一次性任務(wù)）。使用常見(jiàn)不多，可以忽略這個(gè)問(wèn)題。
#提高Job執(zhí)行效率的方法：
spec:
??parallelism:?2???????????#一次運(yùn)行2個(gè)
??completions:?8???????????#最多運(yùn)行8個(gè)
??template:
metadata:
17、描述一下pod的生命周期有哪些狀態(tài)？
Pending：表示pod已經(jīng)被同意創(chuàng)建，正在等待kube-scheduler選擇合適的節(jié)點(diǎn)創(chuàng)建，一般是在準(zhǔn)備鏡像； Running：表示pod中所有的容器已經(jīng)被創(chuàng)建，并且至少有一個(gè)容器正在運(yùn)行或者是正在啟動(dòng)或者是正在重啟； Succeeded：表示所有容器已經(jīng)成功終止，并且不會(huì)再啟動(dòng)； Failed：表示pod中所有容器都是非0（不正常）狀態(tài)退出； Unknown：表示無(wú)法讀取Pod狀態(tài)，通常是kube-controller-manager無(wú)法與Pod通信。
18、 創(chuàng)建一個(gè)pod的流程是什么？
客戶端提交Pod的配置信息（可以是yaml文件定義好的信息）到kube-apiserver； Apiserver收到指令后，通知給controller-manager創(chuàng)建一個(gè)資源對(duì)象； Controller-manager通過(guò)api-server將pod的配置信息存儲(chǔ)到ETCD數(shù)據(jù)中心中； Kube-scheduler檢測(cè)到pod信息會(huì)開(kāi)始調(diào)度預(yù)選，會(huì)先過(guò)濾掉不符合Pod資源配置要求的節(jié)點(diǎn)，然后開(kāi)始調(diào)度調(diào)優(yōu)，主要是挑選出更適合運(yùn)行pod的節(jié)點(diǎn)，然后將pod的資源配置單發(fā)送到node節(jié)點(diǎn)上的kubelet組件上。 Kubelet根據(jù)scheduler發(fā)來(lái)的資源配置單運(yùn)行pod，運(yùn)行成功后，將pod的運(yùn)行信息返回給scheduler，scheduler將返回的pod運(yùn)行狀況的信息存儲(chǔ)到etcd數(shù)據(jù)中心。
19、 刪除一個(gè)Pod會(huì)發(fā)生什么事情？
答：Kube-apiserver會(huì)接受到用戶的刪除指令，默認(rèn)有30秒時(shí)間等待優(yōu)雅退出，超過(guò)30秒會(huì)被標(biāo)記為死亡狀態(tài)，此時(shí)Pod的狀態(tài)Terminating，kubelet看到pod標(biāo)記為Terminating就開(kāi)始了關(guān)閉Pod的工作；
關(guān)閉流程如下：
pod從service的endpoint列表中被移除； 如果該pod定義了一個(gè)停止前的鉤子，其會(huì)在pod內(nèi)部被調(diào)用，停止鉤子一般定義了如何優(yōu)雅的結(jié)束進(jìn)程； 進(jìn)程被發(fā)送TERM信號(hào)（kill -14） 當(dāng)超過(guò)優(yōu)雅退出的時(shí)間后，Pod中的所有進(jìn)程都會(huì)被發(fā)送SIGKILL信號(hào)（kill -9）。
20、 K8s的Service是什么？
答：Pod每次重啟或者重新部署，其IP地址都會(huì)產(chǎn)生變化，這使得pod間通信和pod與外部通信變得困難，這時(shí)候，就需要Service為pod提供一個(gè)固定的入口。
Service的Endpoint列表通常綁定了一組相同配置的pod，通過(guò)負(fù)載均衡的方式把外界請(qǐng)求分配到多個(gè)pod上
21、 k8s是怎么進(jìn)行服務(wù)注冊(cè)的？
答：Pod啟動(dòng)后會(huì)加載當(dāng)前環(huán)境所有Service信息，以便不同Pod根據(jù)Service名進(jìn)行通信。
22、 k8s集群外流量怎么訪問(wèn)Pod？
答：可以通過(guò)Service的NodePort方式訪問(wèn)，會(huì)在所有節(jié)點(diǎn)監(jiān)聽(tīng)同一個(gè)端口，比如：30000，訪問(wèn)節(jié)點(diǎn)的流量會(huì)被重定向到對(duì)應(yīng)的Service上面。
23、 k8s數(shù)據(jù)持久化的方式有哪些？
答：
1）EmptyDir（空目錄）：
沒(méi)有指定要掛載宿主機(jī)上的某個(gè)目錄，直接由Pod內(nèi)保部映射到宿主機(jī)上。類似于docker中的manager volume。
主要使用場(chǎng)景：
只需要臨時(shí)將數(shù)據(jù)保存在磁盤上，比如在合并/排序算法中； 作為兩個(gè)容器的共享存儲(chǔ)，使得第一個(gè)內(nèi)容管理的容器可以將生成的數(shù)據(jù)存入其中，同時(shí)由同一個(gè)webserver容器對(duì)外提供這些頁(yè)面。
emptyDir的特性：
同個(gè)pod里面的不同容器，共享同一個(gè)持久化目錄，當(dāng)pod節(jié)點(diǎn)刪除時(shí)，volume的數(shù)據(jù)也會(huì)被刪除。如果僅僅是容器被銷毀，pod還在，則不會(huì)影響volume中的數(shù)據(jù)。
總結(jié)來(lái)說(shuō)：emptyDir的數(shù)據(jù)持久化的生命周期和使用的pod一致。一般是作為臨時(shí)存儲(chǔ)使用。
2）Hostpath：
將宿主機(jī)上已存在的目錄或文件掛載到容器內(nèi)部。類似于docker中的bind mount掛載方式。
這種數(shù)據(jù)持久化方式，運(yùn)用場(chǎng)景不多，因?yàn)樗黾恿藀od與節(jié)點(diǎn)之間的耦合。
一般對(duì)于k8s集群本身的數(shù)據(jù)持久化和docker本身的數(shù)據(jù)持久化會(huì)使用這種方式，可以自行參考apiService的yaml文件，位于：/etc/kubernetes/main…目錄下。
3）PersistentVolume（簡(jiǎn)稱PV）：
基于NFS服務(wù)的PV，也可以基于GFS的PV。它的作用是統(tǒng)一數(shù)據(jù)持久化目錄，方便管理。
在一個(gè)PV的yaml文件中，可以對(duì)其配置PV的大小，指定PV的訪問(wèn)模式：
ReadWriteOnce：只能以讀寫的方式掛載到單個(gè)節(jié)點(diǎn)； ReadOnlyMany：能以只讀的方式掛載到多個(gè)節(jié)點(diǎn)； ReadWriteMany：能以讀寫的方式掛載到多個(gè)節(jié)點(diǎn)。以及指定pv的回收策略： recycle：清除PV的數(shù)據(jù)，然后自動(dòng)回收； Retain：需要手動(dòng)回收； delete：刪除云存儲(chǔ)資源，云存儲(chǔ)專用；
PS：這里的回收策略指的是在PV被刪除后，在這個(gè)PV下所存儲(chǔ)的源文件是否刪除）。
若需使用PV，那么還有一個(gè)重要的概念：PVC，PVC是向PV申請(qǐng)應(yīng)用所需的容量大小，K8s集群中可能會(huì)有多個(gè)PV，PVC和PV若要關(guān)聯(lián)，其定義的訪問(wèn)模式必須一致。定義的storageClassName也必須一致，若群集中存在相同的（名字、訪問(wèn)模式都一致）兩個(gè)PV，那么PVC會(huì)選擇向它所需容量接近的PV去申請(qǐng)，或者隨機(jī)申請(qǐng)。
來(lái)源：blog.csdn.net/lvjianzhaoa/
●公司要上監(jiān)控，選型調(diào)研下 Zabbix 和 Prometheus
●神器 Nginx 的學(xué)習(xí)手冊(cè) ( 建議收藏 )
●14個(gè)必須掌握的數(shù)據(jù)庫(kù)面試問(wèn)題
●數(shù)據(jù)庫(kù)整理合集：含MySQL、Redis、Mongodb等常見(jiàn)數(shù)據(jù)庫(kù)教程