面試不要不懂裝懂，不會就是不會，不可能每個人都接觸過所有的知識！
- 1. 基礎問題
  - 1.1 Service是怎么關聯Pod的？（課程Service章節）
  - 1.2 HPA V1 V2的區別
  - 1.3 Pod生命周期（課程Pod章節）
  - 1.4 Kubernetes Master節點高可用（課程Master節點和Node節點章節）
  - 1.5 QoS
  - 1.6 flannel和calico（課程安裝章節）
  - 1.7 Helm優點
  - 1.8 公司的架構是什么樣的？
- 2. 日志監控
  - 2.1 容器內日志怎么采集的？
  - 2.2 Fluentd
  - 2.3 日志的索引
  - 2.4 etcd怎么監控的？（課程自帶metrics介面應用的監控）
  - 2.5 黑盒監控blackbox
  - 2.6 狀態碼監控
  - 2.7 你之前是怎么監控K8S的，監控哪些指標
  - 2.8 你之前是怎么收集K8S日志的，有哪些方案
- 3. 存盤問題
  - 3.1 Rook問題
  - 3.2 如何對接外部CEPH
  - 3.3 生產環境的pv回收策略如何選擇？
  - 3.4 K8S持久化對接過哪些儲存，為什么要選擇它？
- 4. 大廠面試題
  - 4.1 介紹下作業經歷，從事過哪些和K8s相關的作業
  - 4.2 主要語言是什么？平時這些專案上云有哪些注意的點
  - 4.3 有遇到過容器的OOM的問題嗎？怎么處理的？
  - 4.4 有狀態應用如何上云？
  - 4.5 決議下CRD和Operator？有沒有自己開發過CRD和Operator？
  - 4.6 什么是CNI？平時K8s集群用的是哪個網路插件？
  - 4.7 為什么Pod中關于資源有request和limit兩個欄位？有想過這么設計的原因嗎？
  - 4.8 OpenShift和K8s相比有哪些不同？
  - 4.9 Pod被調度到一個節點的具體程序？
  - 4.10 有了解過istio嗎，和springcould有什么區別
  - 在k8s Jenkins 發布詳細流程
以上問答只是個人見解，不一定是最好的回答，大家可以自行查閱網上資料，

面試不要不懂裝懂，不會就是不會，不可能每個人都接觸過所有的知識！

1. 基礎問題

1.1 Service是怎么關聯Pod的？（課程Service章節）

答：創建Pod是都會定義Pod的便簽，比如role=frontend，Service通過Selector欄位匹配該標簽即可關聯至該Pod，Pod和Service需要在同一個namespace，中文檔案，

1.2 HPA V1 V2的區別

答：HPA v1為穩定版自動水平伸縮，只支持CPU指標，V2為beta版本，分為v2beta1(支持CPU、記憶體和自定義指標)，v2beta2(支持CPU、記憶體、自定義指標Custom和額外指標ExternalMetrics)，從k8s 1.11之后，度量指標的采集依賴metrics-server，棄用了heapster，中文檔案，

1.3 Pod生命周期（課程Pod章節）

答：
   Pod創建：
      1. API Server 在接收到創建pod的請求之后，會根據用戶提交的引數值來創建一個運行時的pod物件，
      2. 根據 API Server 請求的背景關系的元資料來驗證兩者的 namespace 是否匹配，如果不匹配則創建失敗，
      3. Namespace 匹配成功之后，會向 pod 物件注入一些系統資料，如果 pod 未提供 pod 的名字，則 API Server 會將 pod 的 uid 作為 pod 的名字，
      4. API Server 接下來會檢查 pod 物件的必需欄位是否為空，如果為空，創建失敗，
      5. 上述準備作業完成之后會將在 etcd 中持久化這個物件，將異步呼叫回傳結果封裝成 restful.response，完成結果反饋，
      6. API Server 創建程序完成，剩下的由 scheduler 和 kubelet 來完成，此時 pod 處于 pending 狀態，
      7. Scheduler選擇出最優節點，
      8. Kubelet啟動該Pod，
   Pod洗掉：
      1. 用戶發出洗掉 pod 命令
      2. 將 pod 標記為“Terminating”狀態
         監控到 pod 物件為“Terminating”狀態的同時啟動 pod 關閉程序
         endpoints 控制器監控到 pod 物件關閉，將pod與service匹配的 endpoints 串列中洗掉
         Pod執行PreStop定義的內容
      3. 寬限期（默認30秒）結束之后，若存在任何一個運行的行程，pod 會收到 SIGKILL 信號
      4. Kubelet 請求 API Server 將此 Pod 資源寬限期設定為0從而完成洗掉操作

1.4 Kubernetes Master節點高可用（課程Master節點和Node節點章節）

答：Kube-APIServer為無狀態服務，可以啟動多個，通過負載均衡進行輪訓，ControllerManager和Scheduler為有狀態服務，多節點啟動會進行選主，主節點資訊保存在kube-system命名空間下的對應名稱的endpoint中

1.5 QoS

答：最高級別：Guaranteed節點資源不夠時最后一個被殺掉， Burstable第二個被殺掉，BestEffort第一個被殺掉

1.6 flannel和calico（課程安裝章節）

答：如果沒有用過flannel可以直接說沒有用過flannel，都是用的calico，因為calico性能強大，并且配置簡單，Flannel的host-gw雖然性能好，但是只能用于大二層網路，vxlan對內核要求高，并且flannel不支持網路策略，所以采用calico，因為公司和公有云網路環境不支持BGP，所以目前采用的都是IPIP模式，

1.7 Helm優點

答：大型專案更加方便管理，可以一鍵創建一個環境，可以對整個專案進行版本升級、回滾，部署更加方便，

1.8 公司的架構是什么樣的？

答：我們的架構是這樣的，三臺master，三臺etcd，然后在指定的節點上部署了ingress nginx，然后外部有個網關（可以選擇性說網關是硬體設備F5或者DMZ的nginx，或者公有云的LB）連接到了k8s ingress節點的80和433，然后有個通配符域名指向了ingress，在ingress上面又做的分發，

2. 日志監控

2.1 容器內日志怎么采集的？

答：容器內日志我們是使用filebeat進行采集的，filebeat以sidecar的形式和業務應用運行在同一個Pod內，使用emptyDir進行日志檔案的共享，

2.2 Fluentd

答：Fluentd配置簡單，并且Docker日志一般是json輸出，使用fluentd收集更加方便，當然filebeat也是可以采集節點日志的，

2.3 日志的索引

答：為了更快的查詢日志，一般我們會根據集群、命名空間、資源名稱進行添加索引，

2.4 etcd怎么監控的？（課程自帶metrics介面應用的監控）

答：etcd屬于云原生應用，自帶了metrics介面，可以直接請求metrics介面即可獲取到監控資料，一般監控etcd的狀態、leader是否正常、選擇次數、選主失敗次數、集群延遲、落盤延遲等，（此問題可以根據監控項自行補充）

2.5 黑盒監控blackbox

答：黑盒監控可以監控http、tcp的監控狀態、延遲、決議速度、證書到期時間等指標，可以根據課程的監控圖自行補充，

2.6 狀態碼監控

答：可以這么回答，我們使用的是ingress，ingress也是用Prometheus監控的，可以監控到某個應用的請求狀態，比如多個200、502、403等，課程ingress監控章節，

2.7 你之前是怎么監控K8S的，監控哪些指標

答：我是利用Prometheus監控的，主要是監控宿主機的指標、Pod指標，比如記憶體CPU使用率，是否有重啟這類的，然后也使用了黑盒監控，監控應用是否是正常的等，在k8s的監控和傳統架構區別不大，該監控的還要監控，可以想一下之前是怎么監控的，那在k8s里面同樣也可以監控，

2.8 你之前是怎么收集K8S日志的，有哪些方案

答：可以回答使用filebeat進行收集的，因為filebeat比較輕量級，并且配置比較簡單，同時也支持以sidecar的方式部署到Pod里面，這樣同時也能收集Pod容器內的日志，一般會采用filebeat+kafka+logstash+es+kibana這種架構，

3. 存盤問題

3.1 Rook問題

答：Rook現在已經畢業了，之前雖然沒有畢業，但是對ceph的支持已經是stable了，并且rook降低了ceph的學習成本，幾乎不用運維，所以我們采用了Rook，使用Rook操作ceph擴容也是非常簡單的，只需要更改rook創建ceph集群的資源檔案即可，

3.2 如何對接外部CEPH

答：對接的方式有很多，使用Rook可以對接外部ceph，使用volume、pvc、storageClass和CSI插件都可以對接外部ceph，

3.3 生產環境的pv回收策略如何選擇？

答：目前pv的回收策略分為recycle、delete、retain，具體用法可以參考課程的pv章節，其中recycle（相當于對資料目錄進行rm -rf /xxx/* ，進行回收的時候會創建一個Pod進行rm操作）將被官方使用動態存盤供應(dynamic provisioning)逐步替代，所以面試遇到這類問題，可以著重回答delete和retain，其中Delete回收策略一般用于動態存盤，比如ceph、GFS這類的，也就是通過StorageClass進行管理創建的pv，Delete的策略也是StorageClass的默認策略，因為當一個專案用到存盤時，會通過pvc或者volumeTemplateClaim申請存盤，然后后端存盤會自動創建pv，所以當你洗掉pvc或者pv時，就認為你已經不需要這個存盤了，就會觸發自動洗掉pv，防止造成存盤池存盤過多無人使用的垃圾pv，而靜態檔案建議使用Retain，比如NFS、NAS這類的，因為這些檔案一般都是手動管理的，所以最好是盡量保持這些檔案的可用性，就算不用了，也是可以根據目錄名稱進行手動洗掉，所以retain和delete是用的比較多的，

3.4 K8S持久化對接過哪些儲存，為什么要選擇它？

答：可以寫自己的實際情況，不能沒有做過就胡說，比如常見的NFS和ceph，可以回答CEPH，因為ceph是比較常用的分布式存盤，支持檔案存盤、塊存盤和物件存盤，而且性能還是比較好的，GFS和NFS可以不說，因為GFS可能會被淘汰，NFS是單點的，

4. 大廠面試題

4.1 介紹下作業經歷，從事過哪些和K8s相關的作業

答：真是的作業要說，你在學習程序中做的一些專案或者經驗都可以說一下，但是自己沒有經過手的最好不要說，防止露餡，比如高可用集群搭建和維護、Prometheus監控的使用、CICD的建設等，要往自己會的方向引導，

4.2 主要語言是什么？平時這些專案上云有哪些注意的點

答：主要考察的是你對專案上云以及對某個語言的發版流程是否熟悉，比如Java語言是mvn編譯，go語言是go build，nodejs是npm run build等，你可以說一下自己做過的容器化專案，比如Java語言的或者是nodejs，注意事項就是一個應用上云的步驟的一些細節，比如如何發版、如何回滾、如何配置QoS和健康檢查等，

4.3 有遇到過容器的OOM的問題嗎？怎么處理的？

答：遇到OOM有兩種情況，第一種情況是這個程式確實需要4Gi（假設）記憶體，但是你的limit配置只給了3Gi，這樣就會有OOM，另外一種情況是程式本身是有記憶體溢位的，可能沒有做好垃圾回收，導致記憶體一直往上漲，這樣的可能需要開發人員加上相應的垃圾回收，還有一種程式記憶體溢位是因為limit設定的太低導致不能正常的垃圾回收，比如一個程式正常運行需要3Gi，但是垃圾回收可能也需要占用記憶體，所以此時給3Gi肯定是不行的，一般需要超過3Gi，也就是limit配置要超程序式需求的800M-1Gi，

4.4 有狀態應用如何上云？

答：有狀態應用其實也分為需要存盤資料的和不需要存盤資料的，如果是有需要存盤資料的部署在K8s上，最好有后端可靠的存盤支持，比如分布式的ceph或者公有云的存盤，最極端的情況是沒有后端存盤支持，可以采用hostPath掛載，采用固定節點的形式，可以參考csi hostpath，或者storageClass hostPath，而有的有狀態應用并不需要存盤資料，只是想要有規定的識別符號，

4.5 決議下CRD和Operator？有沒有自己開發過CRD和Operator？

答：operator規范的說是operator = crd+controller，也就是operator可以理解為是一個自定義的控制器，CRD是一個自定義的資源型別，就像我們定義的deployment、service等，這些是官方自帶的控制器，CRD則是擴展的資源型別，開發過就說開發過，可以講一下如何開發的，沒有開發過就說沒有用到這種場景，目前還沒有這個需求，因為一些中間件他們官方已經寫好了operator，然后自己公司的專案一鍵部署使用helm管理的，因為helm比較簡單（不會helm這句話不要說），

4.6 什么是CNI？平時K8s集群用的是哪個網路插件？

答：CNI是k8s提出的容器網路介面，相當于一種規范，只要網路廠商的產品符合了這個規范，那么這個網路廠商的產品就能為k8s提供網路管理，常用的有calico、cilium、flannel等，可以回答說現在常用的是calico，因為他部署方便，很多大廠都在用，并且原生支持網路策略，flannel不支持網路策略，

4.7 為什么Pod中關于資源有request和limit兩個欄位？有想過這么設計的原因嗎？

答：request是用于程式的最小請求，limit是用于程式的最大請求，另一方面request可以防止節點部署過多的Pod，limit可以防止拖垮節點，

4.8 OpenShift和K8s相比有哪些不同？

答：以我個人的理解，openshift是一個企業級的平臺，包含了很多開箱即用的東西，比如可以很方便的創建一個Java應用，或者很方面的進行服務發布，他是對k8s進行了一層封裝，并且提供了S2I的形式用于應用的構建和發布，而K8s是原生的下一代云計算平臺，很多東西都需要自己去維護，比如你想要監控程式，就需要自己去搭建一個Prometheus或者其他的，如果大家對openshift不太熟悉，切記不能說太多openshift的東西，

4.9 Pod被調度到一個節點的具體程序？

答：見本頁1.3

4.10 有了解過istio嗎，和springcould有什么區別

答：有過一些了解Istio是Google開源的服務網格，號稱可以讓開發人員無需關心流量管理方面的代碼，只需要關心業務邏輯，可以提高開發效率，而springcloud是專門為Java語言設計，雖然他可以很方面實作流量管理的功能，比如灰度、熔斷、負載均衡等，但是也需要開發寫少量代碼，并且只能Java使用，而istio和語言無關，并且不需要開發寫代碼，

在k8s Jenkins 發布詳細流程

答：可以看一下課程流水線設計的檔案

以上問答只是個人見解，不一定是最好的回答，大家可以自行查閱網上資料，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/472922.html

標籤：其他

上一篇：第一章：KVM概述

下一篇：資料倉庫(13)大資料數倉經典最值得閱讀書籍推薦

K8S面試應知必回