kubernetes面試題匯總

注：以下所有問題，均為自己總結(jié)，若有錯(cuò)誤之處，還請(qǐng)指出。

1、 k8s是什么？請(qǐng)說出你的了解？

答：Kubenetes是一個(gè)針對(duì)容器應(yīng)用，進(jìn)行自動(dòng)部署，彈性伸縮和管理的開源系統(tǒng)。主要功能是生產(chǎn)環(huán)境中的容器編排。
K8S是Google公司推出的，它來源于由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)、訪問控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制?？蛻舳伺ck8s群集及K8s內(nèi)部組件的通信，都要通過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ì)嘗試重啟該容器，若重啟無效，則會(huì)將該pod殺死，然后重新創(chuàng)建一個(gè)容器）；
• Kube-proxy：Service在邏輯上代表了后端的多個(gè)pod。負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡（外界通過Service訪問pod提供的服務(wù)時(shí)，Service接收到的請(qǐng)求后就是通過kube-proxy來轉(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來當(dāng)做豌豆夾，而豌豆就是pod中的container；

3、 容器和主機(jī)部署應(yīng)用的區(qū)別是什么？

答：容器的中心思想就是秒級(jí)啟動(dòng)；一次封裝、到處運(yùn)行；這是主機(jī)部署應(yīng)用無法達(dá)到的效果，但同時(shí)也更應(yīng)該注重容器的數(shù)據(jù)持久化問題。
另外，容器部署可以將各個(gè)服務(wù)進(jìn)行隔離，互不影響，這也是容器的另一個(gè)核心概念。

4、請(qǐng)你說一下kubenetes針對(duì)pod資源對(duì)象的健康監(jiān)測(cè)機(jī)制？

答：K8s中對(duì)于pod資源對(duì)象的健康狀態(tài)檢測(cè)，提供了三類probe（探針）來執(zhí)行對(duì)pod的健康監(jiān)測(cè)：

1） livenessProbe探針
可以根據(jù)用戶自定義規(guī)則來判定pod是否健康，如果livenessProbe探針探測(cè)到容器不健康，則kubelet會(huì)根據(jù)其重啟策略來決定是否重啟，如果一個(gè)容器不包含livenessProbe探針，則kubelet會(huì)認(rèn)為容器的livenessProbe探針的返回值永遠(yuǎn)成功。
2） ReadinessProbe探針
同樣是可以根據(jù)用戶自定義規(guī)則來判斷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è)問題也可以換另一種方式解決，就是定義上面兩類探針機(jī)制時(shí)，初始化時(shí)間定義的長(zhǎng)一些即可。

每種探測(cè)方法能支持以下幾個(gè)相同的檢查參數(shù)，用于設(shè)置控制檢查時(shí)間：

• initialDelaySeconds：初始第一次探測(cè)間隔，用于應(yīng)用啟動(dòng)的時(shí)間，防止應(yīng)用還沒啟動(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：通過執(zhí)行命令的方式來檢查服務(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)行五秒后開始探測(cè)
      periodSeconds: 5               #每次探測(cè)的時(shí)間間隔為5秒

在上面的配置文件中，探測(cè)機(jī)制為在容器運(yùn)行5秒后，每隔五秒探測(cè)一次，如果cat命令返回的值為“0”，則表示健康，如果為非0，則表示異常。

2）Httpget：通過發(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ǎng)頁(yè)根目錄下的healthz網(wǎng)頁(yè)文件
        port: 8080              #監(jiān)聽端口是8080
      initialDelaySeconds: 3     #容器運(yùn)行3秒后開始探測(cè)
      periodSeconds: 3                #探測(cè)頻率為3秒

上述配置文件中，探測(cè)方式為項(xiàng)容器發(fā)送HTTP GET請(qǐng)求，請(qǐng)求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的狀態(tài)碼表示成功。任何其他代碼表示異常。

3）tcpSocket：通過容器的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é)果無外乎以下三者之一：

• Success：Container通過了檢查；
• Failure：Container沒有通過檢查；
• Unknown：沒有執(zhí)行檢查，因此不采取任何措施（通常是我們沒有定義探針檢測(cè)，默認(rèn)為成功）。

若覺得上面還不夠透徹，可以移步其官網(wǎng)文檔：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

5、 如何控制滾動(dòng)更新過程？

答：
可以通過下面的命令查看到更新時(shí)可以控制的參數(shù)：

[root@master yaml]# kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge ：此參數(shù)控制滾動(dòng)更新過程，副本總數(shù)超過預(yù)期pod數(shù)量的上限?？梢允前俜直?，也可以是具體的值。默認(rèn)為1。
（上述參數(shù)的作用就是在更新過程中，值若為3，那么不管三七二一，先運(yùn)行三個(gè)pod，用于替換舊的pod，以此類推）
maxUnavailable：此參數(shù)控制滾動(dòng)更新過程中，不可用的Pod的數(shù)量。 （這個(gè)值和上面的值沒有任何關(guān)系，舉個(gè)例子：我有十個(gè)pod，但是在更新的過程中，我允許這十個(gè)pod中最多有三個(gè)不可用，那么就將這個(gè)參數(shù)的值設(shè)置為3，在更新的過程中，只要不可用的pod數(shù)量小于或等于3，那么更新過程就不會(huì)停止）。

6、K8s中鏡像的下載策略是什么？

答：可通過命令“kubectl explain pod.spec.containers”來查看imagePullPolicy這行的解釋。

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。

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ù)中下載鏡像的過程
• Unknown：APIserver無法正常獲取到pod對(duì)象的狀態(tài)，通常是其無法與所在工作節(jié)點(diǎn)的kubelet通信所致。

8、 pod的重啟策略是什么？

答：可以通過命令“kubectl explain pod.spec”查看pod的重啟策略。（restartPolicy字段）

• Always：但凡pod對(duì)象終止就重啟，此為默認(rèn)策略。
• OnFailure：僅在pod對(duì)象出現(xiàn)錯(cuò)誤時(shí)才重啟

9、 Service這種資源對(duì)象的作用是什么？

答：用來給相同的多個(gè)pod對(duì)象提供一個(gè)固定的統(tǒng)一訪問接口，常用于服務(wù)發(fā)現(xiàn)和服務(wù)訪問。

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è)字段通過 kubectl explain deploy.spec  命令找到revisionHistoryLimit   <integer>行獲得

11、 標(biāo)簽與標(biāo)簽選擇器的作用是什么？

標(biāo)簽：是當(dāng)相同類型的資源對(duì)象越來越多的時(shí)候，為了更好的管理，可以按照標(biāo)簽將其分為一個(gè)組，為的是提升資源對(duì)象的管理效率。
標(biāo)簽選擇器：就是標(biāo)簽的查詢過濾條件。目前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)簽選擇器（注意不是上面說的空值，而是空的，都沒有定義鍵的名稱），將無法選擇出任何資源；
• 在基于集合的選擇器中，使用“In”或者“Notin”操作時(shí)，其values可以為空，但是如果為空，這個(gè)標(biāo)簽選擇器，就沒有任何意義了。

兩種標(biāo)簽選擇器類型（基于等值、基于集合的書寫方法）：
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（開發(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、 說說你對(duì)Job這種資源對(duì)象的了解？

答：Job與其他服務(wù)類容器不同，Job是一種工作類容器（一般用于做一次性任務(wù)）。使用常見不多，可以忽略這個(gè)問題。

#提高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：表示無法讀取Pod狀態(tài)，通常是kube-controller-manager無法與Pod通信。

18、 創(chuàng)建一個(gè)pod的流程是什么？

答：

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ù)中心。

19、 刪除一個(gè)Pod會(huì)發(fā)生什么事情？

答：Kube-apiserver會(huì)接受到用戶的刪除指令，默認(rèn)有30秒時(shí)間等待優(yōu)雅退出，超過30秒會(huì)被標(biāo)記為死亡狀態(tài)，此時(shí)Pod的狀態(tài)Terminating，kubelet看到pod標(biāo)記為Terminating就開始了關(guān)閉Pod的工作；

關(guān)閉流程如下：
1、 pod從service的endpoint列表中被移除；
2、 如果該pod定義了一個(gè)停止前的鉤子，其會(huì)在pod內(nèi)部被調(diào)用，停止鉤子一般定義了如何優(yōu)雅的結(jié)束進(jìn)程；
3、 進(jìn)程被發(fā)送TERM信號(hào)（kill -14）
4、 當(dāng)超過優(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，通過負(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集群外流量怎么訪問Pod？

答：可以通過Service的NodePort方式訪問，會(huì)在所有節(jié)點(diǎn)監(jiān)聽同一個(gè)端口，比如：30000，訪問節(jié)點(diǎn)的流量會(huì)被重定向到對(duì)應(yīng)的Service上面。

23、 k8s數(shù)據(jù)持久化的方式有哪些？

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

主要使用場(chǎng)景：
1） 只需要臨時(shí)將數(shù)據(jù)保存在磁盤上，比如在合并/排序算法中；
2） 作為兩個(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é)來說：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的訪問模式：

• 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)，其定義的訪問模式必須一致。定義的storageClassName也必須一致，若群集中存在相同的（名字、訪問模式都一致）兩個(gè)PV，那么PVC會(huì)選擇向它所需容量接近的PV去申請(qǐng)，或者隨機(jī)申請(qǐng)。