超詳細！k8s 面試題總結

時間 2021-05-15

標籤 node 算法 docker 數據庫後端 api 安全服務器網絡數據結構欄目快樂工作简体版

原文原文鏈接

簡述ETCD及其特色？

etcd 是 CoreOS 團隊發起的開源項目，是一個管理配置信息和服務發現（service discovery）的項目，它的目標是構建一個高可用的分佈式鍵值（key-value）數據庫，基於 Go 語言實現。node

特色：
簡單：支持 REST 風格的 HTTP+JSON API
安全：支持 HTTPS 方式的訪問
快速：支持併發 1k/s 的寫操做
可靠：支持分佈式結構，基於 Raft 的一致性算法，Raft 是一套經過選舉主節點來實現分佈式系統一致性的算法。

簡述ETCD適應的場景？

etcd基於其優秀的特色，可普遍的應用於如下場景：算法

服務發現(Service Discovery)：服務發現主要解決在同一個分佈式集羣中的進程或服務，要如何才能找到對方並創建鏈接。本質上來講，服務發現就是想要了解集羣中是否有進程在監聽udp或tcp端口，而且經過名字就能夠查找和鏈接。docker

消息發佈與訂閱：在分佈式系統中，最適用的一種組件間通訊方式就是消息發佈與訂閱。即構建一個配置共享中心，數據提供者在這個配置中心發佈消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息發佈，就會實時通知訂閱者。經過這種方式能夠作到分佈式系統配置的集中式管理與動態更新。應用中用到的一些配置信息放到etcd上進行集中管理。數據庫

負載均衡：在分佈式系統中，爲了保證服務的高可用以及數據的一致性，一般都會把數據和服務部署多份，以此達到對等服務，即便其中的某一個服務失效了，也不影響使用。etcd自己分佈式架構存儲的信息訪問支持負載均衡。etcd集羣化之後，每一個etcd的核心節點均可以處理用戶的請求。因此，把數據量小可是訪問頻繁的消息數據直接存儲到etcd中也能夠實現負載均衡的效果。後端

分佈式通知與協調：與消息發佈和訂閱相似，都用到了etcd中的Watcher機制，經過註冊與異步通知機制，實現分佈式環境下不一樣系統之間的通知與協調，從而對數據變動作到實時處理。api

分佈式鎖：由於etcd使用Raft算法保持了數據的強一致性，某次操做存儲到集羣中的值必然是全局一致的，因此很容易實現分佈式鎖。鎖服務有兩種使用方式，一是保持獨佔，二是控制時序。安全

集羣監控與Leader競選：經過etcd來進行監控實現起來很是簡單而且實時性強。服務器

簡述什麼是Kubernetes？

Kubernetes是一個全新的基於容器技術的分佈式系統支撐平臺。是Google開源的容器集羣管理系統（谷歌內部:Borg）。在Docker技術的基礎上，爲容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提升了大規模容器集羣管理的便捷性。而且具備完備的集羣管理能力，多層次的安全防禦和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。網絡

簡述Kubernetes和Docker的關係？

Docker 提供容器的生命週期管理和，Docker 鏡像構建運行時容器。它的主要優勢是將將軟件/應用程序運行所需的設置和依賴項打包到一個容器中，從而實現了可移植性等優勢。數據結構

Kubernetes 用於關聯和編排在多個主機上運行的容器。

簡述Kubernetes中什麼是Minikube、Kubectl、Kubelet？

Minikube 是一種能夠在本地輕鬆運行一個單節點 Kubernetes 羣集的工具。

Kubectl 是一個命令行工具，可使用該工具控制Kubernetes集羣管理器，如檢查羣集資源，建立、刪除和更新組件，查看應用程序。

Kubelet 是一個代理服務，它在每一個節點上運行，並使從服務器與主服務器通訊。

簡述Kubernetes常見的部署方式？

常見的Kubernetes部署方式有：

kubeadm：也是推薦的一種部署方式；
二進制：CentOS 搭建 K8S，一次性成功，收藏了！
minikube：在本地輕鬆運行一個單節點 Kubernetes 羣集的工具。
簡單幾步，無坑部署最小化 K8S 集羣
Kubernetes 部署如此簡單，看徹底明白了

簡述Kubernetes如何實現集羣管理？

在集羣管理方面，Kubernetes將集羣中的機器劃分爲一個Master節點和一羣工做節點Node。其中，在Master節點運行着集羣管理相關的一組進程kube-apiserver、kube-controller-manager和kube-scheduler，這些進程實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理能力，而且都是全自動完成的。推薦你們看看：輕鬆管理 Kubernetes 集羣的7個工具。

簡述Kubernetes的優點、適應場景及其特色？

Kubernetes做爲一個完備的分佈式系統支撐平臺，其主要優點：

容器編排
輕量級
開源
彈性伸縮
負載均衡

Kubernetes常見場景：

快速部署應用
快速擴展應用
無縫對接新的應用功能
節省資源，優化硬件資源的使用

Kubernetes相關特色：

可移植: 支持公有云、私有云、混合雲、多重雲（multi-cloud）。
可擴展: 模塊化,、插件化、可掛載、可組合。
自動化: 自動部署、自動重啓、自動複製、自動伸縮/擴展。

簡述Kubernetes的缺點或當前的不足之處？

Kubernetes當前存在的缺點（不足）以下：

安裝過程和配置相對困難複雜。
管理服務相對繁瑣。
運行和編譯須要不少時間。
它比其餘替代品更昂貴。
對於簡單的應用程序來講，可能不須要涉及Kubernetes便可知足。

簡述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節點上，若干相關容器的組合(Kubernetes 之 Pod 實現原理)。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(Kubernetes 之服務發現)定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，用戶不須要了解後臺Pod是如何運行。

Volume：Volume是Pod中可以被多個容器訪問的共享目錄，Kubernetes中的Volume是定義在Pod上，能夠被一個或多個Pod中的容器掛載到某個目錄下。

Namespace：Namespace用於實現多租戶的資源隔離，可將集羣內部的資源對象分配到不一樣的Namespace中，造成邏輯上的不一樣項目、小組或用戶組，便於不一樣的Namespace在共享使用整個集羣的資源的同時還能被分別管理。

簡述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的伸縮動做。

簡述Kubernetes RC的機制？

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

簡述Kubernetes Replica Set 和 Replication Controller 之間有什麼區別？Replica Set 和 Replication Controller 相似，都是確保在任何給定時間運行指定數量的 Pod 副本。不一樣之處在於RS 使用基於集合的選擇器，而 Replication Controller 使用基於權限的選擇器。

簡述kube-proxy做用？

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

簡述kube-proxy iptables原理？

Kubernetes從1.2版本開始，將iptables做爲kube-proxy的默認模式。iptables模式下的kube-proxy再也不起到Proxy的做用，其核心功能：經過API Server的Watch接口實時跟蹤Service與Endpoint的變動信息，並更新對應的iptables規則，Client的請求流量則經過iptables的NAT機制「直接路由」到目標Pod。

簡述kube-proxy ipvs原理？

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

在IPVS模式下，使用iptables的擴展ipset，而不是直接調用iptables來生成規則鏈。iptables規則鏈是一個線性的數據結構，ipset則引入了帶索引的數據結構，所以當規則不少時，也能夠很高效地查找和匹配。

能夠將ipset簡單理解爲一個IP（段）的集合，這個集合的內容能夠是IP地址、IP網段、端口等，iptables能夠直接添加規則對這個「可變的集合」進行操做，這樣作的好處在於能夠大大減小iptables規則的數量，從而減小性能損耗。

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

iptables與IPVS都是基於Netfilter實現的，但由於定位不一樣，兩者有着本質的差異：iptables是爲防火牆而設計的；IPVS則專門用於高性能負載均衡，並使用更高效的數據結構（Hash表），容許幾乎無限的規模擴張。

與iptables相比，IPVS擁有如下明顯優點：

一、爲大型集羣提供了更好的可擴展性和性能；
二、支持比iptables更復雜的複製均衡算法（最小負載、最少鏈接、加權等）；
三、支持服務器健康檢查和鏈接重試等功能；
四、能夠動態修改ipset的集合，即便iptables的規則正在使用這個集合。

簡述Kubernetes中什麼是靜態Pod？

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

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

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

Running：Pod內全部容器均已建立，且至少有一個容器處於運行狀態、正在啓動狀態或正在重啓狀態。

Succeeded：Pod內全部容器均成功執行退出，且不會重啓。

Failed：Pod內全部容器均已退出，但至少有一個容器退出爲失敗狀態。

Unknown：因爲某種緣由沒法獲取該Pod狀態，可能因爲網絡通訊不順暢致使。

簡述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數據中心。

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

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

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

kubelet按期執行LivenessProbe探針來診斷容器的健康狀態，一般有如下三種方式：

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

TCPSocketAction：經過容器的IP地址和端口號執行TCP檢查，若能創建TCP鏈接，則代表容器健康。

HTTPGetAction：經過容器的IP地址、端口號及路徑調用HTTP Get方法，若響應的狀態碼大於等於200且小於400，則代表容器健康。

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

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

init container的運行方式與應用容器不一樣，它們必須先於應用容器執行完成，當設置了多個init container時，將按順序逐個運行，而且只有前一個init container運行成功後才能運行後一個init container。當全部init container都成功運行後，Kubernetes纔會初始化Pod的各類信息，並開始建立和運行應用容器。

簡述Kubernetes deployment升級過程？

初始建立Deployment時，系統建立了一個ReplicaSet，並按用戶的需求建立了對應數量的Pod副本。
當更新Deployment時，系統建立了一個新的ReplicaSet，並將其副本數量擴展到1，而後將舊ReplicaSet縮減爲2。
以後，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。
最後，新的ReplicaSet運行了對應個新版本Pod副本，舊的ReplicaSet副本數量則縮減爲0。

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

簡述Kubernetes DaemonSet類型的資源特性？

DaemonSet資源對象會在每一個Kubernetes集羣中的節點上運行，而且每一個節點只能運行一個pod，這是它和deployment資源對象的最大也是惟一的區別。所以，在定義yaml文件中，不支持定義replicas。

它的通常使用場景以下：

在去作每一個節點的日誌收集工做。
監控每一個節點的的運行狀態。

簡述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的副本數量，完成擴縮容操做。

簡述Kubernetes Service類型？

經過建立Service，能夠爲一組具備相同功能的容器應用提供一個統一的入口地址，而且將請求負載分發到後端的各個容器應用上。其主要類型有：

ClusterIP：虛擬的服務IP地址，該地址用於Kubernetes集羣內部的Pod訪問，在Node上kube-proxy經過設置的iptables規則進行轉發；
NodePort：使用宿主機的端口，使可以訪問各Node的外部客戶端經過Node的IP地址和端口號就能訪問服務；
LoadBalancer：使用外接負載均衡器完成到服務的負載分發，須要在spec.status.loadBalancer字段指定外部負載均衡器的IP地址，一般用於公有云。

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

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

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

簡述Kubernetes Headless Service？

在某些應用場景中，若須要人爲指定負載均衡器，不使用Service提供的默認負載均衡的功能，或者應用程序但願知道屬於同組服務的其餘實例。Kubernetes提供了Headless Service來實現這種功能，即不爲Service設置ClusterIP（入口IP地址），僅經過Label Selector將後端的Pod列表返回給調用的客戶端。

簡述Kubernetes外部如何訪問集羣內的服務？

對於Kubernetes，集羣外的客戶端默認狀況，沒法經過Pod的IP地址或者Service的虛擬IP地址:虛擬端口號進行訪問。一般能夠經過如下方式進行訪問Kubernetes集羣內的服務：

映射Pod到物理機：將Pod端口號映射到宿主機，即在Pod中採用hostPort方式，以使客戶端應用可以經過物理機訪問容器應用。

映射Service到物理機：將Service端口號映射到宿主機，即在Service中採用nodePort方式，以使客戶端應用可以經過物理機訪問容器應用。

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

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

簡述Kubernetes鏡像的下載策略？

K8s的鏡像下載策略有三種：Always、Never、IFNotPresent。

Always：鏡像標籤爲latest時，老是從指定的倉庫中獲取鏡像。
Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。
IfNotPresent：僅當本地沒有對應鏡像時，才從目標倉庫中下載。默認的鏡像下載策略是：當鏡像標籤是latest時，默認策略是Always；當鏡像標籤是自定義時（也就是標籤不是latest），那麼默認策略是IfNotPresent。

簡述Kubernetes的負載均衡器？

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

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

簡述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綁定到目標節點上。

簡述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鏡像並啓動容器。

簡述Kubernetes Scheduler使用哪兩種算法將Pod綁定到worker節點？

Kubernetes Scheduler根據以下兩種調度算法將 Pod 綁定到最合適的工做節點：

預選（Predicates）：輸入是全部節點，輸出是知足預選條件的節點。kube-scheduler根據預選策略過濾掉不知足策略的Nodes。若是某節點的資源不足或者不知足預選策略的條件則沒法經過預選。如「Node的label必須與Pod的Selector一致」。

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

簡述Kubernetes kubelet的做用？

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

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

kubelet使用cAdvisor對worker節點資源進行監控。在 Kubernetes 系統中，cAdvisor 已被默認集成到 kubelet 組件內，當 kubelet 服務啓動時，它會自動啓動 cAdvisor 服務，而後 cAdvisor 會實時採集所在節點的性能指標及在節點上運行的容器的性能指標。

簡述Kubernetes如何保證集羣的安全性？

Kubernetes經過一系列機制來實現集羣的安全控制，主要有以下不一樣的維度：

基礎設施方面：保證容器與其所在宿主機的隔離；
權限方面：
最小權限原則：合理限制全部組件的權限，確保組件只執行它被受權的行爲，經過限制單個組件的能力來限制它的權限範圍。
用戶權限：劃分普通用戶和管理員的角色。
集羣方面：
API Server的認證受權：Kubernetes集羣中全部資源的訪問和變動都是經過Kubernetes API Server來實現的，所以須要建議採用更安全的HTTPS或Token來識別和認證客戶端身份（Authentication），以及隨後訪問權限的受權（Authorization）環節。
API Server的受權管理：經過受權策略來決定一個API調用是否合法。對合法用戶進行受權而且隨後在用戶訪問時進行鑑權，建議採用更安全的RBAC方式來提高集羣安全受權。
敏感數據引入Secret機制：對於集羣敏感數據建議使用Secret方式進行保護。
AdmissionControl（准入機制）：對kubernetes api的請求過程當中，順序爲：先通過認證 & 受權，而後執行准入操做，最後對目標對象進行操做。

簡述Kubernetes准入機制？

在對集羣進行請求時，每一個准入控制代碼都按照必定順序執行。若是有一個准入控制拒絕了這次請求，那麼整個請求的結果將會當即返回，並提示用戶相應的error信息。

准入控制（AdmissionControl）准入控制本質上爲一段准入代碼，在對kubernetes api的請求過程當中，順序爲：先通過認證 & 受權，而後執行准入操做，最後對目標對象進行操做。經常使用組件（控制代碼）以下：

AlwaysAdmit：容許全部請求
AlwaysDeny：禁止全部請求，多用於測試環境。
ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount作一些事情，好比若是pod沒有serviceAccount屬性，它會自動添加一個default，並確保pod的serviceAccount始終存在。
LimitRanger：觀察全部的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange對象中。
NamespaceExists：觀察全部的請求，若是請求嘗試建立一個不存在的namespace，則這個請求被拒絕。

簡述Kubernetes RBAC及其特色（優點）？

RBAC是基於角色的訪問控制，是一種基於我的用戶的角色來管理對計算機或網絡資源的訪問的方法。

相對於其餘受權模式，RBAC具備以下優點：

對集羣中的資源和非資源權限均有完整的覆蓋。
整個RBAC徹底由幾個API對象完成，同其餘API對象同樣，能夠用kubectl或API進行操做。
能夠在運行時進行調整，無須從新啓動API Server。

簡述Kubernetes Secret做用？

Secret對象，主要做用是保管私密數據，好比密碼、OAuth Tokens、SSH Keys等信息。將這些私密信息放在Secret對象中比直接放在Pod或Docker Image中更安全，也更便於使用和分發。

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

建立完secret以後，可經過以下三種方式使用：

在建立Pod時，經過爲Pod指定Service Account來自動使用該Secret。
經過掛載該Secret到Pod來使用它。
在Docker鏡像下載時使用，經過指定Pod的spc.ImagePullSecrets來引用它。

簡述Kubernetes PodSecurityPolicy機制？

Kubernetes PodSecurityPolicy是爲了更精細地控制Pod對資源的使用方式以及提高安全策略。在開啓PodSecurityPolicy准入控制器後，Kubernetes默認不容許建立任何Pod，須要建立PodSecurityPolicy策略和相應的RBAC受權策略（Authorizing Policies），Pod才能建立成功。

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

在PodSecurityPolicy對象中能夠設置不一樣字段來控制Pod運行時的各類安全策略，常見的有：

特權模式：privileged是否容許Pod以特權模式運行。
宿主機資源：控制Pod對宿主機資源的控制，如hostPID：是否容許Pod共享宿主機的進程空間。
用戶和組：設置運行容器的用戶ID（範圍）或組（範圍）。
提高權限：AllowPrivilegeEscalation：設置容器內的子進程是否能夠提高權限，一般在設置非root用戶（MustRunAsNonRoot）時進行設置。
SELinux：進行SELinux的相關配置。

簡述Kubernetes網絡模型？

Kubernetes網絡模型中每一個Pod都擁有一個獨立的IP地址，並假定全部Pod都在一個能夠直接連通的、扁平的網絡空間中。因此無論它們是否運行在同一個Node（宿主機）中，都要求它們能夠直接經過對方的IP進行訪問。設計這個原則的緣由是，用戶不須要額外考慮如何創建Pod之間的鏈接，也不須要考慮如何將容器端口映射到主機端口等問題。

同時爲每一個Pod都設置一個IP地址的模型使得同一個Pod內的不一樣容器會共享同一個網絡命名空間，也就是同一個Linux網絡協議棧。這就意味着同一個Pod內的容器能夠經過localhost來鏈接對方的端口。

在Kubernetes的集羣裏，IP是以Pod爲單位進行分配的。一個Pod內部的全部容器共享一個網絡堆棧（至關於一個網絡命名空間，它們的IP地址、網絡設備、配置等都是共享的）。

簡述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協同工做。

簡述Kubernetes網絡策略？

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

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

簡述Kubernetes網絡策略原理？

Network Policy的工做原理主要爲：policy controller須要實現一個API Listener，監聽用戶設置的Network Policy定義，並將網絡訪問規則經過各Node的Agent進行實際設置（Agent則須要經過CNI網絡插件實現）。

簡述Kubernetes中flannel的做用？

Flannel能夠用於Kubernetes底層網絡的實現，主要做用有：

它能協助Kubernetes，給每個Node上的Docker容器都分配互相不衝突的IP地址。
它能在這些IP地址之間創建一個覆蓋網絡（Overlay Network），經過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內。

簡述Kubernetes Calico網絡組件實現原理？

Calico是一個基於BGP的純三層的網絡方案，與OpenStack、Kubernetes、AWS、GCE等雲平臺都可以良好地集成。

Calico在每一個計算節點都利用Linux Kernel實現了一個高效的vRouter來負責數據轉發。每一個vRouter都經過BGP協議把在本節點上運行的容器的路由信息向整個Calico網絡廣播，並自動設置到達其餘節點的路由轉發規則。

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

簡述Kubernetes共享存儲的做用？

Kubernetes對於有狀態的容器應用或者對數據須要持久化的應用，所以須要更加可靠的存儲來保存應用產生的重要數據，以便容器應用在重建以後仍然可使用以前的數據。所以須要使用共享存儲。

簡述Kubernetes數據持久化的方式有哪些？

Kubernetes 經過數據持久化來持久化保存重要數據，常見的方式有：

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

場景：
只須要臨時將數據保存在磁盤上，好比在合併/排序算法中；
做爲兩個容器的共享存儲。
特性：
同個pod裏面的不一樣容器，共享同一個持久化目錄，當pod節點刪除時，volume的數據也會被刪除。
emptyDir的數據持久化的生命週期和使用的pod一致，通常是做爲臨時存儲使用。

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

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

PersistentVolume（簡稱PV）：如基於NFS服務的PV，也能夠基於GFS的PV。它的做用是統一數據持久化目錄，方便管理。

簡述Kubernetes PV和PVC？

PV是對底層網絡共享存儲的抽象，將共享存儲定義爲一種「資源」。

PVC則是用戶對存儲資源的一個「申請」。

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

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

Available：可用狀態，還未與某個PVC綁定。
Bound：已與某個PVC綁定。
Released：綁定的PVC已經刪除，資源已釋放，但沒有被集羣回收。
Failed：自動資源回收失敗。

簡述Kubernetes所支持的存儲供應模式？

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

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

動態模式：集羣管理員無須手工建立PV，而是經過StorageClass的設置對後端存儲進行描述，標記爲某種類型。此時要求PVC對存儲的類型進行聲明，系統將自動完成PV的建立及與PVC的綁定。

簡述Kubernetes CSI模型？

Kubernetes CSI是Kubernetes推出與容器對接的存儲接口標準，存儲提供方只須要基於標準接口進行存儲插件的實現，就能使用Kubernetes的原生存儲機制爲容器提供存儲服務。CSI使得存儲提供方的代碼能和Kubernetes代碼完全解耦，部署也與Kubernetes核心組件分離，顯然，存儲插件的開發由提供方自行維護，就能爲Kubernetes用戶提供更多的存儲功能，也更加安全可靠。

CSI包括CSI Controller和CSI Node：

CSI Controller的主要功能是提供存儲服務視角對存儲資源和存儲捲進行管理和操做。
CSI Node的主要功能是對主機（Node）上的Volume進行管理和操做。

簡述Kubernetes Worker節點加入集羣的過程？

一般須要對Worker節點進行擴容，從而將應用系統進行水平擴展。主要過程以下：

一、在該Node上安裝Docker、kubelet和kube-proxy服務；
二、而後配置kubelet和kubeproxy的啓動參數，將Master URL指定爲當前Kubernetes集羣Master的地址，最後啓動這些服務；
三、經過kubelet默認的自動註冊機制，新的Worker將會自動加入現有的Kubernetes集羣中；
四、Kubernetes Master在接受了新Worker的註冊以後，會自動將其歸入當前集羣的調度範圍。

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

簡述Kubernetes Requests和Limits如何影響Pod的調度？

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

簡述Kubernetes Metric Service？

在Kubernetes從1.10版本後採用Metrics Server做爲默認的性能數據採集和監控，主要用於提供核心指標（Core Metrics），包括Node、Pod的CPU和內存使用指標。

對其餘自定義指標（Custom Metrics）的監控則由Prometheus等組件來完成。

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