1、簡述etcd及其特點
etcd是CoreOS團隊發起的開源專案，是一個管理配置資訊和服務發現（service discovery）的專案，它的目標是構建一個高可用的分散式鍵值（key-value）資料庫，基於Go語言實現。
特點：
簡單：支援REST風格的HTTP+JSON API
安全：支援HTTPS方式的訪問
快速：支援併發1k/s的寫操作
可靠：支援分散式結構，基於Raft的一致性演算法，Raft是一套通過選舉主節點來實現分散式系統一致性的演算法。
2、簡述etcd適應的場景
etcd基於其優秀的特點，可廣泛的應用於以下場景：
服務發現（Service Discovery）：服務發現主要解決在同一個分散式叢集中的程式或服務，要如何才能找到對方並建立連線。本質上來說，服務發現就是想要了解叢集中是否有程式在監聽UDP或TCP埠，並且通過名字就可以查詢和連線。
訊息釋出與訂閱：在分散式系統中，最適用的一種元件間通訊方式就是訊息釋出與訂閱。即構建一個配置共享中心，資料提供者在這個配置中心釋出訊息，而訊息使用者則訂閱他們關心的主題，一旦主題有訊息釋出，就會實時通知訂閱者。通過這種方式可以做到分散式系統配置的集中式管理與動態更新。應用中用到的一些配置資訊放到etcd上進行集中管理。
負載均衡：在分散式系統中，為了保證服務的高可用以及資料的一致性，通常都會把資料和服務部署多份，以此達到對等服務，即使其中的某一個服務失效了，也不影響使用。etcd本身分散式架構儲存的資訊訪問支援負載均衡。etcd叢集化以後，每個etcd的核心節點都可以處理使用者的請求。所以，把資料量小但是訪問頻繁的訊息資料直接儲存到etcd中也可以實現負載均衡的效果。
分散式通知與協調：與訊息釋出和訂閱類似，都用到了etcd中的Watcher機制，通過註冊與非同步通知機制，實現分散式環境下不同系統之間的通知與協調，從而對資料變更做到實時處理。
分散式鎖：因為etcd使用Raft演算法保持了資料的強一致性，某次操作儲存到叢集中的值必然是全域性一致的，所以很容易實現分散式鎖。鎖服務有兩種使用方式，一是保持獨佔，二是控制時序。
叢集監控與Leader競選：通過etcd來進行監控實現起來非常簡單並且實時性強。
3、簡述什麼是Kubernetes
Kubernetes是一個全新的基於容器技術的分散式系統支撐平臺。是Google開源的容器叢集管理系統（谷歌內部：Borg）。在Docker技術的基礎上，為容器化的應用提供部署執行、資源排程、服務發現和動態伸縮等一系列完整功能，提高了大規模容器叢集管理的便捷性。並且具有完備的叢集管理能力，多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智慧負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和線上擴容能力、可擴充套件的資源自動排程機制以及多粒度的資源配額管理能力。
4、簡述Kubernetes和Docker的關係
Docker提供容器的生命週期管理和Docker映象構建執行時容器。它的主要優點是將將軟體/應用程式執行所需的設定和依賴項打包到一個容器中，從而實現了可移植性等優點。
Kubernetes用於關聯和編排在多個主機上執行的容器。
5、簡述Minikube、Kubectl、Kubelet分別是什麼
Minikube是一種可以在本地輕鬆執行一個單節點Kubernetes群集的工具。
Kubectl是一個命令列工具，可以使用該工具控制Kubernetes叢集管理器，如檢查群集資源，建立、刪除和更新元件，檢視應用程式。
Kubelet是一個代理服務，它在每個節點上執行，並使從伺服器與主伺服器通訊。
6、簡述Kubernetes常見的部署方式
常見的Kubernetes部署方式有：
kubeadm，也是推薦的一種部署方式；
二進位制；
minikube，在本地輕鬆執行一個單節點Kubernetes群集的工具。
7、簡述Kubernetes如何實現叢集管理
在叢集管理方面，Kubernetes將叢集中的機器劃分為一個Master節點和一群工作節點Node。其中，在Master節點執行著叢集管理相關的一組程式kube-apiserver、kube-controller-manager和kube-scheduler，這些程式實現了整個叢集的資源管理、Pod排程、彈性伸縮、安全控制、系統監控和糾錯等管理能力，並且都是全自動完成的。
8、簡述Kubernetes的優勢、適應場景及其特點
Kubernetes作為一個完備的分散式系統支撐平臺，其主要優勢：
容器編排
輕量級
開源
彈性伸縮
負載均衡
Kubernetes常見場景：
快速部署應用
快速擴充套件應用
無縫對接新的應用功能
節省資源，優化硬體資源的使用
Kubernetes相關特點：
可移植：支援公有云、私有云、混合雲、多重雲（multi-cloud）。
可擴充套件: 模組化,、外掛化、可掛載、可組合。
自動化: 自動部署、自動重啟、自動複製、自動伸縮/擴充套件。
9、簡述Kubernetes的缺點或當前的不足之處
Kubernetes當前存在的缺點（不足）如下：
安裝過程和配置相對困難複雜。
管理服務相對繁瑣。
執行和編譯需要很多時間。
它比其他替代品更昂貴。
對於簡單的應用程式來說，可能不需要涉及Kubernetes即可滿足。
10、簡述Kubernetes相關基礎概念
Master：Kubernetes叢集的管理節點，負責管理叢集，提供叢集的資源資料訪問入口。擁有etcd儲存服務（可選），執行Api Server程式，Controller Manager服務程式及Scheduler服務程式。
Node（worker）：Node（worker）是Kubernetes叢集架構中執行Pod的服務節點，是Kubernetes叢集操作的單元，用來承載被分配Pod的執行，是Pod執行的宿主機。執行Docker Eninge服務，守護程式kunelet及負載均衡器kube-proxy。
Pod：執行於Node節點上，若干相關容器的組合。Pod內包含的容器執行在同一宿主機上，使用相同的網路名稱空間、IP地址和埠，能夠通過localhost進行通訊。Pod是Kubernetes進行建立、排程和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關容器。
Label：Kubernetes中的Label實質是一系列的Key/Value鍵值對，其中key與value可自定義。Label可以附加到各種資源物件上，如Node、Pod、Service、RC等。一個資源物件可以定義任意數量的Label，同一個Label也可以被新增到任意數量的資源物件上去。Kubernetes通過Label Selector（標籤選擇器）查詢和篩選資源物件。
Replication Controller：Replication Controller用來管理Pod的副本，保證叢集中存在指定數量的Pod副本。叢集中副本的數量大於指定數量，則會停止指定數量之外的多餘容器數量。反之，則會啟動少於指定數量個數的容器，保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。
Deployment：Deployment在內部使用了RS來實現目的，Deployment相當於RC的一次升級，其最大的特色為可以隨時獲知當前Pod的部署進度。
HPA（Horizontal Pod Autoscaler）：Pod的橫向自動擴容，也是Kubernetes的一種資源，通過追蹤分析RC控制的所有Pod目標的負載變化情況，來確定是否需要針對性的調整Pod副本數量。
Service：Service定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，使用者不需要了解後臺Pod是如何執行。
Volume：Volume是Pod中能夠被多個容器訪問的共享目錄，Kubernetes中的Volume是定義在Pod上，可以被一個或多個Pod中的容器掛載到某個目錄下。
Namespace：Namespace用於實現多租戶的資源隔離，可將叢集內部的資源物件分配到不同的Namespace中，形成邏輯上的不同專案、小組或使用者組，便於不同的Namespace在共享使用整個叢集的資源的同時還能被分別管理。
11、簡述Kubernetes叢集相關元件
Kubernetes Master控制元件，排程管理整個系統（叢集），包含如下元件：
Kubernetes API Server：作為Kubernetes系統的入口，其封裝了核心物件的增刪改查操作，以RESTful API介面方式提供給外部客戶和內部元件呼叫，叢集內各個功能模組之間資料互動和通訊的中心樞紐。
Kubernetes Scheduler：為新建立的Pod進行節點（Node）選擇（即分配機器），負責叢集的資源排程。
Kubernetes Controller：負責執行各種控制器，目前已經提供了很多控制器來保證Kubernetes的正常執行。
Replication Controller：管理維護Replication Controller，關聯Replication Controller和Pod，保證Replication Controller定義的副本數量與實際執行Pod數量一致。
Node Controller：管理維護Node，定期檢查Node的健康狀態，標識出（失效|未失效）的Node節點。
Namespace Controller：管理維護Namespace，定期清理無效的Namespace，包括Namesapce下的API物件，比如Pod、Service等。
Service Controller：管理維護Service，提供負載以及服務代理。
EndPoints Controller：管理維護Endpoints，關聯Service和Pod，建立Endpoints為Service的後端，當Pod發生變化時，實時更新Endpoints。
Service Account Controller：管理維護Service Account，為每個Namespace建立預設的Service Account，同時為Service Account建立Service Account Secret。
Persistent Volume Controller：管理維護Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進行繫結，為釋放的Persistent Volume執行清理回收。
Daemon Set Controller：管理維護Daemon Set，負責建立Daemon Pod，保證指定的Node上正常的執行Daemon Pod。
Deployment Controller：管理維護Deployment，關聯Deployment和Replication Controller，保證執行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和Pod的更新。
Job Controller：管理維護Job，為Jod建立一次性任務Pod，保證完成Job指定完成的任務數目
Pod Autoscaler Controller：實現Pod的自動伸縮，定時獲取監控資料，進行策略匹配，當滿足條件時執行Pod的伸縮動作。
12、簡述Kubernetes RC的機制
Replication Controller用來管理Pod的副本，保證叢集中存在指定數量的Pod副本。當定義了RC並提交至Kubernetes叢集中之後，Master節點上的Controller Manager元件獲悉，並同時巡檢系統中當前存活的目標Pod，並確保目標Pod例項的數量剛好等於此RC的期望值，若存在過多的Pod副本在執行，系統會停止一些Pod，反之則自動建立一些Pod。
13、簡述Kubernetes Replica Set和Replication Controller之間有什麼區別
Replica Set和Replication Controller類似，都是確保在任何給定時間執行指定數量的Pod副本。不同之處在於RS使用基於集合的選擇器，而Replication Controller使用基於許可權的選擇器。
14、簡述kube-proxy的作用
kube-proxy執行在所有節點上，它監聽apiserver中service和endpoint的變化情況，建立路由規則以提供服務IP和負載均衡功能。簡單理解此程式是Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉發到後端的多個Pod例項上。
15、簡述kube-proxy iptables的原理
Kubernetes從1.2版本開始，將iptables作為kube-proxy的預設模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch介面實時跟蹤Service與Endpoint的變更資訊，並更新對應的iptables規則，Client的請求流量則通過iptables的NAT機制“直接路由”到目標Pod。
16、簡述kube-proxy ipvs的原理
IPVS在Kubernetes1.11中升級為GA穩定版。IPVS則專門用於高效能負載均衡，並使用更高效的資料結構（Hash表），允許幾乎無限的規模擴張，因此被kube-proxy採納為最新模式。
在IPVS模式下，使用iptables的擴充套件ipset，而不是直接呼叫iptables來生成規則鏈。iptables規則鏈是一個線性的資料結構，ipset則引入了帶索引的資料結構，因此當規則很多時，也可以很高效地查詢和匹配。
可以將ipset簡單理解為一個IP（段）的集合，這個集合的內容可以是IP地址、IP網段、埠等，iptables可以直接新增規則對這個“可變的集合”進行操作，這樣做的好處在於可以大大減少iptables規則的數量，從而減少效能損耗。
17、簡述kube-proxy ipvs和iptables的異同
iptables與IPVS都是基於Netfilter實現的，但因為定位不同，二者有著本質的差別：iptables是為防火牆而設計的；IPVS則專門用於高效能負載均衡，並使用更高效的資料結構（Hash表），允許幾乎無限的規模擴張。
與iptables相比，IPVS擁有以下明顯優勢：
為大型叢集提供了更好的可擴充套件性和效能；
支援比iptables更復雜的複製均衡演算法（最小負載、最少連線、加權等）；
支援伺服器健康檢查和連線重試等功能；
可以動態修改ipset的集合，即使iptables的規則正在使用這個集合。
18、簡述Kubernetes中什麼是靜態Pod
靜態Pod是由kubelet進行管理的僅存在於特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行建立，並且總是在kubelet所在的Node上執行。
19、簡述Kubernetes中Pod可能位於的狀態
Pending：API Server已經建立該Pod，且Pod內還有一個或多個容器的映象沒有建立，包括正在下載映象的過程。
Running：Pod內所有容器均已建立，且至少有一個容器處於執行狀態、正在啟動狀態或正在重啟狀態。
Succeeded：Pod內所有容器均成功執行退出，且不會重啟。
Failed：Pod內所有容器均已退出，但至少有一個容器退出為失敗狀態。
Unknown：由於某種原因無法獲取該Pod狀態，可能由於網路通訊不暢導致。
20、簡述Kubernetes建立一個Pod的主要流程？
Kubernetes中建立一個Pod涉及多個元件之間聯動，主要流程如下：
客戶端提交Pod的配置資訊（可以是yaml檔案定義的資訊）到kube-apiserver。
Apiserver收到指令後，通知給controller-manager建立一個資源物件。
Controller-manager通過api-server將Pod的配置資訊儲存到etcd資料中心中。
Kube-scheduler檢測到Pod資訊會開始排程預選，會先過濾掉不符合Pod資源配置要求的節點，然後開始排程調優，主要是挑選出更適合執行Pod的節點，然後將Pod的資源配置單傳送到Node節點上的kubelet元件上。
Kubelet根據scheduler發來的資源配置單執行Pod，執行成功後，將Pod的執行資訊返回給scheduler，scheduler將返回的Pod執行狀況的資訊儲存到etcd資料中心。
21、簡述Kubernetes中Pod的重啟策略
Pod重啟策略（RestartPolicy）應用於Pod內的所有容器，並且僅在Pod所處的Node上由kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，kubelet將根據RestartPolicy的設定來進行相應操作。
Pod的重啟策略包括Always、OnFailure和Never，預設值為Always。
Always：當容器失效時，由kubelet自動重啟該容器；
OnFailure：當容器終止執行且退出碼不為0時，由kubelet自動重啟該容器；
Never：不論容器執行狀態如何，kubelet都不會重啟該容器。
同時Pod的重啟策略與控制方式關聯，當前可用於管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理（靜態Pod）。
不同控制器的重啟策略限制如下：
RC和DaemonSet：必須設定為Always，需要保證該容器持續執行；
Job：OnFailure或Never，確保容器執行完成後不再重啟；
kubelet：在Pod失效時重啟，不論將RestartPolicy設定為何值，也不會對Pod進行健康檢查。
22、簡述Kubernetes中Pod的健康檢查方式
對Pod的健康檢查可以通過兩類探針來檢查：LivenessProbe和ReadinessProbe。
LivenessProbe探針：用於判斷容器是否存活（running狀態），如果LivenessProbe探針探測到容器不健康，則kubelet將殺掉該容器，並根據容器的重啟策略做相應處理。若一個容器不包含LivenessProbe探針，kubelet認為該容器的LivenessProbe探針返回值用於是“Success”。
ReadineeProbe探針：用於判斷容器是否啟動完成（ready狀態）。如果ReadinessProbe探針探測到失敗，則Pod的狀態將被修改。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的Eenpoint。
startupProbe探針：啟動檢查機制，應用一些啟動緩慢的業務，避免業務長時間啟動而被上面兩類探針kill掉。
23、簡述Kubernetes Pod的LivenessProbe探針的常見方式
kubelet定期執行LivenessProbe探針來診斷容器的健康狀態，通常有以下三種方式：
ExecAction：在容器內執行一個命令，若返回碼為0，則表明容器健康。
TCPSocketAction：通過容器的IP地址和埠號執行TCP檢查，若能建立TCP連線，則表明容器健康。
HTTPGetAction：通過容器的IP地址、埠號及路徑呼叫HTTP Get方法，若響應的狀態碼大於等於200且小於400，則表明容器健康。
24、簡述Kubernetes Pod的常見排程方式
Kubernetes中，Pod通常是容器的載體，主要有如下常見排程方式：
Deployment或RC：該排程策略主要功能就是自動部署一個容器應用的多份副本，以及持續監控副本的數量，在叢集內始終維持使用者指定的副本數量。
NodeSelector：定向排程，當需要手動指定將Pod排程到特定Node上，可以通過Node的標籤（Label）和Pod的nodeSelector屬性相匹配。
NodeAffinity親和性排程：親和性排程機制極大的擴充套件了Pod的排程能力，目前有兩種節點親和力表達：
requiredDuringSchedulingIgnoredDuringExecution：硬規則，必須滿足指定的規則，排程器才可以排程Pod至Node上（類似nodeSelector，語法不同）。
preferredDuringSchedulingIgnoredDuringExecution：軟規則，優先排程至滿足的Node的節點，但不強求，多個優先順序規則還可以設定權重值。
Taints和Tolerations（汙點和容忍）：
Taint：使Node拒絕特定Pod執行；
Toleration：為Pod的屬性，表示Pod能容忍（執行）標註了Taint的Node。
25、簡述Kubernetes初始化容器（init container）
init container的執行方式與應用容器不同，它們必須先於應用容器執行完成，當設定了多個init container時，將按順序逐個執行，並且只有前一個init container執行成功後才能執行後一個init container。當所有init container都成功執行後，Kubernetes才會初始化Pod的各種資訊，並開始建立和執行應用容器。
26、簡述Kubernetes deployment升級過程
初始建立Deployment時，系統建立了一個ReplicaSet，並按使用者的需求建立了對應數量的Pod副本。
當更新Deployment時，系統建立了一個新的ReplicaSet，並將其副本數量擴充套件到1，然後將舊ReplicaSet縮減為2。
之後，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。
最後，新的ReplicaSet執行了對應個新版本Pod副本，舊的ReplicaSet副本數量則縮減為0。
27、簡述Kubernetes deployment升級策略
在Deployment的定義中，可以通過spec.strategy指定Pod更新的策略，目前支援兩種策略：Recreate（重建）和RollingUpdate（滾動更新），預設值為RollingUpdate。
Recreate：設定spec.strategy.type=Recreate，表示Deployment在更新Pod時，會先殺掉所有正在執行的Pod，然後建立新的Pod。
RollingUpdate：設定spec.strategy.type=RollingUpdate，表示Deployment會以滾動更新的方式來逐個更新Pod。同時，可以通過設定spec.strategy.rollingUpdate下的兩個引數（maxUnavailable和maxSurge）來控制滾動更新的過程。
28、簡述Kubernetes DaemonSet型別的資源特性
DaemonSet資源物件會在每個Kubernetes叢集中的節點上執行，並且每個節點只能執行一個Pod，這是它和Deployment資源物件的最大也是唯一的區別。因此，在定義yaml檔案中，不支援定義replicas。
它的一般使用場景如下：
在去做每個節點的日誌收集工作。
監控每個節點的的執行狀態。
29、簡述Kubernetes自動擴容機制
Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實現基於CPU使用率進行自動Pod擴縮容的功能。HPA控制器週期性地監測目標Pod的資源效能指標，並與HPA資源物件中的擴縮容條件進行對比，在滿足條件時對Pod副本數量進行調整。
Kubernetes中的某個Metrics Server（Heapster或自定義Metrics Server）持續採集所有Pod副本的指標資料。HPA控制器通過Metrics Server的API（Heapster的API或聚合API）獲取這些資料，基於使用者定義的擴縮容規則進行計算，得到目標Pod副本數量。
當目標Pod副本數量與當前副本數量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發起scale操作，調整Pod的副本數量，完成擴縮容操作。
30、簡述Kubernetes Service型別
通過建立Service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求負載分發到後端的各個容器應用上。其主要型別有：
ClusterIP：虛擬的服務IP地址，該地址用於Kubernetes叢集內部的Pod訪問，在Node上kube-proxy通過設定的iptables規則進行轉發；
NodePort：使用宿主機的埠，使能夠訪問各Node的外部客戶端通過Node的IP地址和埠號就能訪問服務；
LoadBalancer：使用外接負載均衡器完成到服務的負載分發，需要在spec.status.loadBalancer欄位指定外部負載均衡器的IP地址，通常用於公有云。
31、簡述Kubernetes Service分發後端的策略
Service負載分發的策略有：RoundRobin和SessionAffinity
RoundRobin：預設為輪詢模式，即輪詢將請求轉發到後端的各個Pod上。
SessionAffinity：基於客戶端IP地址進行會話保持的模式，即第1次將某個客戶端發起的請求轉發到後端的某個Pod上，之後從相同的客戶端發起的請求都將被轉發到後端相同的Pod上。
32、簡述Kubernetes Headless Service
在某些應用場景中，若需要人為指定負載均衡器，不使用Service提供的預設負載均衡的功能，或者應用程式希望知道屬於同組服務的其他例項。Kubernetes提供了Headless Service來實現這種功能，即不為Service設定ClusterIP（入口IP地址），僅通過Label Selector將後端的Pod列表返回給呼叫的客戶端。
33、簡述Kubernetes外部如何訪問叢集內的服務
對於Kubernetes，叢集外的客戶端預設情況，無法通過Pod的IP地址或者Service的虛擬IP地址：虛擬埠號進行訪問。通常可以通過以下方式進行訪問Kubernetes叢集內的服務：
對映Pod到物理機：將Pod埠號對映到宿主機，即在Pod中採用hostPort方式，以使客戶端應用能夠通過物理機訪問容器應用。
對映Service到物理機：將Service埠號對映到宿主機，即在Service中採用nodePort方式，以使客戶端應用能夠通過物理機訪問容器應用。
對映Sercie到LoadBalancer：通過設定LoadBalancer對映到雲服務商提供的LoadBalancer地址。這種用法僅用於在公有云服務提供商的雲平臺上設定Service的場景。
34、簡述Kubernetes ingress
Kubernetes的Ingress資源物件，用於將不同URL的訪問請求轉發到後端不同的Service，以實現HTTP層的業務路由機制。
Kubernetes使用了Ingress策略和Ingress Controller，兩者結合並實現了一個完整的Ingress負載均衡器。使用Ingress進行負載分發時，Ingress Controller基於Ingress規則將客戶端請求直接轉發到Service對應的後端Endpoint（Pod）上，從而跳過kube-proxy的轉發功能，kube-proxy不再起作用，全過程為：ingress controller + ingress 規則 —-> services。
同時當Ingress Controller提供的是對外服務，則實際上實現的是邊緣路由器的功能。
35、簡述Kubernetes映象的下載策略
Kubernetes的映象下載策略有三種：Always、Never、IFNotPresent。
Always：映象標籤為latest時，總是從指定的倉庫中獲取映象。
Never：禁止從倉庫中下載映象，也就是說只能使用本地映象。
IfNotPresent：僅當本地沒有對應映象時，才從目標倉庫中下載。預設的映象下載策略是：當映象標籤是latest時，預設策略是Always；當映象標籤是自定義時（也就是標籤不是latest），那麼預設策略是IfNotPresent。
36、簡述Kubernetes的負載均衡器
負載均衡器是暴露服務的最常見和標準方式之一。
根據工作環境使用兩種型別的負載均衡器，即內部負載均衡器或外部負載均衡器。內部負載均衡器自動平衡負載並使用所需配置分配容器，而外部負載均衡器將流量從外部負載引導至後端容器。
37、簡述Kubernetes各模組如何與API Server通訊
Kubernetes API Server作為叢集的核心，負責叢集各功能模組之間的通訊。叢集內的各個功能模組通過API Server將資訊存入etcd，當需要獲取和操作這些資料時，則通過API Server提供的REST介面（用GET、LIST或WATCH方法）來實現，從而實現各模組之間的資訊互動。
如kubelet程式與API Server的互動：每個Node上的kubelet每隔一個時間週期，就會呼叫一次API Server的REST介面報告自身狀態，API Server在接收到這些資訊後，會將節點狀態資訊更新到etcd中。
如kube-controller-manager程式與API Server的互動：kube-controller-manager中的Node Controller模組通過API Server提供的Watch介面實時監控Node的資訊，並做相應處理。
如kube-scheduler程式與API Server的互動：Scheduler通過API Server的Watch介面監聽到新建Pod副本的資訊後，會檢索所有符合該Pod要求的Node列表，開始執行Pod排程邏輯，在排程成功後將Pod繫結到目標節點上。
38、簡述Kubernetes Scheduler作用及實現原理
Kubernetes Scheduler是負責Pod排程的重要功能模組，Kubernetes Scheduler在整個系統中承擔了“承上啟下”的重要功能，“承上”是指它負責接收Controller Manager建立的新Pod，為其排程至目標Node；“啟下”是指排程完成後，目標Node上的kubelet服務程式接管後繼工作，負責Pod接下來生命週期。
Kubernetes Scheduler的作用是將待排程的Pod（API新建立的Pod、Controller Manager為補足副本而建立的Pod等）按照特定的排程演算法和排程策略繫結（Binding）到叢集中某個合適的Node上，並將繫結資訊寫入etcd中。
在整個排程過程中涉及三個物件，分別是待排程Pod列表、可用Node列表，以及排程演算法和策略。
Kubernetes Scheduler通過排程演算法排程為待排程Pod列表中的每個Pod從Node列表中選擇一個最適合的Node來實現Pod的排程。隨後，目標節點上的kubelet通過API Server監聽到Kubernetes Scheduler產生的Pod繫結事件，然後獲取對應的Pod清單，下載Image映象並啟動容器。
39、簡述Kubernetes Scheduler使用哪兩種演算法將Pod繫結到worker節點
Kubernetes Scheduler根據如下兩種排程演算法將 Pod 繫結到最合適的工作節點：
預選（Predicates）：輸入是所有節點，輸出是滿足預選條件的節點。kube-scheduler根據預選策略過濾掉不滿足策略的Nodes。如果某節點的資源不足或者不滿足預選策略的條件則無法通過預選。如“Node的label必須與Pod的Selector一致”。
優選（Priorities）：輸入是預選階段篩選出的節點，優選會根據優先策略為通過預選的Nodes進行打分排名，選擇得分最高的Node。例如，資源越富裕、負載越小的Node可能具有越高的排名。
40、簡述Kubernetes kubelet的作用
在Kubernetes叢集中，在每個Node（又稱Worker）上都會啟動一個kubelet服務程式。該程式用於處理Master下發到本節點的任務，管理Pod及Pod中的容器。每個kubelet程式都會在API Server上註冊節點自身的資訊，定期向Master彙報節點資源的使用情況，並通過cAdvisor監控容器和節點資源。
41、簡述Kubernetes kubelet監控Worker節點資源是使用什麼元件來實現的
kubelet使用cAdvisor對worker節點資源進行監控。在Kubernetes系統中，cAdvisor已被預設整合到kubelet元件內，當kubelet服務啟動時，它會自動啟動cAdvisor服務，然後cAdvisor會實時採集所在節點的效能指標及在節點上執行的容器的效能指標。
42、簡述Kubernetes如何保證叢集的安全性
Kubernetes通過一系列機制來實現叢集的安全控制，主要有如下不同的維度：
基礎設施方面：保證容器與其所在宿主機的隔離；
許可權方面：
最小許可權原則：合理限制所有元件的許可權，確保元件只執行它被授權的行為，通過限制單個元件的能力來限制它的許可權範圍。
使用者許可權：劃分普通使用者和管理員的角色。
叢集方面：
API Server的認證授權：Kubernetes叢集中所有資源的訪問和變更都是通過Kubernetes API Server來實現的，因此需要建議採用更安全的HTTPS或Token來識別和認證客戶端身份（Authentication），以及隨後訪問許可權的授權（Authorization）環節。
API Server的授權管理：通過授權策略來決定一個API呼叫是否合法。對合法使用者進行授權並且隨後在使用者訪問時進行鑑權，建議採用更安全的RBAC方式來提升叢集安全授權。
敏感資料引入Secret機制：對於叢集敏感資料建議使用Secret方式進行保護。
AdmissionControl（准入機制）：對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然後執行准入操作，最後對目標物件進行操作。
43、簡述Kubernetes准入機制
在對叢集進行請求時，每個准入控制程式碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求，那麼整個請求的結果將會立即返回，並提示使用者相應的error資訊。
准入控制（AdmissionControl）准入控制本質上為一段准入程式碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然後執行准入操作，最後對目標物件進行操作。常用元件（控制程式碼）如下：
AlwaysAdmit：允許所有請求
AlwaysDeny：禁止所有請求，多用於測試環境。
ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動新增一個default，並確保pod的serviceAccount始終存在。
LimitRanger：觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange物件中。
NamespaceExists：觀察所有的請求，如果請求嘗試建立一個不存在的namespace，則這個請求被拒絕。
44、簡述Kubernetes RBAC及其特點（優勢）
RBAC是基於角色的訪問控制，是一種基於個人使用者的角色來管理對計算機或網路資源的訪問的方法。
相對於其他授權模式，RBAC具有如下優勢：
對叢集中的資源和非資源許可權均有完整的覆蓋。
整個RBAC完全由幾個API物件完成， 同其他API物件一樣， 可以用kubectl或API進行操作。
可以在執行時進行調整，無須重新啟動API Server。
45、簡述Kubernetes Secret作用
Secret物件，主要作用是保管私密資料，比如密碼、OAuth Tokens、SSH Keys等資訊。將這些私密資訊放在Secret物件中比直接放在Pod或Docker Image中更安全，也更便於使用和分發。
46、簡述Kubernetes Secret有哪些使用方式
建立完secret之後，可通過如下三種方式使用：
在建立Pod時，通過為Pod指定Service Account來自動使用該Secret。
通過掛載該Secret到Pod來使用它。
在Docker映象下載時使用，通過指定Pod的spc.ImagePullSecrets來引用它。
47、簡述Kubernetes PodSecurityPolicy機制
Kubernetes PodSecurityPolicy是為了更精細地控制Pod對資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy准入控制器後，Kubernetes預設不允許建立任何Pod，需要建立PodSecurityPolicy策略和相應的RBAC授權策略（Authorizing Policies），Pod才能建立成功。
48、簡述Kubernetes PodSecurityPolicy機制能實現哪些安全策略
在PodSecurityPolicy物件中可以設定不同欄位來控制Pod執行時的各種安全策略，常見的有：
特權模式：privileged是否允許Pod以特權模式執行。
宿主機資源：控制Pod對宿主機資源的控制，如hostPID：是否允許Pod共享宿主機的程式空間。
使用者和組：設定執行容器的使用者ID（範圍）或組（範圍）。
提升許可權：AllowPrivilegeEscalation：設定容器內的子程式是否可以提升許可權，通常在設定非root使用者（MustRunAsNonRoot）時進行設定。
SELinux：進行SELinux的相關配置。
49、簡述Kubernetes網路模型
Kubernetes網路模型中每個Pod都擁有一個獨立的IP地址，並假定所有Pod都在一個可以直接連通的、扁平的網路空間中。所以不管它們是否執行在同一個Node（宿主機）中，都要求它們可以直接通過對方的IP進行訪問。設計這個原則的原因是，使用者不需要額外考慮如何建立Pod之間的連線，也不需要考慮如何將容器埠對映到主機埠等問題。
同時為每個Pod都設定一個IP地址的模型使得同一個Pod內的不同容器會共享同一個網路名稱空間，也就是同一個Linux網路協議棧。這就意味著同一個Pod內的容器可以通過localhost來連線對方的埠。
在Kubernetes的叢集裡，IP是以Pod為單位進行分配的。一個Pod內部的所有容器共享一個網路堆疊（相當於一個網路名稱空間，它們的IP地址、網路裝置、配置等都是共享的）。
50、簡述Kubernetes CNI模型
CNI提供了一種應用容器的外掛化網路解決方案，定義對容器網路進行操作和配置的規範，通過外掛的形式對CNI介面進行實現。CNI僅關注在建立容器時分配網路資源，和在銷燬容器時刪除網路資源。在CNI模型中只涉及兩個概念：容器和網路。
容器（Container）：是擁有獨立Linux網路名稱空間的環境，例如使用Docker或rkt建立的容器。容器需要擁有自己的Linux網路名稱空間，這是加入網路的必要條件。
網路（Network）：表示可以互連的一組實體，這些實體擁有各自獨立、唯一的IP地址，可以是容器、物理機或者其他網路裝置（比如路由器）等。
對容器網路的設定和操作都通過外掛（Plugin）進行具體實現，CNI外掛包括兩種型別：CNI Plugin和IPAM（IP Address Management）Plugin。CNI Plugin負責為容器配置網路資源，IPAM Plugin負責對容器的IP地址進行分配和管理。IPAM Plugin作為CNI Plugin的一部分，與CNI Plugin協同工作。
51、簡述Kubernetes網路策略
為實現細粒度的容器間網路訪問隔離策略，Kubernetes引入Network Policy。
Network Policy的主要功能是對Pod間的網路通訊進行限制和准入控制，設定允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網路策略，配合策略控制器（Policy Controller）進行策略的實現。
52、簡述Kubernetes網路策略原理
Network Policy的工作原理主要為：policy controller需要實現一個API Listener，監聽使用者設定的Network Policy定義，並將網路訪問規則通過各Node的Agent進行實際設定（Agent則需要通過CNI網路外掛實現）。
53、簡述Kubernetes中flannel的作用
Flannel可以用於Kubernetes底層網路的實現，主要作用有：
它能協助Kubernetes，給每一個Node上的Docker容器都分配互相不衝突的IP地址。
它能在這些IP地址之間建立一個覆蓋網路（Overlay Network），通過這個覆蓋網路，將資料包原封不動地傳遞到目標容器內。
54、簡述Kubernetes Calico網路元件實現原理
Calico是一個基於BGP的純三層的網路方案，與OpenStack、Kubernetes、AWS、GCE等雲平臺都能夠良好地整合。
Calico在每個計算節點都利用Linux Kernel實現了一個高效的vRouter來負責資料轉發。每個vRouter都通過BGP協議把在本節點上執行的容器的路由資訊向整個Calico網路廣播，並自動設定到達其他節點的路由轉發規則。
Calico保證所有容器之間的資料流量都是通過IP路由的方式完成互聯互通的。Calico節點組網時可以直接利用資料中心的網路結構（L2或者L3），不需要額外的NAT、隧道或者Overlay Network，沒有額外的封包解包，能夠節約CPU運算，提高網路效率。
55、簡述Kubernetes共享儲存的作用
Kubernetes對於有狀態的容器應用或者對資料需要持久化的應用，因此需要更加可靠的儲存來儲存應用產生的重要資料，以便容器應用在重建之後仍然可以使用之前的資料。因此需要使用共享儲存。
56、簡述Kubernetes資料持久化的方式有哪些
Kubernetes通過資料持久化來持久化儲存重要資料，常見的方式有：
EmptyDir（空目錄）：沒有指定要掛載宿主機上的某個目錄，直接由Pod內保部對映到宿主機上。類似於docker中的manager volume。
場景：
只需要臨時將資料儲存在磁碟上，比如在合併/排序演算法中；
作為兩個容器的共享儲存。
特性：
同個pod裡面的不同容器，共享同一個持久化目錄，當pod節點刪除時，volume的資料也會被刪除。
emptyDir的資料持久化的生命週期和使用的pod一致，一般是作為臨時儲存使用。
Hostpath：將宿主機上已存在的目錄或檔案掛載到容器內部。類似於docker中的bind mount掛載方式。
特性：增加了Pod與節點之間的耦合。
PersistentVolume（簡稱PV）：如基於NFS服務的PV，也可以基於GFS的PV。它的作用是統一資料持久化目錄，方便管理。
57、簡述Kubernetes PV和PVC
PV是對底層網路共享儲存的抽象，將共享儲存定義為一種“資源”。
PVC則是使用者對儲存資源的一個“申請”。
58、簡述Kubernetes PV生命週期內的階段
某個PV在生命週期中可能處於以下4個階段（Phaes）之一。
Available：可用狀態，還未與某個PVC繫結。
Bound：已與某個PVC繫結。
Released：繫結的PVC已經刪除，資源已釋放，但沒有被叢集回收。
Failed：自動資源回收失敗。
59、簡述Kubernetes所支援的儲存供應模式
Kubernetes支援兩種資源的儲存供應模式：靜態模式（Static）和動態模式（Dynamic）。
靜態模式：叢集管理員手工建立許多PV，在定義PV時需要將後端儲存的特性進行設定。
動態模式：叢集管理員無須手工建立PV，而是通過StorageClass的設定對後端儲存進行描述，標記為某種型別。此時要求PVC對儲存的型別進行宣告，系統將自動完成PV的建立及與PVC的繫結。
60、簡述Kubernetes CSI模型
Kubernetes CSI是Kubernetes推出與容器對接的儲存介面標準，儲存提供方只需要基於標準介面進行儲存外掛的實現，就能使用Kubernetes的原生儲存機制為容器提供儲存服務。CSI使得儲存提供方的程式碼能和Kubernetes程式碼徹底解耦，部署也與Kubernetes核心元件分離，顯然，儲存外掛的開發由提供方自行維護，就能為Kubernetes使用者提供更多的儲存功能，也更加安全可靠。
CSI包括CSI Controller和CSI Node：
CSI Controller的主要功能是提供儲存服務視角對儲存資源和儲存捲進行管理和操作。
CSI Node的主要功能是對主機（Node）上的Volume進行管理和操作。
61、簡述Kubernetes Worker節點加入叢集的過程
通常需要對Worker節點進行擴容，從而將應用系統進行水平擴充套件。主要過程如下：
在該Node上安裝Docker、kubelet和kube-proxy服務；
然後配置kubelet和kubeproxy的啟動引數，將Master URL指定為當前Kubernetes叢集Master的地址，最後啟動這些服務；
通過kubelet預設的自動序號產生器制，新的Worker將會自動加入現有的Kubernetes叢集中；
Kubernetes Master在接受了新Worker的註冊之後，會自動將其納入當前叢集的排程範圍。
62、簡述Kubernetes Pod如何實現對節點的資源控制
Kubernetes叢集裡的節點提供的資源主要是計算資源，計算資源是可計量的能被申請、分配和使用的基礎資源。當前Kubernetes叢集中的計算資源主要包括CPU、GPU及Memory。CPU與Memory是被Pod使用的，因此在配置Pod時可以通過引數CPU Request及Memory Request為其中的每個容器指定所需使用的CPU與Memory量，Kubernetes會根據Request的值去查詢有足夠資源的Node來排程此Pod。
通常，一個程式所使用的CPU與Memory是一個動態的量，確切地說，是一個範圍，跟它的負載密切相關：負載增加時，CPU和Memory的使用量也會增加。
63、簡述Kubernetes Requests和Limits如何影響Pod的排程
當一個Pod建立成功時，Kubernetes排程器（Scheduler）會為該Pod選擇一個節點來執行。對於每種計算資源（CPU和Memory）而言，每個節點都有一個能用於執行Pod的最大容量值。排程器在排程時，首先要確保排程後該節點上所有Pod的CPU和記憶體的Requests總和，不超過該節點能提供給Pod使用的CPU和Memory的最大容量值。
64、簡述Kubernetes Metric Service
在Kubernetes從1.10版本後採用Metrics Server作為預設的效能資料採集和監控，主要用於提供核心指標（Core Metrics），包括Node、Pod的CPU和記憶體使用指標。
對其他自定義指標（Custom Metrics）的監控則由Prometheus等元件來完成。
65、簡述Kubernetes中，如何使用EFK實現日誌的統一管理
在Kubernetes叢集環境中，通常一個完整的應用或服務涉及元件過多，建議對日誌系統進行集中化管理，通常採用EFK實現。
EFK是 Elasticsearch、Fluentd 和 Kibana 的組合，其各元件功能如下：
Elasticsearch：是一個搜尋引擎，負責儲存日誌並提供查詢介面；
Fluentd：負責從 Kubernetes 蒐集日誌，每個Node節點上面的Fluentd監控並收集該節點上面的系統日誌，並將處理過後的日誌資訊傳送給Elasticsearch；
Kibana：提供了一個 Web GUI，使用者可以瀏覽和搜尋儲存在 Elasticsearch 中的日誌。
通過在每臺Node上部署一個以DaemonSet方式執行的Fluentd來收集每臺Node上的日誌。Fluentd將Docker日誌目錄/var/lib/docker/containers和/var/log目錄掛載到Pod中，然後Pod會在Node節點的/var/log/pods目錄中建立新的目錄，可以區別不同的容器日誌輸出，該目錄下有一個日誌檔案連結到/var/lib/docker/contianers目錄下的容器日誌輸出。
66、簡述Kubernetes如何進行優雅的節點關機維護
由於Kubernetes節點執行大量Pod，因此在進行關機維護之前，建議先使用kubectl drain將該節點的Pod進行驅逐，然後進行關機維護。
67、簡述Kubernetes叢集聯邦
Kubernetes叢集聯邦可以將多個Kubernetes叢集作為一個叢集進行管理。因此，可以在一個資料中心/雲中建立多個Kubernetes叢集，並使用叢集聯邦在一個地方控制/管理所有叢集。
68、簡述Helm及其優勢
Helm是Kubernetes的軟體包管理工具。類似Ubuntu中使用的APT、CentOS中使用的yum 或者Python中的 pip 一樣。
Helm能夠將一組Kubernetes資源打包統一管理, 是查詢、共享和使用為Kubernetes構建的軟體的最佳方式。
Helm中通常每個包稱為一個Chart，一個Chart是一個目錄（一般情況下會將目錄進行打包壓縮，形成name-version.tgz格式的單一檔案，方便傳輸和儲存）。
在Kubernetes中部署一個可以使用的應用，需要涉及到很多的 Kubernetes 資源的共同協作。使用Helm則具有如下優勢：
統一管理、配置和更新這些分散的Kubernetes的應用資原始檔；
分發和複用一套應用模板；
將應用的一系列資源當做一個軟體包管理。
對於應用釋出者而言，可以通過 Helm 打包應用、管理應用依賴關係、管理應用版本併發布應用到軟體倉庫。
對於使用者而言，使用Helm後不用需要編寫複雜的應用部署檔案，可以以簡單的方式在Kubernetes上查詢、安裝、升級、回滾、解除安裝應用程式。
69、k8s是什麼？請說出你的瞭解？
答：Kubenetes是一個針對容器應用，進行自動部署，彈性伸縮和管理的開源系統。主要功能是生產環境中的容器編排。
K8S是Google公司推出的，它來源於由Google公司內部使用了15年的Borg系統，集結了Borg的精華。
70、K8s架構的組成是什麼？
答：和大多數分散式系統一樣，K8S叢集至少需要一個主節點（Master）和多個計算節點（Node）。
主節點主要用於暴露API，排程部署和節點的管理；
計算節點執行一個容器執行環境，一般是docker環境（類似docker環境的還有rkt），同時執行一個K8s的代理（kubelet）用於和master通訊。計算節點也會執行一些額外的元件，像記錄日誌，節點監控，服務發現等等。計算節點是k8s叢集中真正工作的節點。
K8S架構細分：
1、Master節點（預設不參加實際工作）：
Kubectl：客戶端命令列工具，作為整個K8s叢集的操作入口；
Api Server：在K8s架構中承擔的是“橋樑”的角色，作為資源操作的唯一入口，它提供了認證、授權、訪問控制、API註冊和發現等機制。客戶端與k8s群集及K8s內部元件的通訊，都要通過Api Server這個元件；
Controller-manager：負責維護群集的狀態，比如故障檢測、自動擴充套件、滾動更新等；
Scheduler：負責資源的排程，按照預定的排程策略將pod排程到相應的node節點上；
Etcd：擔任資料中心的角色，儲存了整個群集的狀態；
2、Node節點：
Kubelet：負責維護容器的生命週期，同時也負責Volume和網路的管理，一般執行在所有的節點，是Node節點的代理，當Scheduler確定某個node上執行pod之後，會將pod的具體資訊（image，volume）等傳送給該節點的kubelet，kubelet根據這些資訊建立和執行容器，並向master返回執行狀態。（自動修復功能：如果某個節點中的容器當機，它會嘗試重啟該容器，若重啟無效，則會將該pod殺死，然後重新建立一個容器）；
Kube-proxy：Service在邏輯上代表了後端的多個pod。負責為Service提供cluster內部的服務發現和負載均衡（外界通過Service訪問pod提供的服務時，Service接收到的請求後就是通過kube-proxy來轉發到pod上的）；
container-runtime：是負責管理執行容器的軟體，比如docker
Pod：是k8s叢集裡面最小的單位。每個pod裡邊可以執行一個或多個container（容器），如果一個pod中有兩個container，那麼container的USR（使用者）、MNT（掛載點）、PID（程式號）是相互隔離的，UTS（主機名和域名）、IPC（訊息佇列）、NET（網路棧）是相互共享的。我比較喜歡把pod來當做豌豆夾，而豌豆就是pod中的container；
71、容器和主機部署應用的區別是什麼？
答：容器的中心思想就是秒級啟動；一次封裝、到處執行；這是主機部署應用無法達到的效果，但同時也更應該注重容器的資料持久化問題。
另外，容器部署可以將各個服務進行隔離，互不影響，這也是容器的另一個核心概念。
72、請你說一下kubenetes針對pod資源物件的健康監測機制？
答：K8s中對於pod資源物件的健康狀態檢測，提供了三類probe（探針）來執行對pod的健康監測：
1） livenessProbe探針
可以根據使用者自定義規則來判定pod是否健康，如果livenessProbe探針探測到容器不健康，則kubelet會根據其重啟策略來決定是否重啟，如果一個容器不包含livenessProbe探針，則kubelet會認為容器的livenessProbe探針的返回值永遠成功。
2） ReadinessProbe探針
同樣是可以根據使用者自定義規則來判斷pod是否健康，如果探測失敗，控制器會將此pod從對應service的endpoint列表中移除，從此不再將任何請求排程到此Pod上，直到下次探測成功。
3） startupProbe探針
啟動檢查機制，應用一些啟動緩慢的業務，避免業務長時間啟動而被上面兩類探針kill掉，這個問題也可以換另一種方式解決，就是定義上面兩類探針機制時，初始化時間定義的長一些即可。
每種探測方法能支援以下幾個相同的檢查引數，用於設定控制檢查時間：
initialDelaySeconds：初始第一次探測間隔，用於應用啟動的時間，防止應用還沒啟動而健康檢查失敗
periodSeconds：檢查間隔，多久執行probe檢查，預設為10s；
timeoutSeconds：檢查超時時長，探測應用timeout後為失敗；
successThreshold：成功探測閾值，表示探測多少次為健康正常，預設探測1次。
上面兩種探針都支援以下三種探測方法：
1）Exec：通過執行命令的方式來檢查服務是否正常，比如使用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: #執行以下命令
command: - cat
- /tmp/healthy
initialDelaySeconds: 5 #在容器執行五秒後開始探測
periodSeconds: 5 #每次探測的時間間隔為5秒
在上面的配置檔案中，探測機制為在容器執行5秒後，每隔五秒探測一次，如果cat命令返回的值為“0”，則表示健康，如果為非0，則表示異常。
2）Httpget：通過傳送http/htps請求檢查服務是否正常，返回的狀態碼為200-399則表示容器健康（注http get類似於命令curl -I）。
Httpget探測方式的yaml檔案語法如下：
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
livenessProbe: #採用livenessProbe機制探測
httpGet: #採用httpget的方式
scheme:HTTP #指定協議，也支援https
path: /healthz #檢測是否可以訪問到網頁根目錄下的healthz網頁檔案
port: 8080 #監聽埠是8080
initialDelaySeconds: 3 #容器執行3秒後開始探測
periodSeconds: 3 #探測頻率為3秒
上述配置檔案中，探測方式為項容器傳送HTTP GET請求，請求的是8080埠下的healthz檔案，返回任何大於或等於200且小於400的狀態碼錶示成功。任何其他程式碼表示異常。
3）tcpSocket：通過容器的IP和Port執行TCP檢查，如果能夠建立TCP連線，則表明容器健康，這種方式與HTTPget的探測機制有些類似，tcpsocket健康檢查適用於TCP業務。
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
- containerPort: 8080
在上述的yaml配置檔案中，兩類探針都使用了，在容器啟動5秒後，kubelet將傳送第一個readinessProbe探針，這將連線容器的8080埠，如果探測成功，則該pod為健康，十秒後，kubelet將進行第二次連線。
除了readinessProbe探針外，在容器啟動15秒後，kubelet將傳送第一個livenessProbe探針，仍然嘗試連線容器的8080埠，如果連線失敗，則重啟容器。
探針探測的結果無外乎以下三者之一：
Success：Container通過了檢查；
Failure：Container沒有通過檢查；
Unknown：沒有執行檢查，因此不採取任何措施（通常是我們沒有定義探針檢測，預設為成功）。
若覺得上面還不夠透徹，可以移步其官網文件：
kubernetes.io/docs/tasks/configure...
73、如何控制滾動更新過程？
答：可以通過下面的命令檢視到更新時可以控制的引數：
[root@master yaml]# kubectl explain deploy.spec.strategy.rollingUpdate
maxSurge： 此引數控制滾動更新過程，副本總數超過預期pod數量的上限。可以是百分比，也可以是具體的值。預設為1。
（上述引數的作用就是在更新過程中，值若為3，那麼不管三七二一，先執行三個pod，用於替換舊的pod，以此類推）
maxUnavailable：此引數控制滾動更新過程中，不可用的Pod的數量。
（這個值和上面的值沒有任何關係，舉個例子：我有十個pod，但是在更新的過程中，我允許這十個pod中最多有三個不可用，那麼就將這個引數的值設定為3，在更新的過程中，只要不可用的pod數量小於或等於3，那麼更新過程就不會停止）。
74、K8s中映象的下載策略是什麼？
答：可通過命令“kubectl explain pod.spec.containers”來檢視imagePullPolicy這行的解釋。
K8s的映象下載策略有三種：Always、Never、IFNotPresent；
Always：映象標籤為latest時，總是從指定的倉庫中獲取映象；
Never：禁止從倉庫中下載映象，也就是說只能使用本地映象；
IfNotPresent：僅當本地沒有對應映象時，才從目標倉庫中下載。
預設的映象下載策略是：當映象標籤是latest時，預設策略是Always；當映象標籤是自定義時（也就是標籤不是latest），那麼預設策略是IfNotPresent。
75、image的狀態有哪些？
Running：Pod所需的容器已經被成功排程到某個節點，且已經成功執行，
Pending：APIserver建立了pod資源物件，並且已經存入etcd中，但它尚未被排程完成或者仍然處於倉庫中下載映象的過程
Unknown：APIserver無法正常獲取到pod物件的狀態，通常是其無法與所在工作節點的kubelet通訊所致。
76、pod的重啟策略是什麼？
答：可以通過命令“kubectl explain pod.spec”檢視pod的重啟策略。（restartPolicy欄位）
Always：但凡pod物件終止就重啟，此為預設策略。
OnFailure：僅在pod物件出現錯誤時才重啟
77、Service這種資源物件的作用是什麼？
答：用來給相同的多個pod物件提供一個固定的統一訪問介面，常用於服務發現和服務訪問。
78、版本回滾相關的命令？
[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
#執行回滾操作，指定回滾到版本1
#在yaml檔案的spec欄位中，可以寫以下選項（用於限制最多記錄多少個歷史版本）：
spec:
revisionHistoryLimit: 5
#這個欄位通過 kubectl explain deploy.spec 命令找到revisionHistoryLimit 行獲得
79、標籤與標籤選擇器的作用是什麼？
標籤：是當相同型別的資源物件越來越多的時候，為了更好的管理，可以按照標籤將其分為一個組，為的是提升資源物件的管理效率。
標籤選擇器：就是標籤的查詢過濾條件。目前API支援兩種標籤選擇器：
基於等值關係的，如：“=”、“”“==”、“！=”（注：“==”也是等於的意思，yaml檔案中的matchLabels欄位）；
基於集合的，如：in、notin、exists（yaml檔案中的matchExpressions欄位）；
注：in:在這個集合中；notin：不在這個集合中；exists：要麼全在（exists）這個集合中，要麼都不在（notexists）；
使用標籤選擇器的操作邏輯：
在使用基於集合的標籤選擇器同時指定多個選擇器之間的邏輯關係為“與”操作（比如：- {key: name,operator: In,values: [zhangsan,lisi]} ，那麼只要擁有這兩個值的資源，都會被選中）；
使用空值的標籤選擇器，意味著每個資源物件都被選中（如：標籤選擇器的鍵是“A”，兩個資源物件同時擁有A這個鍵，但是值不一樣，這種情況下，如果使用空值的標籤選擇器，那麼將同時選中這兩個資源物件）
空的標籤選擇器（注意不是上面說的空值，而是空的，都沒有定義鍵的名稱），將無法選擇出任何資源；
在基於集合的選擇器中，使用“In”或者“Notin”操作時，其values可以為空，但是如果為空，這個標籤選擇器，就沒有任何意義了。
兩種標籤選擇器型別（基於等值、基於集合的書寫方法）：
selector:
matchLabels: #基於等值
app: nginx
matchExpressions: #基於集合
- {key: name,operator: In,values: [zhangsan,lisi]} #key、operator、values這三個欄位是固定的
- {key: age,operator: Exists,values:} #如果指定為exists，那麼values的值一定要為空
80、常用的標籤分類有哪些？
標籤分類是可以自定義的，但是為了能使他人可以達到一目瞭然的效果，一般會使用以下一些分類：
版本類標籤（release）：stable（穩定版）、canary（金絲雀版本，可以將其稱之為測試版中的測試版）、beta（測試版）；
環境類標籤（environment）：dev（開發）、qa（測試）、production（生產）、op（運維）；
應用類（app）：ui、as、pc、sc；
架構類（tier）：frontend（前端）、backend（後端）、cache（快取）；
分割槽標籤（partition）：customerA（客戶A）、customerB（客戶B）；
品控級別（Track）：daily（每天）、weekly（每週）。
81、有幾種檢視標籤的方式？
答：常用的有以下三種檢視方式：
[root@master ~]# kubectl get pod –show-labels #檢視pod，並且顯示標籤內容
[root@master ~]# kubectl get pod -L env,tier #顯示資源物件標籤的值
[root@master ~]# kubectl get pod -l env,tier #只顯示符合鍵值資源物件的pod，而“-L”是顯示所有的pod
82、新增、修改、刪除標籤的命令？
#對pod標籤的操作
[root@master ~]# kubectl label pod label-pod abc=123 #給名為label-pod的pod新增標籤
[root@master ~]# kubectl label pod label-pod abc=456 –overwrite #修改名為label-pod的標籤
[root@master ~]# kubectl label pod label-pod abc- #刪除名為label-pod的標籤
[root@master ~]# kubectl get pod –show-labels
#對node節點的標籤操作
[root@master ~]# kubectl label nodes node01 disk=ssd #給節點node01新增disk標籤
[root@master ~]# kubectl label nodes node01 disk=sss –overwrite #修改節點node01的標籤
[root@master ~]# kubectl label nodes node01 disk- #刪除節點node01的disk標籤
83、DaemonSet資源物件的特性？
DaemonSet這種資源物件會在每個k8s叢集中的節點上執行，並且每個節點只能執行一個pod，這是它和deployment資源物件的最大也是唯一的區別。所以，在其yaml檔案中，不支援定義replicas，除此之外，與Deployment、RS等資源物件的寫法相同。
它的一般使用場景如下：
在去做每個節點的日誌收集工作；
監控每個節點的的執行狀態；
84、說說你對Job這種資源物件的瞭解？
答：Job與其他服務類容器不同，Job是一種工作類容器（一般用於做一次性任務）。使用常見不多，可以忽略這個問題。
#提高Job執行效率的方法：
spec:
parallelism: 2 #一次執行2個
completions: 8 #最多執行8個
template:
metadata:
85、描述一下pod的生命週期有哪些狀態？
Pending：表示pod已經被同意建立，正在等待kube-scheduler選擇合適的節點建立，一般是在準備映象；
Running：表示pod中所有的容器已經被建立，並且至少有一個容器正在執行或者是正在啟動或者是正在重啟；
Succeeded：表示所有容器已經成功終止，並且不會再啟動；
Failed：表示pod中所有容器都是非0（不正常）狀態退出；
Unknown：表示無法讀取Pod狀態，通常是kube-controller-manager無法與Pod通訊。
86、建立一個pod的流程是什麼？
客戶端提交Pod的配置資訊（可以是yaml檔案定義好的資訊）到kube-apiserver；
Apiserver收到指令後，通知給controller-manager建立一個資源物件；
Controller-manager通過api-server將pod的配置資訊儲存到ETCD資料中心中；
Kube-scheduler檢測到pod資訊會開始排程預選，會先過濾掉不符合Pod資源配置要求的節點，然後開始排程調優，主要是挑選出更適合執行pod的節點，然後將pod的資源配置單傳送到node節點上的kubelet元件上。
Kubelet根據scheduler發來的資源配置單執行pod，執行成功後，將pod的執行資訊返回給scheduler，scheduler將返回的pod執行狀況的資訊儲存到etcd資料中心。
87、刪除一個Pod會發生什麼事情？
答：Kube-apiserver會接受到使用者的刪除指令，預設有30秒時間等待優雅退出，超過30秒會被標記為死亡狀態，此時Pod的狀態Terminating，kubelet看到pod標記為Terminating就開始了關閉Pod的工作；
關閉流程如下：
pod從service的endpoint列表中被移除；
如果該pod定義了一個停止前的鉤子，其會在pod內部被呼叫，停止鉤子一般定義瞭如何優雅的結束程式；
程式被髮送TERM訊號（kill -14）
當超過優雅退出的時間後，Pod中的所有程式都會被髮送SIGKILL訊號（kill -9）。
88、K8s的Service是什麼？
答：Pod每次重啟或者重新部署，其IP地址都會產生變化，這使得pod間通訊和pod與外部通訊變得困難，這時候，就需要Service為pod提供一個固定的入口。
Service的Endpoint列表通常繫結了一組相同配置的pod，通過負載均衡的方式把外界請求分配到多個pod上
89、k8s是怎麼進行服務註冊的？
答：Pod啟動後會載入當前環境所有Service資訊，以便不同Pod根據Service名進行通訊。
90、k8s叢集外流量怎麼訪問Pod？
答：可以通過Service的NodePort方式訪問，會在所有節點監聽同一個埠，比如：30000，訪問節點的流量會被重定向到對應的Service上面。
91、k8s資料持久化的方式有哪些？
答：
1）EmptyDir（空目錄）：
沒有指定要掛載宿主機上的某個目錄，直接由Pod內保部對映到宿主機上。類似於docker中的manager volume。
主要使用場景：
只需要臨時將資料儲存在磁碟上，比如在合併/排序演算法中；
作為兩個容器的共享儲存，使得第一個內容管理的容器可以將生成的資料存入其中，同時由同一個webserver容器對外提供這些頁面。
emptyDir的特性：
同個pod裡面的不同容器，共享同一個持久化目錄，當pod節點刪除時，volume的資料也會被刪除。如果僅僅是容器被銷燬，pod還在，則不會影響volume中的資料。
總結來說：emptyDir的資料持久化的生命週期和使用的pod一致。一般是作為臨時儲存使用。
2）Hostpath：
將宿主機上已存在的目錄或檔案掛載到容器內部。類似於docker中的bind mount掛載方式。
這種資料持久化方式，運用場景不多，因為它增加了pod與節點之間的耦合。
一般對於k8s叢集本身的資料持久化和docker本身的資料持久化會使用這種方式，可以自行參考apiService的yaml檔案，位於：/etc/kubernetes/main…目錄下。
3）PersistentVolume（簡稱PV）：
基於NFS服務的PV，也可以基於GFS的PV。它的作用是統一資料持久化目錄，方便管理。
在一個PV的yaml檔案中，可以對其配置PV的大小，指定PV的訪問模式：
ReadWriteOnce：只能以讀寫的方式掛載到單個節點；
ReadOnlyMany：能以只讀的方式掛載到多個節點；
ReadWriteMany：能以讀寫的方式掛載到多個節點。以及指定pv的回收策略：
recycle：清除PV的資料，然後自動回收；
Retain：需要手動回收；
delete：刪除雲端儲存資源，雲端儲存專用；
PS：這裡的回收策略指的是在PV被刪除後，在這個PV下所儲存的原始檔是否刪除）。
若需使用PV，那麼還有一個重要的概念：PVC，PVC是向PV申請應用所需的容量大小，K8s叢集中可能會有多個PV，PVC和PV若要關聯，其定義的訪問模式必須一致。定義的storageClassName也必須一致，若群集中存在相同的（名字、訪問模式都一致）兩個PV，那麼PVC會選擇向它所需容量接近的PV去申請，或者隨機申請。
全網收集了90道常見的Kubernetes面試題，更多Kubernetes，學習資料可以轉到我的GitHub專案，裡面內含：書籍推薦，面試題，精選文章，開源專案，PPT，視訊，大廠資料：github.com/0voice/k8s_awesome_docu...
本作品採用《CC 協議》，轉載必須註明作者和本文連結