身為讓容器應用實作大規模工業生産的一大功臣，過去幾年，Kubernetes 勢頭迅猛，BAT、京東、美團、位元組都走上了全域容器化部署以及雲原生架構的康莊大道。
調查報告顯示，在 5000+ 的大型企業中，有超過 50% 的生産環境已經應用了 Kubernetes。程式員如果對 K8S 不夠熟悉，那在适配容器 IP、應用外部配置過程中勢必會難以下手，很容易和大廠優質的崗位擦肩而過。
今天分享一份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，而無需通過代理通路它。
![機器學習筆試、面試題 三[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)