Kubernetes学习笔记（一）：Pod详解：Pod配置、Pod生命周期、Pod调度、容器设计模式
生活随笔
收集整理的這篇文章主要介紹了
Kubernetes学习笔记（一）：Pod详解：Pod配置、Pod生命周期、Pod调度、容器设计模式
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
1、Pod介紹
Pod是Kubernetes進行管理的最小單元，程序要運行必須部署在容器中，而容器必須存在于Pod中
Pod可以認為是容器的封裝，一個Pod中可以存在一個或者多個容器
1）、Pod=進程組
在Kubernetes里面，Pod實際上正是Kubernetes抽象出來的一個可以類比為進程組的概念
由四個進程共同組成的一個應用Helloworld，在Kubernetes里面，實際上會被定義為一個擁有四個容器的Pod
就是說現在有四個職責不同、相互協作的進程，需要放在容器里去運行，在Kubernetes里面并不會把它們放到一個容器里，Kubernetes會把四個獨立的進程分別用四個獨立的容器啟動起來，然后把它們定義在一個Pod里面
所以當Kubernetes把Helloworld給拉起來的時候，實際上會看到四個容器，它們共享了某些資源，這些資源都屬于Pod，所以我們說Pod 在Kubernetes里面只有一個邏輯單位，沒有一個真實的東西對應說這個就是Pod。真正起來在物理上存在的東西，就是四個容器。這四個容器，或者說是多個容器的組合就叫做Pod
Pod是Kubernetes分配資源的一個單位，因為里面的容器要共享某些資源，所以Pod也是Kubernetes的原子調度單位
2）、為什么Pod必須是原子調度單位？
假如現在有兩個容器，它們是緊密協作的，所以它們應該被部署在一個Pod里面。具體來說，第一個容器叫做App，就是業務容器，它會寫日志文件；第二個容器叫做LogCollector，它會把剛剛App容器寫的日志文件轉發到后端的ElasticSearch中
兩個容器的資源需求是這樣的：App容器需要1G內存，LogCollector需要0.5G內存，而當前集群環境的可用內存是這樣一個情況：Node_A：1.25G內存、Node_B：2G內存
假如說現在沒有Pod概念，就只有兩個容器，這兩個容器要緊密協作、運行在一臺機器上?？墒?#xff0c;如果調度器先把App調度到了Node_A上面，接下來會怎么樣呢？這時會發現：LogCollector實際上是沒辦法調度到Node_A上的，因為資源不夠。其實此時整個應用本身就已經出問題了，調度已經失敗了，必須去重新調度
在Kubernetes里，就直接通過Pod這樣一個概念去解決了。因為在Kubernetes里，這樣的一個App容器和LogCollector容器一定是屬于一個Pod的，它們在調度時必然是以一個Pod為單位進行調度，所以這個問題是根本不存在的
3）、Pod里面的容器是超親密關系
Pod里面的容器是超親密關系，大概分為以下幾類：
- 比如說兩個進程之間會發生文件交換，比如一個寫日志，一個讀日志
- 兩個進程之間需要通過localhost或者說是本地的Socket去進行通信，這種本地通信也是超親密關系
- 這兩個容器或者是微服務之間，需要發生非常頻繁的RPC調用，出于性能的考慮，也希望它們是超親密關系
- 兩個容器或者是應用，它們需要共享某些Linux Namespace。最簡單常見的一個例子，就是我有一個容器需要加入另一個容器的Network Namespace。這樣我就能看到另一個容器的網絡設備，和它的網絡信息
4）、Infra container（也叫Pause容器）
每個Pod中都可以包含一個或者多個容器，這些容器可以分為兩類：
-
業務容器（用戶程序所在的容器）：數量可多可少
-
Infra container：每個Pod都會有的一個根容器
1）共享網絡
如上圖所示，這個Pod里有兩個用戶容器A和B，還有一個Infra container。Infra container是一個非常小的鏡像，大概100~200KB左右，是一個匯編語言寫的、永遠處于暫停狀態的容器
整個Pod里Infra container第一個啟動，在Infra containerHold住Network Namespace后，用戶容器就可以加入到Infra container的Network Namespace當中了
所以說一個Pod里面的所有容器，它們看到的網絡視圖是完全一樣的。即：它們看到的網絡設備、IP地址、Mac地址等等，跟網絡相關的信息，其實全是一份，這一份都來自于Pod第一次創建的這個Infra container。這就是Pod解決網絡共享的一個解法
這也就意味著，對于Pod里的容器A和容器B來說：
- 它們可以直接使用localhost進行通信
- 它們看到的網絡設備跟Infra container看到的完全一樣
- 一個Pod只有一個IP地址，也就是這個Pod的Network Namespace對應的IP地址
- 其他的所有網絡資源，都是一個Pod一份，并且被該Pod中的所有容器共享
- Pod的生命周期只跟Infra container一致，而與容器A和B無關
而對于同一個Pod里面的所有用戶容器來說，它們的進出流量，也可以認為都是通過Infra container完成的
2）共享存儲
有了Infra container這個設計之后，共享Volume就簡單多了：Kubernetes只要把所有Volume的定義都設計在Pod層級即可
這樣，一個Volume對應的宿主機目錄對于Pod來說就只有一個，Pod里的容器只要聲明掛載這個Volume，就一定可以共享這個Volume對應的宿主機目錄。比如下面這個例子：
apiVersion: v1 kind: Pod metadata:name: two-containers spec:restartPolicy: Nevervolumes:- name: shared-datahostPath: path: /datacontainers:- name: nginx-containerimage: nginxvolumeMounts:- name: shared-datamountPath: /usr/share/nginx/html- name: debian-containerimage: debianvolumeMounts:- name: shared-datamountPath: /pod-datacommand: ["/bin/sh"]args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]在這個例子中，debian-container和nginx-container都聲明掛載了shared-data這個Volume。而shared-data是hostPath類型。所以，它對應在宿主機上的目錄就是：/data。而這個目錄，其實就被同時綁定掛載進了上述兩個容器當中
這就是nginx-container可以從它的/usr/share/nginx/html目錄中，讀取到debian-container生成的index.html文件的原因
3）Infra container的作用
5）、Pod定義
下面是Pod的資源清單：
apiVersion: v1 # 必選，版本號，例如v1 kind: Pod # 必選，資源類型，例如Pod metadata: # 必選，元數據name: string # 必選，Pod名稱namespace: string # Pod所屬的命名空間，默認為"default"labels: # 自定義標簽列表- name: string spec: # 必選，Pod中容器的詳細定義containers: # 必選，Pod中容器列表- name: string # 必選，容器名稱image: string # 必選，容器的鏡像名稱imagePullPolicy: [ Always|Never|IfNotPresent ] # 鏡像拉取策略command: [string] # 容器的啟動命令列表，如不指定，使用打包時使用的啟動命令args: [string] # 容器的啟動命令參數列表workingDir: string # 容器的工作目錄volumeMounts: # 掛載到容器內部的存儲卷配置- name: string # 引用pod定義的共享存儲卷的名稱，需用volumes[]部分定義的的卷名mountPath: string # 存儲卷在容器內mount的絕對路徑，應少于512字符readOnly: boolean # 是否為只讀模式ports: # 需要暴露的端口庫號列表- name: string # 端口的名稱containerPort: int # 容器需要監聽的端口號hostPort: int # 容器所在主機需要監聽的端口號，默認與Container相同protocol: string # 端口協議，支持TCP和UDP，默認TCPenv: # 容器運行前需設置的環境變量列表- name: string # 環境變量名稱value: string # 環境變量的值resources: # 資源限制和請求的設置limits: # 資源限制的設置cpu: string # Cpu的限制，單位為core數，將用于docker run --cpu-shares參數memory: string # 內存限制，單位可以為Mib/Gib，將用于docker run --memory參數requests: # 資源請求的設置cpu: string # Cpu請求，容器啟動的初始可用數量memory: string # 內存請求，容器啟動的初始可用數量lifecycle: # 生命周期鉤子postStart: # 容器啟動后立即執行此鉤子，如果執行失敗，會根據重啟策略進行重啟preStop: # 容器終止前執行此鉤子，無論結果如何，容器都會終止livenessProbe: # 對Pod內各容器健康檢查的設置，當探測無響應幾次后將自動重啟該容器exec: # 對Pod容器內檢查方式設置為exec方式command: [string] # exec方式需要制定的命令或腳本httpGet: # 對Pod內個容器健康檢查方法設置為HttpGet，需要制定Path、portpath: stringport: numberhost: stringscheme: stringHttpHeaders:- name: stringvalue: stringtcpSocket: # 對Pod內個容器健康檢查方式設置為tcpSocket方式port: numberinitialDelaySeconds: 0 # 容器啟動完成后首次探測的時間，單位為秒timeoutSeconds: 0 # 對容器健康檢查探測等待響應的超時時間，單位秒，默認1秒periodSeconds: 0 # 對容器監控檢查的定期探測時間設置，單位秒，默認10秒一次successThreshold: 0failureThreshold: 0securityContext:privileged: falserestartPolicy: [Always | Never | OnFailure] # Pod的重啟策略nodeName: <string> # 設置NodeName表示將該Pod調度到指定到名稱的node節點上nodeSelector: obeject # 設置NodeSelector表示將該Pod調度到包含這個label的node上imagePullSecrets: # Pull鏡像時使用的secret名稱，以key：secretkey格式指定- name: stringhostNetwork: false # 是否使用主機網絡模式，默認為false，如果設置為true，表示使用宿主機網絡volumes: # 在該pod上定義共享存儲卷列表- name: string # 共享存儲卷名稱 （volumes類型有很多種）emptyDir: {} # 類型為emtyDir的存儲卷，與Pod同生命周期的一個臨時目錄。為空值hostPath: string # 類型為hostPath的存儲卷，表示掛載Pod所在宿主機的目錄path: string # Pod所在宿主機的目錄，將被用于同期中mount的目錄secret: # 類型為secret的存儲卷，掛載集群與定義的secret對象到容器內部scretname: string items: - key: stringpath: stringconfigMap: # 類型為configMap的存儲卷，掛載預定義的configMap對象到容器內部name: stringitems:- key: stringpath: string可通過一個命令來查看每種資源的可配置項
- kubectl explain 資源類型：查看某種資源可以配置的一級屬性
- kubectl explain 資源類型.屬性：查看屬性的子屬性
在Kubernetes中基本所有資源的一級屬性都是一樣的，主要包含5部分：
- apiVersion <string>：版本，由Kubernetes內部定義，版本號必須可以用kubectl api-versions查詢到
- kind <string>：類型，由Kubernetes內部定義，版本號必須可以用kubectl api-resources查詢到
- metadata <Object>：元數據，主要是資源標識和說明，常用的有name、namespace、labels等
- spec <Object>：描述，這是配置中最重要的一部分，里面是對各種資源配置的詳細描述
- status <Object>：狀態信息，里面的內容不需要定義，由Kubernetes自動生成
在上面的屬性中，spec是接下來研究的重點，繼續看下它的常見子屬性:
- containers <[]Object>：容器列表，用于定義容器的詳細信息
- nodeName <String>：根據nodeName的值將Pod調度到指定的Node節點上
- nodeSelector <map[]>：根據NodeSelector中定義的信息選擇將該Pod調度到包含這些label的Node 上
- hostNetwork <boolean>：是否使用主機網絡模式，默認為false，如果設置為true，表示使用宿主機網絡
- volumes <[]Object>：存儲卷，用于定義Pod上面掛在的存儲信息
- restartPolicy <string>：重啟策略，表示Pod在遇到故障的時候的處理策略
2、Pod配置
本小節主要來研究pod.spec.containers屬性，這也是Pod配置中最為關鍵的一項配置
[root@k8s-master ~]# kubectl explain pod.spec.containers KIND: Pod VERSION: v1 RESOURCE: containers <[]Object> # 數組，代表可以有多個容器 FIELDS:args <[]string> # 容器的啟動命令需要的參數列表command <[]string> # 容器的啟動命令列表，如不指定，使用打包時使用的啟動命令env <[]Object> # 容器環境變量的配置envFrom <[]Object>image <string> # 容器需要的鏡像地址imagePullPolicy <string> # 鏡像拉取策略lifecycle <Object>livenessProbe <Object>name <string> -required- # 容器名稱ports <[]Object> # 容器需要暴露的端口號列表readinessProbe <Object>resources <Object> # 資源限制和資源請求的設置securityContext <Object>startupProbe <Object>stdin <boolean>stdinOnce <boolean>terminationMessagePath <string>terminationMessagePolicy <string>tty <boolean>volumeDevices <[]Object>volumeMounts <[]Object>workingDir <string>1）、基本配置
創建dev namespace，后續操作都在該namespace上進行
# 創建namespace [root@k8s-master ~]# kubectl create ns dev namespace/dev created# 查看所有的namespace [root@k8s-master ~]# kubectl get ns NAME STATUS AGE default Active 11h dev Active 12s kube-node-lease Active 11h kube-public Active 11h kube-system Active 11h kubernetes-dashboard Active 11h創建pod-base.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-basenamespace: devlabels:user: admin spec:containers:- name: nginximage: nginx:1.17.1- name: busyboximage: busybox:1.30上面定義了一個比較簡單Pod的配置，里面有兩個容器：
- nginx：用1.17.1版本的nginx鏡像創建（nginx是一個輕量級web容器）
- busybox：用1.30版本的busybox鏡像創建（busybox是一個小巧的linux命令集合）
2）、鏡像拉取
創建pod-imagepullpolicy.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-imagepullpolicynamespace: dev spec:containers:- name: nginximage: nginx:1.17.1imagePullPolicy: Never # 用于設置鏡像拉取策略- name: busyboximage: busybox:1.30imagePullPolicy：用于設置鏡像拉取策略，Kubernetes支持配置三種拉取策略：
- Always：總是從遠程倉庫拉取鏡像（一直遠程下載）
- IfNotPresent：本地有則使用本地鏡像，本地沒有則從遠程倉庫拉取鏡像（本地有就本地 本地沒遠程下載）
- Never：只使用本地鏡像，從不去遠程倉庫拉取，本地沒有就報錯 （一直使用本地）
默認值說明：
-
如果鏡像tag為具體版本號，默認策略是IfNotPresent
-
如果鏡像tag為latest（最終版本），默認策略是Always
修改鏡像拉取策略為IfNotPresent
apiVersion: v1 kind: Pod metadata:name: pod-imagepullpolicynamespace: dev spec:containers:- name: nginximage: nginx:1.17.1imagePullPolicy: IfNotPresent # 用于設置鏡像拉取策略- name: busyboximage: busybox:1.30 # 刪除之前創建的Pod [root@k8s-master ~]# kubectl delete pod pod-imagepullpolicy -n dev pod "pod-imagepullpolicy" deleted# 創建Pod [root@k8s-master ~]# kubectl create -f pod-imagepullpolicy.yaml pod/pod-imagepullpolicy created# 查看Pod詳情 [root@k8s-master ~]# kubectl describe pod pod-imagepullpolicy -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 86s default-scheduler Successfully assigned dev/pod-imagepullpolicy to k8s-node1Normal Pulling 86s kubelet, k8s-node1 Pulling image "nginx:1.17.1"Normal Pulled 52s kubelet, k8s-node1 Successfully pulled image "nginx:1.17.1" # 成功拉取nginx:1.17.1鏡像Normal Created 52s kubelet, k8s-node1 Created container nginxNormal Started 51s kubelet, k8s-node1 Started container nginxNormal Pulled 9s (x4 over 51s) kubelet, k8s-node1 Container image "busybox:1.30" already present on machineNormal Created 9s (x4 over 51s) kubelet, k8s-node1 Created container busyboxNormal Started 8s (x4 over 51s) kubelet, k8s-node1 Started container busyboxWarning BackOff 8s (x5 over 50s) kubelet, k8s-node1 Back-off restarting failed container3）、啟動命令
在前面的案例中，一直有一個問題沒有解決，就是的busybox容器一直沒有成功運行，那么到底是什么原因導致這個容器的故障呢？
原來busybox并不是一個程序，而是類似于一個工具類的集合，Kubernetes集群啟動管理后，它會自動關閉。解決方法就是讓其一直在運行，這就用到了command配置
創建pod-command.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-commandnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1- name: busyboximage: busybox:1.30command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]command：用于在Pod中的容器初始化完畢之后運行一個命令
稍微解釋下上面命令的意思：
"/bin/sh","-c"：使用sh執行命令
touch /tmp/hello.txt;：創建一個/tmp/hello.txt文件
while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;：每隔3秒向文件中寫入當前時間
# 創建Pod [root@k8s-master ~]# kubectl create -f pod-command.yaml pod/pod-command created# 查看Pod狀態，此時發現兩個Pod都正常運行了 [root@k8s-master ~]# kubectl get pod pod-command -n dev NAME READY STATUS RESTARTS AGE pod-command 2/2 Running 0 6s# 進入Pod中的busybox容器，查看文件內容 # 補充一個命令:kubectl exec pod名稱 -n 命名空間 -it -c 容器名稱 /bin/sh 在容器內部執行命令 # 使用這個命令就可以進入某個容器的內部，然后進行相關操作了 [root@k8s-master ~]# kubectl exec pod-command -n dev -it -c busybox /bin/sh / # tail -f /tmp/hello.txt 15:03:45 15:03:48 15:03:51特別說明：
通過上面發現command已經可以完成啟動命令和傳遞參數的功能，為什么這里還要提供一個args選項，用于傳遞參數呢？這其實跟docker有點關系，Kubernetes中的command、args兩項其實是實現覆蓋Dockerfile中ENTRYPOINT的功能
4）、環境變量
創建pod-env.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-envnamespace: dev spec:containers:- name: busyboximage: busybox:1.30command: ["/bin/sh","-c","while true;do /bin/echo $(date +%T);sleep 60; done;"]env: # 設置環境變量列表- name: "username"value: "admin"- name: "password"value: "123456"env：環境變量，用于在Pod中的容器設置環境變量
# 創建Pod [root@k8s-master ~]# kubectl create -f pod-env.yaml pod/pod-env created# 進入容器，輸出環境變量 [root@k8s-master ~]# kubectl exec pod-env -n dev -c busybox -it /bin/sh / # echo $username admin / # echo $password 1234565）、端口設置
首先看下ports支持的子選項：
[root@k8s-master ~]# kubectl explain pod.spec.containers.ports KIND: Pod VERSION: v1 RESOURCE: ports <[]Object> FIELDS:containerPort <integer> -required- # 容器要監聽的端口(0<x<65536)hostIP <string> # 要將外部端口綁定到的主機IP(一般省略)hostPort <integer> # 容器要在主機上公開的端口，如果設置，主機上只能運行容器的一個副本(一般省略) name <string> # 端口名稱，如果指定，必須保證name在pod中是唯一的protocol <string> # 端口協議，必須是UDP、TCP或SCTP，默認為TCP創建pod-ports.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-portsnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1ports: # 設置容器暴露的端口列表- name: nginx-portcontainerPort: 80protocol: TCP # 創建Pod [root@k8s-master ~]# kubectl create -f pod-ports.yaml pod/pod-ports created[root@k8s-master ~]# kubectl get pod pod-ports -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-ports 1/1 Running 0 28s 10.244.2.8 k8s-node1 <none> <none>訪問容器中的程序需要使用的是podIp:containerPort，可以看到該Pod被調度到了k8s-node1節點上
# 在k8s-node1節點上訪問podIp:containerPort [root@k8s-node1 ~]# curl 10.244.2.8:80 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style>body {width: 35em;margin: 0 auto;font-family: Tahoma, Verdana, Arial, sans-serif;} </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p><p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p> </body> </html>6）、資源配額
容器中的程序要運行，肯定是要占用一定資源的，比如cpu和內存等，如果不對某個容器的資源做限制，那么它就可能吃掉大量資源，導致其它容器無法運行。針對這種情況，Kubernetes提供了對內存和cpu的資源進行配額的機制，這種機制主要通過resources選項實現，有兩個子選項：
- limits：用于限制運行時容器的最大占用資源，當容器占用資源超過limits時會被終止，并進行重啟
- requests：用于設置容器需要的最小資源，如果環境資源不夠，容器將無法啟動
可以通過上面兩個選項設置資源的上下限
創建pod-resources.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-resourcesnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1resources: # 資源配額limits: # 限制資源（上限）cpu: "2" # CPU限制，單位是core數memory: "10Gi" # 內存限制requests: # 請求資源（下限）cpu: "1" # CPU限制，單位是core數memory: "10Mi" # 內存限制在這對cpu和memory的單位做一個說明：
- cpu：core數，可以為整數或小數
- memory：內存大小，可以使用Gi、Mi、G、M等形式
修改resources.requests.memory的值為10Gi
apiVersion: v1 kind: Pod metadata:name: pod-resourcesnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1resources: # 資源配額limits: # 限制資源（上限）cpu: "2" # CPU限制，單位是core數memory: "10Gi" # 內存限制requests: # 請求資源（下限）cpu: "1" # CPU限制，單位是core數memory: "10Gi" # 內存限制 # 刪除之前創建的Pod [root@k8s-master ~]# kubectl delete pod pod-resources -n dev pod "pod-resources" deleted# 再次創建Pod [root@k8s-master ~]# kubectl create -f pod-resources.yaml pod/pod-resources created# 查看Pod狀態，發現Pod啟動失敗 [root@k8s-master ~]# kubectl get pod pod-resources -n dev NAME READY STATUS RESTARTS AGE pod-resources 0/1 Pending 0 14s# 查看pod詳情會發現，如下提示 [root@k8s-master ~]# kubectl describe pod pod-resources -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Warning FailedScheduling 49s (x2 over 49s) default-scheduler 0/3 nodes are available: 3 Insufficient memory. # 內存不足3、Pod生命周期
我們一般將Pod對象從創建至終的這段時間范圍稱為Pod的生命周期，它主要包含下面的過程：
- pod創建過程
- 運行初始化容器（init container）過程
- 運行主容器（main container）
- 容器啟動后鉤子（post start）、容器終止前鉤子（pre stop）
- 容器的存活性探測（liveness probe）、就緒性探測（readiness probe）
- pod終止過程
在整個生命周期中，Pod會出現5種狀態，分別如下：
- 掛起（Pending）：apiserver已經創建了pod資源對象，但它尚未被調度完成或者仍處于下載鏡像的過程中
- 運行中（Running）：pod已經被調度至某節點，并且所有容器都已經被kubelet創建完成
- 成功（Succeeded）：pod中的所有容器都已經成功終止并且不會被重啟
- 失敗（Failed）：所有容器都已經終止，但至少有一個容器終止失敗，即容器返回了非0值的退出狀態
- 未知（Unknown）：apiserver無法正常獲取到pod對象的狀態信息，通常由網絡通信失敗所導致
1）、創建和終止
Pod的創建過程
用戶通過kubectl或其他api客戶端提交需要創建的pod信息給apiServer
apiServer開始生成pod對象的信息，并將信息存入etcd，然后返回確認信息至客戶端
apiServer開始反映etcd中的pod對象的變化，其它組件使用watch機制來跟蹤檢查apiServer上的變動
scheduler發現有新的pod對象要創建，開始為Pod分配主機并將結果信息更新至apiServer
node節點上的kubelet發現有pod調度過來，嘗試調用docker啟動容器，并將結果回送至apiServer
apiServer將接收到的pod狀態信息存入etcd中
Pod的終止過程
2）、初始化容器
初始化容器是在Pod的主容器啟動之前要運行的容器，主要是做一些主容器的前置工作，它具有兩大特征：
初始化容器有很多的應用場景，下面列出的是最常見的幾個：
- 提供主容器鏡像中不具備的工具程序或自定義代碼
- 初始化容器要先于應用容器串行啟動并運行完成，因此可用于延后應用容器的啟動直至其依賴的條件得到滿足
接下來做一個案例，模擬下面這個需求：
假設要以主容器來運行nginx，但是要求在運行nginx之前先要能夠連接上mysql和redis所在服務器
為了簡化測試，事先規定好mysql（192.168.5.14）和redis（192.168.5.15）服務器的地址
創建pod-initcontainer.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-initcontainernamespace: dev spec:containers:- name: main-containerimage: nginx:1.17.1ports: - name: nginx-portcontainerPort: 80initContainers:- name: test-mysqlimage: busybox:1.30command: ['sh', '-c', 'until ping 192.168.5.14 -c 1 ; do echo waiting for mysql...; sleep 2; done;']- name: test-redisimage: busybox:1.30command: ['sh', '-c', 'until ping 192.168.5.15 -c 1 ; do echo waiting for reids...; sleep 2; done;']兩個initContainer如果ping不通對應IP就會一直sleep下去，不會退出
# 創建Pod [root@k8s-master ~]# kubectl create -f pod-initcontainer.yaml pod/pod-initcontainer created# 查看pod狀態 # 發現pod卡在啟動第一個初始化容器過程中，后面的容器不會運行 [root@k8s-master ~]# kubectl describe pod pod-initcontainer -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Pulled 74s kubelet, k8s-node2 Container image "busybox:1.30" already present on machineNormal Created 74s kubelet, k8s-node2 Created container test-mysqlNormal Started 74s kubelet, k8s-node2 Started container test-mysqlNormal Scheduled 54s default-scheduler Successfully assigned dev/pod-initcontainer to k8s-node2# 動態查看pod [root@k8s-master ~]# kubectl get pod pod-initcontainer -n dev -w NAME READY STATUS RESTARTS AGE pod-initcontainer 0/1 Init:0/2 0 2m38s為Pod所在節點新增兩個IP，觀察Pod的狀態變化
# 安裝ifconfig [root@k8s-node2 ~]# yum install net-tools -y[root@k8s-node2 ~]# ifconfig enp0s3:1 192.168.5.14 netmask 255.255.255.0 up [root@k8s-node2 ~]# ifconfig enp0s3:1 192.168.5.15 netmask 255.255.255.0 upPod狀態變化如下：
[root@k8s-master ~]# kubectl get pod pod-initcontainer -n dev -w NAME READY STATUS RESTARTS AGE pod-initcontainer 0/1 Init:0/2 0 2m38s pod-initcontainer 0/1 Init:1/2 0 8m26s pod-initcontainer 0/1 Init:1/2 0 8m27s pod-initcontainer 0/1 PodInitializing 0 9m4s pod-initcontainer 1/1 Running 0 9m5s兩個initContainer ping通對應IP后，執行完成，Pod最終創建完成
3）、鉤子函數
鉤子函數能夠感知自身生命周期中的事件，并在相應的時刻到來時運行用戶指定的程序代碼
Kubernetes在主容器的啟動之后和停止之前提供了兩個鉤子函數：
- post start：容器創建之后執行，如果失敗了會重啟容器
- pre stop ：容器終止之前執行，執行完成之后容器將成功終止，在其完成之前會阻塞刪除容器的操作
鉤子處理器支持使用下面三種方式定義動作：
- Exec命令：在容器內執行一次命令
- TCPSocket：在當前容器嘗試訪問指定的socket
- HTTPGet：在當前容器中向某url發起http請求
接下來，以exec方式為例，演示下鉤子函數的使用，創建pod-hook-exec.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-hook-execnamespace: dev spec:containers:- name: main-containerimage: nginx:1.17.1ports:- name: nginx-portcontainerPort: 80lifecycle:postStart: exec: # 在容器啟動的時候執行一個命令，修改掉nginx的默認首頁內容command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]preStop:exec: # 在容器停止之前停止nginx服務command: ["/usr/sbin/nginx","-s","quit"] # 創建pod [root@k8s-master ~]# kubectl create -f pod-hook-exec.yaml pod/pod-hook-exec created# 查看pod [root@k8s-master ~]# kubectl get pods pod-hook-exec -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-hook-exec 1/1 Running 0 13s 10.244.2.9 k8s-node1 <none> <none># 在k8s-node1節點上(Pod所在的節點)訪問podIp:containerPort # nginx的默認首頁內容已經改為了postStart... [root@k8s-node1 ~]# curl 10.244.2.9 postStart...4）、容器探測
容器探測用于檢測容器中的應用實例是否正常工作，是保障業務可用性的一種傳統機制。如果經過探測，實例的狀態不符合預期，那么Kubernetes就會把該問題實例摘除，不承擔業務流量。Kubernetes提供了兩種探針來實現容器探測，分別是：
- liveness probes：存活性探針，用于檢測應用實例當前是否處于正常運行狀態，如果不是，k8s會重啟容器
- readiness probes：就緒性探針，用于檢測應用實例當前是否可以接收請求，如果不能，k8s不會轉發流量
livenessProbe決定是否重啟容器，readinessProbe決定是否將請求轉發給容器
上面兩種探針目前均支持三種探測方式：
- Exec命令：在容器內執行一次命令，如果命令執行的退出碼為0，則認為程序正常，否則不正常
- TCPSocket：將會嘗試訪問一個用戶容器的端口，如果能夠建立這條連接，則認為程序正常，否則不正常
- HTTPGet：調用容器內web應用的url，如果返回的狀態碼在200和399之間，則認為程序正常，否則不正常
下面以liveness probes為例，做幾個演示：
1）方式一：Exec
創建pod-liveness-exec.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-liveness-execnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1ports: - name: nginx-portcontainerPort: 80livenessProbe:exec:command: ["/bin/cat","/tmp/hello.txt"] # 執行一個查看文件的命令 # 創建Pod [root@k8s-master ~]# kubectl create -f pod-liveness-exec.yaml pod/pod-liveness-exec created# 查看Pod詳情 [root@k8s-master ~]# kubectl describe pod pod-liveness-exec -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Pulled 41s kubelet, k8s-node2 Container image "nginx:1.17.1" already present on machineNormal Created 41s kubelet, k8s-node2 Created container nginxNormal Started 41s kubelet, k8s-node2 Started container nginxWarning Unhealthy 22s (x2 over 32s) kubelet, k8s-node2 Liveness probe failed: /bin/cat: /tmp/hello.txt: No such file or directoryNormal Scheduled 21s default-scheduler Successfully assigned dev/pod-liveness-exec to k8s-node2# 觀察上面的信息就會發現nginx容器啟動之后就進行了健康檢查 # 檢查失敗之后，容器被kill掉，然后嘗試進行重啟 # 稍等一會之后，再觀察pod信息，就可以看到RESTARTS不再是0，而是一直增長 [root@k8s-master ~]# kubectl get pods pod-liveness-exec -n dev NAME READY STATUS RESTARTS AGE pod-liveness-exec 0/1 CrashLoopBackOff 4 2m52s2）方式二：TCPSocket
創建pod-liveness-tcpsocket.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-liveness-tcpsocketnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1ports: - name: nginx-portcontainerPort: 80livenessProbe:tcpSocket:port: 8080 # 嘗試訪問8080端口 # 創建Pod [root@k8s-master ~]# kubectl create -f pod-liveness-tcpsocket.yaml pod/pod-liveness-tcpsocket created# 查看Pod詳情 [root@k8s-master ~]# kubectl describe pod pod-liveness-tcpsocket -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 63s default-scheduler Successfully assigned dev/pod-liveness-tcpsocket to k8s-node1Normal Pulled 4s (x3 over 63s) kubelet, k8s-node1 Container image "nginx:1.17.1" already present on machineNormal Created 4s (x3 over 63s) kubelet, k8s-node1 Created container nginxNormal Started 4s (x3 over 62s) kubelet, k8s-node1 Started container nginxWarning Unhealthy 4s (x6 over 54s) kubelet, k8s-node1 Liveness probe failed: dial tcp 10.244.2.10:8080: connect: connection refusedNormal Killing 4s (x2 over 34s) kubelet, k8s-node1 Container nginx failed liveness probe, will be restarted# 觀察上面的信息，發現嘗試訪問8080端口，但是失敗了 # 稍等一會之后，再觀察pod信息，就可以看到RESTARTS不再是0，而是一直增長 [root@k8s-master ~]# kubectl get pod pod-liveness-tcpsocket -n dev NAME READY STATUS RESTARTS AGE pod-liveness-tcpsocket 0/1 CrashLoopBackOff 4 2m30s3）方式三：HTTPGet
創建pod-liveness-httpget.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-liveness-httpgetnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1ports:- name: nginx-portcontainerPort: 80livenessProbe:httpGet: # 其實就是訪問http://127.0.0.1:80/hello scheme: HTTP # 支持的協議，http或者httpsport: 80 # 端口號path: /hello # URI地址 # 創建Pod [root@k8s-master ~]# kubectl create -f pod-liveness-httpget.yaml pod/pod-liveness-httpget created# 查看Pod詳情 [root@k8s-master ~]# kubectl describe pod pod-liveness-httpget -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 39s default-scheduler Successfully assigned dev/pod-liveness-httpget to k8s-node2Normal Pulled 34s (x2 over 59s) kubelet, k8s-node2 Container image "nginx:1.17.1" already present on machineNormal Created 34s (x2 over 59s) kubelet, k8s-node2 Created container nginxNormal Started 34s (x2 over 59s) kubelet, k8s-node2 Started container nginxNormal Killing 34s kubelet, k8s-node2 Container nginx failed liveness probe, will be restartedWarning Unhealthy 24s (x4 over 54s) kubelet, k8s-node2 Liveness probe failed: HTTP probe failed with statuscode: 404# 觀察上面信息，嘗試訪問路徑，但是未找到，出現404錯誤 # 稍等一會之后，再觀察pod信息，就可以看到RESTARTS不再是0，而是一直增長 [root@k8s-master ~]# kubectl get pod pod-liveness-httpget -n dev NAME READY STATUS RESTARTS AGE pod-liveness-httpget 0/1 CrashLoopBackOff 4 2m26s4）liveness其他配置
livenessProbe的子屬性除了這三種方式，還有一些其他的配置：
[root@k8s-master01 ~]# kubectl explain pod.spec.containers.livenessProbe [root@k8s-master ~]# kubectl explain pod.spec.containers.livenessProbe KIND: Pod VERSION: v1 RESOURCE: livenessProbe <Object> FIELDS:exec <Object>failureThreshold <integer> # 連續探測失敗多少次才被認定為失敗。默認是3，最小值是1httpGet <Object>initialDelaySeconds <integer> # 容器啟動后等待多少秒執行第一次探測periodSeconds <integer> # 執行探測的頻率。默認是10秒，最小1秒successThreshold <integer> # 連續探測成功多少次才被認定為成功。默認是1tcpSocket <Object>timeoutSeconds <integer> # 探測超時時間。默認1秒，最小1秒5）、重啟策略
在上一節中，一旦容器探測出現了問題，Kubernetes就會對容器所在的Pod進行重啟，其實這是由Pod的重啟策略決定的，Pod的重啟策略有3種，分別如下：
- Always：容器失效時，自動重啟該容器，這也是默認值
- OnFailure：容器終止運行且退出碼不為0時重啟
- Never：不論狀態為何，都不重啟該容器
重啟策略適用于Pod對象中的所有容器，首次需要重啟的容器，將在其需要時立即進行重啟，隨后再次需要重啟的操作將由kubelet延遲一段時間后進行，且反復的重啟操作的延遲時長以此為10s、20s、40s、80s、160s和300s，300s是最大延遲時長
創建pod-restartpolicy.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-restartpolicynamespace: dev spec:containers:- name: nginximage: nginx:1.17.1ports:- name: nginx-portcontainerPort: 80livenessProbe:httpGet:scheme: HTTPport: 80path: /hellorestartPolicy: Never # 設置重啟策略為Never # 創建Pod [root@k8s-master ~]# kubectl create -f pod-restartpolicy.yaml pod/pod-restartpolicy created# 查看Pod詳情，發現nginx容器失敗 [root@k8s-master ~]# kubectl describe pod pod-restartpolicy -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Pulled 48s kubelet, k8s-node2 Container image "nginx:1.17.1" already present on machineNormal Created 48s kubelet, k8s-node2 Created container nginxNormal Started 48s kubelet, k8s-node2 Started container nginxNormal Scheduled 28s default-scheduler Successfully assigned dev/pod-restartpolicy to k8s-node2Warning Unhealthy 23s (x3 over 43s) kubelet, k8s-node2 Liveness probe failed: HTTP probe failed with statuscode: 404Normal Killing 23s kubelet, k8s-node2 Stopping container nginx# 多等一會，再觀察pod的重啟次數，發現一直是0，并未重啟 [root@k8s-master ~]# kubectl get pod pod-restartpolicy -n dev NAME READY STATUS RESTARTS AGE pod-restartpolicy 0/1 Completed 0 4m10s4、Pod調度
在默認情況下，一個Pod在哪個Node節點上運行，是由Scheduler組件采用相應的算法計算出來的，這個過程是不受人工控制的。但是在實際使用中，這并不滿足的需求，因為很多情況下，我們想控制某些Pod到達某些節點上，那么應該怎么做呢？這就要求了解Kubernetes對Pod的調度規則，Kubernetes提供了四大類調度方式：
- 自動調度：運行在哪個節點上完全由Scheduler經過一系列的算法計算得出
- 定向調度：NodeName、NodeSelector
- 親和性調度：NodeAffinity、PodAffinity、PodAntiAffinity
- 污點（容忍）調度：Taints、Toleration
1）、定向調度
定向調度：指的是利用在Pod上聲明nodeName或者nodeSelector，以此將Pod調度到期望的Node節點上。注意，這里的調度是強制的，這就意味著即使要調度的目標Node不存在，也會向上面進行調度，只不過Pod運行失敗而已
1）NodeName
創建pod-nodename.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-nodenamenamespace: dev spec:containers:- name: nginximage: nginx:1.17.1nodeName: k8s-node1 # 指定調度到k8s-node1節點上 # 創建Pod [root@k8s-master ~]# kubectl create -f pod-nodename.yaml pod/pod-nodename created# 查看Pod調度到NODE屬性，確實是調度到了k8s-node1節點上 [root@k8s-master ~]# kubectl get pod pod-nodename -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodename 1/1 Running 0 28s 10.244.2.11 k8s-node1 <none> <none>修改nodeName的值為k8s-node3（并沒有k8s-node3節點）
apiVersion: v1 kind: Pod metadata:name: pod-nodenamenamespace: dev spec:containers:- name: nginximage: nginx:1.17.1nodeName: k8s-node3 # 指定調度到k8s-node3節點上 # 刪除之前創建的Pod，重新創建Pod [root@k8s-master ~]# kubectl delete pod pod-nodename -n dev pod "pod-nodename" deleted [root@k8s-master ~]# kubectl create -f pod-nodename.yaml pod/pod-nodename created#再次查看，發現已經向k8s-node3節點調度，但是由于不存在k8s-node3節點，所以Pod無法正常運行 [root@k8s-master ~]# kubectl get pod pod-nodename -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodename 0/1 Pending 0 8s <none> k8s-node3 <none> <none>2）NodeSelector
NodeSelector用于將Pod調度到添加了指定標簽的Node節點上。它是通過Kubernetes的label-selector機制實現的，也就是說，在Pod創建之前，會由Scheduler使用MatchNodeSelector調度策略進行label匹配，找出目標Node，然后將Pod調度到目標節點，該匹配規則是強制約束
# 分別為node節點添加標簽 [root@k8s-master ~]# kubectl label node k8s-node1 nodeenv=pro node/k8s-node1 labeled [root@k8s-master ~]# kubectl label node k8s-node2 nodeenv=test node/k8s-node2 labeled# 查看node節點標簽 [root@k8s-master ~]# kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS k8s-master Ready master 19h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master= k8s-node1 Ready <none> 19h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1,kubernetes.io/os=linux,nodeenv=pro k8s-node2 Ready <none> 19h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux,nodeenv=test創建pod-nodeselector.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-nodeselectornamespace: dev spec:containers:- name: nginximage: nginx:1.17.1nodeSelector: nodeenv: pro # 指定調度到具有nodeenv=pro標簽的節點上 # 創建Pod [root@k8s-master ~]# kubectl create -f pod-nodeselector.yaml pod/pod-nodeselector created# 查看Pod調度到NODE屬性，確實是調度到了k8s-node1節點上 [root@k8s-master ~]# kubectl get pod pod-nodeselector -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeselector 1/1 Running 0 29s 10.244.2.12 k8s-node1 <none> <none>修改nodeSelector的值為nodeenv: xxx（不存在打有此標簽的節點）
apiVersion: v1 kind: Pod metadata:name: pod-nodeselectornamespace: dev spec:containers:- name: nginximage: nginx:1.17.1nodeSelector:nodeenv: xxx # 指定調度到具有nodeenv=xxx標簽的節點上 # 刪除之前創建的Pod，重新創建Pod [root@k8s-master ~]# kubectl delete pod pod-nodeselector -n dev pod "pod-nodeselector" deleted [root@k8s-master ~]# kubectl create -f pod-nodeselector.yaml pod/pod-nodeselector created# 再次查看，發現Pod無法正常運行，Node的值為none [root@k8s-master ~]# kubectl get pod pod-nodeselector -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeselector 0/1 Pending 0 26s <none> <none> <none> <none># 查看詳情，發現node selector匹配失敗的提示 [root@k8s-master ~]# kubectl describe pod pod-nodeselector -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Warning FailedScheduling 46s (x2 over 47s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.2）、親和性調度
上一節，介紹了兩種定向調度的方式，使用起來非常方便，但是也有一定的問題，那就是如果沒有滿足條件的Node，那么Pod將不會被運行，即使在集群中還有可用Node列表也不行，這就限制了它的使用場景
基于上面的問題，Kubernetes還提供了一種親和性調度（Affinity）。它在NodeSelector的基礎之上的進行了擴展，可以通過配置的形式，實現優先選擇滿足條件的Node進行調度，如果沒有，也可以調度到不滿足條件的節點上，使調度更加靈活
Affinity主要分為三類：
- nodeAffinity（node親和性）: 以node為目標，解決pod可以調度到哪些node的問題
- podAffinity（pod親和性） : 以pod為目標，解決pod可以和哪些已存在的pod部署在同一個拓撲域中的問題
- podAntiAffinity（pod反親和性） : 以pod為目標，解決pod不能和哪些已存在pod部署在同一個拓撲域中的問題
關于親和性（反親和性）使用場景的說明：
- 親和性：如果兩個應用頻繁交互，那就有必要利用親和性讓兩個應用的盡可能的靠近，這樣可以減少因網絡通信而帶來的性能損耗
- 反親和性：當應用的采用多副本部署時，有必要采用反親和性讓各個應用實例打散分布在各個node上，這樣可以提高服務的高可用性
1）nodeAffinity
首先來看一下nodeAffinity的可配置項：
pod.spec.affinity.nodeAffinityrequiredDuringSchedulingIgnoredDuringExecution Node節點必須滿足指定的所有規則才可以，相當于硬限制nodeSelectorTerms 節點選擇列表matchFields 按節點字段列出的節點選擇器要求列表matchExpressions 按節點標簽列出的節點選擇器要求列表(推薦)key 鍵values 值operator 關系符 支持Exists, DoesNotExist, In, NotIn, Gt, LtpreferredDuringSchedulingIgnoredDuringExecution 優先調度到滿足指定的規則的Node，相當于軟限制 (傾向)preference 一個節點選擇器項，與相應的權重相關聯matchFields 按節點字段列出的節點選擇器要求列表matchExpressions 按節點標簽列出的節點選擇器要求列表(推薦)key 鍵values 值operator 關系符，支持In、NotIn、Exists、DoesNotExist、Gt、Ltweight 傾向權重，在范圍1-100關系符的使用說明：
- matchExpressions:- key: nodeenv # 匹配存在標簽的key為nodeenv的節點operator: Exists- key: nodeenv # 匹配標簽的key為nodeenv，且value是"xxx"或"yyy"的節點operator: Invalues: ["xxx","yyy"]- key: nodeenv # 匹配標簽的key為nodeenv，且value大于"xxx"的節點operator: Gtvalues: "xxx"接下來演示一下requiredDuringSchedulingIgnoredDuringExecution：
創建pod-nodeaffinity-required.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-nodeaffinity-requirednamespace: dev spec:containers:- name: nginximage: nginx:1.17.1affinity: # 親和性設置nodeAffinity: # 設置node親和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制nodeSelectorTerms:- matchExpressions: # 匹配nodeenv的值在["xxx","yyy"]中的標簽- key: nodeenvoperator: Invalues: ["xxx","yyy"] # 創建Pod [root@k8s-master ~]# kubectl create -f pod-nodeaffinity-required.yaml pod/pod-nodeaffinity-required created# 查看Pod狀態(運行失敗) [root@k8s-master ~]# kubectl get pod pod-nodeaffinity-required -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeaffinity-required 0/1 Pending 0 19s <none> <none> <none> <none># 查看Pod的詳情 # 發現調度失敗，提示node選擇失敗 [root@k8s-master ~]# kubectl describe pod pod-nodeaffinity-required -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Warning FailedScheduling 66s (x2 over 66s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.修改matchExpressions匹配nodeenv的值在["pro","yyy"]中的標簽
apiVersion: v1 kind: Pod metadata:name: pod-nodeaffinity-requirednamespace: dev spec:containers:- name: nginximage: nginx:1.17.1affinity: # 親和性設置nodeAffinity: # 設置node親和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制nodeSelectorTerms:- matchExpressions: # 匹配nodeenv的值在["pro","yyy"]中的標簽- key: nodeenvoperator: Invalues: ["pro","yyy"] # 刪除之前創建的Pod，重新創建Pod [root@k8s-master ~]# kubectl delete pod pod-nodeaffinity-required -n dev pod "pod-nodeaffinity-required" deleted [root@k8s-master ~]# kubectl create -f pod-nodeaffinity-required.yaml pod/pod-nodeaffinity-required created# 此時查看，發現調度成功，已經將Pod調度到了k8s-node1上 [root@k8s-master ~]# kubectl get pod pod-nodeaffinity-required -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeaffinity-required 1/1 Running 0 20s 10.244.2.13 k8s-node1 <none> <none>再演示一下requiredDuringSchedulingIgnoredDuringExecution：
創建pod-nodeaffinity-preferred.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-nodeaffinity-preferrednamespace: dev spec:containers:- name: nginximage: nginx:1.17.1affinity: # 親和性設置nodeAffinity: # 設置node親和性preferredDuringSchedulingIgnoredDuringExecution: # 軟限制- weight: 1preference:matchExpressions: # 匹配nodeenv的值在["xxx","yyy"]中的標簽(當前環境沒有)- key: nodeenvoperator: Invalues: ["xxx","yyy"] # 創建Pod [root@k8s-master ~]# kubectl create -f pod-nodeaffinity-preferred.yaml pod/pod-nodeaffinity-preferred created# 查看Pod狀態(運行成功) [root@k8s-master ~]# kubectl get pod pod-nodeaffinity-preferred -n dev NAME READY STATUS RESTARTS AGE pod-nodeaffinity-preferred 1/1 Running 0 13sNodeAffinity規則設置的注意事項：
2）podAffinity
podAffinity主要實現以運行的Pod為參照，實現讓新創建的Pod跟參照Pod在一個區域的功能
首先來看一下podAffinity的可配置項：
pod.spec.affinity.podAffinityrequiredDuringSchedulingIgnoredDuringExecution 硬限制namespaces 指定參照pod的namespacetopologyKey 指定調度作用域labelSelector 標簽選擇器matchExpressions 按節點標簽列出的節點選擇器要求列表(推薦)key 鍵values 值operator 關系符，支持In、NotIn、Exists、DoesNotExistmatchLabels 指多個matchExpressions映射的內容preferredDuringSchedulingIgnoredDuringExecution 軟限制podAffinityTerm 選項namespaces topologyKeylabelSelectormatchExpressions key 鍵values 值operatormatchLabels weight 傾向權重，在范圍1-100topologyKey用于指定調度時作用域，例如：
- 如果指定為kubernetes.io/hostname，那就是以Node節點為區分范圍
- 如果指定為beta.kubernetes.io/os，則以Node節點的操作系統類型來區分
接下來演示一下requiredDuringSchedulingIgnoredDuringExecution：
首先創建一個參照Pod，pod-podaffinity-target.yaml：
apiVersion: v1 kind: Pod metadata:name: pod-podaffinity-targetnamespace: devlabels:podenv: pro # 設置標簽 spec:containers:- name: nginximage: nginx:1.17.1nodeName: k8s-node1 # 將目標Pod名確指定到k8s-node1上 # 創建參照Pod [root@k8s-master ~]# kubectl create -f pod-podaffinity-target.yaml pod/pod-podaffinity-target created# 查看Pod，已經將Pod調度到了k8s-node1上 [root@k8s-master ~]# kubectl get pod pod-podaffinity-target -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-podaffinity-target 1/1 Running 0 15s 10.244.2.14 k8s-node1 <none> <none>創建pod-podaffinity-required.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-podaffinity-requirednamespace: dev spec:containers:- name: nginximage: nginx:1.17.1affinity: # 親和性設置podAffinity: # 設置pod親和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配podenv的值在["xxx","yyy"]中的標簽- key: podenvoperator: Invalues: ["xxx","yyy"]topologyKey: kubernetes.io/hostname上面配置表達的意思是：新Pod必須要與擁有標簽podenv=xxx或者podenv=yyy的Pod在同一Node上，顯然現在沒有這樣Pod
# 創建Pod [root@k8s-master ~]# kubectl create -f pod-podaffinity-required.yaml pod/pod-podaffinity-required created# 查看pod狀態，發現未運行 [root@k8s-master ~]# kubectl get pod pod-podaffinity-required -n dev NAME READY STATUS RESTARTS AGE pod-podaffinity-required 0/1 Pending 0 21s# 查看詳情 [root@k8s-master ~]# kubectl describe pod pod-podaffinity-required -n dev ...... Events:Type Reason Age From Message---- ------ ---- ---- -------Warning FailedScheduling 56s (x2 over 56s) default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod affinity rules, 2 node(s) didn't match pod affinity/anti-affinity.修改matchExpressions匹配podenv的值在["pro","yyy"]中的標簽
apiVersion: v1 kind: Pod metadata:name: pod-podaffinity-requirednamespace: dev spec:containers:- name: nginximage: nginx:1.17.1affinity: # 親和性設置podAffinity: # 設置pod親和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配podenv的值在["pro","yyy"]中的標簽- key: podenvoperator: Invalues: ["pro","yyy"]topologyKey: kubernetes.io/hostname # 刪除之前創建的Pod，重新創建Pod [root@k8s-master ~]# kubectl delete pod pod-podaffinity-required -n dev pod "pod-podaffinity-required" deleted [root@k8s-master ~]# kubectl create -f pod-podaffinity-required.yaml pod/pod-podaffinity-required created# 查看Pod，已經將Pod調度到了k8s-node1上(和參照Pod在同一節點上) [root@k8s-master ~]# kubectl get pod pod-podaffinity-required -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-podaffinity-required 1/1 Running 0 31s 10.244.2.15 k8s-node1 <none> <none>3）podAntiAffinity
podAntiAffinity主要實現以運行的Pod為參照，讓新創建的Pod跟參照Pod不在一個區域中的功能
它的配置方式和選項跟podAffinty是一樣的，這里不再做詳細解釋，直接做一個測試案例
繼續使用上個案例中目標Pod
[root@k8s-master ~]# kubectl get pod pod-podaffinity-target -n dev -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS pod-podaffinity-target 1/1 Running 0 18m 10.244.2.14 k8s-node1 <none> <none> podenv=pro創建pod-podantiaffinity-required.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-podantiaffinity-requirednamespace: dev spec:containers:- name: nginximage: nginx:1.17.1affinity: # 親和性設置podAntiAffinity: # 設置pod親和性requiredDuringSchedulingIgnoredDuringExecution: # 硬限制- labelSelector:matchExpressions: # 匹配podenv的值在["pro"]中的標簽- key: podenvoperator: Invalues: ["pro"]topologyKey: kubernetes.io/hostname上面配置表達的意思是：新Pod必須要與擁有標簽podenv=pro的Pod不在同一Node上
# 創建Pod [root@k8s-master ~]# kubectl create -f pod-podantiaffinity-required.yaml pod/pod-podantiaffinity-required created# 查看Pod，已經將Pod調度到了k8s-node2上(和參照Pod不在同一節點上) [root@k8s-master ~]# kubectl get pod pod-podantiaffinity-required -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-podantiaffinity-required 1/1 Running 0 11s 10.244.1.13 k8s-node2 <none> <none>3）、污點和容忍
1）污點（Taints）
前面的調度方式都是站在Pod的角度上，通過在Pod上添加屬性，來確定Pod是否要調度到指定的Node上，其實我們也可以站在Node的角度上，通過在Node上添加污點屬性，來決定是否允許Pod調度過來
Node被設置上污點之后就和Pod之間存在了一種相斥的關系，進而拒絕Pod調度進來，甚至可以將已經存在的Pod驅逐出去
污點的格式為：key=value:effect, key和value是污點的標簽，effect描述污點的作用，支持如下三個選項：
- PreferNoSchedule：Kubernetes將盡量避免把Pod調度到具有該污點的Node上，除非沒有其他節點可調度
- NoSchedule：Kubernetes將不會把Pod調度到具有該污點的Node上，但不會影響當前Node上已存在的Pod
- NoExecute：Kubernetes將不會把Pod調度到具有該污點的Node上，同時也會將Node上已存在的Pod驅離
使用kubectl設置和去除污點的命令示例如下：
# 設置污點 kubectl taint node k8s-node1 key=value:effect# 去除污點 kubectl taint node k8s-node1 key:effect-# 去除所有污點 kubectl taint node k8s-node1 key-接下來，演示下污點的效果：
暫時停止k8s-node2節點，關閉該節點的虛擬機，關閉后k8s-node2狀態為NotReady：
[root@k8s-master ~]# kubectl get node NAME STATUS ROLES AGE VERSION k8s-master Ready master 21h v1.18.0 k8s-node1 Ready <none> 21h v1.18.0 k8s-node2 NotReady <none> 21h v1.18.0 # 為k8s-node1設置污點(PreferNoSchedule) [root@k8s-master ~]# kubectl taint node k8s-node1 tag=test:PreferNoSchedule node/k8s-node1 tainted [root@k8s-master ~]# kubectl describe node k8s-node1 Name: k8s-node1 Roles: <none> Labels: beta.kubernetes.io/arch=amd64beta.kubernetes.io/os=linuxkubernetes.io/arch=amd64kubernetes.io/hostname=k8s-node1kubernetes.io/os=linuxnodeenv=pro Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"3a:ce:27:0c:c1:6c"}flannel.alpha.coreos.com/backend-type: vxlanflannel.alpha.coreos.com/kube-subnet-manager: trueflannel.alpha.coreos.com/public-ip: 10.0.2.15kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.socknode.alpha.kubernetes.io/ttl: 0volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Mon, 07 Feb 2022 10:13:56 +0800 Taints: tag=test:PreferNoSchedule ......# 創建pod1 [root@k8s-master ~]# kubectl run taint1 --image=nginx:1.17.1 -n dev pod/taint1 created [root@k8s-master ~]# kubectl get pod -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES taint1 1/1 Running 0 14s 10.244.2.17 k8s-node1 <none> <none># 為k8s-node1設置污點(取消PreferNoSchedule，設置NoSchedule) [root@k8s-master ~]# kubectl taint node k8s-node1 tag:PreferNoSchedule- node/k8s-node1 untainted [root@k8s-master ~]# kubectl taint node k8s-node1 tag=test:NoSchedule node/k8s-node1 tainted [root@k8s-master ~]# kubectl describe node k8s-node1 Name: k8s-node1 Roles: <none> Labels: beta.kubernetes.io/arch=amd64beta.kubernetes.io/os=linuxkubernetes.io/arch=amd64kubernetes.io/hostname=k8s-node1kubernetes.io/os=linuxnodeenv=pro Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"3a:ce:27:0c:c1:6c"}flannel.alpha.coreos.com/backend-type: vxlanflannel.alpha.coreos.com/kube-subnet-manager: trueflannel.alpha.coreos.com/public-ip: 10.0.2.15kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.socknode.alpha.kubernetes.io/ttl: 0volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Mon, 07 Feb 2022 10:13:56 +0800 Taints: tag=test:NoSchedule ......# 創建pod2 [root@k8s-master ~]# kubectl run taint2 --image=nginx:1.17.1 -n dev pod/taint2 created [root@k8s-master ~]# kubectl get pod -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES taint1 1/1 Running 0 3m16s 10.244.2.17 k8s-node1 <none> <none> taint2 0/1 Pending 0 52s <none> <none> <none> <none># 為k8s-node1設置污點(取消NoSchedule，設置NoExecute) [root@k8s-master ~]# kubectl taint node k8s-node1 tag:NoSchedule- node/k8s-node1 untainted [root@k8s-master ~]# kubectl taint node k8s-node1 tag=test:NoExecute node/k8s-node1 tainted [root@k8s-master ~]# kubectl describe node k8s-node1 Name: k8s-node1 Roles: <none> Labels: beta.kubernetes.io/arch=amd64beta.kubernetes.io/os=linuxkubernetes.io/arch=amd64kubernetes.io/hostname=k8s-node1kubernetes.io/os=linuxnodeenv=pro Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"3a:ce:27:0c:c1:6c"}flannel.alpha.coreos.com/backend-type: vxlanflannel.alpha.coreos.com/kube-subnet-manager: trueflannel.alpha.coreos.com/public-ip: 10.0.2.15kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.socknode.alpha.kubernetes.io/ttl: 0volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Mon, 07 Feb 2022 10:13:56 +0800 Taints: tag=test:NoExecute ......# 創建pod3 [root@k8s-master ~]# kubectl run taint3 --image=nginx:1.17.1 -n dev pod/taint3 created # 之前創建的pod1和pod2已被刪除，pod3也無法調度 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE taint3 0/1 Pending 0 11s小提示：
使用kubeadm搭建的集群，默認就會給master節點添加一個污點標記，所以Pod就不會調度到master節點上
2）容忍（Toleration）
上面介紹了污點的作用，我們可以在Node上添加污點用于拒絕Pod調度上來，但是如果就是想將一個Pod調度到一個有污點的Node上去，這時候應該怎么做呢？這就要使用到容忍
污點就是拒絕，容忍就是忽略，Node通過污點拒絕Pod調度上去，Pod通過容忍忽略拒絕
下面先通過一個案例看下效果：
創建pod-toleration.yaml文件，內容如下：
apiVersion: v1 kind: Pod metadata:name: pod-tolerationnamespace: dev spec:containers:- name: nginximage: nginx:1.17.1tolerations: # 添加容忍- key: "tag" # 要容忍的污點的keyoperator: "Equal" # 操作符value: "test" # 容忍的污點的valueeffect: "NoExecute" # 添加容忍的規則，這里必須和標記的污點規則相同 # 創建Pod [root@k8s-master ~]# kubectl create -f pod-toleration.yaml pod/pod-toleration created# 添加容忍的pod創建成功(pod-toleration)，沒有容忍規則的pod(taint3)依然無法創建 [root@k8s-master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pod-toleration 1/1 Running 0 8s taint3 0/1 Pending 0 7m10s下面看一下容忍的詳細配置：
[root@k8s-master ~]# kubectl explain pod.spec.tolerations KIND: Pod VERSION: v1 RESOURCE: tolerations <[]Object> FIELDS:effect <string> # 對應污點的effect，空意味著匹配所有影響key <string> # 對應著要容忍的污點的鍵，空意味著匹配所有的鍵operator <string> # key-value的運算符，支持Equal和Exists(默認)tolerationSeconds <integer> # 容忍時間，當effect為NoExecute時生效，表示pod在Node上的停留時間value <string> # 對應著要容忍的污點的值5、容器設計模式
1）、案例
比如，現在要發布一個應用，這個應用是Java寫的，有一個war包需要把它放到Tomcat的web APP目錄下面，這樣就可以把它啟動起來了。可是像這樣一個war包或Tomcat這樣一個容器的話，怎么去做，怎么去發布？
-
方法一：可以把war包和Tomcat打包放進一個鏡像里面。但是這樣帶來一個問題，無論是要更新war包還是要更新Tomcat，都要重新做一個新的鏡像，這是比較麻煩的
-
方式二：鏡像里面只打包Tomcat。它就是一個Tomcat，但是需要使用數據卷的方式，比如說hostPath，從宿主機上把war包掛載進Tomcat容器中，掛到web APP目錄下面，這樣把這個容器啟用起來之后，里面就能用了。這樣做的問題是需要維護一套分布式存儲系統。因為這個容器可能第一次啟動是在宿主機A上面，第二次重新啟動就可能跑到B上去了，容器它是一個可遷移的東西，它的狀態是不保持的。所以必須維護一套分布式存儲系統，使容器不管是在A還是在B上，都可以找到這個war包
2）、InitContainer
在上圖的yaml里，首先定義一個Init Container，它只做一件事情，就是把war包從鏡像里拷貝到一個Volume里面，它做完這個操作就退出了，所以Init Container會比用戶容器先啟動，并且嚴格按照定義順序來依次執行
然后，這個關鍵在于剛剛拷貝到的這樣一個目的目錄：APP目錄，實際上是一個Volume。而一個Pod里面的多個容器，它們是可以共享Volume的，所以現在這個Tomcat容器，只是打包了一個Tomcat鏡像。但在啟動的時候，要聲明使用APP目錄作為我的Volume，并且要把它們掛載在web APP目錄下面
而這個時候，由于前面已經運行過了一個Init Container，已經執行完拷貝操作了，所以這個Volume里面已經存在了應用的war包：就是sample.war。等到第二步執行啟動這個Tomcat容器的時候，去掛這個Volume，一定能在里面找到前面拷貝來的sample.war
所以這是一個通過組合兩個不同角色的容器，并且按照這樣一些像Init Container這樣一種編排方式，統一的去打包這樣一個應用，把它用Pod來去做的非常典型的一個例子。像這樣的一個概念，在Kubernetes里面就是一個非常經典的容器設計模式，叫做Sidecar
3）、容器設計模式：Sidecar
什么是Sidecar？就是說其實在Pod里面，可以定義一些專門的容器，來執行主業務容器所需要的一些輔助工作
這種做法一個非常明顯的優勢就是在于其實將輔助功能從我的業務容器解耦了，所以能夠獨立發布Sidecar容器，并且更重要的是這個能力是可以重用的，即同樣的一個監控Sidecar或者日志Sidecar，可以被全公司的人共用的
1）Sidecar：應用與日志收集
應用日志收集，業務容器將日志寫在一個Volume里面，而由于Volume在Pod里面是被共享的，所以日志容器——即Sidecar容器一定可以通過共享該Volume，直接把日志文件讀出來，然后存到遠程存儲里面，或者轉發到另外一個例子?，F在業界常用的Fluentd日志進程或日志組件，基本上都是這樣的工作方式
2）Sidecar：代理容器
假如現在有個Pod需要訪問一個外部系統，或者一些外部服務，但是這些外部系統是一個集群，那么這個時候如何通過一個統一的、簡單的方式，用一個IP地址，就把這些集群都訪問到？有一種方法就是：修改代碼。因為代碼里記錄了這些集群的地址；另外還有一種解耦的方法，即通過Sidecar代理容器
簡單說，單獨寫一個這么小的Proxy，用來處理對接外部的服務集群，它對外暴露出來只有一個IP地址就可以了。所以接下來，業務容器主要訪問Proxy，然后由Proxy去連接這些服務集群，這里的關鍵在于Pod里面多個容器是通過localhost直接通信的，因為它們同屬于一個network Namespace，網絡視圖都一樣，所以它們倆通信localhost，并沒有性能損耗
所以說代理容器除了做了解耦之外，并不會降低性能，更重要的是，像這樣一個代理容器的代碼就又可以被全公司重用了
3）Sidecar：適配器容器
比如，現在業務容器暴露出來的監控接口是/metrics，訪問這個這個容器的metrics的這個URL就可以拿到了。可是現在，這個監控系統升級了，它訪問的URL是/health，我只認得暴露出health健康檢查的URL，才能去做監控，metrics不認識。那這個怎么辦？那就需要改代碼了，但可以不去改代碼，而是額外寫一個Adapter，用來把所有對health的這個請求轉發給metrics就可以了，所以這個Adapter對外暴露的是health這樣一個監控的URL，這就可以了
這樣的關鍵還在于Pod之中的容器是通過localhost直接通信的，所以沒有性能損耗，并且這樣一個Adapter容器可以被全公司重用起來
參考：
Kubernetes(K8S) 入門進階實戰完整教程，黑馬程序員K8S全套教程（基礎+高級）
極客時間 《深入剖析Kubernetes》
云原生技術公開課
總結
以上是生活随笔為你收集整理的Kubernetes学习笔记（一）：Pod详解：Pod配置、Pod生命周期、Pod调度、容器设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Struts2的s标签库使用方式
- 下一篇： transform（平移、旋转、缩放、3