前言

先前已經介紹了Pod以及實作方式，那麼現在延伸問題，如果一個服務使用一個Pod，當該Pod出現問題而導致服務下線，K8s有何方法可以提高服務可用性嗎?

ReplicationController和ReplicaSet就是由此衍生的。

ReplicationController

在早期的K8s中，ReplicationController協助管理多個Pod，負責監控目前Pod數量是否有達到一定數量，若少於該定義數量，則會自動啟動新的Pod，而不需手動建立;反之，異常多出的Pod也會被自動回收。

ReplicaSet

後來發展了ReplicaSet，同樣負責維護指定數量且穩定運行的Pod(s)。
與前者差別在於ReplicaSet支援set-based label selector，而ReplicationController僅支援equality-based label selector。

以下為建立ReplicaSet的範例:

# replicaset-definition.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: frontend
    labels:
        app: guestbook
        tier: frontend
spec:
    replicas: 3
    selector:
        matchLabels:
            tier: frontend
    template:
        metadata:
            labels:
                tier: frontend
        spec:
            containers:
            - name: php-redis
              image: gcr.io/google_samples/gb-frontend:v3

spec.replicas: 代表同時要存在運行的Pod數量。
spec.selector: 此處透過設定Label為tier: frontend的Pod，由此ReplicaSet所管理。
spec.template: 此處撰寫Pod設定檔，也就是要以什麼樣的規格、要運行甚麼 container在該Pod中，以此作為基礎再行複製，因此透過replicaset-definition.yml便可一併建立ReplicaSet以及符合要求的Pod。

A Deployment that configures a ReplicaSet is now the recommended way to set up replication.

官方建議使用Deployment，來取代ReplicationController和ReplicaSet

小結

今天很簡短帶過概念，希望後續有更多資料補充