3、Kubernetes之深刻了解Pod

 

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

　

二、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-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/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

　　

三、靜態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

　　

四、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

5.Pod的配置管理

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

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

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

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

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

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

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

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

　 　5.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
NAME DATA AGE
cm-appvars 2 3s
[root@kubernetes-master ~]# kubectl describe configmap cm-appvars
Name: cm-appvars
Namespace: default
Labels: <none>
Annotations: <none>
 
Data
====
appdatadir: 9 bytes
apploglevel: 4 bytes
[root@kubernetes-master ~]# kubectl get configmap cm-appvars -o yaml
apiVersion: v1
data:
appdatadir: /var/data
apploglevel: info
kind: ConfigMap
metadata:
creationTimestamp: 2017-04-14T06:03:36Z
name: cm-appvars
namespace: default
resourceVersion: "571221"
selfLink: /api/v1/namespaces/default/configmaps/cm-appvars
uid: 190323cb-20d8-11e7-94ec-000c29ac8d83　

 

　　另：建立一個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

 

　　5.3使用ConfigMap的條件限制

　　使用configmap的限制條件以下：

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

6.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進行健康檢查

 

七、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;sleep 10; rm -fr /tmp/health;sleep 600
    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：健康檢查發送請求後等待響應的超時時間，單位秒。當發生超時就被認爲容器沒法提供服務無，該容器將被重啓

 

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-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。調度側露更加靈活。

 

　　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。

 

10.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版本的回滾。