在面試的時(shí)候，面試官常常會(huì)問一些問題：
- k8s是什么？有什么用?
- k8s由哪些組件組成？
- pod的啟動(dòng)流程？
- k8s里有哪些控制器？
- k8s的調(diào)度器里有哪些調(diào)度算法？
- pod和pod之間的通信過程？
- 外面用戶訪問pod數(shù)據(jù)流程？
- 你常用哪些命令？
- 容器的類型？
- 3種探針？
- pod的升級(jí)？
- HPA、VPA、CA？
- 污點(diǎn)和容忍？
- 有狀態(tài)的應(yīng)用和無狀態(tài)的應(yīng)用？
- ingress相關(guān)？
- RBAC相關(guān)？
- CI/CD 持續(xù)集成、持續(xù)交付 jenkins？
- pod有多少種狀態(tài)？
- pod的重啟策略？
下面，就讓我來詳細(xì)說明一些這些問題
1. k8s是什么？有什么用??
k8s就是一個(gè)編排容器的工具，一個(gè)可以管理應(yīng)用全生命周期的工具，從創(chuàng)建應(yīng)用，應(yīng)用的部署，應(yīng)用提供服務(wù)，擴(kuò)容縮容應(yīng)用，應(yīng)用更新，都非常的方便，而且可以做到故障自愈。
例如：一個(gè)服務(wù)器掛了，K8s可以自動(dòng)將這個(gè)服務(wù)器上的服務(wù)調(diào)度到另外一個(gè)主機(jī)上進(jìn)行運(yùn)行，無需進(jìn)行人工干涉。
所以 k8s 一般都是和 Docker 搭配起來使用的。
2. k8s由哪些組件組成？
k8s的master里有哪些組件？
- ?? ?1.etcd ?存放數(shù)據(jù)
- ?? ?2.scheduler 調(diào)度器 --》例如：容器（pod）到底在那個(gè)node服務(wù)器上啟動(dòng)
- ?? ?3.api-server ?接口： master和node之間通信和交換數(shù)據(jù)
- ?? ?4.controller 控制器： deployment 部署控制器，replicaSET 副本控制器等
k8s的node節(jié)點(diǎn)上有哪些組件？
- ?? ?1.kubulet ?幫助啟動(dòng)容器的
- ?? ?2.kubu-proxy 負(fù)責(zé)網(wǎng)絡(luò)通信和負(fù)載均衡
master上
API Server?
API 服務(wù)器是 Kubernetes 控制平面的組件， 該組件負(fù)責(zé)公開了 Kubernetes API，負(fù)責(zé)處理接受請(qǐng)求的工作。 API 服務(wù)器是 Kubernetes 控制平面的前端。
etcd
數(shù)據(jù)庫, 一致且高可用的鍵值存儲(chǔ)，用作 Kubernetes 所有集群數(shù)據(jù)的后臺(tái)數(shù)據(jù)庫。
kube-scheduler
調(diào)度器, 負(fù)責(zé)監(jiān)視新創(chuàng)建的、未指定運(yùn)行節(jié)點(diǎn)（node）的 Pods， 并選擇節(jié)點(diǎn)來讓 Pod 在上面運(yùn)行。
kube-controller-manager
控制器管理器，負(fù)責(zé)運(yùn)行控制器進(jìn)程
cloud-controller-manager
嵌入了特定于云平臺(tái)的控制邏輯，與公有云進(jìn)行對(duì)接的控制器
node上
kubelet
它保證容器（containers）都運(yùn)行在 Pod 中。
單獨(dú)的程序，在宿主機(jī)里運(yùn)行
[root@k8smaster kubernetes]# ps aux|grep kubelet
root 1020 6.7 2.2 1951916 87964 ? Ssl 09:58 7:01 /usr/bin/kubeletkube-proxy
是集群中每個(gè)節(jié)點(diǎn)（node）上所運(yùn)行的網(wǎng)絡(luò)代理
kube-proxy 維護(hù)節(jié)點(diǎn)上的一些網(wǎng)絡(luò)規(guī)則， 這些網(wǎng)絡(luò)規(guī)則會(huì)允許從集群內(nèi)部或外部的網(wǎng)絡(luò)會(huì)話與 Pod 進(jìn)行網(wǎng)絡(luò)通信。
如果操作系統(tǒng)提供了可用的數(shù)據(jù)包過濾層，則 kube-proxy 會(huì)通過它來實(shí)現(xiàn)網(wǎng)絡(luò)規(guī)則。 否則，kube-proxy 僅做流量轉(zhuǎn)發(fā)。
單獨(dú)的程序，在宿主機(jī)里運(yùn)行
[root@k8smaster kubernetes]# ps aux|grep kube-proxy
root 3548 0.2 0.8 744320 32848 ? Ssl 09:59 0:13 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=k8smaster
root 100881 0.0 0.0 112828 992 pts/0 S+ 11:42 0:00 grep --color=auto kube-proxy3. pod的啟動(dòng)流程？
4. k8s里有哪些控制器？
deployment-部署控制器
一旦運(yùn)行了 Kubernetes 集群，就可以在其上部署容器化應(yīng)用程序。 為此，您需要?jiǎng)?chuàng)建 Kubernetes Deployment 配置。Deployment 指揮 Kubernetes 如何創(chuàng)建和更新應(yīng)用程序的實(shí)例。創(chuàng)建 Deployment 后，Kubernetes master 將應(yīng)用程序?qū)嵗{(diào)度到集群中的各個(gè)節(jié)點(diǎn)上。?
創(chuàng)建 Deployment 時(shí)，您需要指定應(yīng)用程序的容器映像以及要運(yùn)行的副本數(shù)。?
deployment控制器會(huì)去node節(jié)點(diǎn)上去創(chuàng)建pod，根據(jù)你指定的鏡像名字，在pod里創(chuàng)建需要的容器?
刪除deployment，就自動(dòng)刪除啟動(dòng)的pod?
ReplicaSet-副本的控制器
光從ReplicaSet這個(gè)控制器的名字（副本集）也能想到它是用來控制副本數(shù)量的，這里的每一個(gè)副本就是一個(gè)Pod。ReplicaSet它是用來確保我們有指定數(shù)量的Pod副本正在運(yùn)行的Kubernetes控制器，意在保證系統(tǒng)當(dāng)前正在運(yùn)行的Pod數(shù)等于期望狀態(tài)里指定的Pod數(shù)目。
一般來說，Kubernetes建議使用Deployment控制器而不是直接使用ReplicaSet，Deployment是一個(gè)管理ReplicaSet并提供Pod聲明式更新、應(yīng)用的版本管理以及許多其他功能的更高級(jí)的控制器。所以Deployment控制器不直接管理Pod對(duì)象，而是由?Deployment?管理ReplicaSet，再由ReplicaSet負(fù)責(zé)管理Pod對(duì)象。
daemonSet-守護(hù)進(jìn)程控制器
當(dāng)我們啟動(dòng)pod的時(shí)候，每個(gè)node節(jié)點(diǎn)上只啟動(dòng)一個(gè)pod?
舉例： 假如我們有6個(gè)node，需要在每個(gè)node上一個(gè)安裝一個(gè)監(jiān)控使用的pod ，就可以使用Daemon Sets--》特別適合日志采集和數(shù)據(jù)收集的pod?
DaemonSet 確保全部（或者某些）節(jié)點(diǎn)上運(yùn)行一個(gè) Pod 的副本?
job-批處理控制器
Job控制器用于Pod對(duì)象運(yùn)行一次性任務(wù)，容器中的進(jìn)程在正常運(yùn)行結(jié)束后不會(huì)對(duì)其進(jìn)行重啟，而是將Pod對(duì)象置于"Completed"(完成)狀態(tài)，若容器中的進(jìn)程因錯(cuò)誤而終止，則需要按照重啟策略配置確定是否重啟，未運(yùn)行完成的Pod對(duì)象因其所在的節(jié)點(diǎn)故障而意外終止后會(huì)被調(diào)度。?
cronjob-計(jì)劃任務(wù)控制器
CronJob 用于執(zhí)行周期性的動(dòng)作，例如備份、報(bào)告生成等。 這些任務(wù)中的每一個(gè)都應(yīng)該配置為周期性重復(fù)的（例如：每天/每周/每月一次）； 你可以定義任務(wù)開始執(zhí)行的時(shí)間間隔。
計(jì)劃任務(wù)相關(guān)
5. k8s的調(diào)度器里有哪些調(diào)度算法？
- ?? ?1.deployment: ? 全自動(dòng)調(diào)度，根據(jù)node的算力（cpu，內(nèi)存，帶寬，已經(jīng)運(yùn)行的pod等）--》到底是如何給node評(píng)分的，最底層的機(jī)制
- ?? ?2.node selector：定向調(diào)度
- ?? ?3.nodeaffinity ? ?--》盡量把不同的pod放到一臺(tái)node上
- ?? ?4.podaffinity ? ? --》盡量把相同的pod放到一起
- ?? ?5.taints和tolerations ?污點(diǎn)和容忍
taints和toleration是怎么樣查看的？如何知道哪些機(jī)器上有污點(diǎn)，哪些pod可以容忍？?
[root@scmaster ~]# kubectl describe node scmaster|grep -i taint
Taints: node-role.kubernetes.io/master:NoSchedule
[root@scmaster ~]#[root@scmaster ~]# kubectl describe pod etcd-scmaster -n kube-system |grep -i tolerations
Tolerations: :NoExecute op=Exists
[root@scmaster ~]# ?
6. pod和pod之間的通信過程？
同一個(gè)Pod中的容器通信
同一個(gè)pod中的容器是共享網(wǎng)絡(luò)ip地址和端口號(hào)的，通信顯然沒問題
集群內(nèi)Pod之間的通信?
Pod會(huì)有獨(dú)立的IP地址，這個(gè)IP地址是被Pod中所有的Container共享的，那多個(gè)Pod之間的通信能通過這個(gè)IP地址嗎？我們可以將此類pod間的通信分為兩個(gè)維度：
集群中同一臺(tái)機(jī)器中的Pod
pause 容器啟動(dòng)之前，會(huì)為容器創(chuàng)建虛擬一對(duì) ethernet 接口，一個(gè)保留在宿主機(jī) vethxxx（插在網(wǎng)橋上），一個(gè)保留在容器網(wǎng)絡(luò)命名空間內(nèi)，并重命名為eth0。兩個(gè)虛擬接口的兩端，從一端進(jìn)入，另一端出來。任何 Pod 連接到該網(wǎng)橋的 Pod 都可以收發(fā)數(shù)據(jù)。
集群中不同機(jī)器之間的通信是通過網(wǎng)絡(luò)插件實(shí)現(xiàn)的?
Kubernetes跨主機(jī)容器之間的通信組件，目前主流的是flannel和calico?
???????
?
其中跨整個(gè)集群的 Pod ip 是唯一的，當(dāng)報(bào)文從一個(gè)節(jié)點(diǎn)轉(zhuǎn)發(fā)到另外一個(gè)節(jié)點(diǎn)時(shí)，報(bào)文首先通過 veth，然后通過網(wǎng)橋，轉(zhuǎn)發(fā)到物理適配器網(wǎng)卡，最后轉(zhuǎn)發(fā)到其它節(jié)點(diǎn)的虛擬網(wǎng)橋，進(jìn)而到達(dá) veth 目標(biāo)容器。?
flannel和calico參考：https://www.cnblogs.com/xiaoyuxixi/p/13304602.html
7. 外面用戶訪問pod數(shù)據(jù)流程？
8. 常用命令
- kubectl get? 資源對(duì)象
- kubectl describe??查詢?cè)敿?xì)信息
- kubectl logs? 查看日志
- kubectl exec -it 容器名 -- bash? ?進(jìn)入容器
- kubectl apply -f ?*.yml? ?執(zhí)行yml文件
- kubectl delete?-f ?*.yml? ? 刪除前面執(zhí)行的yml文件創(chuàng)建的內(nèi)容
9. 容器的類型有哪些?
init初始化容器?
初始化（init）容器像常規(guī)應(yīng)用容器一樣，只有一點(diǎn)不同：初始化（init）容器必須在應(yīng)用容器啟動(dòng)前運(yùn)行完成。 Init 容器的運(yùn)行順序：一個(gè)初始化（init）容器必須在下一個(gè)初始化（init）容器開始前運(yùn)行完成。?
為一個(gè)pod里后面啟動(dòng)的容器準(zhǔn)備一些條件
容器啟動(dòng)有先后順序，同時(shí)一個(gè)pod里的容器也是可以有依賴的?
與普通容器不同之處：Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因?yàn)樗鼈儽仨氃?Pod 就緒之前運(yùn)行完成
pause容器
Pause容器 全稱infrastucture container（又叫infra）基礎(chǔ)容器，作為init pod存在，其他pod都會(huì)從pause 容器中fork出來?
- 1、每個(gè)Pod里運(yùn)行著一個(gè)特殊的被稱之為Pause的容器，其他容器則為業(yè)務(wù)容器，這些業(yè)務(wù)容器共享Pause容器的網(wǎng)絡(luò)棧和Volume掛載卷
- 2、因此他們之間通信和數(shù)據(jù)交換更為高效，在設(shè)計(jì)時(shí)我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進(jìn)程放入同一個(gè)Pod中。
- 3、同一個(gè)Pod里的容器之間僅需通過localhost就能互相通信。?
在創(chuàng)建一個(gè)pod的時(shí)候，最先創(chuàng)建的容器?
pause容器--》把pod的公用的命名空間都創(chuàng)建好--》init容器---》app容器?
sidecar容器
Sidecar模式是一種將應(yīng)用功能從應(yīng)用本身剝離出來作為單獨(dú)進(jìn)程的方式。該模式允許我們向應(yīng)用無侵入添加多種功能，避免了為滿足第三方組件需求而向應(yīng)用添加額外的配置代碼。
就像邊車加裝在摩托車上一樣，在軟件架構(gòu)中，sidecar附加到主應(yīng)用，或者叫父應(yīng)用上，以擴(kuò)展/增強(qiáng)功能特性，同時(shí)Sidecar與主應(yīng)用是松耦合的。
當(dāng)另一個(gè)容器被添加到一個(gè)pod中，為主容器提供額外的功能，但不需要改變主容器，它被稱為一個(gè)sidecar容器
一個(gè)或多個(gè)共享同一個(gè)pod的容器至少要共享兩樣?xùn)|西
- 一個(gè)文件系統(tǒng)-這意味著你可以使用共享卷在同一個(gè)pod中的兩個(gè)或多個(gè)容器之間共享文件。共享卷是簡(jiǎn)單的共享文件夾。
- 網(wǎng)絡(luò)-同一Pod中的容器之間的通信可以通過回環(huán)接口 - localhost進(jìn)行。
Sidecar模式的好處
- 通過將公用基礎(chǔ)設(shè)施相關(guān)功能抽象到不同的層來降低微服務(wù)的代碼復(fù)雜性
- 由于我們不需要在每個(gè)微服務(wù)中編寫配置代碼，因此減少了微服務(wù)架構(gòu)中的代碼重復(fù)
- P應(yīng)用和底層平臺(tái)之間實(shí)現(xiàn)了松耦合
工作模式：?
app容器
應(yīng)用程序容器?跑業(yè)務(wù)代碼的容器
10. 3種探針
探針：使用探針去試探pod是否能正常提供服務(wù)，在pod啟動(dòng)的不同階段使用不同的方法去監(jiān)控，判斷pod是否正常?
案例
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
當(dāng)探針發(fā)現(xiàn)pod沒有運(yùn)行的時(shí)候，kubelet會(huì)根據(jù)pod的重啟策略，重啟pod
11. pod的升級(jí)？
參考：https://zhuanlan.zhihu.com/p/342229988
使用Deployment來控制Pod的主要好處之一是能夠執(zhí)行滾動(dòng)更新。滾動(dòng)更新允許你逐步更新Pod的配置，并且Deployment提供了許多選項(xiàng)來控制滾動(dòng)更新的過程。
控制滾動(dòng)更新最重要的選項(xiàng)是更新策略。在Deployment的YAML定義文件中，由spec.strategy.type字段指定Pod的滾動(dòng)更新策略，它有兩個(gè)可選值：
- RollingUpdate (默認(rèn)值)：逐步創(chuàng)建新的Pod，同時(shí)逐步終止舊Pod，用新Pod替換舊Pod。
- Recreate：在創(chuàng)建新Pod前，所有舊Pod必須全部終止。
大多數(shù)情況下，RollingUpdate是Deployment的首選更新策略。如果你的Pod需要作為單例運(yùn)行，并且不允許在任何時(shí)間存在多副本，這種時(shí)候Recreate更新策略會(huì)很有用。
使用RollingUpdate策略時(shí)，還有兩個(gè)選項(xiàng)可以讓你微調(diào)更新過程：
-
maxSurge：在更新期間，允許創(chuàng)建超過期望狀態(tài)定義的
Pod數(shù)的最大值。 - maxUnavailable：在更新期間，容忍不可訪問的Pod數(shù)的最大值
maxSurge和maxUnavailable選項(xiàng)都可以使用整數(shù)（比如：2）或者百分比（比如：50%）進(jìn)行配置，而且這兩項(xiàng)不能同時(shí)為零。當(dāng)指定為整數(shù)時(shí)，表示允許超期創(chuàng)建或者不可訪問的Pod數(shù)。當(dāng)指定為百分比時(shí)，將使用期望狀態(tài)里定義的Pod數(shù)作為基數(shù)。比如：如果對(duì)maxSurge和maxUnavailable都使用默認(rèn)值25％，并且將更新應(yīng)用于具有8個(gè)容器的Deployment，那么意味著maxSurge為2個(gè)容器，maxUnavailable也將為2個(gè)容器。這意味著在更新過程中，將滿足以下條件：
- 最多有10個(gè)
Pod（8個(gè)期望狀態(tài)里指定的Pod和2個(gè)maxSurge允許超期創(chuàng)建的Pod）在更新過程中處于Ready狀態(tài)。 - 最少有6個(gè)
Pod（8個(gè)期望狀態(tài)里指定的Pod和2個(gè)maxUnavailable允許不可訪問的Pod）將始終處于Ready狀態(tài)。
值得注意的一點(diǎn)是，在考慮Deployment應(yīng)在更新期間運(yùn)行的Pod數(shù)量時(shí)，使用的是在Deployment的更新版本中指定的副本數(shù)，而不是現(xiàn)有Deployment版本的期望狀態(tài)中指定的副本數(shù)。
可以用另外一種方式理解這兩個(gè)選項(xiàng)：maxSurge是一次將創(chuàng)建的新Pod的最大數(shù)量，maxUnavailable是一次將被刪除的舊Pod的最大數(shù)量。
讓我們具體看一下使用以下更新策略將具有3個(gè)副本的Deployment從"v1"更新為" v2"的過程：
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0這個(gè)更新策略是，我們想一次新建一個(gè)Pod，并且應(yīng)該始終保持Deployment中的Pod有三個(gè)是Ready狀態(tài)。下面的動(dòng)圖說明了滾動(dòng)更新的每一步都發(fā)生了什么。如果Deployment看到Pod已經(jīng)完全部署好了將會(huì)把Pod標(biāo)記為Ready，創(chuàng)建中的Pod標(biāo)記為NotReady，正在被刪除的Pod標(biāo)記為Terminating。
12.?HPA、VPA、CA？
參考：https://blog.csdn.net/weixin_41989934/article/details/118645084?
HPA 水平Pod自動(dòng)擴(kuò)縮器
HAP，全稱 Horizontal Pod Autoscaler， 可以基于 CPU 利用率自動(dòng)擴(kuò)縮 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 數(shù)量。 除了 CPU 利用率，也可以基于其他應(yīng)程序提供的自定義度量指標(biāo)來執(zhí)行自動(dòng)擴(kuò)縮。 Pod 自動(dòng)擴(kuò)縮不適用于無法擴(kuò)縮的對(duì)象，比如 DaemonSet。
Pod 水平自動(dòng)擴(kuò)縮特性由 Kubernetes API 資源和控制器實(shí)現(xiàn)。資源決定了控制器的行為。 控制器會(huì)周期性的調(diào)整副本控制器或 Deployment 中的副本數(shù)量，以使得 Pod 的平均 CPU 利用率與用戶所設(shè)定的目標(biāo)值匹配。
- HPA 定期檢查內(nèi)存和 CPU 等指標(biāo)，自動(dòng)調(diào)整 Deployment 中的副本數(shù)，比如流量變化：
HPA工作原理
?k8s里的HPA功能比傳統(tǒng)的集群有什么優(yōu)勢(shì)？
1.啟動(dòng)速度
2.擴(kuò)展性--》自動(dòng)擴(kuò)縮
3.資源的消耗方面--》節(jié)省服務(wù)器
速度
價(jià)格--》成本
穩(wěn)定性
可靠性
metrics server
HPA的指標(biāo)數(shù)據(jù)是通過metrics服務(wù)來獲得，必須要提前安裝好?
Metrics Server 是 Kubernetes 內(nèi)置自動(dòng)縮放管道的可擴(kuò)展、高效的容器資源指標(biāo)來源。
Metrics Server 從 Kubelets 收集資源指標(biāo)，并通過Metrics API在 Kubernetes apiserver 中公開它們， 以供Horizo??ntal Pod Autoscaler和Vertical Pod Autoscaler 使用，比如CPU、文件描述符、內(nèi)存、請(qǐng)求延時(shí)等指標(biāo)，metric-server收集數(shù)據(jù)給k8s集群內(nèi)使用，如kubectl,hpa,scheduler等。還可以通過 訪問指標(biāo) API kubectl top，從而更輕松地調(diào)試自動(dòng)縮放管道
安裝參考：https://www.cnblogs.com/scajy/p/15577926.html
示例：
首先我們部署一個(gè)nginx,副本數(shù)為2，請(qǐng)求cpu資源為200m。同時(shí)為了便宜測(cè)試，使用NodePort暴露服務(wù)，命名空間設(shè)置為:hpa
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: hpa
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
cpu: 200m ##
memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: hpa
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginx
查看部署結(jié)果
# kubectl get po -n hpa
NAME READY STATUS RESTARTS AGE
nginx-5c87768612-48b4v 1/1 Running 0 8m38s
nginx-5c87768612-kfpkq 1/1 Running 0 8m38s
創(chuàng)建HPA
- 這里創(chuàng)建一個(gè)HPA，用于控制我們上一步驟中創(chuàng)建的 Deployment，使 Pod 的副本數(shù)量維持在 1 到 10 之間。
- HPA 將通過增加或者減少 Pod 副本的數(shù)量（通過 Deployment）以保持所有 Pod 的平均 CPU 利用率在 50% 以內(nèi)。
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: nginx
namespace: hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
查看部署結(jié)果
# kubectl get hpa -n hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 2 50s
壓測(cè)觀察Pod數(shù)和HPA變化
# 執(zhí)行壓測(cè)命令
# ab -c 1000 -n 100000000 http://127.0.0.1:30792/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
# 觀察變化
# kubectl get hpa -n hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 303%/50% 1 10 7 12m
# kubectl get po -n hpa
NAME READY STATUS RESTARTS AGE
pod/nginx-5c87768612-6b4sl 1/1 Running 0 85s
pod/nginx-5c87768612-99mjb 1/1 Running 0 69s
pod/nginx-5c87768612-cls7r 1/1 Running 0 85s
pod/nginx-5c87768612-hhdr7 1/1 Running 0 69s
pod/nginx-5c87768612-jj744 1/1 Running 0 85s
pod/nginx-5c87768612-kfpkq 1/1 Running 0 27m
pod/nginx-5c87768612-xb94x 1/1 Running 0 69s
可以看出，hpa TARGETS達(dá)到了303%，需要擴(kuò)容。pod數(shù)自動(dòng)擴(kuò)展到了7個(gè)。等待壓測(cè)結(jié)束；
# kubectl get hpa -n hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 20%/50% 1 10 7 16m
---N分鐘后---
# kubectl get hpa -n hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 0%/50% 1 10 7 18m
---再過N分鐘后---
# kubectl get po -n hpa
NAME READY STATUS RESTARTS AGE
nginx-5c87768612-jj744 1/1 Running 0 11m
hpa示例總結(jié)
CPU 利用率已經(jīng)降到 0，所以 HPA 將自動(dòng)縮減副本數(shù)量至 1。
為什么會(huì)將副本數(shù)降為1，而不是我們部署時(shí)指定的replicas: 2呢？
因?yàn)樵趧?chuàng)建HPA時(shí)，指定了副本數(shù)范圍，這里是minReplicas: 1，maxReplicas: 10。所以HPA在縮減副本數(shù)時(shí)減到了1。
?
VPA? 垂直Pod自動(dòng)伸縮
VPA 全稱 Vertical Pod Autoscaler，即垂直 Pod 自動(dòng)擴(kuò)縮容，它根據(jù)容器資源使用率自動(dòng)設(shè)置 CPU 和 內(nèi)存 的requests，從而允許在節(jié)點(diǎn)上進(jìn)行適當(dāng)?shù)恼{(diào)度，以便為每個(gè) Pod 提供適當(dāng)?shù)馁Y源。
它既可以縮小過度請(qǐng)求資源的容器，也可以根據(jù)其使用情況隨時(shí)提升資源不足的容量。
?
- 有些時(shí)候無法通過增加 Pod 數(shù)來擴(kuò)容，比如數(shù)據(jù)庫。這時(shí)候可以通過 VPA 增加 Pod 的大小，比如調(diào)整 Pod 的 CPU 和內(nèi)存：
CA???集群自動(dòng)縮放器
集群自動(dòng)伸縮器（CA）基于待處理的豆莢擴(kuò)展集群節(jié)點(diǎn)。它會(huì)定期檢查是否有任何待處理的豆莢，如果需要更多的資源，并且擴(kuò)展的集群仍然在用戶提供的約束范圍內(nèi)，則會(huì)增加集群的大小。CA與云供應(yīng)商接口，請(qǐng)求更多節(jié)點(diǎn)或釋放空閑節(jié)點(diǎn)。它與GCP、AWS和Azure兼容。版本1.0（GA）與Kubernetes 1.8一起發(fā)布。
- 當(dāng)集群資源不足時(shí)，CA 會(huì)自動(dòng)配置新的計(jì)算資源并添加到集群中：
13. 污點(diǎn)和容忍？
Taint需要和Toleration配合使用，讓Pod避開那些不合適的Node。在 Node上設(shè)置一個(gè)或多個(gè)Taint之后，除非Pod明確聲明能夠容忍這些污 點(diǎn)，否則無法在這些Node上運(yùn)行。
Toleration是Pod的屬性，讓Pod能夠 （注意，只是能夠，而非必須）運(yùn)行在標(biāo)注了Taint的Node上。
污點(diǎn)： 在node節(jié)點(diǎn)上打污點(diǎn)
?? ?pod在調(diào)度的時(shí)候，會(huì)選擇沒有污點(diǎn)的節(jié)點(diǎn)去運(yùn)行
?? ?調(diào)度器在分配pod到那個(gè)節(jié)點(diǎn)上的時(shí)候，會(huì)選擇沒有污點(diǎn)的節(jié)點(diǎn)，去啟動(dòng)pod
容忍：
?? ?是pod有污點(diǎn)的節(jié)點(diǎn)服務(wù)器，任然可以調(diào)度到這個(gè)節(jié)點(diǎn)上去運(yùn)行
?? ?調(diào)度器在調(diào)度的過程中會(huì)查看節(jié)點(diǎn)服務(wù)器是否有污點(diǎn)，然后看pod的策略里是否能容忍這個(gè)污點(diǎn)，如果能容忍就調(diào)度到這個(gè)節(jié)點(diǎn)服務(wù)器上，如果不能容忍就不調(diào)度過去。
?
給node1打上污點(diǎn)
申明可以容忍pod對(duì)污點(diǎn)的不調(diào)度策略
先檢查key是否匹配，匹配是看operator是exists或者equal 表示匹配，effect可以理解為允許在有污點(diǎn)的節(jié)點(diǎn)上啟動(dòng)這個(gè)pod，如果key不匹配，就不允許調(diào)度到這個(gè)污點(diǎn)節(jié)點(diǎn)
equal 操作，需要寫key和value，exists不需要接value
?
為什么master節(jié)點(diǎn)上沒有業(yè)務(wù)pod？
?? ?答案：因?yàn)閙aster節(jié)點(diǎn)上有污點(diǎn)，默認(rèn)業(yè)務(wù)pod都不調(diào)度到master節(jié)點(diǎn)
能容忍任何的污點(diǎn)和排斥等級(jí)
能接受任何污點(diǎn)并且排斥等級(jí)是NoExecute的節(jié)點(diǎn)服務(wù)器
內(nèi)置的污點(diǎn)名字
容忍時(shí)間
tolerationSeconds: 3600
刪除污點(diǎn)：在定義污點(diǎn)的語句后加-
14. 有狀態(tài)的應(yīng)用和無狀態(tài)的應(yīng)用？
有狀態(tài)應(yīng)用
可以說是 需要數(shù)據(jù)存儲(chǔ)功能的服務(wù)、或者指多線程類型的服務(wù)，隊(duì)列等。（mysql數(shù)據(jù)庫、kafka、zookeeper等）。每個(gè)實(shí)例都需要有自己獨(dú)立的持久化存儲(chǔ)
特點(diǎn):
- 縮容的時(shí)候是順序進(jìn)行的，不是隨機(jī)的
- pod的編號(hào)是有順序的
- 每個(gè)實(shí)例都需要有自己獨(dú)立的持久化存儲(chǔ)
案例：
nginx： 無狀態(tài) ： 啟動(dòng)的時(shí)候，不必須按照順序，并且pod是隨機(jī)分配id
? ? ? ? ? ? web服務(wù)： ?訪問任意一個(gè)web服務(wù)器，得到結(jié)果都是一樣的，而且網(wǎng)頁數(shù)據(jù)也是從同一個(gè)地方獲取
mysql： 有狀態(tài) ： 啟動(dòng)的時(shí)候，必須按照順序，并且pod是有固定的編號(hào)，不允許隨機(jī)分配
?? ?master ，slave
?? ?寫數(shù)據(jù)--》master上寫
無狀態(tài)的應(yīng)用
（1）、是指該服務(wù)運(yùn)行的實(shí)例不會(huì)在本地存儲(chǔ)需要持久化的數(shù)據(jù)，并且多個(gè)實(shí)例對(duì)于同一個(gè)請(qǐng)求響應(yīng)的結(jié)果是完全一致的。
（2）、多個(gè)實(shí)例可以共享相同的持久化數(shù)據(jù)。例如：nginx實(shí)例，tomcat實(shí)例等
（3）、相關(guān)的k8s資源有：ReplicaSet、ReplicationController、Deployment等，由于是無狀態(tài)服務(wù)，所以這些控制器創(chuàng)建的pod序號(hào)都是隨機(jī)值。并且在縮容的時(shí)候并不會(huì)明確縮容某一個(gè)pod，而是隨機(jī)的，因?yàn)樗袑?shí)例得到的返回值都是一樣，所以縮容任何一個(gè)pod都可以。
15. ingress相關(guān)
參考：https://blog.csdn.net/ZhouXin1111112/article/details/132669303?spm=1001.2014.3001.5501
16. RBAC相關(guān)
參考：https://blog.csdn.net/ZhouXin1111112/article/details/132670500?spm=1001.2014.3001.5502
17. CI/CD 持續(xù)集成、持續(xù)交付 jenkins
?參考：https://blog.csdn.net/ZhouXin1111112/article/details/132577550?spm=1001.2014.3001.5502
18. pod有多少種狀態(tài)
Kubernetes 中的 Pod 有以下幾種狀態(tài)：
- Pending（掛起）：Pod 已經(jīng)被 Kubernetes API 接受，但它的容器鏡像還沒有被拉取，或者 Pod 所需的節(jié)點(diǎn)資源（CPU、內(nèi)存等）還沒有滿足。在這個(gè)狀態(tài)中，Pod 是不可調(diào)度的。
- Running（運(yùn)行）：Pod 已經(jīng)調(diào)度到了節(jié)點(diǎn)上并且所有容器都已經(jīng)創(chuàng)建，至少有一個(gè)容器仍在運(yùn)行中或者在啟動(dòng)過程中。
- Succeeded（成功）：Pod 中的所有容器都已經(jīng)正常終止，并且不會(huì)再重啟。
- Failed（失敗）：Pod 中至少有一個(gè)容器已經(jīng)以非零狀態(tài)退出。
- Unknown（未知）：無法獲取 Pod 的狀態(tài)。這種狀態(tài)通常是由于與 Pod 相關(guān)的 API 調(diào)用失敗或者 Pod 控制器處于錯(cuò)誤狀態(tài)導(dǎo)致的。
除了上述狀態(tài)之外，Pod還有一些特殊的條件狀態(tài)，它們記錄了 Pod 的一些細(xì)節(jié)信息，例如 Pod 是否處于調(diào)度中、容器鏡像是否拉取成功等。這些狀態(tài)和條件狀態(tài)可以通過?kubectl describe pod?命令獲取，這些條件狀態(tài)：
- PodScheduled：表示 Pod 是否已經(jīng)被調(diào)度到了節(jié)點(diǎn)上。
- ContainersReady：表示 Pod 中的所有容器是否已經(jīng)準(zhǔn)備就緒。
- Initialized：表示 Pod 中的所有容器是否已經(jīng)初始化。
- Ready：表示 Pod 是否已經(jīng)準(zhǔn)備就緒，即所有容器都已經(jīng)啟動(dòng)并且可以接收流量。
- CrashLoopBackOff： 容器退出，kubelet正在將它重啟
- InvalidImageName： 無法解析鏡像名稱
- ImageInspectError： 無法校驗(yàn)鏡像
- ErrImageNeverPull： 策略禁止拉取鏡像
- ImagePullBackOff： 正在重試?yán)?/li>
- RegistryUnavailable： 連接不到鏡像中心
- ErrImagePull：通用的拉取鏡像出錯(cuò)
- CreateContainerConfigError： 不能創(chuàng)建kubelet使用的容器配置
- CreateContainerError： 創(chuàng)建容器失敗
- m.internalLifecycle.PreStartContainer?執(zhí)行hook報(bào)錯(cuò)
- RunContainerError： 啟動(dòng)容器失敗
- PostStartHookError： 執(zhí)行hook報(bào)錯(cuò)
- ContainersNotInitialized： 容器沒有初始化完畢
- ContainersNotReady： 容器沒有準(zhǔn)備完畢
- ContainerCreating：容器創(chuàng)建中
- PodInitializing：pod 初始化中
- DockerDaemonNotReady：docker還沒有完全啟動(dòng)
- NetworkPluginNotReady： 網(wǎng)絡(luò)插件還沒有完全啟動(dòng)
- Evicte: pod被驅(qū)趕
19. pod的重啟策略？
Pod 的 spec 中包含一個(gè) restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默認(rèn)值是 Always。文章來源：http://www.zghlxwxcb.cn/news/detail-695560.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-695560.html
到了這里，關(guān)于kubernetes常見面試問題詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
