Kubernetes Deployment與Replica Set

Deployment相對於RC的優勢

RS與Deployment主要用於替代RC。RS的全稱為Replica Set。相對於RC，RS與Deployment的優勢如下：

• RC只支持基於等式的selector，如env=dev或者environment!=qa。但在RS中，還支持新的基於集合的selector，如version in (v1.0,v2.0)或者env not in (dev,qa)。這給復雜的運維管理帶來方便
• 使用Deployment升級Pod只需要定義Pod的最終狀態，k8s會為你執行必要的操作。雖然使用kubectl rolling-update也可以完成滾動升級，但它是在客戶端與服務端多次交互控制RC完成的，所以REST API中並沒有rolling-update的接口，這為定制自己的管理系統帶來了一些麻煩。Deployment擁有更加靈活的升級、回滾功能。

Replica Set目前與RC的區別只是支持的selector不同，后續會加入更多的功能。Deployment使用了Replica Set，是更高一層的概念。除非需要自定義升級功能或者根本不需要升級Pod，否則還是建議使用Deployment而不直接使用Replica Set。

Deployment配置文件

Deployment的配置與RC基本相同，詳細配置可以參考官方文檔下面直接給出一個配置示例deployment.yml內容如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: hello-deployment
    namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      name: hello-deployment
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 10%
      maxUnavailable: 0     
  template:
    metadata:
      labels:
        name: hello-deployment
    spec:
      containers:
      - name: webserver
        image: nginx:1.14
        ports:
        - containerPort:80

需要說明的是strategy部分，用於定義deployment的升級策略。具體的deployment滾動升級的詳細操作可以參考另一篇文章《Service滾動更新》。這里簡單說下這幾個配置項的意義：

• spec.strategy：用於定義升級的策略
• spec.strategy.type：定義使用何種方式升級。一種是RollingUpdate，即滾動升級。另一種方式為Recreate。即先將所有舊的Pod停止，然后再啟動新的pod。默認策略即為RollingUpdate
• spec.strategy.type.rollingUpdate：如果采用RollingUpdate的方式進行升級操作，則可以定義更詳細的滾動升級策略
• spec.strategy.type.rollingUpdate.maxSurge： 指定在升級時，最大可以創建多少個pod。這個值可以是一個絕對值數字，也可以是個百分比。例如，當這個值指定為30%時，也就是說，新舊pod的總量不能超過130%。簡單來講，就是在滾動升級時，會先啟動30%的新的pod。然后開始殺掉舊的pod，每當一個舊的pod被殺掉，一個新的pod的會被啟動，始終保持總量不超過130%，直至更新完成。需要說明的是，當maxUnavailable為0時，maxSurge的值不能為0。
• spec.strategy.type.rollingUpdate.maxUnavailable： 指定在升級時，最大不可用的pods的值。可以是一個絕對值數字，也可以是個百分比。例如，當這個值指定為30%時，最少可用的Pod為70%,也就是說，在滾動升級的時候，會先殺掉30%舊的pod，然后開始啟動新pod。當一個新的Pod被創建，一個舊的Pod就會被銷毀。始終保持可用的pod在總量的70%，直至升級完成。需要說明的是，當maxSurge為0時，maxUnavailable的值不能為0。

創建deployment：

kubectl create -f deployment.yml --recode