前言
下面是 16 道 Kubernetes 面試題。非標(biāo)準(zhǔn)答案啊研，如有錯(cuò)誤地方請(qǐng)指出。目的是幫助大家溫習(xí)K8S鸥拧。
題目 與 非標(biāo)準(zhǔn)答案
一、k8s集群規(guī)模削解，使用的版本及部署方式富弦，master節(jié)點(diǎn)跑了什么組件，每個(gè)組件作用氛驮？
k8s集群規(guī)模：個(gè)人推薦 K8S 集群規(guī)模不要超過千臺(tái)節(jié)點(diǎn)
k8s使用版本：比最新版本低一個(gè)版本（例：目前最新是1.17版本腕柜，生產(chǎn)推薦使用 1.16版本）
k8s部署方式：個(gè)人推薦使用 kubeadm 和 二進(jìn)制 部署
K8S Master 節(jié)點(diǎn)一般跑了： ETCD、ApiServer矫废、Controller Manager盏缤、Scheduler
ETCD 分布式的K-V存儲(chǔ)系統(tǒng)
-
http sever：（在etcd3里面變成了grpc server），主要處理client的操作請(qǐng)求以及節(jié)點(diǎn)間的數(shù)據(jù)同步和心跳保持 -
raft狀態(tài)機(jī)：通過對(duì)raft一致性協(xié)議的實(shí)現(xiàn)來保證etcd集群的高可用性 -
store：負(fù)責(zé)etcd中事務(wù)操作的邏輯蓖扑，是api server的命令的具體實(shí)現(xiàn) -
wal存儲(chǔ)：負(fù)責(zé)具體的數(shù)據(jù)持久存儲(chǔ)操作唉铜。它分為兩部分，entry負(fù)責(zé)實(shí)際的日志數(shù)據(jù)存儲(chǔ)（在etcd里數(shù)據(jù)的存儲(chǔ)都是帶版本號(hào)的律杠，對(duì)于同一個(gè)鍵值可能會(huì)有多個(gè)版本的記錄存在潭流，所以數(shù)據(jù)實(shí)際的存儲(chǔ)方式即通過事務(wù)日志進(jìn)行存儲(chǔ)竞惋，而在內(nèi)存里則存有鍵和版本號(hào)的映射關(guān)系以方便查詢）。snapshot則是對(duì)日志數(shù)據(jù)的的狀態(tài)存儲(chǔ)以防止過多的數(shù)據(jù)存在灰嫉。
API Server
ApiServer：對(duì)外提供增刪查改etcd中資源配置數(shù)據(jù)拆宛，worker節(jié)點(diǎn)kubelet同master節(jié)點(diǎn)的API Server進(jìn)行交互，
Master節(jié)點(diǎn)的scheduler和controller manager組件也需要同API Server進(jìn)行交互以獲取和修改對(duì)應(yīng)資源的狀態(tài)讼撒。
ApiServer 三層認(rèn)證：
kubernetes 認(rèn)證
kubernetes認(rèn)證：kubernetes 提供了多種認(rèn)證方式浑厚，比如客戶端證書、靜態(tài)token根盒、靜態(tài)密碼文件钳幅、ServiceAccountTokens等等。你可以同時(shí)使用一種或多種認(rèn)證方式郑象。只要通過任何一個(gè)都被認(rèn)作是認(rèn)證通過贡这。下面我們就認(rèn)識(shí)幾個(gè)常見的認(rèn)證方式。
-
客戶端證書認(rèn)證：客戶端證書認(rèn)證叫作TLS雙向認(rèn)證厂榛，也就是服務(wù)器客戶端互相驗(yàn)證證書的正確性盖矫，在都正確的情況下協(xié)調(diào)通信加密方案。為了使用這個(gè)方案击奶，api-server需要用–client-ca-file選項(xiàng)來開啟辈双。 -
靜態(tài)Token：當(dāng)我們有非常多的node節(jié)點(diǎn)時(shí)，手動(dòng)為每個(gè)node節(jié)點(diǎn)配置TLS認(rèn)證比較麻煩柜砾，這時(shí)就可以用到引導(dǎo)token的認(rèn)證方式湃望，前提是需要在api-server開啟experimental-bootstrap-token-auth特性，客戶端的token信息與預(yù)先定義的token匹配認(rèn)證通過后痰驱，自動(dòng)為node頒發(fā)證書证芭。當(dāng)然引導(dǎo)token是一種機(jī)制，可以用到各種場(chǎng)景中担映。 -
Service Account Tokens 認(rèn)證：有些情況下废士，我們希望在pod內(nèi)部訪問api-server，獲取集群的信息蝇完，甚至對(duì)集群進(jìn)行改動(dòng)官硝。針對(duì)這種情況，kubernetes提供了一種特殊的認(rèn)證方式：Service Account短蜕。 Service Account 和 pod氢架、service、deployment 一樣是 kubernetes 集群中的一種資源朋魔，用戶也可以創(chuàng)建自己的 Service Account岖研。
ServiceAccount 主要包含了三個(gè)內(nèi)容：namespace、Token 和 CA警检。namespace 指定了 pod 所在的 namespace缎玫，CA 用于驗(yàn)證 apiserver 的證書硬纤，token 用作身份驗(yàn)證。它們都通過 mount 的方式保存在 pod 的文件系統(tǒng)中赃磨。
kubernetes 授權(quán)
在 Kubernetes1.6 版本中新增角色訪問控制機(jī)制（Role-Based Access筝家，RBAC）讓集群管理員可以針對(duì)特定使用者或服務(wù)賬號(hào)的角色，進(jìn)行更精確的資源訪問控制邻辉。在RBAC中溪王，權(quán)限與角色相關(guān)聯(lián)，用戶通過成為適當(dāng)角色的成員而得到這些角色的權(quán)限值骇。這就極大地簡(jiǎn)化了權(quán)限的管理莹菱。在一個(gè)組織中，角色是為了完成各種工作而創(chuàng)造吱瘩，用戶則依據(jù)它的責(zé)任和資格來被指派相應(yīng)的角色道伟，用戶可以很容易地從一個(gè)角色被指派到另一個(gè)角色。
目前 Kubernetes 中有一系列的鑒權(quán)機(jī)制使碾，因?yàn)镵ubernetes社區(qū)的投入和偏好蜜徽，相對(duì)于其它鑒權(quán)機(jī)制而言，RBAC是更好的選擇票摇。
kubernetes 準(zhǔn)入控制
準(zhǔn)入控制（AdmissionControl）準(zhǔn)入控制本質(zhì)上為一段準(zhǔn)入代碼拘鞋，在對(duì)kubernetes api的請(qǐng)求過程中，順序?yàn)椋合冉?jīng)過認(rèn)證 & 授權(quán)矢门，然后執(zhí)行準(zhǔn)入操作盆色，最后對(duì)目標(biāo)對(duì)象進(jìn)行操作。這個(gè)準(zhǔn)入代碼在api-server中祟剔，而且必須被編譯到二進(jìn)制文件中才能被執(zhí)行隔躲。
在對(duì)集群進(jìn)行請(qǐng)求時(shí)，每個(gè)準(zhǔn)入控制代碼都按照一定順序執(zhí)行物延。如果有一個(gè)準(zhǔn)入控制拒絕了此次請(qǐng)求蹭越，那么整個(gè)請(qǐng)求的結(jié)果將會(huì)立即返回，并提示用戶相應(yīng)的error信息教届。
常用組件（控制代碼）如下：
-
AlwaysAdmit：允許所有請(qǐng)求 -
AlwaysDeny：禁止所有請(qǐng)求，多用于測(cè)試環(huán)境 -
ServiceAccount：它將serviceAccounts實(shí)現(xiàn)了自動(dòng)化驾霜，它會(huì)輔助serviceAccount做一些事情案训，比如如果pod沒有serviceAccount屬性，它會(huì)自動(dòng)添加一個(gè)default粪糙，并確保pod的serviceAccount始終存在 -
LimitRanger：他會(huì)觀察所有的請(qǐng)求强霎，確保沒有違反已經(jīng)定義好的約束條件，這些條件定義在namespace中LimitRange對(duì)象中蓉冈。如果在kubernetes中使用LimitRange對(duì)象城舞，則必須使用這個(gè)插件轩触。 -
NamespaceExists：它會(huì)觀察所有的請(qǐng)求，如果請(qǐng)求嘗試創(chuàng)建一個(gè)不存在的namespace家夺，則這個(gè)請(qǐng)求被拒絕脱柱。
Controller Manager
Controller Manager：以守護(hù)進(jìn)程的形式運(yùn)行著kubernetes幾個(gè)核心的控制循環(huán)（也就是控制器），包括deployment拉馋，replicaset，namespace，serviceaccount埠巨，node等等双妨，通過調(diào)用Api Server 的 list watch接口來監(jiān)控自己負(fù)責(zé)的資源的配置變化.
Scheduler
Scheduler：是一個(gè)策略豐富、拓?fù)涓兄⒐ぷ髫?fù)載特定的功能矩乐，調(diào)度器顯著影響可用性、性能和容量回论。調(diào)度器需要考慮個(gè)人和集體的資源要求散罕、服務(wù)質(zhì)量要求、硬件/軟件/政策約束透葛、親和力和反親和力規(guī)范笨使、數(shù)據(jù)局部性、負(fù)載間干擾僚害、完成期限等硫椰。
kube-scheduler 給一個(gè) pod 做調(diào)度選擇包含兩個(gè)步驟：
-
過濾：過濾階段會(huì)將所有滿足 Pod 調(diào)度需求的 Node 選出來。例如萨蚕，PodFitsResources 過濾函數(shù)會(huì)檢查候選 Node 的可用資源能否滿足 Pod 的資源請(qǐng)求靶草。在過濾之后，得出一個(gè) Node 列表岳遥，里面包含了所有可調(diào)度節(jié)點(diǎn)奕翔；通常情況下，這個(gè) Node 列表包含不止一個(gè) Node浩蓉。如果這個(gè)列表是空的派继，代表這個(gè) Pod 不可調(diào)度。 -
打分：打分階段捻艳，調(diào)度器會(huì)為 Pod 從所有可調(diào)度節(jié)點(diǎn)中選取一個(gè)最合適的 Node驾窟。根據(jù)當(dāng)前啟用的打分規(guī)則，調(diào)度器會(huì)給每一個(gè)可調(diào)度節(jié)點(diǎn)進(jìn)行打分认轨。最后绅络，kube-scheduler 會(huì)將 Pod 調(diào)度到得分最高的 Node 上。如果存在多個(gè)得分最高的 Node，kube-scheduler 會(huì)從中隨機(jī)選取一個(gè)恩急。
二杉畜、kube-scheduler工作原理，多少節(jié)點(diǎn)對(duì)外提供服務(wù)
根據(jù)各種調(diào)度算法將 Pod 綁定到最合適的工作節(jié)點(diǎn)
預(yù)選（Predicates）：輸入是所有節(jié)點(diǎn)衷恭，輸出是滿足預(yù)選條件的節(jié)點(diǎn)此叠。kube-scheduler根據(jù)預(yù)選策略過濾掉不滿足策略的Nodes。例如匾荆，如果某節(jié)點(diǎn)的資源不足或者不滿足預(yù)選策略的條件如“Node的label必須與Pod的Selector一致”時(shí)則無法通過預(yù)選拌蜘。優(yōu)選（Priorities）：輸入是預(yù)選階段篩選出的節(jié)點(diǎn)，優(yōu)選會(huì)根據(jù)優(yōu)先策略為通過預(yù)選的Nodes進(jìn)行打分排名牙丽，選擇得分最高的Node简卧。例如，資源越富裕烤芦、負(fù)載越小的Node可能具有越高的排名举娩。
三、apiserver工作原理构罗，多少節(jié)點(diǎn)對(duì)外提供服務(wù)铜涉，負(fù)載均衡高可用如何實(shí)現(xiàn)
apiserver 工作原理圖
一般規(guī)模小的集群，3 臺(tái) apiserver 已經(jīng)夠用遂唧，如果集群規(guī)則大芙代，apiserver 和 ECT 節(jié)點(diǎn)都需要擴(kuò)容。
apiserver 負(fù)載均衡：apiserver 服務(wù)是一個(gè)無狀態(tài)服務(wù)盖彭，可以使用 Nginx + Keepalived纹烹、HAProxy + Keepalived和 云廠商LB（比如：阿里云SLB）。
四召边、controller-manager 和etcd 通信嗎铺呵？
不通信
原因：controller-manager 和 scheduler 它們都是和 kube-apiserver通信，然后 kube-apiserver 再和etcd通信隧熙。
五片挂、headless-service使用場(chǎng)景
- 自主選擇權(quán) client可以自主選擇哪個(gè)server
- Headless Service 的對(duì)應(yīng)的每一個(gè) Endpoints，即每一個(gè)Pod贞盯，都會(huì)有對(duì)應(yīng)的DNS域名音念，這樣Pod之間就可以互相訪問。
六躏敢、集群使用的網(wǎng)絡(luò)方案闷愤，pod如何和node網(wǎng)絡(luò)通信的
Flannel：使用vxlan技術(shù)為各節(jié)點(diǎn)創(chuàng)建一個(gè)可以互通的Pod網(wǎng)絡(luò)，使用的端口為UDP 8472（需要開放該端口父丰，如公有云AWS等）。flanneld第一次啟動(dòng)時(shí)，從etcd獲取配置的Pod網(wǎng)段信息蛾扇，為本節(jié)點(diǎn)分配一個(gè)未使用的地址段攘烛，然后創(chuàng)建flannedl.1網(wǎng)絡(luò)接口（也可能是其它名稱，如flannel1等）镀首。flannel將分配給自己的Pod網(wǎng)段信息寫入 /run/flannel/subnet.env 文件坟漱，docker后續(xù)使用這個(gè)文件中的環(huán)境變量設(shè)置docker0網(wǎng)橋，從而從這個(gè)地址段為本節(jié)點(diǎn)的所有Pod容器分配IP更哄。
Calico：在宿主機(jī)部署calico作為虛擬路由器芋齿，容器流量通過veth pair到達(dá)宿主機(jī)的網(wǎng)絡(luò)命名空間上。
七成翩、etcd高可用及備份恢復(fù)方案
etcd高可用：部署ETCD時(shí)觅捆，在配置文件中配置 ETCD_INITIAL_CLUSTER="etcd節(jié)點(diǎn)ip:端口,etcd節(jié)點(diǎn)ip:端口,etcd節(jié)點(diǎn)ip:端口"，集群數(shù)量最好是奇數(shù)麻敌。
備份命令：
$ ETCDCTL_API=3 etcdctl \
--cacert="${CACERT}" --cert="${CERT}" --key="${EKY}" \
--endpoints=${ENDPOINTS} \
snapshot save /data/etcd_backup_dir/etcd-snapshot-`date +%Y%m%d`.db
具體備份與恢復(fù)：參考 Etcd v3備份與恢復(fù)
八栅炒、k8s集群節(jié)點(diǎn)需要關(guān)機(jī)維護(hù)，需要怎么操作
# 驅(qū)逐 node 節(jié)點(diǎn)上 pod
$ kubectl drain k8s-node-01 --force --ignore-daemonsets
# 關(guān)機(jī)
$ init 0
九术羔、使用什么pod控制器赢赊，crd都需要定義什么,存活性監(jiān)測(cè)和就緒性監(jiān)測(cè)的實(shí)現(xiàn)方式
Pod控制器：Deployment，ReplicationController级历，StatefulSet释移，DaemonSet，Cronjob寥殖，Job
CRD定義：在 Kubernetes 中一切都可視為資源玩讳，Kubernetes 1.7 之后增加了對(duì) CRD 自定義資源二次開發(fā)能力來擴(kuò)展 Kubernetes API，通過 CRD 我們可以向 Kubernetes API 中增加新資源類型扛禽，而不需要修改 Kubernetes 源碼來創(chuàng)建自定義的 API server锋边，該功能大大提高了 Kubernetes 的擴(kuò)展能力。當(dāng)你創(chuàng)建一個(gè)新的CustomResourceDefinition (CRD)時(shí)编曼，Kubernetes API服務(wù)器將為你指定的每個(gè)版本創(chuàng)建一個(gè)新的RESTful資源路徑豆巨，我們可以根據(jù)該api路徑來創(chuàng)建一些我們自己定義的類型資源。CRD可以是命名空間的掐场，也可以是集群范圍的往扔，由CRD的作用域(scpoe)字段中所指定的，與現(xiàn)有的內(nèi)置對(duì)象一樣熊户，刪除名稱空間將刪除該名稱空間中的所有自定義對(duì)象萍膛。customresourcedefinition本身沒有名稱空間，所有名稱空間都可以使用嚷堡。
存活性監(jiān)測(cè)和就緒性監(jiān)測(cè)的實(shí)現(xiàn)方式：readiness probe,liveness probe:HTTP請(qǐng)求蝗罗，TCP連接艇棕，命令行
十、pod如何平滑升級(jí)
minReadySeconds: 5
strategy:
# indicate which strategy we want for rolling update
type: RollingUpdate
rollingUpdate:
maxSurge: 30%
maxUnavailable: 30%
十一串塑、k8s內(nèi)核及文件系統(tǒng)需要哪些設(shè)置
開啟網(wǎng)橋模式沼琉、禁止使用swap空間 只有當(dāng)系統(tǒng)OOM時(shí)才允許使用它、開啟OOM桩匪、不檢查物理內(nèi)存是否夠用打瘪、關(guān)閉ipv6(防止觸發(fā)docker BUG)、設(shè)置系統(tǒng)時(shí)區(qū)傻昙、設(shè)置Hostname闺骚、tcp_tw_recycle關(guān)閉、與k8s的NAT沖突妆档、升級(jí)系統(tǒng)內(nèi)核 4.4+
十二僻爽、存儲(chǔ)卷使用方式
- 動(dòng)態(tài)存儲(chǔ)使用
storageclass - 靜態(tài)存儲(chǔ)使用
persistentvolume
十三、對(duì)外提供服務(wù)的pod暴露方式有哪些
-
hostNetwork：在pod中使用該配置过吻，在這種Pod中運(yùn)行的應(yīng)用程序可以直接看到pod啟動(dòng)的主機(jī)的網(wǎng)絡(luò)接口 -
hostPort：直接將容器的端口與所調(diào)度的節(jié)點(diǎn)上的端口路由进泼，這樣用戶就可以通過主機(jī)的IP來訪問Pod -
NodePort：是K8s里一個(gè)廣泛應(yīng)用的服務(wù)暴露方式。K8s中的service默認(rèn)情況都是使用Cluster IP這種類型纤虽，會(huì)產(chǎn)生一個(gè)只能在內(nèi)部訪問的Cluster IP乳绕，如果想能夠直接訪問service，需要將service type修改為nodePort逼纸。同時(shí)給改service指定一個(gè)nodeport值(30000-32767)洋措，用--service-node-port-range定義。 -
LoadBalancer：只能在service上定義杰刽，是公有云提供的負(fù)載均衡器 -
Ingress：ingress controller是由K8s管理的負(fù)載均衡容器菠发，它的鏡像包含一個(gè)nginx或HAProxy負(fù)載均衡器和一個(gè)控制器守護(hù)進(jìn)程。
十四贺嫂、traefik的實(shí)現(xiàn)原理
Traefik 作為一種邊緣路由器滓鸠，動(dòng)態(tài)感知后端服務(wù)實(shí)例變化，進(jìn)行動(dòng)態(tài)調(diào)整轉(zhuǎn)發(fā)配置第喳，會(huì)與ApiServer進(jìn)行交互糜俗，發(fā)現(xiàn)k8s集群內(nèi)部容器狀態(tài)變化。
十五曲饱、生產(chǎn)中碰到過什么問題悠抹，故障排查思路，如何解決的
故障排查扩淀，參考下面幾篇文章：
十六楔敌、容器日志收集方案，都收集了什么類型日志驻谆，實(shí)現(xiàn)方式卵凑，filebeat和logstash區(qū)別庆聘，grafana繪圖
一般使用EFK方式收集日志；logstash是jvm跑的勺卢，資源消耗比較大掏觉，filebeat更輕量級(jí)，但logstash有filter功能
一般結(jié)構(gòu)都是filebeat采集日志值漫，然后發(fā)送到消息隊(duì)列，redis织盼，kafaka杨何。然后logstash去獲取，利用filter功能過濾分析沥邻，然后存儲(chǔ)到elasticsearch中危虱。
grafana繪圖：省略。唐全。埃跷。
參考鏈接
- https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
- https://www.kubernetes.org.cn/3789.html
- https://blog.csdn.net/huwh_/article/details/75675706
本文由 YP小站 發(fā)布！
