既然是微服務的解決方案，怎麼能少了HA！ (^o^)-☆

蛤？什麼是HA？

高可用 (High Availability)
專指服務不中斷、持續提供服務的能力。服務停機時間越短，可用性越高。

為了確保時時刻刻都有一定數量的 Pod 在執行服務，我們需要一個適合的元件定義這件事。

ReplicaSet

主要功能：確保隨時都有指定數量的 Pod 正在運行。
運作方式：利用 Label 與 Pod 做配對，當偵測到對應 Label 的 Pod 不符合設定時，會執行增減。

對，它的功能就這麼單純。
只要服務一直都維持著ReplicaSet的設定數，就平安無事什麼也不會發生。

檢視一下它的 yaml file：

apiVersion: apps/v1 
kind: ReplicaSet 
metadata:
  name: myapp-replicaset 
  labels: 
    app: myapp 
    type: front-end 
spec: 
  template:
   # =================== template =================== 
    metadata: 
      name: myapp-pod 
      labels: 
        app: myapp 
        type: front-end 
    spec: 
      containers: 
      - name: nginx-container
        image: nginx 
   # ================================================= 
   replicas: 3 
   selector: 
     matchLabels: 
       type: front-end

• spec
  包含 ReplicaSet 相關設定的所有細節：用來建立 Pod 的 image、與 Pod 對應的標籤(label)、需維持的 Pod 數量等... ...
• template
  設定欲建立的 Pod 模板。
  如果覺得眼熟... 沒錯！！！
  這段幾乎跟 Day-9：yaml 中的範例 yaml 一模一樣，需要設定的元件格式長什麼樣子，就算是寫在其他設定的元件之中，格式也不會改變 🫶
• replicas
  要維持的 Pod 數量。
• selector
  篩選器，用來設定對應 Pod 的條件式。

ReplicaSet 的前身：ReplicationController

ReplicationController 其實就是舊版的 ReplicaSet。
直接用 yaml 比較兩者差異：

apiVersion: v1  
kind: ReplicationController  
metadata:  
  name: my-replication-controller  
spec:  
  replicas: 3  
  selector:  
    app: my-app  
  template:  
    metadata:  
      labels:  
        app: my-app  
    spec:  
      containers:  
        - name: nginx-container  
          image: nginx

可以發現 selector 的設定跟 ReplicaSet 不太一樣：
ReplicationController 的篩選只支援=篩選，也就是抓取的 Pod 必須要包含指定的 Label (包含 key & value 皆需一致)，才會被圈到管理範圍中。

但 ReplicaSet 不同。
ReplicaSet 支援 matchLabels 和 matchExpressions 兩種篩選方式。

matchLabels

AND 邏輯，在 yaml 設定上通常會是：

selector:
  matchLabels:
    key1: value1
    key2: value2

Pod 上需包含所有指定的標籤，才會算進服務數量中。

那缺少的另外兩個 Pod 怎麼辦！！！
ReplicaSet 的工作就是定義要有多少數量的 Pod 在運作，所以 Kubernetes 就會...

再啟兩個 Pod ( ´ ▽ ` )ﾉ
（當然原本的也還是會在。）
所以為了避免無端的資源浪費，Label 的使用還是值得花點心思設計的。(^_^)a

matchExpressions

matchExpressions 提供比 matchLabels 更靈活的篩選條件。
其每個條件都是由key、operator、value 組合而成。

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

支援的篩選方式包含：

• In：Pod 標籤必須包含設定值
• NotIn：Pod 標籤不能包含定值
• Exists：必須存在具設定值的標籤（指key，不判斷 value）
• DoesNotExist：不允許存在具設定值的標籤（指key，不判斷 value）

定義太拗口，直接上範例：

selector: 
  matchExpressions: 
    - {key: app, operator: In, values: [frontend, backend]} 
    - {key: tier, operator: NotIn, values: [testing, staging]} 
    - {key: environment, operator: Exists} 
    - {key: demo, operator: DoesNotExist}

1. Pod 標籤中包含 app: frontend 或是 app: backend 者符合
2. 排除 Pod 標籤包含：tier: testing 或 tier: staging 者
3. Pod 標籤中必須包含 environment，值是什麼無所謂
4. Pod 標籤不可包含 demo，值是什麼無所謂
   

• 多個 matchExpressions 條件之間是 AND 關係
• 在單個表達式內，In 和 NotIn 中的多個值之間是 OR 關係

另外，matchLabels 和 matchExpressions是可以同時使用的喔！
由此就不難看出 ReplicaSet 會取代 ReplicationController 的原因了。
不過相對的，ReplicaSet 雖然提供了強大的篩選方式，卻也要格外注意撰寫的邏輯，要是過於複雜到難以理解，就容易影響維護性，光是整理篩選邏輯就要多長兩根白髮。
比如說上面的篩選條件...

隨隨便便就可以列舉好幾種相似但是不符合篩選條件的標籤設定。

盡可能使用簡單的 matchLabels，只在需要更複雜邏輯時使用 matchExpressions

小結

其實，ReplicaSet 取代 ReplicationController 不只是篩選的靈活性，更重要的是與其他元件的搭配使用：ReplicaSet是可以與 Deployment 搭擋組合技的！
使用 Deployment 配置資源時，甚至不需要直接管理 ReplicaSet。因為它作為 Deployment 與 Pod 之間的管理邏輯，只需要專注在維持指定數量的 Pod，確保系統的穩定運行就可以了。