本文基於kubernetes 1.5.2版本編寫
概念
Deployment（中文意思爲部署、調度）提供了一種更加簡單的更新RC和Pod的機制，K8S版本1.2實現的。通過在Deployment中描述所期望的集羣狀態，Deployment Controller會將現在的集羣狀態在一個可控的速度下逐步更新成所期望的集羣狀態。Deployment主要職責同樣是爲了保證pod的數量和健康，90%的功能與RC完全一樣，可以看做新一代的RC。
功能
Deployment集成了上線部署、滾動升級、創建副本、暫停上線任務，恢復上線任務，回滾到以前某一版本（成功/穩定）的Deployment等功能，在某種程度上，Deployment可以實現無人值守的上線，大大降低上線過程的複雜溝通、操作風險。
RC全部功能：Deployment繼承了RC全部功能。
事件和狀態查看：可以查看Deployment的升級詳細進度和狀態。
回滾：當升級pod鏡像或者相關參數時發現問題，可以使用回滾操作回滾到上一個穩定的版本或者指定的版本。
版本記錄：每次對Deployment的操作，都能保存下來，給予後續可能的回滾使用。
暫停和啓動：對於每一次升級，都能夠隨時暫停和啓動。
多種升級方案：Recreate--刪除所有已存在的pod,重新創建新的; RollingUpdate--滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數，例如設置最大不可用pod數量，最小升級間隔時間等等。
使用場景
使用Deployment來啓動（上線/部署）一個Pod或者RS
檢查一個Deployment是否成功執行
更新Deployment來重新創建相應的Pods（例如，需要使用一個新的Image）
如果現有的Deployment不穩定，那麼回滾到一個早期的穩定的Deployment版本
暫停或者恢復一個Deployment
與RC比較，deployment的優勢
Deployment使用了RS，它是更高一層的概念。
RC只支持基於等式的selector（env=dev或environment!=qa），但RS還支持新的，基於集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），這對複雜的運維管理很方便。
使用Deployment升級Pod，只需要定義Pod的最終狀態，K8S會爲你執行必要的操作，雖然能夠使用命令kubectl rolling-update完成升級，但它是在客戶端與服務端多次交互控制RC完成的，所以REST API中並沒有rolling-update的接口，這爲定製自己的管理系統帶來了一些麻煩。
Deployment擁有更加靈活強大的升級、回滾功能。
常用命令
創建
使用子命令create，創建Deployment
kubectl create -f test-dpm.yaml --record
注意--record參數，使用此參數將記錄後續創建對象的操作，方便管理與問題追溯
查看部署狀態
kubectl rolloutstatus deployment/lykops-dpm
kubectl describe deployment/lykops-dpm
升級
kubectl set image deployment/lykops-dpm lykops-dpm=app:v1
或者使用子命令edit，編輯spec.replicas/spec.template.spec.container.image字段，完成deployment的擴縮容與滾動升級（這要比子命令rolling-update速度快很多）
暫定升級
kubectl rolloutpause deployment/lykops-dpm
繼續升級
kubectl rolloutresume deployment/lykops-dpm
回滾
kubectl rolloutundo deployment/lykops-dpm
查看deployments版本
kubectl rollouthistory deployments
回滾到指定版本
kubectl rolloutundo deployment/lykops-dpm --to-revision=2
升級歷史
kubectl describedeployment/lykops-dpm
Name: lykops-dpm
Namespace: default
CreationTimestamp: Tue, 01 Aug 2017 16:56:45 +0800
Labels: app=lykops-dpm
project=lykops
software=apache
version=v1
Selector: app=lykops-dpm,name=lykops-dpm,project=lykops,software=apache,version=v1
Replicas: 3updated | 3 total | 3 available | 0 unavailable
StrategyType: Recreate
MinReadySeconds: 30
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: lykops-dpm-4183418831 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-2823415590 to 3
28m 28m 1 {deployment-controller } Normal ScalingReplicaSet Scaleddown replica set lykops-dpm-2823415590 to 0
28m 28m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-4001949646 to 3
26m 26m 1 {deployment-controller } Normal ScalingReplicaSet Scaleddown replica set lykops-dpm-4001949646 to 0
26m 26m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-4183418831 to 3
例子
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: lykops-dpm
labels:
software: apache
project: lykops
app: lykops-dpm
version: v1
spec:
replicas: 3 #副本數量
minReadySeconds: 30 #滾動升級時，容器準備就緒時間最少爲30s
strategy:
type: recreate #升級方式
#rollingUpdate:##由於replicas爲3,則整個升級,pod個數在2-4個之間
# maxSurge: 3 #滾動升級時會先啓動3個pod
# maxUnavailable: 1 #滾動升級時允許的最大Unavailable的pod個數
selector:
matchLabels:
name: lykops-dpm
software: apache
project: lykops
app: lykops-dpm
version: v1
template:
metadata:
labels:
name: lykops-dpm
software: apache
project: lykops
app: lykops-dpm
version: v1
spec:
terminationGracePeriodSeconds: 60 ##k8s將會給應用發送SIGTERM信號，可以用來正確、優雅地關閉應用,默認爲30秒
containers:
- name: lykops-dpm
image: web:apache
command: [ "sh", "/etc/run.sh" ]
ports:
- containerPort: 80
name: http
protocol: TCP
resources:
requests:
cpu: 0.05
memory: 16Mi
limits:
cpu: 0.1
memory: 32Mi
livenessProbe:#livenessProbe是K8S認爲該pod是存活的，不存在則需要kill掉，然後再新啓動一個，以達到RS指定的個數。
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:#readinessProbe是K8S認爲該pod是啓動成功的，這裏根據每個應用的特性，自己去判斷，可以執行command，也可以進行httpGet。
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
參數說明
strategy中的type
升級策略有recreate和rollingUpdate。recreate--刪除所有已存在的pod，重新創建新的; rollingUpdate--滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數，例如設置最大不可用pod數量，最小升級間隔時間等等。
如何使用哪種策略，需要看應用場景。recreate策略將會在升級過程中，停止服務，但會保證應用版本一致；使用rollingUpdate不會中斷服務，但會導致調用時出現應用版本不一致的情況，輸出內容不一致。
maxSurge與maxUnavailable
maxSurge: 1 表示滾動升級時會先啓動1個pod
maxUnavailable:1 表示滾動升級時允許的最大Unavailable的pod個數。由於replicas爲3,則整個升級,pod個數在2-4個之間 terminationGracePeriodSeconds
k8s將會給應用發送SIGTERM信號，可以用來正確、優雅地關閉應用,默認爲30秒。
如果需要更優雅地關閉，則可以使用k8s提供的pre-stop lifecycle hook 的配置聲明，將會在發送SIGTERM之前執行。
livenessProbe與readinessProbe
livenessProbe是K8S認爲該pod是存活的，不存在則需要kill掉，然後再新啓動一個，以達到RS指定的個數。
readinessProbe是K8S認爲該pod是啓動成功的，這裏根據每個應用的特性，自己去判斷，可以執行command，也可以進行httpGet。比如對於使用java web服務的應用來說，並不是簡單地說tomcat啓動成功就可以對外提供服務的，還需要等待spring容器初始化，數據庫連接連接上等等。對於spring boot應用，默認的actuator帶有/health接口，可以用來進行啓動成功的判斷。
其中readinessProbe.initialDelaySeconds可以設置爲系統完全啓動起來所需的最少時間，livenessProbe.initialDelaySeconds可以設置爲系統完全啓動起來所需的最大時間+若干秒。