1、集群資源分類

名稱空間級別：名稱空間（Namespace）是用于隔離和組織資源的一種機(jī)制。每個資源都屬于一個特定的名稱空間，并且可以通過名稱空間來對資源進(jìn)行分組和管理。

. 工作負(fù)載型資源：pod 、各種控制器

. 服務(wù)發(fā)現(xiàn)及負(fù)載型資源：Service、Ingress

. 配置與存儲型資源：Volume、CSI

. 特殊類型的存儲卷：ConfigMap、Secret、DownwardAPI

集群級別：有一些資源是在整個集群范圍內(nèi)創(chuàng)建和管理的，而不是在特定的名稱空間中?？梢员欢鄠€名稱空間中的資源共享和使用。通過集群級別資源，可以管理和配置整個集群的行為和屬性。

. Node（節(jié)點(diǎn)）：Node 是 Kubernetes 集群中的工作節(jié)點(diǎn)，它可以運(yùn)行容器化的應(yīng)用程序。Node 代表集群中的物理或虛擬機(jī)器，并提供計(jì)算和存儲資源。

.??Namespace（名稱空間）：雖然名稱空間通常是在特定的名稱空間級別創(chuàng)建和管理的，但集群級別也有一個默認(rèn)的名稱空間（default），用于存放沒有明確指定名稱空間的資源。

.?Cluster（集群）：Cluster 是整個 Kubernetes 系統(tǒng)的頂層概念，它由一組相互連接的節(jié)點(diǎn)組成。Cluster 用于管理和協(xié)調(diào)集群中的各種資源。

.?StorageClass（存儲類）：StorageClass 定義了用于創(chuàng)建 PersistentVolume 的存儲配置。它描述了存儲系統(tǒng)的屬性和參數(shù)，并允許在集群級別定義不同的存儲類。

.?ClusterRole（集群角色）和 ClusterRoleBinding（集群角色綁定）：ClusterRole 定義了一組權(quán)限，可以在整個集群范圍內(nèi)使用。ClusterRoleBinding 將 ClusterRole 授予用戶、組或服務(wù)賬戶，以控制其對集群級別資源的訪問權(quán)限。

.?CustomResourceDefinition（自定義資源定義）：CustomResourceDefinition 允許用戶定義自己的自定義資源類型，這些資源類型可以在整個集群范圍內(nèi)使用。

元數(shù)據(jù)類型：根據(jù)指標(biāo)進(jìn)行對應(yīng)操作。如：HPA、PodTemplate、LimitRange

2、YAML文件

http://www.itdecent.cn/p/a2df63b7a901?v=1702538513542

3、pod生命周期

4、InitC

（1）說明

InitC容器與普通容器非常像，除了如下兩點(diǎn)：

（1）Init容器總是運(yùn)行到成功為止；即如果沒有啟動成功，k8s會不斷重啟該pod（除非pod對應(yīng)的restarPolicy為Never，它不會重啟）

（2）每個Init容器必須在下一個Inti容器啟動之前完成

（2）? 測試如下

apiVersion: v1

kind: Pod

metadata:

? name: myapp-pod

? labels:

? ? app: myapp

spec:

? containers:

? ? ? - name: myapp-container

? ? ? image: busybox

? ? command: ['sh','-c','echo The app is running! && sleep 3600']

? initContainers:

? ? ? - name: init-myservice

? ? ? image: busybox

? ? command: ['sh','-c',' until nslookup myservice; do echo waiting for myservice; sleep 2;done;']

? ? -name: init-mydb

? ? image: busybox

? command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

kind: Service

apiVersion: v1

metadata:

? ? name: myservice

spec:

? ports:

? - protocol: TCP

? ? ? ? port: 80

? ? targetPort: 9376

---

kind: Service

apiVersion: v1

metadata:

? ? name: mydb

spec:

? ports:

? ? -protocol: TCP

? ? ? ? port: 80

? ? targetPort: 9377

kubectl?create -f??myservice.yaml? ?# 以yaml形式創(chuàng)建service

kubectl?create -f??mydb.yaml? ?# 以yaml形式創(chuàng)建service

kubectl?create -f??init-pod.yaml? ?# 以yaml形式創(chuàng)建Pod

kubectl? get pod -n kube-system #獲取位于?kube-system?命名空間中的 Pod 列表

kubectl describe pod myapp-pod #查看myapp-pod信息（名稱、運(yùn)行狀態(tài)、事件等）

kubectl log myapp-pod -c test? ?#查看myapp-pod中容器為test 的日志（只有一個容器，無需-c）

（3）特殊說明

1、在Pod啟動過程中，Init容器會按順序在網(wǎng)絡(luò)和數(shù)據(jù)卷初始化之后啟動。每個容器必須在下一個容器啟動之前成功退出；

2、如果由于運(yùn)行時或失敗退出，將導(dǎo)致容器啟動失敗，它會根據(jù)Pod的restartPolicy指定的策略進(jìn)行重試。然而，如果Pod的 restartPolicy 設(shè)置為 Always，Init 容器失敗時會使用 RestartPolicy策略

3、在所有的Init容器沒有成功之前，Pod將不會變成Ready狀態(tài)。Init容器的端口將不會在 Service中進(jìn)行聚集。 正在初始化中的Pod處于Pending狀態(tài)，但應(yīng)該會將Initializing狀態(tài)設(shè)置為 true

4、如果Pod重啟，所有Init容器必須重新執(zhí)行

5、對Init容器spec的修改被限制在容器image字段，修改其他字段都不會生效。更改Init容器的 image字段，等價于重啟該P(yáng)od;

6、Init容器具有應(yīng)用容器的所有字段。除了readinessProbe，因?yàn)镮nit容器無法定義不同于完成(completion)的就緒(readiness)之外的其他狀態(tài)。這會在驗(yàn)證過程中強(qiáng)制執(zhí)行。readinessProbe?用于確定容器是否已準(zhǔn)備好接收流量，而 Init 容器的主要目的是在應(yīng)用容器啟動之前執(zhí)行一些初始化任務(wù)，因此沒有必要進(jìn)行 readiness 探針的檢測。

7、在Pod中的每個app和Init容器的名稱必須唯一;與任何其它容器共享同一個名稱，會在驗(yàn)證時拋出錯誤

5、探針

init C 有一個很明顯的缺點(diǎn)就是，如果init C 容器去探測某個容器（主容器依賴的容器）已經(jīng)啟動，等待init C容器結(jié)束之后，主容器再去訪問該依賴容器，此時那個依賴容器掛了，就出現(xiàn)問題了，這個時候就需要探針來完成。探針可以通過主容器訪問依賴容器，即在主容器內(nèi)對依賴容器進(jìn)行訪問，比較合理。

探針是由kubelet對容器執(zhí)行的定期診斷。要執(zhí)行診斷，kubelet調(diào)用由容器實(shí)現(xiàn)的 Handler。

有三種類型的處理程序:

ExecAction: 在容器內(nèi)執(zhí)行指定命令。如果命令退出時返回碼為0則認(rèn)為診斷成功。

TCPSocketAction: 對指定端口上的容器的IP地址進(jìn)行TCP檢查。如果端口打開，則診斷被認(rèn)為是成功的。

HTTPGetAction: 對指定的端口和路徑上的容器的IP地址執(zhí)行 HTTP Get 請求。如果響應(yīng)的狀態(tài)碼大于等于200且小于400，則診斷被認(rèn)為是成功的

每次探測都將獲得以下三種結(jié)果之一:

成功:容器通過了診斷。

失敗:容器未通過診斷。

未知:診斷失敗，因此不會采取任何行動

如下有兩種探針

livenessProbe：存活檢測，不存活，直接重啟pod

readlinessProbe:就緒檢測，不就緒，不將pod狀態(tài)改為ready

（1）readinessProbe; (就緒探測)?

readinessProbe; (就緒探測) 指示容器是否準(zhǔn)備好服務(wù)請求。如果就緒探測失敗，端點(diǎn)控制器將從與Pod 匹配的所有Service的端點(diǎn)中刪除該P(yáng)od的IP地址。初始延遲之前的就緒狀態(tài)默認(rèn)為Failure。如果容器不提供就緒探針，則默認(rèn)狀態(tài)為 Success。

如下：容器在啟動時，1s后進(jìn)行就緒檢測，檢測index1.html是否存在，不存在，3s后再檢測，有的話，狀態(tài)改為ready

apiVersion: v1

kind: Pod

metadata:

? name: readiness-httpget-pod

? namespace: default

spec:

? containers:

? ? - name: readiness-httpget-container

? ? image: wangyanglinux/myapp:v1

? ? imagePullPolicy: IfNotPresent

?readinessProbe:

?httpGet:

? ? ? ? ? port: 80

? ? ? ? ? path: /index1.html

? ? ? ? initialDelaySeconds: 1? ? ##容器啟動后等待 1 秒后開始執(zhí)行第一次探測。

? ? ? ? periodSeconds: 3? ? ??##每隔 3 秒執(zhí)行一次探測。

創(chuàng)建完之后，比如 readiness-httpget-pod沒同時出現(xiàn)read和running，則說明存在問題。

這里用到一個命令 ，進(jìn)入pod的內(nèi)的某個容器內(nèi)查看明細(xì)

kubectlexecpod名 -c 容器 -it -- /bin/sh

（2）?livenessProbe：(存活探測)

livenessProbe：(存活探測) 指示容器是否正在運(yùn)行。如果存活探測失敗，則kubelet會殺死容器，并且容器將受到其重啟策略的影響。如果容器不提供存活探針，則默認(rèn)狀態(tài)為 Success。

如下：這個存活探針，在容器啟動后的第一秒開始，每隔 3 秒執(zhí)行一次探測命令?test -e /tmp/live，如果?/tmp/live?文件存在，探測成功，容器被認(rèn)為是存活的；如果文件不存在，探測失敗，容器被認(rèn)為出現(xiàn)了故障。

apiVersion: v1

kind: Pod

metadata:

? ? name: liveness-exec-pod

? ? namespace: default

spec:

? containers:

? - name: liveness-exec-container

? ? image: hub.atguigu.com/library/busybox

? ? imagePullPolicy: IfNotPresent

? ? command: ["/bin/sh","-c","touch /tmp/live; sleep 60; rm - rf /tmp/live; sleep 3600"]? ? ? ? ##容器啟動時執(zhí)行的命令，其中包括創(chuàng)建?/tmp/live?文件、等待 60 秒、刪除?/tmp/live?文件、再等待 3600 秒。

?livenessProbe:

? ? ? exec:

? ? ? ? command: ["test","-e","/tmp/live"]? ? ?##探測命令，用于檢測?/tmp/live?文件是否存在。

? ? ? initialDelaySeconds: 1? ? ##容器啟動后等待 1 秒后開始執(zhí)行第一次探測。

? ? ? periodSeconds: 3? ?##每隔 3 秒執(zhí)行一次探測。

如下：這個存活探針，在容器啟動后的第一秒開始，每隔 3 秒發(fā)送一個 HTTP GET 請求到容器的 "http" 端口的 "/index.html" 路徑。如果探測請求返回成功的狀態(tài)碼（2xx 或 3xx），探測成功，容器被認(rèn)為是存活的；如果返回失敗的狀態(tài)碼（4xx 或 5xx）或超時，探測失敗，容器被認(rèn)為出現(xiàn)了故障。

apiVersion: v1

kind: Pod

metadata:

? name: liveness-httpget-pod

? namespace: default

spec:

? containers:

? ? - name: liveness-httpget-container

? ? image: wangyanglinux/myapp:v1

? ? imagePullPolicy: IfNotPresent

? ? ports:? #定義容器暴露的端口列表。

? ? ? - name: http

? ? ? ? containerPort: 80

?????livenessProbe:

?????????httpGet:

? ? ? ? ? ????port: http? ?##指定探測請求發(fā)送到容器暴露的名為 "http" 的端口。改為80亦可

? ? ? ? ????? path: /index1.html

? ? ? ????initialDelaySeconds: 1

? ? ? ????periodSeconds: 3

? ? ????? timeoutSeconds: 10? ? ##探測請求的超時時間為 10 秒。

apiVersion: v1

kind: Pod

metadata:

? name: probe-tcp

? namespace: default

spec:

? containers:

? - name : nginx

? ? image: myapp:v1

?livenessProbe:

? ? ? ? initialDelaySeconds: 5

? ? ? ? timeoutSeconds: 1

?tcpSocket:

? ? ? ? ? ? port : 80

? ? periodSeconds: 3

6、stop 、start

Pod hook(鉤子) 是由Kubernetes 管理的kubelet 發(fā)起的，當(dāng)容器中的進(jìn)程啟動前或者容器中的進(jìn)程終止之前運(yùn)行，這是包含在容器的生命周期之中?？梢酝瑫r為pod 中的所有容器都配置 hook

Hook的類型包括兩種：

exec : 執(zhí)行一段命令

HTTP: 發(fā)送HTTP請求

apiVersion: v1

kind: Pod

metadata:

? name: lifecycle-demo

spec:

? containers:

? ? ? - name: lifecycle-demo-container

? ? ? image: nginx

? ? ? lifecycle:

?postStart:? ? ? ? ? ? ? ? ? ? ? ? ? #在容器啟動后執(zhí)行的鉤子。

? ? ? ? ? ? exec:

? ? ? ? ? ? ? command: ["/bin/sh","-c","echo Hello from the postStart handler"]

?preStop:? ? ? ? ? ? ? ? ? ? ? ? ? ? #在容器終止之前執(zhí)行的鉤子。

? ? ? ? ? ? exec:

? ? ? ? ? ? ? command: ["/bin/sh","-c","echo Hello from the preStop handler"]

?Pod 中PodStatus的phase 可能存在的值

1、掛起(Pending): Pod已被Kubernetes系統(tǒng)接受，但有一個或者多個容器鏡像尚未創(chuàng)建。等待時間包括調(diào)度Pod的時間和通過網(wǎng)絡(luò)下載鏡像的時間，這可能需要花點(diǎn)時間

2、運(yùn)行中(Running):該P(yáng)od已經(jīng)綁定到了一個節(jié)點(diǎn)上，Pod中所有的容器都已被創(chuàng)建。至少有一個容器正在運(yùn)行，或者正處于啟動或重啟狀態(tài)

3、成功(Succeeded):Pod中的所有容器都被成功終止，并且不會再重啟

4、失敗(Failed):Pod中的所有容器都已終止了，并且至少有一個容器是因?yàn)?b>失敗終止。也就是說，容器以非0狀態(tài)退出或者被系統(tǒng)終止