k8s實踐(9)--深刻了解Pod

1、Pod簡介

---

       Pod是k8s系統中能夠建立和管理的最小單元，是資源對象模型中由用戶建立或部署的最小資源對象模型，也是在k8s上運行容器化應用的資源對象，其餘的資源對象都是用來支撐或者擴展Pod對象功能的，好比控制器對象是用來管控Pod對象的，Service或者Ingress資源對象是用來暴露Pod引用對象的，PersistentVolume資源對象是用來爲Pod提供存儲等等，k8s不會直接處理容器，而是Pod，Pod是由一個或者多個container組成的。

每一個Pod都是運行應用的單個實例，若是須要水平擴展應用（例如，運行多個實例），則應該使用多個Pods，每一個實例一個Pod。在Kubernetes中，這樣一般稱爲Replication。Replication的Pod一般由Controller建立和管理。

1.一、爲何須要pod

咱們先談談爲何k8s會使用pod這個最小單元，而不是使用docker的容器，k8s既然使用了pod，固然有它的理由。

一、更利於擴展
k8s不只僅支持Docker容器，也支持rkt甚至用戶自定義容器，爲何會有這麼多不一樣的容器呢，由於容器並非真正的虛擬機，docker的一些概念和誤區總結，此外，Kubernetes不依賴於底層某一種具體的規則去實現容器技術，而是經過CRI這個抽象層操做容器，這樣就會須要pod這樣一個東西，pod內部再管理多個業務上緊密相關的用戶業務容器，就會更有利用業務擴展pod而不是擴展容器。

 

二、更容易定義一組容器的狀態

若是咱們沒有使用pod，而是直接使用一組容器去跑一個業務呢，那麼當其中一個或者若干個容器出現問題呢，咱們如何去定義這一組容器的狀態呢，經過pod這個概念，這個問題就能夠很好的解決，一組業務容器跑在一個k8s的pod中，這個pod中會有一個pause容器，這個容器與其餘的業務容器都沒有關係，以這個pause容器的狀態來表明這個pod的狀態.

 

三、利於容器間文件共享，以及通訊。
     pod裏的多個業務容器共享pause容器的ip和存儲卷Volume，pod中的其餘容器共享pause容器的ip地址和存儲，這樣就作到了文件共享和互信。

 

1.2 Pod 特性：

1  資源共享：IP和Volume

一個Pod裏的多個容器能夠共享存儲和網絡IP，能夠看做一個邏輯的主機。共享的如 namespace,cgroups或者其餘的隔離資源。

多個容器共享同一個network namespace，由此在一個Pod裏的多個容器共享Pod的IP和端口namespace，因此一個Pod內的多個容器之間能夠經過localhost來進行通訊,所須要注意的是不一樣容器要注意不要有端口衝突便可。不一樣的Pod有不一樣的IP,不一樣Pod內的多個容器以前通訊，不可使用IPC（若是沒有特殊指定的話）通訊，一般狀況下使用Pod的IP進行通訊。

k8s要求底層網絡支持集羣內任意兩個pod直接的TCP/IP直接通訊，這一般纔有虛擬二層網絡技術來實現，例如Flannel，Openswitch等。

一個Pod裏的多個容器能夠共享存儲卷，這個存儲卷會被定義爲Pod的一部分，而且能夠掛載到該Pod裏的全部容器的文件系統上。

2 生命週期短暫

Pod屬於生命週期比較短暫的組件，好比，當Pod所在節點發生故障，那麼該節點上的Pod會被調度到其餘節點，但須要注意的是，被從新調度的Pod是一個全新的Pod,跟以前的Pod沒有半毛錢關係。

3  平坦的網絡

K8s集羣中的全部Pod都在同一個共享網絡地址空間中，也就是說每一個Pod均可以經過其餘Pod的IP地址來實現訪問。

 

1.3 Pod使用和管理

一、核心原則是：將多個應用分散到多個Pod中

     緣由：基於資源的合理應用；擴縮容，不一樣應用應該有不一樣的擴縮容策略等。

     若是容器之間不是必須運行在一塊兒的話，那麼就放到不一樣的Pod裏

若是容器以前是相互獨立的組件，那麼就放到不一樣的Pod裏

若是容器以前擴縮容策略不同，那麼就放到不一樣的Pod裏

結論：單Pod單容器應用，除非特殊緣由。

 

你不多會直接在kubernetes中建立單個Pod。由於Pod的生命週期是短暫的，用後即焚的實體。當Pod被建立後（不管是由你直接建立仍是被其餘Controller），都會被Kubernetes調度到集羣的Node上。直到Pod的進程終止、被刪掉、由於缺乏資源而被驅逐、或者Node故障以前這個Pod都會一直保持在那個Node上。

注意：重啓Pod中的容器跟重啓Pod不是一回事。Pod只提供容器的運行環境並保持容器的運行狀態，重啓容器不會形成Pod重啓。

Pod不會自愈。若是Pod運行的Node故障，或者是調度器自己故障，這個Pod就會被刪除。一樣的，若是Pod所在Node缺乏資源或者Pod處於維護狀態，Pod也會被驅逐。Kubernetes使用更高級的稱爲Controller的抽象層，來管理Pod實例。雖然能夠直接使用Pod，可是在Kubernetes中一般是使用Controller來管理Pod的。

1.四、Pod和Controller

Controller能夠建立和管理多個Pod，提供副本管理、滾動升級和集羣級別的自愈能力。例如，若是一個Node故障，Controller就能自動將該節點上的Pod調度到其餘健康的Node上。

包含一個或者多個Pod的Controller示例：

• Deployment
• StatefulSet
• DaemonSet

一般，Controller會用你提供的Pod Template來建立相應的Pod。

在用戶定義範圍內，若是pod增多，則ReplicationController會終止額外的pod，若是減小，RC會建立新的pod，始終保持在定義範圍。例如，RC會在Pod維護（例如內核升級）後在節點上從新建立新Pod。

 

 

2、Pod定義

---

       對Pod的定義能夠經過Yaml或Json格式的配置文件來完成。關於Yaml或Json中都能寫哪些參數，參考官網http://kubernetes.io/docs/user-guide/pods/multi-container/

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，默認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   

 

 

3、Pod使用

---

　　在使用docker時，咱們可使用docker run命令建立並啓動一個容器，而在Kubernetes系統中對長時間運行的容器要求是：其主程序須要一直在前臺運行。若是咱們建立的docker鏡像的啓動命令是後臺執行程序，例如Linux腳本：

　　nohup ./startup.sh &

　　則kubelet建立包含這個容器的pod後運行完該命令，即認爲Pod執行結束，以後根據RC中定義的pod的replicas副本數量生產一個新的pod，而一旦建立出新的pod，將在執行完命令後陷入無限循環的過程當中，這就是Kubernetes須要咱們建立的docker鏡像以一個前臺命令做爲啓動命令的緣由。

　　對於沒法改造爲前臺執行的應用，也可使用開源工具supervisor輔助進行前臺運行的功能。

Pod能夠由一個或多個容器組合而成

場景1：單個應用多個容器

spring boot web：

apiVersion:v1
kind: Pod
metadata:
  name:  springbootweb
  label:
    name:  test
spec:
  containers:
  - name: springbootweb
    image: registry.tuling123.com/springboot:latest
    ports:
    - containerPort: 9081

kubectl create -f springboot-deployment.yml
 

[root@k8s-master pod]# kubectl get pods
NAME            READY     STATUS    RESTARTS   AGE
springbootweb   0/1       Pending   0          1m

kubectl get pods -o wide

# 加入 –o wide參數 查看額外信息：包括node和ip

pod處於pending的緣由：經過kubectl describe pods springbootweb進一步查找問題。

能夠看到pod的鏡像信息寫錯了：

先刪除pod，而後再建立：kubectl delete pod  springbootweb

 

因爲建立的端口號是9081，能夠直接訪問：curl 10.0.86.2:9081

# curl 10.0.86.2:9081
Hello world

 

 

 

場景2：Pod不一樣應用多個容器組合而成

例如：兩個容器應用的前端frontend和redis爲緊耦合的關係，應該組合成一個總體對外提供服務，則應該將這兩個打包爲一個pod.

配置文件frontend-localredis-pod.yaml以下：

apiVersion:v1
kind: Pod
metadata:
  name: redis-php
  label:
    name: redis-php
spec:
  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 gods

NAME READY STATUS RESTATS AGE

redis-php 2/2Running 0 10m

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

 

2.3 集羣外部訪問Pod

上面的例子，在k8s集羣的安裝有kube-proxy的node節點上，能夠直接經過curl 10.0.86.2:9081 訪問集羣的pod。但在集羣外的客戶端系統沒法經過Pod的IP地址或者Service的虛擬IP地址和虛擬端口號訪問到它們。爲了讓外部客戶端能夠訪問這些服務,能夠將Pod或Service的端口號映射到宿主機,以使得客戶端應用可以經過物理機訪問容器應用。

一、將容器應用的端口號映射到物理機

apiVersion:v1
kind: Pod
metadata:
  name:  springbootweb
  label:
    name:  test
spec:
  containers:
  - name: springbootweb
    image: registry.tuling123.com/springboot:latest
    ports:
    - containerPort:9081
      hostPort: 9082

 

(2)經過設置Pod級別的hostNetwork-true,該Pod中全部容器的端口號都將被直接映射到物理機上。設置hostNetwork-true時須要注意,在容器的ports定義部分若是不指定hostPort,則默認hostPort等於containerPort,若是指定了hostPort,則hostPort必須等於containerPort的值。

 

apiVersion:v1
kind: Pod
metadata:
  name:  springbootweb
  label:
    name:  test
spec:
  hostNetwork: true
  containers:
  - name: springbootweb
    image: registry.tuling123.com/springboot:latest
    ports:
    - containerPort:9081

　　

4、靜態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/1Pending 0 1s

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

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

#docker ps

 

5、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-php
  label:
    name: volume-pod
spec:
  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

六.Pod的配置管理

---

　　應用部署的一個最佳實踐是將應用所需的配置信息於程序進行分離，這樣可使得應用程序被更好的複用，經過不用配置文件也能實現更靈活的功能。將應用打包爲容器鏡像後，能夠經過環境變量或外掛文件的方式在建立容器時進行配置注入。ConfigMap是Kubernetes v1.2版本開始提供的一種統一集羣配置管理方案。

6.1 ConfigMap：容器應用的配置管理

　　容器使用ConfigMap的典型用法以下：

　　（1）生產爲容器的環境變量。

　　（2）設置容器啓動命令的啓動參數（需設置爲環境變量）。

　　（3）以Volume的形式掛載爲容器內部的文件或目錄。

　　ConfigMap以一個或多個key:value的形式保存在Kubernetes系統中共應用使用，既能夠用於表示一個變量的值，也能夠表示一個完整的配置文件內容。

經過yuaml配置文件或者直接使用kubelet create configmap 命令的方式來建立ConfigMap

6.2 ConfigMap的建立

　　　舉個小例子cm-appvars.yaml來描述將幾個應用所需的變量定義爲ConfigMap的用法：

# vim cm-appvars.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir:/var/data

　　執行kubectl create命令建立該ConfigMap

#kubectl create -f cm-appvars.yaml

configmap "cm-appvars.yaml"created

查看創建好的ConfigMap：

#kubectl get configmap

kubectl describe configmap cm-appvars

kubectl get configmap cm-appvars -o yaml

 

　　另：建立一個cm-appconfigfile.yaml描述將兩個配置文件server.xml和logging.properties定義爲configmap的用法，設置key爲配置文件的別名，value則是配置文件的文本內容：

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cm-appvars
    data:
      key-serverxml:
        <?xml Version='1.0'encoding='utf-8'?>
        <Server port="8005"shutdown="SHUTDOWN">
        .....
          </service>
        </Server>
      key-loggingproperties:
        "handlers=lcatalina.org.apache.juli.FileHandler,
        ...."

在pod "cm-test-app"定義中，將configmap "cm-appconfigfile"中的內容以文件形式mount到容器內部configfiles目錄中。

Pod配置文件cm-test-app.yaml內容以下：

#vim cm-test-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cm-test-app
spec:
  containers:
  - name: cm-test-app
    image: tomcat-app:v1
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: serverxml                          #引用volume名
      mountPath:/configfiles                       #掛載到容器內部目錄
        configMap:
          name: cm-test-appconfigfile                  #使用configmap定義的的cm-appconfigfile
          items:
          - key: key-serverxml                     #將key=key-serverxml
            path: server.xml                           #value將server.xml文件名進行掛載
          - key: key-loggingproperties                 #將key=key-loggingproperties    
            path: logging.properties                   #value將logging.properties文件名進行掛載

建立該Pod：
#kubectl create -f cm-test-app.yaml
Pod "cm-test-app"created　

登陸容器查看configfiles目錄下的server.xml和logging.properties文件，他們的內容就是configmap 「cm-appconfigfile」中定義的兩個key的內容
#kubectl exec -ti cm-test-app -- bash
root@cm-rest-app:/# cat /configfiles/server.xml
root@cm-rest-app:/# cat /configfiles/logging.properties

 

6.3使用ConfigMap的條件限制

使用configmap的限制條件以下：

• configmap必須在pod之間建立
• configmap也能夠定義爲屬於某個Namespace，只有處於相同namespaces中的pod能夠引用
• configmap中配額管理還未能實現
• kubelet只支持被api server管理的pod使用configmap，靜態pod沒法引用
• 在pod對configmap進行掛載操做時，容器內部職能掛載爲目錄，沒法掛載文件。

 

7、Pod生命週期和重啓策略

---

　　Pod在整個生命週期過程當中被定義爲各類狀態，熟悉Pod的各類狀態有助於理解如何設置Pod的調度策略、重啓策略

　　Pod的狀態包含如下幾種，如圖：

　　

　　Pod的重啓策略（RestartPolicy）應用於Pod內全部的容器，而且僅在Pod所處的Node上由kubelet進行判斷和重啓操做。當某哥容器異常退出或者健康檢查石柏師，kubelet將根據RestartPolicy的設置進行相應的操做

　　Pod的重啓策略包括Always、OnFailure及Nerver，默認值爲Always。

　　kubelet重啓失效容器的時間間隔以sync-frequency乘以2n來計算，例如一、二、四、8倍等，最長延時5分鐘，而且成功重啓後的10分鐘後重置該事件。

　　Pod的重啓策略和控制方式息息相關，當前可用於管理Pod的控制器寶庫ReplicationController、Job、DaemonSet及直接經過kubelet管理（靜態Pod），每種控制器對Pod的重啓策略要求以下：

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

 

8、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-exec
  label:
    name: liveness
spec:
  containers:
  - name: tomcat
    image: grc.io/google_containers/tomcat
    args:
    -/bin/sh
    - -c
    -echo ok >/tmp.health;sleep10; rm -fr /tmp/health;sleep600
    livenessProbe:
      exec:
        command:
        -cat
        -/tmp/health
      initianDelaySeconds:15
      timeoutSeconds:1

（2）TCPSocketAction：經過容器ip地址和端口號執行TCP檢查，若是可以創建tcp鏈接代表容器健康。例：

kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      tcpSocket:
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

3）HTTPGetAction：經過容器Ip地址、端口號及路徑調用http get方法，若是響應的狀態嗎大於200且小於400，則認爲容器健康。例：

apiVersion:v1
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path:/_status/healthz
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

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

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

 

九.玩轉Pod調度

---

　　在Kubernetes系統中，Pod在大部分場景下都只是容器的載體而已，一般須要經過RC、Deployment、DaemonSet、Job等對象來完成Pod的調度和自動控制功能。

9.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-master
  label:
    name: redis-master
spec:
  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。調度側露更加靈活。

9.2 DaemonSet：特定場景調度

DaemonSet用於管理集羣中每一個Node上僅運行一份Pod的副本實例，如圖：

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

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

DaemonSet的Pod調度策略相似於RC，除了使用系統內置的算法在每臺Node上進行調度，也能夠在Pod的定義中使用NodeSelector或NodeAffinity來指定知足條件的Node範圍來進行調度。

 

 

十.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/1Running 0 1h
redis-slave-54wfk 1/1Running 0 1h
redis-slave-3da5y 1/1Running 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。

 

十一.Pod的滾動升級

---

　　當集羣中的某個服務須要升級時，咱們須要中止目前與該服務相關的全部Pod，而後從新拉取鏡像並啓動。若是集羣規模較大，因服務所有中止後升級的方式將致使長時間的服務不可用。由此，Kubernetes提供了rolling-update（滾動升級）功能來解決該問題。

滾動升級經過執行kubectl rolling-update命令一鍵完成，該命令建立一個新的RC，而後自動控制舊版本的Pod數量逐漸減小到0，同時新的RC中的Pod副本數量從0逐步增長到目標值，最終實現Pod的升級。須要注意的是，系統要求新的RC須要與舊的RC在相同的Namespace內，即不能把別人的資產轉到到自家名下。

　　例：將redis-master從1.0版本升級到2.0：

apiVersion: v1
kind: replicationController
metadata:
  name: redis-master-v2
  labels:
    name: redis-master
    Version: v2
spec:
  replicas: 1
  selector:
    name: redis-master
    Version: v2
  template:
    labels:
      name: redis-master
      Version: v2
    spec:
      containers:
      - name: master
        images: kubeguide/redis-master:2.0
        ports:
        - containerPort: 6379

須要注意的點：

　　（1）RC的name不能與舊的RC名字相同

　　（2）在sele中應至少有一個label與舊的RC的label不一樣，以標識爲新的RC。本例中新增了一個名爲version的label與舊的RC區分

　　運行kubectl rolling-update來完成Pod的滾動升級：

#kubectl rolling-update redis-master -f redis-master-controller-v2.yaml

另外一種方法就是不使用配置文件，直接用kubectl rolling-update加上--image參數指定新版鏡像名來完成Pod的滾動升級

#kubectl rolling-update redis-master --image=redis-master:2.0

與使用配置文件的方式不一樣的是，執行的結果是舊的RC被刪除，新的RC仍然使用就的RC的名字。

　若是在更新過程總髮現配置有誤，則用戶能夠中斷更新操做，並經過執行kubectl rolling-update-rollback完成Pod版本的回滾。

 

 

問題

---

一、在建立pod的時候發現報了這個錯誤：

Error from server (ServerTimeout): error when creating "busybox.yaml": No API token found for
service account "default", retry after the token is automatically created and added to the service
account



分析
根據報錯信息能夠初步看出是service account沒有設置API token引發的。

解決
解決方式有兩種：

方式一：禁用ServiceAccount
編輯/etc/kubenetes/apiserver：
將如下這行中的ServiceAccount刪除便可
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"
改成：
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"

這種方式比較粗暴，可能會遇到必需要用ServiceAccount的狀況。

方式二：配置ServiceAccount
一、首先生成密鑰：
openssl genrsa -out /etc/kubernetes/serviceaccount.key 2048

二、編輯/etc/kubenetes/apiserver
添加如下內容：
KUBE_API_ARGS="--service_account_key_file=/etc/kubernetes/serviceaccount.key"

三、再編輯/etc/kubernetes/controller-manager
添加如下內容：
KUBE_CONTROLLER_MANAGER_ARGS="--service_account_private_key_file=/etc/kubernetes/serviceaccount.key"

最後不管是哪一種解決方式都須要再重啓kubernetes服務： systemctl restart etcd kube-apiserver kube-controller-manager kube-scheduler