Kubernetes對象之Pod

系列目錄

Pod是Kubernetes調度的最小單元。一個Pod能夠包含一個或多個容器，所以它能夠被看做是內部容器的邏輯宿主機。Pod的設計理念是爲了支持多個容器在一個Pod中共享網絡和文件系統 所以處於一個Pod中的多個容器共享如下資源：

• PID命名空間：Pod中不一樣的應用程序能夠看到其餘應用程序的進程ID。

• network命名空間：Pod中多個容器處於同一個網絡命名空間，所以可以訪問的IP和端口範圍都是相同的。也能夠經過localhost相互訪問。

• IPC命名空間：Pod中的多個容器共享Inner-process Communication命名空間，所以能夠經過SystemV IPC或POSIX進行進程間通訊。
  UTS命名空間：Pod中的多個容器共享同一個主機名。

• Volumes：Pod中各個容器能夠共享在Pod中定義分存儲卷（Volume）。

Pod，容器與Node（工做主機）之間的關係以下圖所示：

1. Pod的定義

經過yaml文件或者json描述Pod和其內容器的運行環境和指望狀態，例如一個最簡單的運行nginx應用的pod，定義以下：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

在生產環境中，推薦使用諸如Deployment，StatefulSet，Job或者CronJob等控制器來建立Pod，而不是直接建立。

將上述pod描述文件保存爲nginx-pod.yaml，使用kubectl apply命令運行pod

kubectl apply -f nginx-pod.yaml

下面簡要分析一下上面的Pod定義文件：

• apiVersion： 使用哪一個版本的Kubernetes API來建立此對象
• kind：要建立的對象類型，例如Pod，Deployment等
• metadata：用於惟一區分對象的元數據，包括：name，UID和namespace
• labels：是一個個的key/value對，定義這樣的label到Pod後，其餘控制器對象能夠經過這樣的label來定位到此Pod，從而對Pod進行管理。（參見Deployment等控制器對象）

spec： 其它描述信息，包含Pod中運行的容器，容器中運行的應用等等。不一樣類型的對象擁有不一樣的spec定義。詳情參見API文檔：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/

Kubernetes在每一個Pod啓動時，會自動建立一個鏡像爲gcr.io/google_containers/pause:version的容器，全部處於該Pod中的容器在啓動時都會添加諸如--net=container:pause --ipc=contianer:pause --pid=container:pause的啓動參數，所以pause容器成爲Pod內共享命名空間的基礎。全部容器共享pause容器的IP地址，也被稱爲Pod IP。

若是咱們但願從外部訪問這nginx應用，那麼咱們還須要建立Service對象來暴露IP和port。

2. Pod的生命週期

Pod的生命週期是Replication Controller進行管理的。一個Pod的生命週期過程包括：

• 經過yaml或json對Pod進行描述

• apiserver（運行在Master主機）收到建立Pod的請求後，將此Pod對象的定義存儲在etcd中

• scheduler（運行在Master主機）將此Pod分配到Node上運行

• Pod內全部容器運行結束後此Pod也結束

在整個過程當中，Pod一般處於如下的五種階段之一：

• Pending：Pod定義正確，提交到Master，但其所包含的容器鏡像還未徹底建立。一般，Master對Pod進行調度須要一些時間，Node進行容器鏡像的下載也須要一些時間，啓動容器也須要必定時間。（寫數據到etcd，調度，pull鏡像，啓動容器）。

• Running：Pod已經被分配到某個Node上，而且全部的容器都被建立完畢，至少有一個容器正在運行中，或者有容器正在啓動或重啓中。

• Succeeded：Pod中全部的容器都成功運行結束，而且不會被重啓。這是Pod的一種最終狀態

• Failed：Pod中全部的容器都運行結束了，其中至少有一個容器是非正常結束的（exit code不是0）。這也是Pod的一種最終狀態。

• Unknown：沒法得到Pod的狀態，一般是因爲沒法和Pod所在的Node進行通訊。

2.1 Restart policy

定義Pod時，能夠指定restartPolicy字段，代表此Pod中的容器在何種條件下會重啓。restartPolicy擁有三個候選值：

• Always：只要退出就重啓

• OnFailure：失敗退出時（exit code不爲0）才重啓

• Never：永遠不重啓

2.2 經過controller管理Pod

Pod自己不具有容錯性，這意味着若是Pod運行的Node宕機了，那麼該Pod沒法恢復。所以推薦使用Deployment等控制器來建立Pod並管理。

通常來講，Pod不會自動消失，只能手動銷燬或者被預先定義好的controller銷燬。但有一種特殊狀況，當Pod處於Succeeded或Failed階段，而且超過必定時間後（由master決定），會觸發超時過時從而被銷燬。

整體上來講，Kubernetes中擁有三種類型的controller：

• Job。一般用於管理必定會結束的Pod。若是但願Pod被Job controller管理，那麼restartPolicy必須指定爲OnFailure或Never。

• ReplicationController，ReplicaSet和Deployment。用於管理永遠處於運行狀態的Pod。若是但願Pod被此類controller管理，那麼restartPolicy必須指定爲Always。

• DaemonSet。它可以保證你的Pod在每一臺Node都運行一個副本。