今天分享一份kubenetes高頻面試題，共包括有80道高頻面試題，助你k8s難點要點一網打盡！
1、簡述ETCD及其特點?
etcd是一個分布式的、高可用的、一致的key-value存儲數據庫，基於Go語言實現，主要用於共享配置和服務發現。
特點：
完全復制：集群中的每個節點都可以使用完整的存檔
高可用性：Etcd可用於避免硬件的單點故障或網絡問題
一致性：每次讀取都會返回跨多主機的最新寫入
簡單：包括一個定義良好、面向用戶的API（gRPC）
安全：實現了帶有可選的客戶端證書身份驗證的自動化TLS
快速：每秒10000次寫入的基准速度
可靠：使用Raft算法實現了強一致、高可用的服務存儲目錄
2、簡述ETCD適應的場景?
服務發現：服務發現要解決的也是分布式系統中最常見的問題之一，即在同一個分布式集群中的進程或服務，要如何才能找到對方並建立連接。本質上來說，服務發現就是想要了解集群中是否有進程在監聽udp或tcp端口，並且通過名字就可以查找和連接。
消息發布與訂閱：在分布式系統中，最實用對的一種組件間的通信方式：消息發布與訂閱。構建一個配置共享中心，數據提供者在這個配置中心發布消息，而消息使用者訂閱他們關心的主題，一旦主題有消息發布，就會實時通知訂閱者。達成集中式管理與動態更新。應用中用到的一些配置信息放到etcd上進行集中管理。
負載均衡：分布式系統中，為了保證服務的高可用以及數據的一致性，通常都會把數據和服務部署多份，以此達到對等服務，即使其中的某一個服務失效了，也不影響使用。etcd本身分布式架構存儲的信息訪問支持負載均衡。
分布式通知與協調：通過注冊與異步通知機制，實現分布式環境下不同系統之間的通知與協調，從而對數據變更做到實時處理。
分布式鎖：因為etcd使用Raft算法保持了數據的強一致性，某次操作存儲到集群中的值必然是全局一致的，所以很容易實現分布式鎖。鎖服務有兩種使用方式，一是保持獨占，二是控制時序。
分布式隊列：分布式隊列的常規用法與場景五中所描述的分布式鎖的控制時序用法類似，即創建一個先進先出的隊列，保證順序。
集群監控與Leader精選：通過etcd來進行監控實現起來非常簡單並且實時性強。
3、簡述什么是Kubernetes?
kubernetes，簡稱K8s，是一個開源的，用於管理雲平台中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效,Kubernetes提供了應用部署，規划，更新，維護的一種機制。
4、簡述Kubernetes和Docker的關系?
Docker開源的容器引擎，一種更加輕量級的虛擬化技術。
Kubernetes，容器管理工具，用來管理容器pod的集合，它可以實現容器集群的自動化部署、自動擴縮容、維護等功能。
5、簡述Kubernetes中什么是Minikube、Kubectl、Kubelet?
Minikube 是一種可以在本地輕松運行一個單節點 Kubernetes 群集的工具。
Kubectl 是一個命令行工具，可以使用該工具控制Kubernetes集群管理器，如檢查群集資源，創建、刪除和更新組件，查看應用程序。
Kubelet 是一個代理服務，它在每個節點上運行，並使從服務器與主服務器通信。
6、簡述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即可滿足。
10、簡述Kubernetes相關基礎概念?
master：k8s集群的管理節點，負責管理集群，提供集群的資源數據訪問入口。擁有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是Kurbernetes進行創建、調度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個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、簡述kube-proxy作用?
kube-proxy 運行在所有節點上，它監聽 apiserver 中 service 和 endpoint 的變化情況，創建路由規則以提供服務 IP 和負載均衡功能。簡單理解此進程是Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉發到后端的多個Pod實例上。
14、簡述kube-proxy iptables原理?
Kubernetes從1.2版本開始，將iptables作為kube-proxy的默認模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch接口實時跟蹤Service與Endpoint的變更信息，並更新對應的iptables規則，Client的請求流量則通過iptables的NAT機制“直接路由”到目標Pod。
15、簡述kube-proxy ipvs原理?
IPVS在Kubernetes1.11中升級為GA穩定版。IPVS則專門用於高性能負載均衡，並使用更高效的數據結構（Hash表），允許幾乎無限的規模擴張，因此被kube-proxy采納為最新模式。
在IPVS模式下，使用iptables的擴展ipset，而不是直接調用iptables來生成規則鏈。iptables規則鏈是一個線性的數據結構，ipset則引入了帶索引的數據結構，因此當規則很多時，也可以很高效地查找和匹配。
可以將ipset簡單理解為一個IP（段）的集合，這個集合的內容可以是IP地址、IP網段、端口等，iptables可以直接添加規則對這個“可變的集合”進行操作，這樣做的好處在於可以大大減少iptables規則的數量，從而減少性能損耗。
16、簡述kube-proxy ipvs和iptables的異同?
iptables與IPVS都是基於Netfilter實現的，但因為定位不同，二者有着本質的差別：iptables是為防火牆而設計的；IPVS則專門用於高性能負載均衡，並使用更高效的數據結構（Hash表），允許幾乎無限的規模擴張。
與iptables相比，IPVS擁有以下明顯優勢：
為大型集群提供了更好的可擴展性和性能；
支持比iptables更復雜的復制均衡算法（最小負載、最少連接、加權等）；
支持服務器健康檢查和連接重試等功能；
可以動態修改ipset的集合，即使iptables的規則正在使用這個集合。
17、簡述Kubernetes中什么是靜態Pod?
靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行創建，並且總是在kubelet所在的Node上運行。
18、簡述Kubernetes中Pod可能位於的狀態?
Pending：API Server已經創建該Pod，且Pod內還有一個或多個容器的鏡像沒有創建，包括正在下載鏡像的過程。
Running：Pod內所有容器均已創建，且至少有一個容器處於運行狀態、正在啟動狀態或正在重啟狀態。
Succeeded：Pod內所有容器均成功執行退出，且不會重啟。
Failed：Pod內所有容器均已退出，但至少有一個容器退出為失敗狀態。
Unknown：由於某種原因無法獲取該Pod狀態，可能由於網絡通信不暢導致。
19、簡述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數據中心。
20、簡述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進行健康檢查。21、簡述Kubernetes中Pod的健康檢查方式?
21、簡述Kubernetes中Pod的健康檢查方式?
LivenessProbe探針：用於判斷容器是否存活（running狀態），如果LivenessProbe探針探測到容器不健康，則kubelet將殺掉該容器，並根據容器的重啟策略做相應處理。若一個容器不包含LivenessProbe探針，kubelet認為該容器的LivenessProbe探針返回值用於是“Success”。
ReadineeProbe探針：用於判斷容器是否啟動完成（ready狀態）。如果ReadinessProbe探針探測到失敗，則Pod的狀態將被修改。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的Eenpoint。
startupProbe探針：啟動檢查機制，應用一些啟動緩慢的業務，避免業務長時間啟動而被上面兩類探針kill掉。
22、簡述Kubernetes Pod的LivenessProbe探針的常見方式?
ExecAction：在容器內執行一個命令，若返回碼為0，則表明容器健康。
TCPSocketAction：通過容器的IP地址和端口號執行TCP檢查，若能建立TCP連接，則表明容器健康。
HTTPGetAction：通過容器的IP地址、端口號及路徑調用HTTP Get方法，若響應的狀態碼大於等於200且小於400，則表明容器健康。
23、簡述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。
24、簡述Kubernetes初始化容器（init container）?
init container的運行方式與應用容器不同，它們必須先於應用容器執行完成，當設置了多個init container時，將按順序逐個運行，並且只有前一個init container運行成功后才能運行后一個init container。當所有init container都成功運行后，Kubernetes才會初始化Pod的各種信息，並開始創建和運行應用容器。
25、簡述Kubernetes deployment升級過程?
初始創建Deployment時，系統創建了一個ReplicaSet，並按用戶的需求創建了對應數量的Pod副本。
當更新Deployment時，系統創建了一個新的ReplicaSet，並將其副本數量擴展到1，然后將舊ReplicaSet縮減為2。
之后，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。
最后，新的ReplicaSet運行了對應個新版本Pod副本，舊的ReplicaSet副本數量則縮減為0。
26、簡述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）來控制滾動更新的過程。
27、簡述Kubernetes DaemonSet類型的資源特性?
DaemonSet資源對象會在每個Kubernetes集群中的節點上運行，並且每個節點只能運行一個pod，這是它和deployment資源對象的最大也是唯一的區別。因此，在定義yaml文件中，不支持定義replicas。
它的一般使用場景如下：
在去做每個節點的日志收集工作。
監控每個節點的的運行狀態。
28、簡述Kubernetes自動擴容機制?
Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實現基於CPU使用率進行自動Pod擴縮容的功能。HPA控制器周期性地監測目標Pod的資源性能指標，並與HPA資源對象中的擴縮容條件進行對比，在滿足條件時對Pod副本數量進行調整。
29、簡述Kubernetes Service類型?
通過創建Service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求負載分發到后端的各個容器應用上。其主要類型有：
ClusterIP：虛擬的服務IP地址，該地址用於Kubernetes集群內部的Pod訪問，在Node上kube-proxy通過設置的iptables規則進行轉發；
NodePort：使用宿主機的端口，使能夠訪問各Node的外部客戶端通過Node的IP地址和端口號就能訪問服務；
LoadBalancer：使用外接負載均衡器完成到服務的負載分發，需要在spec.status.loadBalancer字段指定外部負載均衡器的IP地址，通常用於公有雲。
30、簡述Kubernetes Service分發后端的策略?
Service負載分發的策略有：RoundRobin和SessionAffinity
RoundRobin：默認為輪詢模式，即輪詢將請求轉發到后端的各個Pod上。
SessionAffinity：基於客戶端IP地址進行會話保持的模式，即第1次將某個客戶端發起的請求轉發到后端的某個Pod上，之后從相同的客戶端發起的請求都將被轉發到后端相同的Pod上。
31、簡述Kubernetes Headless Service?
在某些應用場景中，若需要人為指定負載均衡器，不使用Service提供的默認負載均衡的功能，或者應用程序希望知道屬於同組服務的其他實例。Kubernetes提供了Headless Service來實現這種功能，即不為Service設置ClusterIP（入口IP地址），僅通過Label Selector將后端的Pod列表返回給調用的客戶端。
32、簡述Kubernetes外部如何訪問集群內的服務?
映射Pod到物理機：將Pod端口號映射到宿主機，即在Pod中采用hostPort方式，以使客戶端應用能夠通過物理機訪問容器應用。
映射Service到物理機：將Service端口號映射到宿主機，即在Service中采用nodePort方式，以使客戶端應用能夠通過物理機訪問容器應用。
映射Sercie到LoadBalancer：通過設置LoadBalancer映射到雲服務商提供的LoadBalancer地址。這種用法僅用於在公有雲服務提供商的雲平台上設置Service的場景。
33、簡述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提供的是對外服務，則實際上實現的是邊緣路由器的功能。
34、簡述Kubernetes鏡像的下載策略?
K8s的鏡像下載策略有三種：Always、Never、IFNotPresent。
Always：鏡像標簽為latest時，總是從指定的倉庫中獲取鏡像。
Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。
IfNotPresent：僅當本地沒有對應鏡像時，才從目標倉庫中下載。
默認的鏡像下載策略是：當鏡像標簽是latest時，默認策略是Always；當鏡像標簽是自定義時（也就是標簽不是latest），那么默認策略是IfNotPresent。
35、簡述Kubernetes的負載均衡器?
負載均衡器是暴露服務的最常見和標准方式之一。
根據工作環境使用兩種類型的負載均衡器，即內部負載均衡器或外部負載均衡器。內部負載均衡器自動平衡負載並使用所需配置分配容器，而外部負載均衡器將流量從外部負載引導至后端容器。
36、簡述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綁定到目標節點上。
37、簡述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鏡像並啟動容器。
38、簡述Kubernetes Scheduler使用哪兩種算法將Pod綁定到worker節點?
預選（Predicates）：輸入是所有節點，輸出是滿足預選條件的節點。kube-scheduler根據預選策略過濾掉不滿足策略的Nodes。如果某節點的資源不足或者不滿足預選策略的條件則無法通過預選。如“Node的label必須與Pod的Selector一致”。
優選（Priorities）：輸入是預選階段篩選出的節點，優選會根據優先策略為通過預選的Nodes進行打分排名，選擇得分最高的Node。例如，資源越富裕、負載越小的Node可能具有越高的排名。
39、簡述Kubernetes kubelet的作用?
在Kubernetes集群中，在每個Node（又稱Worker）上都會啟動一個kubelet服務進程。該進程用於處理Master下發到本節點的任務，管理Pod及Pod中的容器。每個kubelet進程都會在API Server上注冊節點自身的信息，定期向Master匯報節點資源的使用情況，並通過cAdvisor監控容器和節點資源。
40、簡述Kubernetes kubelet監控Worker節點資源是使用什么組件來實現的?
kubelet使用cAdvisor對worker節點資源進行監控。在 Kubernetes 系統中，cAdvisor 已被默認集成到 kubelet 組件內，當 kubelet 服務啟動時，它會自動啟動 cAdvisor 服務，然后 cAdvisor 會實時采集所在節點的性能指標及在節點上運行的容器的性能指標。
41、簡述Kubernetes如何保證集群的安全性?
Kubernetes通過一系列機制來實現集群的安全控制，主要有如下不同的維度：
基礎設施方面：保證容器與其所在宿主機的隔離；
權限方面：
最小權限原則：合理限制所有組件的權限，確保組件只執行它被授權的行為，通過限制單個組件的能力來限制它的權限范圍。
用戶權限：划分普通用戶和管理員的角色。
集群方面：
API Server的認證授權：Kubernetes集群中所有資源的訪問和變更都是通過Kubernetes API Server來實現的，因此需要建議采用更安全的HTTPS或Token來識別和認證客戶端身份（Authentication），以及隨后訪問權限的授權（Authorization）環節。
API Server的授權管理：通過授權策略來決定一個API調用是否合法。對合法用戶進行授權並且隨后在用戶訪問時進行鑒權，建議采用更安全的RBAC方式來提升集群安全授權。
敏感數據引入Secret機制：對於集群敏感數據建議使用Secret方式進行保護。
AdmissionControl（准入機制）：對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然后執行准入操作，最后對目標對象進行操作。
42、簡述Kubernetes准入機制?
在對集群進行請求時，每個准入控制代碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求，那么整個請求的結果將會立即返回，並提示用戶相應的error信息。
准入控制（AdmissionControl）准入控制本質上為一段准入代碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然后執行准入操作，最后對目標對象進行操作。常用組件（控制代碼）如下：
AlwaysAdmit：允許所有請求
AlwaysDeny：禁止所有請求，多用於測試環境。
ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動添加一個default，並確保pod的serviceAccount始終存在。
LimitRanger：觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange對象中。
NamespaceExists：觀察所有的請求，如果請求嘗試創建一個不存在的namespace，則這個請求被拒絕。
43、簡述Kubernetes RBAC及其特點（優勢）?
RBAC是基於角色的訪問控制，是一種基於個人用戶的角色來管理對計算機或網絡資源的訪問的方法。
相對於其他授權模式，RBAC具有如下優勢：
對集群中的資源和非資源權限均有完整的覆蓋。
整個RBAC完全由幾個API對象完成， 同其他API對象一樣， 可以用kubectl或API進行操作。
可以在運行時進行調整，無須重新啟動API Server。
44、簡述Kubernetes Secret作用?
Secret對象，主要作用是保管私密數據，比如密碼、OAuth Tokens、SSH Keys等信息。將這些私密信息放在Secret對象中比直接放在Pod或Docker Image中更安全，也更便於使用和分發。
45、簡述Kubernetes Secret有哪些使用方式?
創建完secret之后，可通過如下三種方式使用：
在創建Pod時，通過為Pod指定Service Account來自動使用該Secret。
通過掛載該Secret到Pod來使用它。
在Docker鏡像下載時使用，通過指定Pod的spc.ImagePullSecrets來引用它。
46、簡述Kubernetes PodSecurityPolicy機制?
Kubernetes PodSecurityPolicy是為了更精細地控制Pod對資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy准入控制器后，Kubernetes默認不允許創建任何Pod，需要創建PodSecurityPolicy策略和相應的RBAC授權策略（Authorizing Policies），Pod才能創建成功。
47、簡述Kubernetes PodSecurityPolicy機制能實現哪些安全策略?
在PodSecurityPolicy對象中可以設置不同字段來控制Pod運行時的各種安全策略，常見的有：
特權模式：privileged是否允許Pod以特權模式運行。
宿主機資源：控制Pod對宿主機資源的控制，如hostPID：是否允許Pod共享宿主機的進程空間。
用戶和組：設置運行容器的用戶ID（范圍）或組（范圍）。
提升權限：AllowPrivilegeEscalation：設置容器內的子進程是否可以提升權限，通常在設置非root用戶（MustRunAsNonRoot）時進行設置。
SELinux：進行SELinux的相關配置。
48、簡述Kubernetes網絡模型?
Kubernetes網絡模型中每個Pod都擁有一個獨立的IP地址，並假定所有Pod都在一個可以直接連通的、扁平的網絡空間中。所以不管它們是否運行在同一個Node（宿主機）中，都要求它們可以直接通過對方的IP進行訪問。設計這個原則的原因是，用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮如何將容器端口映射到主機端口等問題。
同時為每個Pod都設置一個IP地址的模型使得同一個Pod內的不同容器會共享同一個網絡命名空間，也就是同一個Linux網絡協議棧。這就意味着同一個Pod內的容器可以通過localhost來連接對方的端口。
在Kubernetes的集群里，IP是以Pod為單位進行分配的。一個Pod內部的所有容器共享一個網絡堆棧（相當於一個網絡命名空間，它們的IP地址、網絡設備、配置等都是共享的）。
49、簡述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協同工作。
50、簡述Kubernetes網絡策略?
為實現細粒度的容器間網絡訪問隔離策略，Kubernetes引入Network Policy。
Network Policy的主要功能是對Pod間的網絡通信進行限制和准入控制，設置允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網絡策略，配合策略控制器（Policy Controller）進行策略的實現。
51、簡述Kubernetes網絡策略原理?
Network Policy的工作原理主要為：policy controller需要實現一個API Listener，監聽用戶設置的Network Policy定義，並將網絡訪問規則通過各Node的Agent進行實際設置（Agent則需要通過CNI網絡插件實現）。
52、簡述Kubernetes中flannel的作用?
Flannel可以用於Kubernetes底層網絡的實現，主要作用有：
它能協助Kubernetes，給每一個Node上的Docker容器都分配互相不沖突的IP地址。
它能在這些IP地址之間建立一個覆蓋網絡（Overlay Network），通過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內。
53、簡述Kubernetes Calico網絡組件實現原理?
Calico是一個基於BGP的純三層的網絡方案，與OpenStack、Kubernetes、AWS、GCE等雲平台都能夠良好地集成。
Calico在每個計算節點都利用Linux Kernel實現了一個高效的vRouter來負責數據轉發。每個vRouter都通過BGP協議把在本節點上運行的容器的路由信息向整個Calico網絡廣播，並自動設置到達其他節點的路由轉發規則。
Calico保證所有容器之間的數據流量都是通過IP路由的方式完成互聯互通的。Calico節點組網時可以直接利用數據中心的網絡結構（L2或者L3），不需要額外的NAT、隧道或者Overlay Network，沒有額外的封包解包，能夠節約CPU運算，提高網絡效率。
54、簡述Kubernetes共享存儲的作用?
Kubernetes對於有狀態的容器應用或者對數據需要持久化的應用，因此需要更加可靠的存儲來保存應用產生的重要數據，以便容器應用在重建之后仍然可以使用之前的數據。因此需要使用共享存儲。
55、簡述Kubernetes數據持久化的方式有哪些?
Kubernetes通過數據持久化來持久化保存重要數據，常見的方式有：
EmptyDir（空目錄）：沒有指定要掛載宿主機上的某個目錄，直接由Pod內保部映射到宿主機上。類似於docker中的manager volume。
場景：
只需要臨時將數據保存在磁盤上，比如在合並/排序算法中；
作為兩個容器的共享存儲。
特性：
同個pod里面的不同容器，共享同一個持久化目錄，當pod節點刪除時，volume的數據也會被刪除。
emptyDir的數據持久化的生命周期和使用的pod一致，一般是作為臨時存儲使用。
Hostpath：將宿主機上已存在的目錄或文件掛載到容器內部。類似於docker中的bind mount掛載方式。
特性：增加了pod與節點之間的耦合。
PersistentVolume（簡稱PV）：如基於NFS服務的PV，也可以基於GFS的PV。它的作用是統一數據持久化目錄，方便管理。
56、簡述Kubernetes PV和PVC?
PV是對底層網絡共享存儲的抽象，將共享存儲定義為一種“資源”。
PVC則是用戶對存儲資源的一個“申請”。
57、簡述Kubernetes PV生命周期內的階段?
某個PV在生命周期中可能處於以下4個階段（Phaes）之一。
Available：可用狀態，還未與某個PVC綁定。
Bound：已與某個PVC綁定。
Released：綁定的PVC已經刪除，資源已釋放，但沒有被集群回收。
Failed：自動資源回收失敗。
58、簡述Kubernetes所支持的存儲供應模式?
Kubernetes支持兩種資源的存儲供應模式：靜態模式（Static）和動態模式（Dynamic）。
靜態模式：集群管理員手工創建許多PV，在定義PV時需要將后端存儲的特性進行設置。
動態模式：集群管理員無須手工創建PV，而是通過StorageClass的設置對后端存儲進行描述，標記為某種類型。此時要求PVC對存儲的類型進行聲明，系統將自動完成PV的創建及與PVC的綁定。
59、簡述Kubernetes CSI模型?
Kubernetes CSI是Kubernetes推出與容器對接的存儲接口標准，存儲提供方只需要基於標准接口進行存儲插件的實現，就能使用Kubernetes的原生存儲機制為容器提供存儲服務。CSI使得存儲提供方的代碼能和Kubernetes代碼徹底解耦，部署也與Kubernetes核心組件分離，顯然，存儲插件的開發由提供方自行維護，就能為Kubernetes用戶提供更多的存儲功能，也更加安全可靠。
CSI包括CSI Controller和CSI Node：
CSI Controller的主要功能是提供存儲服務視角對存儲資源和存儲卷進行管理和操作。
CSI Node的主要功能是對主機（Node）上的Volume進行管理和操作。
60、簡述Kubernetes Worker節點加入集群的過程?
通常需要對Worker節點進行擴容，從而將應用系統進行水平擴展。主要過程如下：
在該Node上安裝Docker、kubelet和kube-proxy服務； 然后配置kubelet和kubeproxy的啟動參數，將Master URL指定為當前Kubernetes集群Master的地址，最后啟動這些服務；
通過kubelet默認的自動注冊機制，新的Worker將會自動加入現有的Kubernetes集群中； Kubernetes Master在接受了新Worker的注冊之后，會自動將其納入當前集群的調度范圍。
61、簡述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的使用量也會增加。
62、簡述Kubernetes Requests和Limits如何影響Pod的調度?
當一個Pod創建成功時，Kubernetes調度器（Scheduler）會為該Pod選擇一個節點來執行。對於每種計算資源（CPU和Memory）而言，每個節點都有一個能用於運行Pod的最大容量值。調度器在調度時，首先要確保調度后該節點上所有Pod的CPU和內存的Requests總和，不超過該節點能提供給Pod使用的CPU和Memory的最大容量值。
63、簡述Kubernetes Metric Service?
在Kubernetes從1.10版本后采用Metrics Server作為默認的性能數據采集和監控，主要用於提供核心指標（Core Metrics），包括Node、Pod的CPU和內存使用指標。對其他自定義指標（Custom Metrics）的監控則由Prometheus等組件來完成。
64、簡述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目錄下的容器日志輸出。
65、簡述Kubernetes如何進行優雅的節點關機維護?
由於Kubernetes節點運行大量Pod，因此在進行關機維護之前，建議先使用kubectl drain將該節點的Pod進行驅逐，然后進行關機維護。
66、簡述Kubernetes集群聯邦?
Kubernetes集群聯邦可以將多個Kubernetes集群作為一個集群進行管理。因此，可以在一個數據中心/雲中創建多個Kubernetes集群，並使用集群聯邦在一個地方控制/管理所有集群。
67、簡述Helm及其優勢?
Helm 是 Kubernetes 的軟件包管理工具。類似 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一樣。
Helm能夠將一組K8S資源打包統一管理, 是查找、共享和使用為Kubernetes構建的軟件的最佳方式。 Helm中通常每個包稱為一個Chart，一個Chart是一個目錄（一般情況下會將目錄進行打包壓縮，形成name-version.tgz格式的單一文件，方便傳輸和存儲）。
Helm優勢
在 Kubernetes中部署一個可以使用的應用，需要涉及到很多的 Kubernetes 資源的共同協作。使用helm則具有如下優勢：
統一管理、配置和更新這些分散的 k8s 的應用資源文件；
分發和復用一套應用模板；
將應用的一系列資源當做一個軟件包管理。
對於應用發布者而言，可以通過 Helm 打包應用、管理應用依賴關系、管理應用版本並發布應用到軟件倉庫。
對於使用者而言，使用 Helm 后不用需要編寫復雜的應用部署文件，可以以簡單的方式在 Kubernetes 上查找、安裝、升級、回滾、卸載應用程序。
68、標簽與標簽選擇器的作用是什么?
標簽可以附加在kubernetes任何資源對象之上的鍵值型數據，常用於標簽選擇器的匹配度檢查，從而完成資源篩選
標簽選擇器用於表達標簽的查詢條件或選擇標准，Kubernetes API目前支持兩個選擇器：基於等值關系（equality-based）的標簽選項器以及基於集合關系（set-based）的標簽選擇器。
69、考慮一家擁有分布式系統的跨國公司，擁有大量數據中心，虛擬機和許多從事各種任務的員工。您認為這樣公司如何以與Kubernetes一致的方式管理所有任務?
答：正如我們所有人都知道IT部門推出了數千個容器，其任務在分布式系統中遍布全球眾多節點。
在這種情況下，公司可以使用能夠為基於雲的應用程序提供敏捷性，橫向擴展功能和DevOps實踐的東西。
因此，該公司可以使用Kubernetes來定制他們的調度架構並支持多種容器格式。這使得容器任務之間的親和性成為可能，從而提供更高的效率，並為各種容器網絡解決方案和容器存儲提供廣泛支持。
70、考慮一種情況，即公司希望通過維持最低成本來提高其效率和技術運營速度。您認為公司將如何實現這一目標?
答：公司可以通過構建CI/CD管道來實現DevOps方法，但是這里可能出現的一個問題是配置可能需要一段時間才能啟動並運行。因此，在實施CI/CD管道之后，公司的下一步應該是在雲環境中工作。一旦他們開始處理雲環境，他們就可以在集群上安排容器，並可以在Kubernetes的幫助下進行協調。這種方法將有助於公司縮短部署時間，並在各種環境中加快速度。
71、假設一家公司想要修改它的部署方法，並希望建立一個更具可擴展性和響應性的平台。您如何看待這家公司能夠實現這一目標以滿足客戶需求?
答：為了給數百萬客戶提供他們期望的數字體驗，公司需要一個可擴展且響應迅速的平台，以便他們能夠快速地將數據發送到客戶網站。現在，要做到這一點，公司應該從他們的私有數據中心（如果他們使用任何）轉移到任何雲環境，如AWS。不僅如此，他們還應該實現微服務架構，以便他們可以開始使用Docker容器。一旦他們准備好基礎框架，他們就可以開始使用最好的編排平台，即Kubernetes。這將使團隊能夠自主地構建應用程序並快速交付它們。
72、考慮一家擁有非常分散的系統的跨國公司，期待解決整體代碼庫問題。您認為公司如何解決他們的問題?
答：那么，為了解決這個問題，我們可以將他們的單片代碼庫轉移到微服務設計，然后每個微服務都可以被視為一個容器。因此，所有這些容器都可以在Kubernetes的幫助下進行部署和協調。
73、我們所有人都知道，從單片到微服務的轉變解決了開發方面的問題，但卻增加了部署方面的問題。公司如何解決部署方面的問題?
答：團隊可以試驗容器編排平台，例如Kubernetes，並在數據中心運行。因此，通過這種方式，公司可以生成模板化應用程序，在五分鍾內部署它，並在此時將實際實例集中在暫存環境中。這種Kubernetes項目將有數十個並行運行的微服務，以提高生產率，即使節點出現故障，也可以立即重新安排，而不會影響性能。
74、考慮一家拼車公司希望通過同時擴展其平台來增加服務器數量,公司如何有效地實現這種資源分配?
答：這個問題的解決方案就是Kubernetes。Kubernetes確保資源得到有效優化，並且只使用特定應用程序所需的那些資源。因此，通過使用最佳容器編排工具，公司可以有效地實現資源分配。
75、您認為公司如何處理服務器及其安裝?
答：公司可以采用集裝箱化的概念。一旦他們將所有應用程序部署到容器中，他們就可以使用Kubernetes進行編排，並使用像Prometheus這樣的容器監視工具來監視容器中的操作。因此，利用容器的這種使用，在數據中心中為它們提供更好的容量規划，因為它們現在將受到更少的限制，因為服務和它們運行的硬件之間存在抽象。
76、考慮一種情況，公司希望向具有各種環境的客戶提供所有必需的分發。您認為他們如何以動態的方式實現這一關鍵目標?
答：該公司可以使用Docker環境，組建一個橫截面團隊，使用Kubernetes構建Web應用程序。這種框架將幫助公司實現在最短的時間內將所需產品投入生產的目標。因此，在這樣的機器運行的情況下，公司可以向所有具有各種環境的客戶發放電子郵件。
77、假設公司希望在不同的雲基礎架構上運行各種工作負載，從裸機到公共雲。公司將如何在不同界面的存在下實現這一目標?
答：該公司可以將其基礎設施分解為微服務，然后采用Kubernetes。這將使公司在不同的雲基礎架構上運行各種工作負載。
78、什么是Google容器引擎?
Google Container Engine（GKE）是Docker容器和集群的開源管理平台。這個基於 Kubernetes的引擎僅支持在Google的公共雲服務中運行的群集。
79、您如何看待公司從單—服務轉向微服務並部署其服務容器?
由於公司的目標是從單一應用程序轉向微服務，它們最終可以逐個構建，並行構建，只需在后台切換配置。然后他們可以將這些內置微服務放在Kubernetes平台上。因此，他們可以從一次或兩次遷移服務開始，並監控它們以確保一切運行穩定。一旦他們覺得一切順利，他們就可以將其余的應用程序遷移到他們的Kubernetes集群中。
80、什么是Headless Service？
Headless Service類似於“普通”服務，但沒有群集IP。此服務使您可以直接訪問pod，而無需通過代理訪問它。