k8s面試問什么？

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

1、 k8s是什么？請說出你的了解？

答：Kubenetes是一個針對容器應(yī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集群至少需要一個主節(jié)點（Master）和多個計算節(jié)點（Node）。

• 主節(jié)點主要用于暴露API，調(diào)度部署和節(jié)點的管理；
• 計算節(jié)點運行一個容器運行環(huán)境，一般是docker環(huán)境（類似docker環(huán)境的還有rkt），同時運行一個K8s的代理（kubelet）用于和master通信。計算節(jié)點也會運行一些額外的組件，像記錄日志，節(jié)點監(jiān)控，服務(wù)發(fā)現(xiàn)等等。計算節(jié)點是k8s集群中真正工作的節(jié)點。

K8S架構(gòu)細(xì)分：

1、Master節(jié)點（默認(rèn)不參加實際工作）：

• Kubectl：客戶端命令行工具，作為整個K8s集群的操作入口；
• Api Server：在K8s架構(gòu)中承擔(dān)的是“橋梁”的角色，作為資源操作的唯一入口，它提供了認(rèn)證、授權(quán)、訪問控制、API注冊和發(fā)現(xiàn)等機制。客戶端與k8s群集及K8s內(nèi)部組件的通信，都要通過Api Server這個組件；
• Controller-manager：負(fù)責(zé)維護群集的狀態(tài)，比如故障檢測、自動擴展、滾動更新等；
• Scheduler：負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將pod調(diào)度到相應(yīng)的node節(jié)點上；
• Etcd：擔(dān)任數(shù)據(jù)中心的角色，保存了整個群集的狀態(tài)；

2、Node節(jié)點：

• Kubelet：負(fù)責(zé)維護容器的生命周期，同時也負(fù)責(zé)Volume和網(wǎng)絡(luò)的管理，一般運行在所有的節(jié)點，是Node節(jié)點的代理，當(dāng)Scheduler確定某個node上運行pod之后，會將pod的具體信息（image，volume）等發(fā)送給該節(jié)點的kubelet，kubelet根據(jù)這些信息創(chuàng)建和運行容器，并向master返回運行狀態(tài)。（自動修復(fù)功能：如果某個節(jié)點中的容器宕機，它會嘗試重啟該容器，若重啟無效，則會將該pod殺死，然后重新創(chuàng)建一個容器）；
• Kube-proxy：Service在邏輯上代表了后端的多個pod。負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡（外界通過Service訪問pod提供的服務(wù)時，Service接收到的請求后就是通過kube-proxy來轉(zhuǎn)發(fā)到pod上的）；
• container-runtime：是負(fù)責(zé)管理運行容器的軟件，比如docker
• Pod：是k8s集群里面最小的單位。每個pod里邊可以運行一個或多個container（容器），如果一個pod中有兩個container，那么container的USR（用戶）、MNT（掛載點）、PID（進程號）是相互隔離的，UTS（主機名和域名）、IPC（消息隊列）、NET（網(wǎng)絡(luò)棧）是相互共享的。我比較喜歡把pod來當(dāng)做豌豆夾，而豌豆就是pod中的container；

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

答：容器的中心思想就是秒級啟動；一次封裝、到處運行；這是主機部署應(yīng)用無法達到的效果，但同時也更應(yīng)該注重容器的數(shù)據(jù)持久化問題。

另外，容器部署可以將各個服務(wù)進行隔離，互不影響，這也是容器的另一個核心概念。

4、請你說一下kubenetes針對pod資源對象的健康監(jiān)測機制？

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

1） livenessProbe探針

可以根據(jù)用戶自定義規(guī)則來判定pod是否健康，如果livenessProbe探針探測到容器不健康，則kubelet會根據(jù)其重啟策略來決定是否重啟，如果一個容器不包含livenessProbe探針，則kubelet會認(rèn)為容器的livenessProbe探針的返回值永遠(yuǎn)成功。

2） ReadinessProbe探針

同樣是可以根據(jù)用戶自定義規(guī)則來判斷pod是否健康，如果探測失敗，控制器會將此pod從對應(yīng)service的endpoint列表中移除，從此不再將任何請求調(diào)度到此Pod上，直到下次探測成功。

3） startupProbe探針

啟動檢查機制，應(yīng)用一些啟動緩慢的業(yè)務(wù)，避免業(yè)務(wù)長時間啟動而被上面兩類探針kill掉，這個問題也可以換另一種方式解決，就是定義上面兩類探針機制時，初始化時間定義的長一些即可。

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

• initialDelaySeconds：初始第一次探測間隔，用于應(yīng)用啟動的時間，防止應(yīng)用還沒啟動而健康檢查失敗
• periodSeconds：檢查間隔，多久執(zhí)行probe檢查，默認(rèn)為10s；
• timeoutSeconds：檢查超時時長，探測應(yīng)用timeout后為失?。?/section>
• successThreshold：成功探測閾值，表示探測多少次為健康正常，默認(rèn)探測1次。

上面兩種探針都支持以下三種探測方法：

1）Exec： 通過執(zhí)行命令的方式來檢查服務(wù)是否正常，比如使用cat命令查看pod中的某個重要配置文件是否存在，若存在，則表示pod健康。反之異常。

Exec探測方式的yaml文件語法如下：

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的探測機制
      exec:                      #執(zhí)行以下命令
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5          #在容器運行五秒后開始探測
      periodSeconds: 5               #每次探測的時間間隔為5秒

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

2）Httpget： 通過發(fā)送http/htps請求檢查服務(wù)是否正常，返回的狀態(tài)碼為200-399則表示容器健康（注http get類似于命令curl -I）。

Httpget探測方式的yaml文件語法如下：

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    livenessProbe:              #采用livenessProbe機制探測
      httpGet:                  #采用httpget的方式
    scheme:HTTP         #指定協(xié)議，也支持https
        path: /healthz          #檢測是否可以訪問到網(wǎng)頁根目錄下的healthz網(wǎng)頁文件
        port: 8080              #監(jiān)聽端口是8080
      initialDelaySeconds: 3     #容器運行3秒后開始探測
      periodSeconds: 3                #探測頻率為3秒

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

3）tcpSocket： 通過容器的IP和Port執(zhí)行TCP檢查，如果能夠建立TCP連接，則表明容器健康，這種方式與HTTPget的探測機制有些類似，tcpsocket健康檢查適用于TCP業(yè)務(wù)。

tcpSocket探測方式的yaml文件語法如下：

spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
- containerPort: 8080
#這里兩種探測機制都用上了，都是為了和容器的8080端口建立TCP連接
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

在上述的yaml配置文件中，兩類探針都使用了，在容器啟動5秒后，kubelet將發(fā)送第一個readinessProbe探針，這將連接容器的8080端口，如果探測成功，則該pod為健康，十秒后，kubelet將進行第二次連接。

除了readinessProbe探針外，在容器啟動15秒后，kubelet將發(fā)送第一個livenessProbe探針，仍然嘗試連接容器的8080端口，如果連接失敗，則重啟容器。

探針探測的結(jié)果無外乎以下三者之一：

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

若覺得上面還不夠透徹，可以移步其官網(wǎng)文檔：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

5、 如何控制滾動更新過程？

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

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

maxSurge：　此參數(shù)控制滾動更新過程，副本總數(shù)超過預(yù)期pod數(shù)量的上限。可以是百分比，也可以是具體的值。默認(rèn)為1。

（上述參數(shù)的作用就是在更新過程中，值若為3，那么不管三七二一，先運行三個pod，用于替換舊的pod，以此類推）

maxUnavailable： 此參數(shù)控制滾動更新過程中，不可用的Pod的數(shù)量。

（這個值和上面的值沒有任何關(guān)系，舉個例子：我有十個pod，但是在更新的過程中，我允許這十個pod中最多有三個不可用，那么就將這個參數(shù)的值設(shè)置為3，在更新的過程中，只要不可用的pod數(shù)量小于或等于3，那么更新過程就不會停止）。

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

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

K8s的鏡像下載策略有三種：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。

7、 image的狀態(tài)有哪些？

• Running：Pod所需的容器已經(jīng)被成功調(diào)度到某個節(jié)點，且已經(jīng)成功運行，
• Pending：APIserver創(chuàng)建了pod資源對象，并且已經(jīng)存入etcd中，但它尚未被調(diào)度完成或者仍然處于倉庫中下載鏡像的過程
• Unknown：APIserver無法正常獲取到pod對象的狀態(tài)，通常是其無法與所在工作節(jié)點的kubelet通信所致。

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

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

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

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

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

10、版本回滾相關(guān)的命令？

[root@master httpd-web]# kubectl apply -f httpd2-deploy1.yaml  --record  
#運行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字段中，可以寫以下選項（用于限制最多記錄多少個歷史版本）：
spec:
  revisionHistoryLimit: 5            
#這個字段通過 kubectl explain deploy.spec  命令找到revisionHistoryLimit   <integer>行獲得

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

標(biāo)簽：是當(dāng)相同類型的資源對象越來越多的時候，為了更好的管理，可以按照標(biāo)簽將其分為一個組，為的是提升資源對象的管理效率。

標(biāo)簽選擇器：就是標(biāo)簽的查詢過濾條件。目前API支持兩種標(biāo)簽選擇器：

• 基于等值關(guān)系的，如：“=”、“”“==”、“！=”（注：“==”也是等于的意思，yaml文件中的matchLabels字段）；
• 基于集合的，如：in、notin、exists（yaml文件中的matchExpressions字段）；

注：in:在這個集合中；notin：不在這個集合中；exists：要么全在（exists）這個集合中，要么都不在（notexists）；

使用標(biāo)簽選擇器的操作邏輯：

• 在使用基于集合的標(biāo)簽選擇器同時指定多個選擇器之間的邏輯關(guān)系為“與”操作（比如：- {key: name,operator: In,values: [zhangsan,lisi]} ，那么只要擁有這兩個值的資源，都會被選中）；
• 使用空值的標(biāo)簽選擇器，意味著每個資源對象都被選中（如：標(biāo)簽選擇器的鍵是“A”，兩個資源對象同時擁有A這個鍵，但是值不一樣，這種情況下，如果使用空值的標(biāo)簽選擇器，那么將同時選中這兩個資源對象）
• 空的標(biāo)簽選擇器（注意不是上面說的空值，而是空的，都沒有定義鍵的名稱），將無法選擇出任何資源；

在基于集合的選擇器中，使用“In”或者“Notin”操作時，其values可以為空，但是如果為空，這個標(biāo)簽選擇器，就沒有任何意義了。

兩種標(biāo)簽選擇器類型（基于等值、基于集合的書寫方法）：

selector:
  matchLabels:           #基于等值
    app: nginx
  matchExpressions:         #基于集合
    - {key: name,operator: In,values: [zhangsan,lisi]}     #key、operator、values這三個字段是固定的
    - {key: age,operator: Exists,values:}   #如果指定為exists，那么values的值一定要為空

12、 常用的標(biāo)簽分類有哪些？

標(biāo)簽分類是可以自定義的，但是為了能使他人可以達到一目了然的效果，一般會使用以下一些分類：

• 版本類標(biāo)簽（release）：stable（穩(wěn)定版）、canary（金絲雀版本，可以將其稱之為測試版中的測試版）、beta（測試版）；
• 環(huán)境類標(biāo)簽（environment）：dev（開發(fā)）、qa（測試）、production（生產(chǎn)）、op（運維）；
• 應(yīng)用類（app）：ui、as、pc、sc；
• 架構(gòu)類（tier）：frontend（前端）、backend（后端）、cache（緩存）；
• 分區(qū)標(biāo)簽（partition）：customerA（客戶A）、customerB（客戶B）；
• 品控級別（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      #顯示資源對象標(biāo)簽的值
[root@master ~]# kubectl get pod -l env,tier      #只顯示符合鍵值資源對象的pod，而“-L”是顯示所有的pod

14、 添加、修改、刪除標(biāo)簽的命令？

#對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
 
#對node節(jié)點的標(biāo)簽操作   
[root@master ~]# kubectl label nodes node01 disk=ssd      #給節(jié)點node01添加disk標(biāo)簽
[root@master ~]# kubectl label nodes node01 disk=sss –overwrite    #修改節(jié)點node01的標(biāo)簽
[root@master ~]# kubectl label nodes node01 disk-         #刪除節(jié)點node01的disk標(biāo)簽

15、 DaemonSet資源對象的特性？

DaemonSet這種資源對象會在每個k8s集群中的節(jié)點上運行，并且每個節(jié)點只能運行一個pod，這是它和deployment資源對象的最大也是唯一的區(qū)別。所以，在其yaml文件中，不支持定義replicas，除此之外，與Deployment、RS等資源對象的寫法相同。

它的一般使用場景如下：

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

16、 說說你對Job這種資源對象的了解？

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

#提高Job執(zhí)行效率的方法：
spec:
  parallelism: 2           #一次運行2個
  completions: 8           #最多運行8個
  template:
metadata:

17、描述一下pod的生命周期有哪些狀態(tài)？

• Pending：表示pod已經(jīng)被同意創(chuàng)建，正在等待kube-scheduler選擇合適的節(jié)點創(chuàng)建，一般是在準(zhǔn)備鏡像；
• Running：表示pod中所有的容器已經(jīng)被創(chuàng)建，并且至少有一個容器正在運行或者是正在啟動或者是正在重啟；
• Succeeded：表示所有容器已經(jīng)成功終止，并且不會再啟動；
• Failed：表示pod中所有容器都是非0（不正常）狀態(tài)退出；
• Unknown：表示無法讀取Pod狀態(tài)，通常是kube-controller-manager無法與Pod通信。

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

• 客戶端提交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ù)中心。

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

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

關(guān)閉流程如下：

• pod從service的endpoint列表中被移除；
• 如果該pod定義了一個停止前的鉤子，其會在pod內(nèi)部被調(diào)用，停止鉤子一般定義了如何優(yōu)雅的結(jié)束進程；
• 進程被發(fā)送TERM信號（kill -14）
• 當(dāng)超過優(yōu)雅退出的時間后，Pod中的所有進程都會被發(fā)送SIGKILL信號（kill -9）。

20、 K8s的Service是什么？

答：Pod每次重啟或者重新部署，其IP地址都會產(chǎn)生變化，這使得pod間通信和pod與外部通信變得困難，這時候，就需要Service為pod提供一個固定的入口。

Service的Endpoint列表通常綁定了一組相同配置的pod，通過負(fù)載均衡的方式把外界請求分配到多個pod上

21、 k8s是怎么進行服務(wù)注冊的？

答：Pod啟動后會加載當(dāng)前環(huán)境所有Service信息，以便不同Pod根據(jù)Service名進行通信。

22、 k8s集群外流量怎么訪問Pod？

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

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

答：

1）EmptyDir（空目錄）：

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

主要使用場景：

• 只需要臨時將數(shù)據(jù)保存在磁盤上，比如在合并/排序算法中；
• 作為兩個容器的共享存儲，使得第一個內(nèi)容管理的容器可以將生成的數(shù)據(jù)存入其中，同時由同一個webserver容器對外提供這些頁面。

emptyDir的特性：

同個pod里面的不同容器，共享同一個持久化目錄，當(dāng)pod節(jié)點刪除時，volume的數(shù)據(jù)也會被刪除。如果僅僅是容器被銷毀，pod還在，則不會影響volume中的數(shù)據(jù)。

總結(jié)來說：emptyDir的數(shù)據(jù)持久化的生命周期和使用的pod一致。一般是作為臨時存儲使用。

2）Hostpath：

將宿主機上已存在的目錄或文件掛載到容器內(nèi)部。類似于docker中的bind mount掛載方式。

這種數(shù)據(jù)持久化方式，運用場景不多，因為它增加了pod與節(jié)點之間的耦合。

一般對于k8s集群本身的數(shù)據(jù)持久化和docker本身的數(shù)據(jù)持久化會使用這種方式，可以自行參考apiService的yaml文件，位于：/etc/kubernetes/main…目錄下。

3）PersistentVolume（簡稱PV）：

基于NFS服務(wù)的PV，也可以基于GFS的PV。它的作用是統(tǒng)一數(shù)據(jù)持久化目錄，方便管理。

在一個PV的yaml文件中，可以對其配置PV的大小，指定PV的訪問模式：

• ReadWriteOnce：只能以讀寫的方式掛載到單個節(jié)點；
• ReadOnlyMany：能以只讀的方式掛載到多個節(jié)點；
• ReadWriteMany：能以讀寫的方式掛載到多個節(jié)點。以及指定pv的回收策略：
• recycle：清除PV的數(shù)據(jù)，然后自動回收；
• Retain：需要手動回收；
• delete：刪除云存儲資源，云存儲專用；

PS：這里的回收策略指的是在PV被刪除后，在這個PV下所存儲的源文件是否刪除）。

若需使用PV，那么還有一個重要的概念：PVC，PVC是向PV申請應(yīng)用所需的容量大小，K8s集群中可能會有多個PV，PVC和PV若要關(guān)聯(lián)，其定義的訪問模式必須一致。定義的storageClassName也必須一致，若群集中存在相同的（名字、訪問模式都一致）兩個PV，那么PVC會選擇向它所需容量接近的PV去申請，或者隨機申請。