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