時間：2017-04-14 13:22:14 1、yaml格式的Pod配置文件內容及注解 深入Pod之前，首先我們來了解下Pod的yaml整體文件內容及功能注解。 如下： # yaml格式的pod定義文件完整內容： apiVersion: v1 #必選，版本號，例如v1 kind: Pod #必選，Pod metadata: #必選，元數據name: string #必選，Pod名稱namespace: string #必選，Pod所屬的命名空間labels: #自定義標簽- name: string #自定義標簽名字annotations: #自定義注釋列表- name: string spec: #必選，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，默認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 #內存清楚，容器啟動的初始可用數量livenessProbe: #對Pod內個容器健康檢查的設置，當探測無響應幾次后將自動重啟該容器，檢查方法有exec、httpGet和tcpSocket，對一個容器只需設置其中一種方法即可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的重啟策略，Always表示一旦不管以何種方式終止運行，kubelet都將重啟，OnFailure表示只有Pod以非0退出碼退出才重啟，Nerver表示不再重啟該PodnodeSelector: obeject #設置NodeSelector表示將該Pod調度到包含這個label的node上，以key：value的格式指定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的存儲卷，掛載集群與定義的secre對象到容器內部scretname: string items: - key: stringpath: stringconfigMap: #類型為configMap的存儲卷，掛載預定義的configMap對象到容器內部name: stringitems:- key: stringpath: 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:v1 kind: Pod metadata:name: redis-phplabel:name: redis-php spec:containers:- name: frontendimage: kubeguide/guestbook-php-frontend:localredisports:- containersPort: 80- name: redis-phpimage:kubeguide/redis-masterports:- containersPort: 6379

　　

屬于一個Pod的多個容器應用之間相互訪問只需要通過localhost就可以通信，似的這一組容器被綁定在一個環境中。 使用kubectl create創建該Pod后，get Pod信息可以看到如下圖： #kubectl get gods NAME READY STATUS RESTATS AGE redis-php 2/2 Running 0 10m

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

查看pod的詳細信息，可以看到兩個容器的定義和創建過程。
[root@kubernetes-master ~]# kubectl describe redis-php the server doesn‘t have a resource type "redis-php" [root@kubernetes-master ~]# kubectl describe pod redis-php Name: redis-php Namespace: default Node: kubernetes-minion/10.0.0.23 Start Time: Wed, 12 Apr 2017 09:14:58 +0800 Labels: name=redis-php Status: Running IP: 10.1.24.2 Controllers: <none> Containers: nginx: Container ID: docker://d05b743c200dff7cf3b60b7373a45666be2ebb48b7b8b31ce0ece9be4546ce77 Image: nginx Image ID: docker-pullable://docker.io/nginx@sha256:e6693c20186f837fc393390135d8a598a96a833917917789d63766cab6c59582 Port: 80/TCP State: Running Started: 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-node1 pod "static-web-node1" deleted #kubectl get pods NAME READY STATUS RESTARTS AGE static-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:v1 kind: Pod metadata:name: redis-phplabel:name: volume-pod spec:containers:- name: tomcatimage: tomcatports:- containersPort: 8080volumeMounts:- name: app-logsmountPath: /usr/local/tomcat/logs- name: busyboximage:busyboxcommand: ["sh","-C","tail -f /logs/catalina*.log"]volumes:- name: app-logsemptyDir:{} 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:v1 kind: Pod metadata:name: liveness-execlabel:name: liveness spec:containers:- name: tomcatimage: grc.io/google_containers/tomcatargs:- /bin/sh- -c- echo ok >/tmp.health;sleep 10; rm -fr /tmp/health;sleep 600livenessProbe:exec:command:- cat- /tmp/healthinitianDelaySeconds:15timeoutSeconds:1　 （2）TCPSocketAction：通過容器ip地址和端口號執行TCP檢查，如果能夠建立tcp連接表明容器健康 例： kind: Pod metadata:name: pod-with-healthcheck spec:containers:- name: nginximage: nginxlivenessProbe:tcpSocket: port: 80initianDelaySeconds:30timeoutSeconds:1 （3）HTTPGetAction：通過容器Ip地址、端口號及路徑調用http get方法，如果響應的狀態嗎大于200且小于400，則認為容器健康 例： apiVersion:v1 kind: Pod metadata:name: pod-with-healthcheck spec:containers:- name: nginximage: nginxlivenessProbe:httpGet: path: /_status/healthzport: 80initianDelaySeconds:30timeoutSeconds: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:v1 kind: Pod metadata:name: redis-masterlabel:name: redis-master spec:replicas: 1selector:name: redis-mastertemplate:metadata:labels:name: redis-masterspec:containers:- name: redis-masterimages: kubeguide/redis-masterports:- containerPort: 6379nodeSelector: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=3 ReplicationController "redis-slave" scaled #kubectl get pods NAME READY STATUS RESTARTS AGE redis-slave-1sf23 1/1 Running 0 1h redis-slave-54wfk 1/1 Running 0 1h redis-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。 ?持續更新中。。。。。。。。。。。。。。。。

原文：http://www.cnblogs.com/xhyan/p/6708344.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Kubernetes之深入了解Pod的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。