Replication Controller炒瘸、Replica Set
假如我們現(xiàn)在有一個Pod正在提供線上的服務膘滨，我們來想想一下我們可能會遇到的一些場景：
- 某次運營活動非常成功，網(wǎng)站訪問量突然暴增
- 運行當前
Pod的節(jié)點發(fā)生故障了捶枢，Pod不能正常提供服務了
第一種情況握截，可能比較好應對，一般活動之前我們會大概計算下會有多大的訪問量烂叔，提前多啟動幾個Pod川蒙，活動結(jié)束后再把多余的Pod殺掉，雖然有點麻煩长已，但是應該還是能夠應對這種情況的畜眨。
第二種情況，可能某天夜里收到大量報警說服務掛了术瓮，然后起來打開電腦在另外的節(jié)點上重新啟動一個新的Pod康聂，問題也很好的解決了。
如果我們都人工的去解決遇到的這些問題胞四，似乎又回到了以前刀耕火種的時代了是吧恬汁，如果有一種工具能夠來幫助我們管理Pod就好了，Pod不夠了自動幫我新增一個辜伟，Pod掛了自動幫我在合適的節(jié)點上重新啟動一個Pod氓侧，這樣是不是遇到上面的問題我們都不需要手動去解決了。
幸運的是导狡，Kubernetes就為我們提供了這樣的資源對象：
- Replication Controller：用來部署约巷、升級
Pod - Replica Set：下一代的
Replication Controller - Deployment：可以更加方便的管理
Pod和Replica Set
Replication Controller（RC）
Replication Controller簡稱RC，RC是Kubernetes系統(tǒng)中的核心概念之一旱捧，簡單來說独郎，RC可以保證在任意時間運行Pod的副本數(shù)量踩麦，能夠保證Pod總是可用的。如果實際Pod數(shù)量比指定的多那就結(jié)束掉多余的氓癌，如果實際數(shù)量比指定的少就新啟動一些Pod谓谦，當Pod失敗、被刪除或者掛掉后贪婉，RC都會去自動創(chuàng)建新的Pod來保證副本數(shù)量反粥，所以即使只有一個Pod，我們也應該使用RC來管理我們的Pod疲迂。
我們想想如果現(xiàn)在我們遇到上面的問題的話才顿，可能除了第一個不能做到完全自動化，其余的我們是不是都不用擔心了鬼譬，運行Pod的節(jié)點掛了娜膘，RC檢測到Pod失敗了逊脯，就會去合適的節(jié)點重新啟動一個Pod就行优质，不需要我們手動去新建一個Pod了。如果是第一種情況的話在活動開始之前我們給Pod指定10個副本军洼，結(jié)束后將副本數(shù)量改成2巩螃，這樣是不是也遠比我們手動去啟動、手動去關(guān)閉要好得多匕争，而且我們后面還會給大家介紹另外一種資源對象HPA可以根據(jù)資源的使用情況來進行自動擴縮容避乏，這樣以后遇到這種情況，我們就真的可以安心的去睡覺了甘桑。
現(xiàn)在我們來使用RC來管理我們前面使用的Nginx的Pod拍皮，YAML文件如下：
apiVersion: v1
kind: ReplicationController
metadata:
name: rc-demo
labels:
name: rc
spec:
replicas: 3
selector:
name: rc
template:
metadata:
labels:
name: rc
spec:
containers:
- name: nginx-demo
image: nginx
ports:
- containerPort: 80
上面的YAML文件相對于我們之前的Pod的格式：
- kind：
ReplicationController - spec.replicas: 指定
Pod副本數(shù)量，默認為1 - spec.selector:
RC通過該屬性來篩選要控制的Pod - spec.template: 這里就是我們之前的
Pod的定義的模塊跑杭，但是不需要apiVersion和kind了 - spec.template.metadata.labels: 注意這里的
Pod的labels要和spec.selector相同铆帽，這樣RC就可以來控制當前這個Pod了。
這個YAML文件中的意思就是定義了一個RC資源對象德谅，它的名字叫rc-demo爹橱，保證一直會有3個Pod運行，Pod的鏡像是nginx鏡像窄做。
注意
spec.selector和spec.template.metadata.labels這兩個字段必須相同愧驱，否則會創(chuàng)建失敗的，當然我們也可以不寫spec.selector椭盏，這樣就默認與Pod模板中的metadata.labels相同了组砚。所以為了避免不必要的錯誤的話，不寫為好掏颊。
然后我們來創(chuàng)建上面的RC對象(保存為 rc-demo.yaml):
$ kubectl create -f rc-demo.yaml
查看RC：
$ kubectl get rc
查看具體信息：
$ kubectl describe rc rc-demo
然后我們通過RC來修改下Pod的副本數(shù)量為2：
$ kubectl apply -f rc-demo.yaml
或者
$ kubectl edit rc rc-demo
而且我們還可以用RC來進行滾動升級惫确，比如我們將鏡像地址更改為nginx:1.7.9:
$ kubectl rolling-update rc-demo --image=nginx:1.7.9
但是如果我們的Pod中多個容器的話，就需要通過修改YAML文件來進行修改了:
$ kubectl rolling-update rc-demo -f rc-demo.yaml
如果升級完成后出現(xiàn)了新的問題，想要一鍵回滾到上一個版本的話改化，使用RC只能用同樣的方法把鏡像地址替換成之前的掩蛤，然后重新滾動升級。
Replication Set（RS）
Replication Set簡稱RS陈肛，隨著Kubernetes的高速發(fā)展揍鸟，官方已經(jīng)推薦我們使用RS和Deployment來代替RC了，實際上RS和RC的功能基本一致句旱，目前唯一的一個區(qū)別就是RC只支持基于等式的selector（env=dev或environment!=qa）阳藻，但RS還支持基于集合的selector（version in (v1.0, v2.0)），這對復雜的運維管理就非常方便了谈撒。
kubectl命令行工具中關(guān)于RC的大部分命令同樣適用于我們的RS資源對象腥泥。不過我們也很少會去單獨使用RS，它主要被Deployment這個更加高層的資源對象使用啃匿，除非用戶需要自定義升級功能或根本不需要升級Pod蛔外，在一般情況下，我們推薦使用Deployment而不直接使用Replica Set溯乒。
最后我們總結(jié)下關(guān)于RC/RS的一些特性和作用吧：
- 大部分情況下夹厌，我們可以通過定義一個
RC實現(xiàn)的Pod的創(chuàng)建和副本數(shù)量的控制 -
RC中包含一個完整的Pod定義模塊（不包含apiversion和kind） -
RC是通過label selector機制來實現(xiàn)對Pod副本的控制的 - 通過改變
RC里面的Pod副本數(shù)量，可以實現(xiàn)Pod的擴縮容功能 - 通過改變
RC里面的Pod模板中鏡像版本裆悄，可以實現(xiàn)Pod的滾動升級功能（但是不支持一鍵回滾矛纹，需要用相同的方法去修改鏡像地址）
