什麼是Deployment？
Deployment提供了運作Pod能力，并且為Pod提供滾動更新、伸縮、副本等功能，一般用于運作無狀态的應用。目前建議使用Deployment來代替RelicaSet及ReplicationController的使用。
什麼是無狀态應用？
無狀态應用是不将資料或應用程式狀态存儲到容器中，這将使無狀态應用程式更具可伸縮性。例如前端應用是無狀态的，可以部署多個副本以提高其可用性并在需求低時進行縮減，并且這些副本不需要唯一的辨別。
Deployment操作
建立Deployment
kubectl create deployment nginx-deployment --image=nginx:1.16
通過yaml檔案操作
kubectl apply -f nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16 
檢視Deployment清單
kubectl get deployment
檢視Deployment描述資訊
kubectl describe deployment
Deployment 手動伸縮Pod數量
方式1. 通過kubectl set image
kubectl scale deployment nginx-deployment --replicas 5
方式2. 通過kubectl apply
kubectl apply -f nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16 方式3. 通過kubectl edit
kubectl edit deployment/nginx-deployment
spec:
replicas: 5 Deployment 自動伸縮Pod數量 (Horizontal Pod Autoscaler)
HPA基于觀察到的CPU使用率或借助自定義名額自動縮放 ReplicaSet、Deployment中的Pod數量 。控制器會定期調整複制控制器或部署中副本的數量，以使觀察到的平均CPU使用率與使用者指定的目标相比對。
方式1. 通過autoscale
kubectl autoscale deployment nginx-deployment --min=5 --max=10 --cpu-percent=80
方式2. 通過yaml檔案
kubectl apply -f hpa-demo.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: nginx-deployment
spec:
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: nginx-deployment
minReplicas: 5
maxReplicas: 10
targetCPUUtilizationPercentage: 80 kubectl edit hpa nginx-deployment
spec:
maxReplicas: 10
minReplicas: 5
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment
targetCPUUtilizationPercentage: 80 檢視HPA清單
kubectl get hpa
檢視HPA描述資訊
kubectl describe hpa nginx-deployment
Deployment 版本管理
通過更改部署的Pod模闆規範來更新Deployment中Pod鏡像。觸發更新時Deployment會停止Pod及逐漸将Pod的數量縮減為零，然後使用Pod模闆來調出新的Pod。
kubectl set image deployment/nginx-deployment nginx=nginx:1.17
kubectl apply -f deployment-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.17 kubectl edit deployment/nginx-deployment
spec:
containers:
image: nginx:1.17 通過.spec.revisionHistoryLimit 字段，可指定為該 Deployment 保留多少個舊的 ReplicaSet。
預設為10，當為0時，将無法對Deployment進行復原操作。
檢視曆史版本，在這裡版本1的是nginx:1.16，版本2是nginx:1.17
kubectl rollout history deployment/nginx-deployment
復原版本到版本1
kubectl rollout undo deployment/nginx-deployment
檢視更新狀态
kubectl rollout status deployment/nginx-deployment
暫停更新
kubectl rollout pause deployment/nginx-deployment
恢複更新
kubectl rollout resume deployment/nginx-deployment
部署政策
在Kubernetes中，針對于不同的應用場景推出了不同的釋出政策，選擇合适的政策将會使業務在釋出過程中更加穩定。
Recreate: (重建) 停止舊版本服務後部署新版本
優點: 容易配置，服務一次性更新。
缺點: 部署時間長，取決于舊版本的停止時間及新版本的部署時間。
通過Deployment YAML配置清單定義
spec:
replicas: 3
strategy:
type: Recreate RollingUpdate: (滾動) 舊版本到新版本的逐漸替換的政策
優點: 容易配置，不用停機，處理狀态平衡的服務友善。
缺點: 需要一定的時間去完成部署、復原，無法控制流量。
spec:
strategy:
type: RollingUpdate #指定滾動更新
rollingUpdate:
maxSurge: 25% #超過期望的Pod數量
maxUnavailable: 25% #不可用Pod最大數量 .spec.strategy.rollingUpdate.minReadySeconds:
設定更新前等待時間，防止容器啟動後造成無法提供服務
.spec.strategy.rollingUpdate.maxSurge:
設定更新過程中最多可以比定義的Pod多出的數量
.spec.strategy.rollingUpdate.maxUnavaible:
設定更新過程中最多有多少個Pod處于不可用狀态 定義滾動更新的政策，如果maxUnavaible用預設值1，實際沒起到更新失敗後對舊Pod的保護。如果新的Pod啟動失敗，依然把舊的正常Pod Kill掉了，這不符合我們的預期。改成百分比後，若新Pod啟動失敗，則更新過程會被Block住，舊的正常Pod還是處于Running狀态。
Blue/Green: (藍綠) 保持舊版本，釋出新版本，然後将流量從舊版本切換到新版本
優點: 即時部署、復原，服務一次性更新。
缺點: 由于新舊版本同時存在需要2倍的資源，無法處理有狀态應用。
通過Service YAML配置清單定義
labels:
app: nginx
version: v1.0.0
labels:
app: nginx
version: v2.0.0 Canary: (金絲雀)切換一部分使用者到新版本，然後在将全部流量切換到新版本
優點: 快速復原，如果出問題情況下影響最小
缺點: 需要一定的時間去完成部署、復原
通過Deployment YAML配置清單定義，調整不同ReplicaSet的副本數
spec: # Version v1.0.0
replicas: 90
spec: # Version v2.0.0
replicas: 10 或者可以通過Istio Route YAML配置清單定義
route:
- tags:
version: v1.0.0
weight: 90
- tags:
version: v2.0.0
weight: 10 A/B testing: (A/B測試) 根據不同的條件将流量切換到新版本，例如Cookie、位址位置、語言等
優點: 多版本同時運作，可控制流量
缺點: 需要負載均衡器根據條件去排程流量，需要分布式跟蹤去解決會話錯誤問題
通過Istio Route YAML配置清單定義
kind: RouteRule
metadata:
name: nginx-v1.0.0
spec:
destination:
name: nginx
route:
- labels:
version: v1.0.0
match:
request:
headers:
x-api-version:
exact: "v1.0.0"
kind: RouteRule
metadata:
name: nginx-v2.0.0
spec:
destination:
name: nginx
route:
- labels:
version: v2.0.0
match:
request:
headers:
x-api-version:
exact: "v2.0.0" Shadow: (影子) 傳入舊版本的請求流量鏡像到新版本，響應流量将會被丢棄，當滿足穩定性的測試時将會切換流量至新版本。
優點: 可以使用生産的流量對新版本進行測試而對使用者沒有影響
缺點: 由于新舊版本同時存在需要2倍的資源，配置複雜，可能需要模拟服務提供消相應
通過Istio VirtualSerivce YAML配置清單定義
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: nginx-vs
labels:
app: nginx
spec:
hosts:
- nginx.local
gateways:
- nginx
http:
- route:
- destination:
host: nginx-v1.0.0
mirror:
host: nginx-v2.0.0 一般在充足的測試下通常使用滾動或者藍綠方案，藍綠及陰影的方案對資源要求。如果缺乏測試或者信心可以使用金絲雀、A/B測試、影子方案。如果測試特定的次元可以使用A/B測試方案。如果使用到影子方案則需要額外的服務模拟流量，以及防止對資料的重複生産，但用在測試性能時很有用。
Deployment狀态管理
與Pod一樣，Deployment的聲明周期不是一直處于同一個狀态不變的，在操作ReplicaSet時狀态會随之改變。
Progressing Deployment正在建立新的ReplicaSet、正在擴容、縮容已有的ReplicaSet。
Available Deployment的可用副本數已經達到期望定義的政策，ReplicaSet中的版本已經更新完成。
Failed Deployment配置了無效的引用、錯誤的探針、無法拉取鏡像、權限不足等。
通過kubectl檢視Deployment狀态情況，Conditions段
kubectl describe deployment
kubectl get deployment -o yaml
使用技巧
在業務情況允許下，盡量将容器設定成無狀态化的方式運作，這樣對于環境等要求是最小的。而且容器設定采用最小化功能的原則，一個Pod内可以包含多個容器負責不同的功能。