Kubernetes之深入瞭解Pod

標籤：重啟   type   des   color   rpo   綁定   ems   基本   包含   

  1、yaml格式的Pod設定檔內容及註解　　深入Pod之前，首先我們來瞭解下Pod的yaml整體檔案內容及功能註解。如下：

# yaml格式的pod定義檔案完整內容：apiVersion: v1        #必選，版本號碼，例如v1kind: Pod       #必選，Podmetadata:       #必選，中繼資料  name: string        #必選，Pod名稱  namespace: string     #必選，Pod所屬的命名空間  labels:       #自訂標籤    - name: string      #自訂標籤名字  annotations:        #自訂注釋列表    - name: stringspec:         #必選，Pod中容器的詳細定義  containers:       #必選，Pod中容器列表  - name: string      #必選，容器名稱    image: string     #必選，容器的鏡像名稱    imagePullPolicy: [Always | Never | IfNotPresent]  #擷取鏡像的策略 Alawys表示下載鏡像 IfnotPresent表示優先使用本地鏡像，否則下載鏡像，Nerver表示僅使用本地鏡像    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，預設TCP    env:        #容器運行前需設定的環境變數列表    - 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      #記憶體清楚，容器啟動的初始可用數量    livenessProbe:      #對Pod內個容器健全狀態檢查的設定，當探測無響應幾次後將自動重啟該容器，檢查方法有exec、httpGet和tcpSocket，對一個容器只需設定其中一種方法即可      exec:       #對Pod容器內檢查方式設定為exec方式        command: [string]   #exec方式需要制定的命令或指令碼      httpGet:        #對Pod內個容器健全狀態檢查方法設定為HttpGet，需要制定Path、port        path: string        port: number        host: string        scheme: string        HttpHeaders:        - name: string          value: string      tcpSocket:      #對Pod內個容器健全狀態檢查方式設定為tcpSocket方式         port: number       initialDelaySeconds: 0   #容器啟動完成後首次探測的時間，單位為秒       timeoutSeconds: 0    #對容器健全狀態檢查探測等待響應的逾時時間，單位秒，預設1秒       periodSeconds: 0     #對容器監控檢查的定期探測時間設定，單位秒，預設10秒一次       successThreshold: 0       failureThreshold: 0       securityContext:         privileged: false    restartPolicy: [Always | Never | OnFailure] #Pod的重啟策略，Always表示一旦不管以何種方式終止運行，kubelet都將重啟，OnFailure表示只有Pod以非0退出碼退出才重啟，Nerver表示不再重啟該Pod    nodeSelector: obeject   #設定NodeSelector表示將該Pod調度到包含這個label的node上，以key：value的格式指定    imagePullSecrets:     #Pull鏡像時使用的secret名稱，以key：secretkey格式指定    - name: string    hostNetwork: false      #是否使用主機網路模式，預設為false，如果設定為true，表示使用宿主機網路    volumes:        #在該pod上定義共用儲存卷列表    - name: string      #共用儲存卷名稱 （volumes類型有很多種）      emptyDir: {}      #類型為emtyDir的儲存卷，與Pod同生命週期的一個臨時目錄。為空白值      hostPath: string      #類型為hostPath的儲存卷，表示掛載Pod所在宿主機的目錄        path: string      #Pod所在宿主機的目錄，將被用於同期中mount的目錄      secret:       #類型為secret的儲存卷，掛載叢集與定義的secre對象到容器內部        scretname: string           items:              - key: string          path: string      configMap:      #類型為configMap的儲存卷，掛載預定義的configMap對象到容器內部        name: string        items:        - key: string          path: string     

　

2、Pod基本用法：　　在使用docker時，我們可以使用docker run命令建立並啟動一個容器，而在Kubernetes系統中對長時間啟動並執行容器要求是：其主程式需要一直在前台運行。如果我們建立的docker鏡像的啟動命令是後台執行程式，例如Linux指令碼：　　nohup ./startup.sh &　　則kubelet建立包含這個容器的pod後運行完該命令，即認為Pod執行結束，之後根據RC中定義的pod的replicas副本數量生產一個新的pod，而一旦建立出新的pod，將在執行完命令後陷入無限迴圈的過程中，這就是Kubernetes需要我們建立的docker鏡像以一個前台命令作為啟動命令的原因。　　對於無法改造為前台執行的應用，也可以使用開源工具supervisor輔助進行前台啟動並執行功能。 ****Pod可以由一個或多個容器組合而成例如：兩個容器應用的前端frontend和redis為緊耦合的關係，應該組合成一個整體對外提供服務，則應該將這兩個打包為一個pod.設定檔frontend-localredis-pod.yaml如下：

apiVersion:v1kind: Podmetadata:  name: redis-php  label:    name: redis-phpspec:  containers:  - name: frontend    image: kubeguide/guestbook-php-frontend:localredis    ports:    - containersPort: 80  - name: redis-php    image:kubeguide/redis-master    ports:    - containersPort: 6379

　　

　　屬於一個Pod的多個容器應用之間相互訪問只需要通過localhost就可以通訊，似的這一組容器被綁定在一個環境中。　　使用kubectl create建立該Pod後，get Pod資訊可以看到如：

#kubectl get godsNAME READY STATUS RESTATS AGEredis-php 2/2 Running 0 10m

　　可以看到READY資訊為2/2，表示Pod中的兩個容器都成功運行了.

　　查看pod的詳細資料，可以看到兩個容器的定義和建立過程。

[[email protected] ~]# kubectl describe redis-phpthe server doesn‘t have a resource type "redis-php"[[email protected] ~]# kubectl describe pod redis-phpName: redis-phpNamespace: defaultNode: kubernetes-minion/10.0.0.23Start Time: Wed, 12 Apr 2017 09:14:58 +0800Labels: name=redis-phpStatus: RunningIP: 10.1.24.2Controllers: <none>Containers:nginx:Container ID: docker://d05b743c200dff7cf3b60b7373a45666be2ebb48b7b8b31ce0ece9be4546ce77Image: nginxImage ID: docker-pullable://docker.io/[email protected]:e6693c20186f837fc393390135d8a598a96a833917917789d63766cab6c59582Port: 80/TCPState: RunningStarted: Wed, 12 Apr 2017 09:19:31 +0800

　　

3、靜態Pod　　靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，並且kubelet無法對他們進行健全狀態檢查。靜態Pod總是由kubelet進行建立，並且總是在kubelet所在的Node上運行。建立靜態Pod有兩種方式：設定檔或者HTTP方式1）設定檔方式　　首先，需要設定kubelet的啟動參數"--config",指定kubelet需要監控的設定檔所在的目錄，kubelet會定期掃描該目錄，冰根據目錄中的 .yaml或 .json檔案進行建立操作假設配置目錄為/etc/kubelet.d/配置啟動參數:--config=/etc/kubelet.d/,然後重啟kubelet服務後，再宿主機受用docker ps或者在Kubernetes Master上都可以看到指定的容器在列表中由於靜態pod無法通過API Server直接管理，所以在master節點嘗試刪除該pod，會將其變為pending狀態，也不會被刪除

#kubetctl delete pod static-web-node1pod "static-web-node1" deleted#kubectl get podsNAME READY STATUS RESTARTS AGEstatic-web-node1 0/1 Pending 0 1s

　　

　　要刪除該pod的操作只能在其所在的Node上操作，將其定義的.yaml檔案從/etc/kubelet.d/目錄下刪除

#rm -f /etc/kubelet.d/static-web.yaml#docker ps

　　

4、Pod容器共用Volume　　Volume類型包括：emtyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、gitRepo、secret、nfs、scsi、glusterfs、persistentVolumeClaim、rbd、flexVolume、cinder、cephfs、flocker、downwardAPI、fc、azureFile、configMap、vsphereVolume等等，可以定義多個Volume，每個Volume的name保持唯一。在同一個pod中的多個容器能夠共用pod層級的儲存卷Volume。Volume可以定義為各種類型，多個容器各自進行掛載操作，講一個Volume掛載為容器內需要的目錄。如：

 

　　如中的Pod中包含兩個容器：tomcat和busybox，在pod層級設定Volume “app-logs”，用於tomcat想其中寫記錄檔，busybox讀記錄檔。設定檔如下：

apiVersion:v1kind: Podmetadata:  name: redis-php  label:    name: volume-podspec:  containers:  - name: tomcat    image: tomcat    ports:    - containersPort: 8080    volumeMounts:    - name: app-logs      mountPath: /usr/local/tomcat/logs  - name: busybox    image:busybox    command: ["sh","-C","tail -f /logs/catalina*.log"]  volumes:  - name: app-logs    emptyDir:{}

busybox容器可以通過kubectl logs查看輸出內容

#kubectl logs volume-pod -c busybox　

tomcat容器產生的記錄檔可以登入容器查看

#kubectl exec -ti volume-pod -c tomcat -- ls /usr/local/tomcat/logs

5.Pod的組態管理  .......6.Pod生命週期和重啟策略　　Pod在整個生命週期過程中被定義為各種狀態，熟悉Pod的各種狀態有助於理解如何設定Pod的調度策略、重啟策略　　Pod的狀態包含以下幾種，　　　　Pod的重啟策略（RestartPolicy）應用於Pod內所有的容器，並且僅在Pod所處的Node上由kubelet進行判斷和重啟操作。當某哥容器異常退出或者健全狀態檢查石柏師，kubelet將根據RestartPolicy的設定進行相應的操作　　Pod的重啟策略包括Always、OnFailure及Nerver，預設值為Always。　　kubelet重啟失效容器的時間間隔以sync-frequency乘以2n來計算，例如1、2、4、8倍等，最長延時5分鐘，並且成功重啟後的10分鐘後重設該事件。　　Pod的重啟策略和控制方式息息相關，當前可用於管理Pod的控制器寶庫ReplicationController、Job、DaemonSet及直接通過kubelet管理（靜態Pod），每種控制器對Pod的重啟策略要求如下：

• • RC和DaemonSet：必須設定為Always，需要保證該容器持續運行
  • Job：OnFailure或Nerver，確保容器執行完成後不再重啟
  • kubelet：在Pod失效時重啟他，不論RestartPolicy設定什麼值，並且也不會對Pod進行健全狀態檢查

  7、Pod健全狀態檢查　　對Pod的健全狀態檢查可以通過兩類探針來檢查：LivenessProbe和ReadinessProbe

• • LivenessProbe探針：用於判斷容器是否存活（running狀態），如果LivenessProbe探針探測到容器不健康，則kubelet殺掉該容器，並根據容器的重啟策略做響應處理
  • ReadinessProbe探針：用於判斷容器是否啟動完成（ready狀態），可以接受請求。如果ReadinessProbe探針探測失敗，則Pod的狀態被修改。Endpoint Controller將從service的Endpoint中刪除包含該容器所在的Pod的Endpoint。

　　kubelet定製執行LivenessProbe探針來診斷容器的健康情況。LivenessProbe有三種事項方式。 （1）ExecAction：在容器內部執行一個命令，如果該命令的傳回值為0，則表示容器健康例：

apiVersion:v1kind: Podmetadata:  name: liveness-exec  label:    name: livenessspec:  containers:  - name: tomcat    image: grc.io/google_containers/tomcat    args:    - /bin/sh    - -c    - echo ok >/tmp.health;sleep 10; rm -fr /tmp/health;sleep 600    livenessProbe:      exec:        command:        - cat        - /tmp/health      initianDelaySeconds:15      timeoutSeconds:1　

（2）TCPSocketAction：通過容器ip地址和連接埠號碼執行TCP檢查，如果能夠建立tcp串連表明容器健康例：

kind: Podmetadata:  name: pod-with-healthcheckspec:  containers:  - name: nginx    image: nginx    livenessProbe:      tcpSocket:         port: 80      initianDelaySeconds:30      timeoutSeconds:1

（3）HTTPGetAction：通過容器Ip地址、連接埠號碼及路徑調用http get方法，如果響應的狀態嗎大於200且小於400，則認為容器健康例：

apiVersion:v1kind: Podmetadata:  name: pod-with-healthcheckspec:  containers:  - name: nginx    image: nginx    livenessProbe:      httpGet:         path: /_status/healthz        port: 80      initianDelaySeconds:30      timeoutSeconds:1

　　

對於每種探針方式，都需要設定initialDelaySeconds和timeoutSeconds兩個參數，它們含義如下：

• initialDelaySeconds：啟動容器後首次監控檢查的等待時間，單位秒
• timeouSeconds：健全狀態檢查發送請求後等待響應的逾時時間，單位秒。當發生逾時就被認為容器無法提供服務無，該容器將被重啟

  8.玩轉Pod調度　　在Kubernetes系統中，Pod在大部分情境下都只是容器的載體而已，通常需要通過RC、Deployment、DaemonSet、Job等對象來完成Pod的調度和自動控制功能。8.1 RC、Deployment：全自動調度　　RC的主要功能之一就是自動部署容器應用的多份副本，以及持續監控副本的數量，在叢集內始終維護使用者指定的副本數量。在調度策略上，除了使用系統內建的調度演算法選擇合適的Node進行調度，也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node進行調度。1）NodeSelector:定向調度　　Kubernetes Master上的scheduler服務（kube-Scheduler進程）負責實現Pod的調度，整個過程通過一系列複雜的演算法，最終為每個Pod計算出一個最佳的目標節點，通常我們無法知道Pod最終會被調度到哪個節點上。實際情況中，我們需要將Pod調度到我們指定的節點上，可以通過Node的標籤和pod的nodeSelector屬性相匹配來達到目的。（1）首先通過kubectl label命令給目標Node打上標籤kubectl label nodes <node-name> <label-key>=<label-value>例：

#kubectllabel nodes k8s-node-1 zonenorth

（2）然後在Pod定義中加上nodeSelector的設定例：

apiVersion:v1kind: Podmetadata:  name: redis-master  label:    name: redis-masterspec:  replicas: 1  selector:    name: redis-master    template:      metadata:        labels:          name: redis-master      spec:        containers:        - name: redis-master          images: kubeguide/redis-master          ports:          - containerPort: 6379        nodeSelector:          zone: north　

運行kubectl create -f命令建立Pod，scheduler就會將該Pod調度到擁有zone=north標籤的Node上。 如果多個Node擁有該標籤，則會根據調度演算法在該組Node上選一個可用的進行Pod調度。需要注意的是：如果叢集中沒有擁有該標籤的Node，則這個Pod也無法被成功調度。 2）NodeAffinity：親和性調度該調度策略是將來替換NodeSelector的新一代調度策略。由於NodeSelector通過Node的Label進行精確匹配，所有NodeAffinity增加了In、NotIn、Exists、DoesNotexist、Gt、Lt等操作符來選擇Node。調度側露更加靈活。 8.2 DaemonSet：特定情境調度DaemonSet用於管理叢集中每個Node上僅運行一份Pod的副本執行個體，

 

這種用法適合一些有下列需求的應用：

• 在每個Node上運行個以GlusterFS儲存或者ceph儲存的daemon進程
• 在每個Node上運行一個日誌採集程式，例如fluentd或者logstach
• 在每個Node上運行一個健康程式，採集Node的效能資料。

DaemonSet的Pod調度策略類似於RC，除了使用系統內建的演算法在每台Node上進行調度，也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node範圍來進行調度。 8.3 批處理調度  9.Pod的擴容和縮榮　　在實際生產環境中，我們經常遇到某個服務需要擴容的情境，也有可能因為資源精確需要縮減資源而需要減少服務執行個體數量，此時我們可以Kubernetes中RC提供scale機制來完成這些工作。以redis-slave RC為例，已定義的最初副本數量為2，通過kubectl scale命令可以將Pod副本數量重新調整

#kubectl scale rc redis-slave --replicas=3ReplicationController "redis-slave" scaled#kubectl get podsNAME READY STATUS RESTARTS AGEredis-slave-1sf23 1/1 Running 0 1hredis-slave-54wfk 1/1 Running 0 1hredis-slave-3da5y 1/1 Running 0 1h　

　　除了可以手工通過kubectl scale命令完成Pod的擴容和縮容操作以外，新版本新增加了Horizontal Podautoscaler(HPA)的控制器，用於實現基於CPU使用路進行啟動Pod擴容縮容的功能。該控制器基於Mastger的kube-controller-manager服務啟動參數 --horizontal-pod-autoscler-sync-period定義的時間長度（預設30秒），周期性監控目標Pod的Cpu使用率並在滿足條件時對ReplicationController或Deployment中的Pod副本數量進行調整，以符合使用者定義的平均Pod Cpu使用率，Pod Cpu使用率來源於heapster組件，所以需預先安裝好heapster。    持續更新中。。。。。。。。。。。。。。。。

Kubernetes之深入瞭解Pod