26、簡述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在共享使用整個叢集的資源的同時還能被分別管理。

27、簡述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的伸縮動作。

28、簡述Kubernetes RC的機制？

Replication Controller用來管理Pod的副本，保證叢集中存在指定數量的Pod副本。當定義了RC並提交至Kubernetes叢集中之後，Master節點上的Controller Manager元件獲悉，並同時巡檢系統中當前存活的目標Pod，並確保目標Pod例項的數量剛好等於此RC的期望值，若存在過多的Pod副本在執行，系統會停止一些Pod，反之則自動建立一些Pod。

29、簡述Kubernetes Replica Set 和 Replication Controller 之間有什麼區別？

Replica Set 和 Replication Controller 類似，都是確保在任何給定時間執行指定數量的 Pod 副本。不同之處在於RS 使用基於集合的選擇器，而 Replication Controller 使用基於許可權的選擇器。

30、簡述kube-proxy作用？

kube-proxy 執行在所有節點上，它監聽 apiserver 中 service 和 endpoint 的變化情況，建立路由規則以提供服務 IP 和負載均衡功能。簡單理解此程序是Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉發到後端的多個Pod例項上。

31、簡述kube-proxy iptables原理？

Kubernetes從1.2版本開始，將iptables作為kube-proxy的預設模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch介面實時跟蹤Service與Endpoint的變更資訊，並更新對應的iptables規則，Client的請求流量則通過iptables的NAT機制“直接路由”到目標Pod。

32、簡述kube-proxy ipvs原理？

IPVS在Kubernetes1.11中升級為GA穩定版。IPVS則專門用於高效能負載均衡，並使用更高效的資料結構（Hash表），允許幾乎無限的規模擴張，因此被kube-proxy採納為最新模式。

在IPVS模式下，使用iptables的擴充套件ipset，而不是直接呼叫iptables來生成規則鏈。iptables規則鏈是一個線性的資料結構，ipset則引入了帶索引的資料結構，因此當規則很多時，也可以很高效地查詢和匹配。

可以將ipset簡單理解為一個IP（段）的集合，這個集合的內容可以是IP地址、IP網段、埠等，iptables可以直接新增規則對這個“可變的集合”進行操作，這樣做的好處在於可以大大減少iptables規則的數量，從而減少效能損耗。

33、簡述kube-proxy ipvs和iptables的異同？

iptables與IPVS都是基於Netfilter實現的，但因為定位不同，二者有著本質的差別：iptables是為防火牆而設計的；IPVS則專門用於高效能負載均衡，並使用更高效的資料結構（Hash表），允許幾乎無限的規模擴張。

與iptables相比，IPVS擁有以下明顯優勢：

• 為大型叢集提供了更好的可擴充套件性和效能；

• 支援比iptables更復雜的複製均衡演算法（最小負載、最少連線、加權等）；

• 支援伺服器健康檢查和連線重試等功能；

• 可以動態修改ipset的集合，即使iptables的規則正在使用這個集合。

34、簡述Kubernetes中什麼是靜態Pod？

靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行建立，並且總是在kubelet所在的Node上執行。

35、簡述Kubernetes中Pod可能位於的狀態？

• Pending：API Server已經建立該Pod，且Pod內還有一個或多個容器的映象沒有建立，包括正在下載映象的過程。

• Running：Pod內所有容器均已建立，且至少有一個容器處於執行狀態、正在啟動狀態或正在重啟狀態。

• Succeeded：Pod內所有容器均成功執行退出，且不會重啟。

• Failed：Pod內所有容器均已退出，但至少有一個容器退出為失敗狀態。

• Unknown：由於某種原因無法獲取該Pod狀態，可能由於網路通訊不暢導致。

36、簡述Kubernetes建立一個Pod的主要流程？

Kubernetes中建立一個Pod涉及多個元件之間聯動，主要流程如下：

1、客戶端提交Pod的配置資訊（可以是yaml檔案定義的資訊）到kube-apiserver。
2、Apiserver收到指令後，通知給controller-manager建立一個資源物件。
3、Controller-manager通過api-server將pod的配置資訊儲存到ETCD資料中心中。
4、Kube-scheduler檢測到pod資訊會開始排程預選，會先過濾掉不符合Pod資源配置要求的節點，然後開始排程調優，主要是挑選出更適合執行pod的節點，然後將pod的資源配置單傳送到node節點上的kubelet元件上。
5、Kubelet根據scheduler發來的資源配置單執行pod，執行成功後，將pod的執行資訊返回給scheduler，scheduler將返回的pod執行狀況的資訊儲存到etcd資料中心。

37、簡述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進行健康檢查。

38、簡述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掉。

39、簡述Kubernetes Pod的LivenessProbe探針的常見方式？

kubelet定期執行LivenessProbe探針來診斷容器的健康狀態，通常有以下三種方式：

• ExecAction：在容器內執行一個命令，若返回碼為0，則表明容器健康。

• TCPSocketAction：通過容器的IP地址和埠號執行TCP檢查，若能建立TCP連線，則表明容器健康。

• HTTPGetAction：通過容器的IP地址、埠號及路徑呼叫HTTP Get方法，若響應的狀態碼大於等於200且小於400，則表明容器健康。

40、簡述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。

41、簡述Kubernetes初始化容器（init container）？

init container的執行方式與應用容器不同，它們必須先於應用容器執行完成，當設定了多個init container時，將按順序逐個執行，並且只有前一個init container執行成功後才能執行後一個init container。當所有init container都成功執行後，Kubernetes才會初始化Pod的各種資訊，並開始建立和執行應用容器。

42、簡述Kubernetes deployment升級過程？

初始建立Deployment時，系統建立了一個ReplicaSet，並按使用者的需求建立了對應數量的Pod副本。

當更新Deployment時，系統建立了一個新的ReplicaSet，並將其副本數量擴充套件到1，然後將舊ReplicaSet縮減為2。

之後，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。

最後，新的ReplicaSet運行了對應個新版本Pod副本，舊的ReplicaSet副本數量則縮減為0。

43、簡述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）來控制滾動更新的過程。

44、簡述Kubernetes DaemonSet型別的資源特性？

DaemonSet資源物件會在每個Kubernetes叢集中的節點上執行，並且每個節點只能執行一個pod，這是它和deployment資源物件的最大也是唯一的區別。因此，在定義yaml檔案中，不支援定義replicas。

它的一般使用場景如下：

• 在去做每個節點的日誌收集工作。

• 監控每個節點的的執行狀態。

45、簡述Kubernetes自動擴容機制？

Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實現基於CPU使用率進行自動Pod擴縮容的功能。HPA控制器週期性地監測目標Pod的資源效能指標，並與HPA資源物件中的擴縮容條件進行對比，在滿足條件時對Pod副本數量進行調整。

HPA原理

Kubernetes中的某個Metrics Server（Heapster或自定義Metrics Server）持續採集所有Pod副本的指標資料。HPA控制器通過Metrics Server的API（Heapster的API或聚合API）獲取這些資料，基於使用者定義的擴縮容規則進行計算，得到目標Pod副本數量。

當目標Pod副本數量與當前副本數量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發起scale操作，調整Pod的副本數量，完成擴縮容操作。

46、簡述Kubernetes Service型別？

通過建立Service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求負載分發到後端的各個容器應用上。其主要型別有：

• ClusterIP：虛擬的服務IP地址，該地址用於Kubernetes叢集內部的Pod訪問，在Node上kube-proxy通過設定的iptables規則進行轉發；

• NodePort：使用宿主機的埠，使能夠訪問各Node的外部客戶端通過Node的IP地址和埠號就能訪問服務；

• LoadBalancer：使用外接負載均衡器完成到服務的負載分發，需要在spec.status.loadBalancer欄位指定外部負載均衡器的IP地址，通常用於公有云。

47、簡述Kubernetes Service分發後端的策略？

Service負載分發的策略有：RoundRobin和SessionAffinity

• RoundRobin：預設為輪詢模式，即輪詢將請求轉發到後端的各個Pod上。

• SessionAffinity：基於客戶端IP地址進行會話保持的模式，即第1次將某個客戶端發起的請求轉發到後端的某個Pod上，之後從相同的客戶端發起的請求都將被轉發到後端相同的Pod上。

48、簡述Kubernetes Headless Service？

在某些應用場景中，若需要人為指定負載均衡器，不使用Service提供的預設負載均衡的功能，或者應用程式希望知道屬於同組服務的其他例項。Kubernetes提供了Headless Service來實現這種功能，即不為Service設定ClusterIP（入口IP地址），僅通過Label Selector將後端的Pod列表返回給呼叫的客戶端。

49、簡述Kubernetes外部如何訪問叢集內的服務？

對於Kubernetes，叢集外的客戶端預設情況，無法通過Pod的IP地址或者Service的虛擬IP地址:虛擬埠號進行訪問。通常可以通過以下方式進行訪問Kubernetes叢集內的服務：

• 對映Pod到物理機：將Pod埠號對映到宿主機，即在Pod中採用hostPort方式，以使客戶端應用能夠通過物理機訪問容器應用。

• 對映Service到物理機：將Service埠號對映到宿主機，即在Service中採用nodePort方式，以使客戶端應用能夠通過物理機訪問容器應用。

• 對映Sercie到LoadBalancer：通過設定LoadBalancer對映到雲服務商提供的LoadBalancer地址。這種用法僅用於在公有云服務提供商的雲平臺上設定Service的場景。

50、簡述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提供的是對外服務，則實際上實現的是邊緣路由器的功能。

51、簡述Kubernetes映象的下載策略？

K8s的映象下載策略有三種：Always、Never、IFNotPresent。

• Always：映象標籤為latest時，總是從指定的倉庫中獲取映象。

• Never：禁止從倉庫中下載映象，也就是說只能使用本地映象。

• IfNotPresent：僅當本地沒有對應映象時，才從目標倉庫中下載。

預設的映象下載策略是：當映象標籤是latest時，預設策略是Always；當映象標籤是自定義時（也就是標籤不是latest），那麼預設策略是IfNotPresent。

52、簡述Kubernetes的負載均衡器？

負載均衡器是暴露服務的最常見和標準方式之一。

根據工作環境使用兩種型別的負載均衡器，即內部負載均衡器或外部負載均衡器。內部負載均衡器自動平衡負載並使用所需配置分配容器，而外部負載均衡器將流量從外部負載引導至後端容器。

53、簡述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繫結到目標節點上。

54、簡述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映象並啟動容器。

55、簡述Kubernetes Scheduler使用哪兩種演算法將Pod繫結到worker節點？

Kubernetes Scheduler根據如下兩種排程演算法將 Pod 繫結到最合適的工作節點：

• 預選（Predicates）：輸入是所有節點，輸出是滿足預選條件的節點。kube-scheduler根據預選策略過濾掉不滿足策略的Nodes。如果某節點的資源不足或者不滿足預選策略的條件則無法通過預選。如“Node的label必須與Pod的Selector一致”。

• 優選（Priorities）：輸入是預選階段篩選出的節點，優選會根據優先策略為通過預選的Nodes進行打分排名，選擇得分最高的Node。例如，資源越富裕、負載越小的Node可能具有越高的排名。

56、述Kubernetes kubelet的作用？

在Kubernetes叢集中，在每個Node（又稱Worker）上都會啟動一個kubelet服務程序。該程序用於處理Master下發到本節點的任務，管理Pod及Pod中的容器。每個kubelet程序都會在API Server上註冊節點自身的資訊，定期向Master彙報節點資源的使用情況，並通過cAdvisor監控容器和節點資源。

57、簡述Kubernetes kubelet監控Worker節點資源是使用什麼元件來實現的？

kubelet使用cAdvisor對worker節點資源進行監控。在 Kubernetes 系統中，cAdvisor 已被預設整合到 kubelet 元件內，當 kubelet 服務啟動時，它會自動啟動 cAdvisor 服務，然後 cAdvisor 會實時採集所在節點的效能指標及在節點上執行的容器的效能指標。

58、簡述Kubernetes如何保證叢集的安全性？

Kubernetes通過一系列機制來實現叢集的安全控制，主要有如下不同的維度：

基礎設施方面：保證容器與其所在宿主機的隔離；

許可權方面：

• 最小許可權原則：合理限制所有元件的許可權，確保元件只執行它被授權的行為，通過限制單個元件的能力來限制它的許可權範圍。

• 使用者許可權：劃分普通使用者和管理員的角色。

叢集方面：

• API Server的認證授權：Kubernetes叢集中所有資源的訪問和變更都是通過Kubernetes API Server來實現的，因此需要建議採用更安全的HTTPS或Token來識別和認證客戶端身份（Authentication），以及隨後訪問許可權的授權（Authorization）環節。

• API Server的授權管理：通過授權策略來決定一個API呼叫是否合法。對合法使用者進行授權並且隨後在使用者訪問時進行鑑權，建議採用更安全的RBAC方式來提升叢集安全授權。

• 敏感資料引入Secret機制：對於叢集敏感資料建議使用Secret方式進行保護。

• AdmissionControl（准入機制）：對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然後執行准入操作，最後對目標物件進行操作。

59、簡述Kubernetes准入機制？

在對叢集進行請求時，每個准入控制程式碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求，那麼整個請求的結果將會立即返回，並提示使用者相應的error資訊。

准入控制（AdmissionControl）准入控制本質上為一段准入程式碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然後執行准入操作，最後對目標物件進行操作。常用元件（控制程式碼）如下：

• AlwaysAdmit：允許所有請求

• AlwaysDeny：禁止所有請求，多用於測試環境。

• ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動新增一個default，並確保pod的serviceAccount始終存在。

• LimitRanger：觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange物件中。

• NamespaceExists：觀察所有的請求，如果請求嘗試建立一個不存在的namespace，則這個請求被拒絕。

60、簡述Kubernetes RBAC及其特點（優勢）？

RBAC是基於角色的訪問控制，是一種基於個人使用者的角色來管理對計算機或網路資源的訪問的方法。

相對於其他授權模式，RBAC具有如下優勢：

• 對叢集中的資源和非資源許可權均有完整的覆蓋。

• 整個RBAC完全由幾個API物件完成， 同其他API物件一樣， 可以用kubectl或API進行操作。

• 可以在執行時進行調整，無須重新啟動API Server。

61、簡述Kubernetes Secret作用？

Secret物件，主要作用是保管私密資料，比如密碼、OAuth Tokens、SSH Keys等資訊。將這些私密資訊放在Secret物件中比直接放在Pod或Docker Image中更安全，也更便於使用和分發。

62、簡述Kubernetes Secret有哪些使用方式？

建立完secret之後，可通過如下三種方式使用：

• 在建立Pod時，通過為Pod指定Service Account來自動使用該Secret。

• 通過掛載該Secret到Pod來使用它。

• 在Docker映象下載時使用，通過指定Pod的spc.ImagePullSecrets來引用它。

63、簡述Kubernetes PodSecurityPolicy機制？

Kubernetes PodSecurityPolicy是為了更精細地控制Pod對資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy准入控制器後，Kubernetes預設不允許建立任何Pod，需要建立PodSecurityPolicy策略和相應的RBAC授權策略（Authorizing Policies），Pod才能建立成功。

64、簡述Kubernetes PodSecurityPolicy機制能實現哪些安全策略？

在PodSecurityPolicy物件中可以設定不同欄位來控制Pod執行時的各種安全策略，常見的有：

• 特權模式：privileged是否允許Pod以特權模式執行。

• 宿主機資源：控制Pod對宿主機資源的控制，如hostPID：是否允許Pod共享宿主機的程序空間。

• 使用者和組：設定執行容器的使用者ID（範圍）或組（範圍）。

• 提升許可權：AllowPrivilegeEscalation：設定容器內的子程序是否可以提升許可權，通常在設定非root使用者（MustRunAsNonRoot）時進行設定。

• SELinux：進行SELinux的相關配置。

65、簡述Kubernetes網路模型？

Kubernetes網路模型中每個Pod都擁有一個獨立的IP地址，並假定所有Pod都在一個可以直接連通的、扁平的網路空間中。所以不管它們是否執行在同一個Node（宿主機）中，都要求它們可以直接通過對方的IP進行訪問。設計這個原則的原因是，使用者不需要額外考慮如何建立Pod之間的連線，也不需要考慮如何將容器埠對映到主機埠等問題。

同時為每個Pod都設定一個IP地址的模型使得同一個Pod內的不同容器會共享同一個網路名稱空間，也就是同一個Linux網路協議棧。這就意味著同一個Pod內的容器可以通過localhost來連線對方的埠。

在Kubernetes的叢集裡，IP是以Pod為單位進行分配的。一個Pod內部的所有容器共享一個網路堆疊（相當於一個網路名稱空間，它們的IP地址、網路裝置、配置等都是共享的）。

66、簡述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協同工作。

67、簡述Kubernetes網路策略？

為實現細粒度的容器間網路訪問隔離策略，Kubernetes引入Network Policy。

Network Policy的主要功能是對Pod間的網路通訊進行限制和准入控制，設定允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網路策略，配合策略控制器（Policy Controller）進行策略的實現。

68、簡述Kubernetes網路策略原理？

Network Policy的工作原理主要為：policy controller需要實現一個API Listener，監聽使用者設定的Network Policy定義，並將網路訪問規則通過各Node的Agent進行實際設定（Agent則需要通過CNI網路外掛實現）。

69、簡述Kubernetes中flannel的作用？

Flannel可以用於Kubernetes底層網路的實現，主要作用有：

• 它能協助Kubernetes，給每一個Node上的Docker容器都分配互相不衝突的IP地址。

• 它能在這些IP地址之間建立一個覆蓋網路（Overlay Network），通過這個覆蓋網路，將資料包原封不動地傳遞到目標容器內。

70、簡述Kubernetes Calico網路元件實現原理？

Calico是一個基於BGP的純三層的網路方案，與OpenStack、Kubernetes、AWS、GCE等雲平臺都能夠良好地整合。

Calico在每個計算節點都利用Linux Kernel實現了一個高效的vRouter來負責資料轉發。每個vRouter都通過BGP協議把在本節點上執行的容器的路由資訊向整個Calico網路廣播，並自動設定到達其他節點的路由轉發規則。

Calico保證所有容器之間的資料流量都是通過IP路由的方式完成互聯互通的。Calico節點組網時可以直接利用資料中心的網路結構（L2或者L3），不需要額外的NAT、隧道或者Overlay Network，沒有額外的封包解包，能夠節約CPU運算，提高網路效率。

71、簡述Kubernetes共享儲存的作用？

Kubernetes對於有狀態的容器應用或者對資料需要持久化的應用，因此需要更加可靠的儲存來儲存應用產生的重要資料，以便容器應用在重建之後仍然可以使用之前的資料。因此需要使用共享儲存。

72、簡述Kubernetes資料持久化的方式有哪些？

Kubernetes通過資料持久化來持久化儲存重要資料，常見的方式有：

EmptyDir（空目錄）：沒有指定要掛載宿主機上的某個目錄，直接由Pod內保部對映到宿主機上。類似於docker中的manager volume。

場景：

• 只需要臨時將資料儲存在磁碟上，比如在合併/排序演算法中；

• 作為兩個容器的共享儲存。

特性：

• 同個pod裡面的不同容器，共享同一個持久化目錄，當pod節點刪除時，volume的資料也會被刪除。

• emptyDir的資料持久化的生命週期和使用的pod一致，一般是作為臨時儲存使用。

Hostpath：將宿主機上已存在的目錄或檔案掛載到容器內部。類似於docker中的bind mount掛載方式。

特性：增加了pod與節點之間的耦合。

PersistentVolume（簡稱PV）：如基於NFS服務的PV，也可以基於GFS的PV。它的作用是統一資料持久化目錄，方便管理。

73、簡述Kubernetes PV和PVC？

PV是對底層網路共享儲存的抽象，將共享儲存定義為一種“資源”。

PVC則是使用者對儲存資源的一個“申請”。

74、簡述Kubernetes PV生命週期內的階段？

某個PV在生命週期中可能處於以下4個階段（Phaes）之一。

• Available：可用狀態，還未與某個PVC繫結。

• Bound：已與某個PVC繫結。

• Released：繫結的PVC已經刪除，資源已釋放，但沒有被叢集回收。

• Failed：自動資源回收失敗。

75、簡述Kubernetes所支援的儲存供應模式？

Kubernetes支援兩種資源的儲存供應模式：靜態模式（Static）和動態模式（Dynamic）。

• 靜態模式：叢集管理員手工建立許多PV，在定義PV時需要將後端儲存的特性進行設定。

• 動態模式：叢集管理員無須手工建立PV，而是通過StorageClass的設定對後端儲存進行描述，標記為某種型別。此時要求PVC對儲存的型別進行宣告，系統將自動完成PV的建立及與PVC的繫結。

76、簡述Kubernetes CSI模型？

Kubernetes CSI是Kubernetes推出與容器對接的儲存介面標準，儲存提供方只需要基於標準介面進行儲存外掛的實現，就能使用Kubernetes的原生儲存機制為容器提供儲存服務。CSI使得儲存提供方的程式碼能和Kubernetes程式碼徹底解耦，部署也與Kubernetes核心元件分離，顯然，儲存外掛的開發由提供方自行維護，就能為Kubernetes使用者提供更多的儲存功能，也更加安全可靠。

CSI包括CSI Controller和CSI Node：

• CSI Controller的主要功能是提供儲存服務視角對儲存資源和儲存捲進行管理和操作。

• CSI Node的主要功能是對主機（Node）上的Volume進行管理和操作。

77、簡述Kubernetes Worker節點加入叢集的過程？

通常需要對Worker節點進行擴容，從而將應用系統進行水平擴充套件。主要過程如下：

1、在該Node上安裝Docker、kubelet和kube-proxy服務；
2、然後配置kubelet和kubeproxy的啟動引數，將Master URL指定為當前Kubernetes叢集Master的地址，最後啟動這些服務；
3、通過kubelet預設的自動註冊機制，新的Worker將會自動加入現有的Kubernetes叢集中；
4、Kubernetes Master在接受了新Worker的註冊之後，會自動將其納入當前叢集的排程範圍。

78、簡述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的使用量也會增加。

79、簡述Kubernetes Requests和Limits如何影響Pod的排程？

當一個Pod建立成功時，Kubernetes排程器（Scheduler）會為該Pod選擇一個節點來執行。對於每種計算資源（CPU和Memory）而言，每個節點都有一個能用於執行Pod的最大容量值。排程器在排程時，首先要確保排程後該節點上所有Pod的CPU和記憶體的Requests總和，不超過該節點能提供給Pod使用的CPU和Memory的最大容量值。

80、簡述Kubernetes Metric Service？

在Kubernetes從1.10版本後採用Metrics Server作為預設的效能資料採集和監控，主要用於提供核心指標（Core Metrics），包括Node、Pod的CPU和記憶體使用指標。對其他自定義指標（Custom Metrics）的監控則由Prometheus等元件來完成。

81、簡述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目錄下的容器日誌輸出。

82、簡述Kubernetes如何進行優雅的節點關機維護？

由於Kubernetes節點執行大量Pod，因此在進行關機維護之前，建議先使用kubectl drain將該節點的Pod進行驅逐，然後進行關機維護。

83、簡述Kubernetes叢集聯邦？

Kubernetes叢集聯邦可以將多個Kubernetes叢集作為一個叢集進行管理。因此，可以在一個數據中心/雲中建立多個Kubernetes叢集，並使用叢集聯邦在一個地方控制/管理所有叢集。

84、簡述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 上查詢、安裝、升級、回滾、解除安裝應用程式。

85、簡述OpenShift及其特性？

OpenShift是一個容器應用程式平臺，用於在安全的、可伸縮的資源上部署新應用程式，而配置和管理開銷最小。

OpenShift構建於Red Hat Enterprise Linux、Docker和Kubernetes之上，為企業級應用程式提供了一個安全且可伸縮的多租戶作業系統，同時還提供了整合的應用程式執行時和庫。

其主要特性：

• 自助服務平臺：OpenShift允許開發人員使用Source-to-Image(S2I)從模板或自己的原始碼管理儲存庫建立應用程式。系統管理員可以為使用者和專案定義資源配額和限制，以控制系統資源的使用。

• 多語言支援：OpenShift支援Java、Node.js、PHP、Perl以及直接來自Red Hat的Ruby。OpenShift還支援中介軟體產品，如Apache httpd、Apache Tomcat、JBoss EAP、ActiveMQ和Fuse。

• 自動化：OpenShift提供應用程式生命週期管理功能，當上遊源或容器映像發生更改時，可以自動重新構建和重新部署容器。根據排程和策略擴充套件或故障轉移應用程式。

• 使用者介面：OpenShift提供用於部署和監視應用程式的web UI，以及用於遠端管理應用程式和資源的CLi。

• 協作：OpenShift允許在組織內或與更大的社群共享專案。

• 可伸縮性和高可用性：OpenShift提供了容器多租戶和一個分散式應用程式平臺，其中包括彈性，高可用性，以便應用程式能夠在物理機器宕機等事件中存活下來。OpenShift提供了對容器健康狀況的自動發現和自動重新部署。

• 容器可移植性：在OpenShift中，應用程式和服務使用標準容器映像進行打包，組合應用程式使用Kubernetes進行管理。這些映像可以部署到基於這些基礎技術的其他平臺上。

• 開源：沒有廠商鎖定。

• 安全性：OpenShift使用SELinux提供多層安全性、基於角色的訪問控制以及與外部身份驗證系統(如LDAP和OAuth)整合的能力。

• 動態儲存管理：OpenShift使用Kubernetes持久卷和持久卷宣告的方式為容器資料提供靜態和動態儲存管理

• 基於雲(或不基於雲)：可以在裸機伺服器、活來自多個供應商的hypervisor和大多數IaaS雲提供商上部署OpenShift容器平臺。

• 企業級：Red Hat支援OpenShift、選定的容器映像和應用程式執行時。可信的第三方容器映像、執行時和應用程式由Red Hat認證。可以在OpenShift提供的高可用性的強化安全環境中執行內部或第三方應用程式。

• 日誌聚合和metrics：可以在中心節點收集、聚合和分析部署在OpenShift上的應用程式的日誌資訊。OpenShift能夠實時收集關於應用程式的度量和執行時資訊，並幫助不斷優化效能。

• 其他特性：OpenShift支援微服務體系結構，OpenShift的本地特性足以支援DevOps流程，很容易與標準和定製的持續整合/持續部署工具整合。

86、簡述OpenShift projects及其作用？

OpenShift管理projects和users。一個projects對Kubernetes資源進行分組，以便使用者可以使用訪問許可權。還可以為projects分配配額，從而限制了已定義的pod、volumes、services和其他資源。

project允許一組使用者獨立於其他組組織和管理其內容，必須允許使用者訪問專案。如果允許建立專案，使用者將自動訪問自己的專案。

87、簡述OpenShift高可用的實現？

OpenShift平臺叢集的高可用性(HA)有兩個不同的方面：

OpenShift基礎設施本身的HA(即主機)；

以及在OpenShift叢集中執行的應用程式的HA。

預設情況下，OpenShift為master節點提供了完全支援的本機HA機制。

對於應用程式或“pods”，如果pod因任何原因丟失，Kubernetes將排程另一個副本，將其連線到服務層和持久儲存。如果整個節點丟失，Kubernetes會為它所有的pod安排替換節點，最終所有的應用程式都會重新可用。pod中的應用程式負責它們自己的狀態，因此它們需要自己維護應用程式狀態(如HTTP會話複製或資料庫複製)。

88、簡述OpenShift的SDN網路實現？

預設情況下，Docker網路使用僅使用主機虛機網橋bridge，主機內的所有容器都連線至該網橋。連線到此橋的所有容器都可以彼此通訊，但不能與不同主機上的容器通訊。

為了支援跨叢集的容器之間的通訊，OpenShift容器平臺使用了軟體定義的網路(SDN)方法。軟體定義的網路是一種網路模型，它通過幾個網路層的抽象來管理網路服務。SDN將處理流量的軟體(稱為控制平面)和路由流量的底層機制(稱為資料平面)解耦。SDN支援控制平面和資料平面之間的通訊。

在OpenShift中，可以為pod網路配置三個SDN外掛:

• ovs-subnet：預設外掛，子網提供了一個flat pod網路，其中每個pod可以與其他pod和service通訊。

• ovs-multitenant：該為pod和服務提供了額外的隔離層。當使用此外掛時，每個project接收一個惟一的虛擬網路ID (VNID)，該ID標識來自屬於該project的pod的流量。通過使用VNID，來自不同project的pod不能與其他project的pod和service通訊。

• ovs-network policy：此外掛允許管理員使用NetworkPolicy物件定義自己的隔離策略。
  cluster network由OpenShift SDN建立和維護，它使用Open vSwitch建立overlay網路，master節點不能通過叢集網路訪問容器，除非master同時也為node節點。

89、簡述OpenShift角色及其作用？

OpenShift的角色具有不同級別的訪問和策略，包括叢集和本地策略。user和group可以同時與多個role關聯。

90、簡述OpenShift支援哪些身份驗證？

OpenShift容器平臺支援的其他認證型別包括:

• Basic Authentication (Remote)：一種通用的後端整合機制，允許使用者使用針對遠端標識提供者驗證的憑據登入到OpenShift容器平臺。使用者將他們的使用者名稱和密碼傳送到OpenShift容器平臺，OpenShift平臺通過到伺服器的請求驗證這些憑據，並將憑據作為基本的Auth頭傳遞。這要求使用者在登入過程中向OpenShift容器平臺輸入他們的憑據。

• Request Header Authentication：使用者使用請求頭值(如X-RemoteUser)登入到OpenShift容器平臺。它通常與身份驗證代理結合使用，身份驗證代理對使用者進行身份驗證，然後通過請求頭值為OpenShift容器平臺提供使用者標識。

• Keystone Authentication：Keystone是一個OpenStack專案，提供標識、令牌、目錄和策略服務。OpenShift容器平臺與Keystone整合，通過配置OpenStack Keystone v3伺服器將使用者儲存在內部資料庫中，從而支援共享身份驗證。這種配置允許使用者使用Keystone憑證登入OpenShift容器平臺。

• LDAP Authentication：使用者使用他們的LDAP憑證登入到OpenShift容器平臺。在身份驗證期間，LDAP目錄將搜尋與提供的使用者名稱匹配的條目。如果找到匹配項，則嘗試使用條目的專有名稱(DN)和提供的密碼進行簡單繫結。

• GitHub Authentication：GitHub使用OAuth，它允許與OpenShift容器平臺整合使用OAuth身份驗證來促進令牌交換流。這允許使用者使用他們的GitHub憑證登入到OpenShift容器平臺。為了防止使用GitHub使用者id的未授權使用者登入到OpenShift容器平臺叢集，可以將訪問許可權限制在特定的GitHub組織中。

91、簡述什麼是中介軟體？

中介軟體是一種獨立的系統軟體或服務程式，分散式應用軟體藉助這種軟體在不同的技術之間共享資源。通常位於客戶機/ 伺服器的作業系統中間，是連線兩個獨立應用程式或獨立系統的軟體。

通過中介軟體實現兩個不同系統之間的資訊交換。

作者：木二
連結：http://www.yuque.com/docs/share/d3dd1e8e-6828-4da7-9e30-6a4f45c6fa8e