前言

昨天的文章介紹完 Replication Controller 相信大家應該對於 K8s 是如何控制 Pod 有了初步的了解了，其實真正實務上是比較少用 Replication Controller 進行 Pod 控制，都是用 Deployment 搭配 ReplicaSet 進行控制，接下來的文章就來講講這兩個物件吧！

由於 Deployment 能講的東西真的太多了，所以筆者會拆成三篇文章來介紹，方便讀者消化全部的內容，廢話不多說開始系列文的第一篇內容吧！

什麼是 ReplicaSet？

看到 Replica 的讀者應該就知道這個跟控制 Pod 的數量又有關係了，其實 ReplicaSet 跟 Replication Controller 很像，差別在於 ReplicaSet 提供了更彈性的 selector，在 Replication Controller 中我們必須要把完整的 key/value pair Label 寫上去，在 ReplicaSet 中則不用這麼麻煩，但 ReplicaSet 一樣也可以寫上完整的 Label 就看開發者要如何設計。

ReplicaSet 特性

上面提到 ReplicaSet 有非常彈性的 selector 這邊就來講一下 ReplicaSet 是如何讓 selector 變得更加彈性，這裡一共要介紹兩種 ReplicaSet 的 selector 寫法。

• matchLabels

  matchLabels 其實跟一般的 selector 做的事情一模一樣，也是要寫出完整的 Label 出來，整體來說寫法會長的像這樣：

  selector:
    matchLabels:
      app: frontend
  

• matchExpressions

matchExpressions 則是提供更彈性的選取條件，每一筆條件主要由 key、 operator、value 組成，並用一個 {} 包起來，整個看起來會很像 JS 的物件型態，整體來說寫法會長的像這樣：

selector:
 matchExpression:
   - {key: app, operator: In, values: [frontend, backend]}

看起來好像很複雜但其實很簡單，上面範例中的 Expression 翻成中文就是只要 Label 的 key 是 app 而且其值有符合 [frontend, backend] 陣列中的其中一個值的 Pod 就會被選取到。

所以同理可證假如今天有一個 matchExpression 長得像這樣：

selector:
 matchExpression:
   - {key: env, operator: NotIn, values: [dev, canary]}

這句話就可以依樣畫葫蘆知道要選取的是 Label 中 key 為 env 且其值並不是 [dev, canary] 中其中一個值的 Pod 。

什麼是 Deployment？

在開始介紹 Deployment 之前，這邊筆者要複製一段官網上的文字：

a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features.

官網這段文字寫得非常好，告訴我們 Deployement 其實就是一種負責管理 ReplicaSet 以及控制 Pod 更新的物件，在先前的文章都沒有提到 Pod 的更新是因為 Pod 無法直接更新，必須要砍掉重建才會是新的內容，有了 Deployment 之後我們就可以很方便的進行 Pod 的更新了。

由於 ReplicaSet 本身也會控制 Pod ，所以整個整體看起來就會像是 Deployment 控制著 Pod ，但其實Deployment 真正控制的是 ReplicaSet 喔！

所以整體來說 Deployment 再加上 ReplicaSet 的架構會長得像這樣：

Deployment 特性

• 部署一個應用服務

  上面提到 Deployment 可以幫助 Pod 進行更新，通常在開發一個產品的時候一定會不斷的更新，透過 Deployment 我們就可以快速的幫 Pod 更新內部的 container，所以通常在部署應用的時候都會使用 Deployment。

• 在服務升級的過程中可以達到無停機服務遷移(zero downtime deployment)

  在 Deployment 進行內部 Pod 更新的過程中會有一個專有名詞叫 RollingUpdate，RollingUpdate 翻成中文就是滾動更新的意思，在更新的過程中 Deployment 會先產生一個新的 ReplicaSet 而這個 ReplicaSet 內部的 Pod 會運行新的內容，待新的 Pod 被 K8s 確認可以正常運作時 Deployment 就會將舊的 ReplicaSet 進行取代的動作，這樣就達到無停機服務遷移了。

• 可以 Rollback 到先前版本

  每一次 Deployment 在進行滾動更新的時候都會把當前的 ReplicaSet 做一個版本控制的紀錄，跟 git commit 很像，利用這些紀錄就可以快速的恢復成之前的版本，這些 Pod 也就會變成先前的內容。

小結

今天介紹了 Deployment 最基本的觀念，相信讀者應該對 Deployment 有了初步的瞭解了。

接下來的文章要介紹 Deployment 如何撰寫以及建立，如果對於文章有任何問題都歡迎留言給我，那我們就下一篇文章見嘍～