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-deploymentnamespace: default spec:replicas: 3selector:matchLabels:name: hello-deploymentstrategy:type: RollingUpdaterollingUpdate:maxSurge: 10%maxUnavailable: 0 template:metadata:labels:name: hello-deploymentspec:containers:- name: webserverimage: nginx:1.14ports:- 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

轉載于:https://www.cnblogs.com/breezey/p/8810094.html

總結

以上是生活随笔為你收集整理的Kubernetes Deployment与Replica Set的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。