簡寫為deploy，是k8s控制器的另一種實現，它構建於ReplicaSet之上，可為pod和rs資源提供聲明式更新。
deploy控制器資源的大部分功能均可通過調用rs來實現，同時，還增添了部分特性：
事件和狀態查看：必要時可以查看deploy對象升級的詳細進度和狀態
回滾：升級操作完成后發現問題時，支持使用回滾機制將應用返回到前一個或由用戶指定的歷史記錄中的版本
版本記錄：對deploy對象的每一次操作都予以保存，以提供后續可能執行的回滾操作
暫停和啟動：對於每一次升級，都能夠隨時暫停和啟動
多種自動更新方案：一是Recreate，即重建更新機制，全面停止、刪除舊的pod后用新版本替代；另一個RollingUpdate，即滾動升級機制，逐步替換舊的pod至新的版本
一、創建deploy
其spec字段中嵌套使用的字段包含了rs控制器支持的replicas、selector、template和minReadySeconds，它也正是利用這些信息完成了其二級資源rs對象的創建，如下示例：
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy spec: replicas: 3 selector: matchLabels: labels: app: myapp spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - containerPort: 80 name: http
使用命令“kubectl apply -f myapp-deploy.yaml --record”命令部署，使用“kubectl get deploy”命令可以列出創建的deploy對象相關信息。deploy控制器會自動創建相關的rs控制器，並以“[deployment_name]-[template-hash-value]”格式為其命名，其中的hash值由deploy自動生成。由deploy創建的rs對象會自動使用相同的標簽選擇器。deploy借助於rs管理pod資源，其大部分管理操作與rs相同，不過，deploy也有rs所不具有的部分高級功能，這其中最著名的為自動滾動更新機制。
二、更新策略
depoly只需要由用戶指定在pod模板中要改動的內容交由其自動完成更新，更新應用程序的規模也只需要修改期望的副本數量，余下的事情交給deploy控制器即可。
deploy控制器支持兩種更新策略：滾動更新和重新創建，默認為滾動更新。重新創建即首先刪除現有的pod對象，而后由控制器基於新模板重新創建出新版本資源對象。通常，只應該在應用的新舊版本不兼容時才會使用recreate策略。
滾動更新在刪除一部分舊版本pod資源的同時，補充創建一部分新版本的pod對象進行應用升級，其優勢是升級期間，容器中應用提供的服務不會中斷，但要求應用程序能夠應對新舊版本同時工作的情形。
deploy控制器的滾動更新操作並非在同一個rs控制器對象下刪除並創建pod資源，而是將它們分置於兩個不同的控制器之下：舊控制器的pod對象數量不斷減少的同時，新控制器的pod對象數量不斷增加，直到舊控制器不再擁有pod對象，而新控制器的副本數量變得完全符合期望值為止。
滾動更新時，應用升級期間還要確保可用的pod對象數量不低於某閾值以確保可以持續處理客戶端的服務請求，變動的方式和pod對象的數量范圍將通過spec.strategy.rollingUpdate.maxSurge和spec.rollingUpdate.maxUnavailable兩個屬性協同進行定義。
maxSurge：指定升級期間存在的總pod對象數量最多可超出期望值的個數，其值可以是0或正整數，也可以是一個期望值的百分比
maxUnavailable：升級期間正常可用的pod副本數（包括新舊版本）最多不能低於期望數值的個數，其值可以是0或正整數，也可以是一個期望值的百分比；默認值為1.
maxSurge和maxUnavailable屬性的值不可同時為0，否則pod對象的副本數在符合用戶期望的數量后無法做出合理變動以進行滾動更新操作。
配置時，用戶還可以使用deploy控制器的spec.minReadySeconds屬性來控制應用的升級速度。新舊更替過程中，新創建的pod對象一旦成功響應就緒探測即被視為可用，而后即可立即開始下一輪的替換操作。而spec.minReadySeconds能夠定義在新的pod對象來讓k8s在每次創建出pod資源后都要等上一段時長后再開始下一輪的更替，這個時間長度的理想值是等到pod對象中的應用已經可以接受並處理請求流量。
deploy控制器也支持用戶保留其滾動更新歷史中的舊rs對象版本，控制器可保存的歷史版本數量由spec.revisionHistoryLimit屬性進行定義。在創建deploy對象時使用“--record”選項來保存版本升級的歷史。
三、升級deploy
修改pod模板相關的配置參數便能完成deploy控制器資源的更新，對deploy控制器資源的修改尤其適合使用apply和patch命令來進行；
四、金絲雀發布
deploy控制器還支持自定義控制更新過程中的滾動節奏，如暫停（pause）或繼續（resume）更新操作，尤其時借助於maxSurge和maxUnavailable屬性還能實現更為精巧的過程控制。例如，待第一批新pod對象創建完成后立即暫停更新過程，此時，僅存在一小部分新版本的應用，主體部分還是舊版本。然后再根據用戶特征精心篩選出小部分用戶的請求路由至新版本的pod應用，並持續觀察其是否能穩定低按期望的方式運行。確定沒有問題后再繼續完成余下pod資源的滾動更新，否則立即回滾更新操作，這便是金絲雀發布。
五、回滾deploy控制器下的應用發布
若因各種原因導致滾動更新無法正常進行，則應將應用回滾到之前的版本，或者回滾到由用戶指定的歷史記錄中的版本，可使用命令“kubectl rollout undo”完成，也可使用選項“--to-version=*”來指定版本。回滾操作中，其revision記錄中的信息會發生變動，回滾操作會被當作一次滾動更新追加進歷史記錄中，而被回滾的條目則會被刪除。需要注意的是，如果此前的滾動更新過程處於暫停狀態，那么回滾操作就需要先將pod模板的版本改回到之前的版本，然后繼續更新，否則，其將一直處於暫停狀態無法回滾。
六、擴容和縮容
通過修改spec.replicas即可修改deploy中pod資源副本數量，它將實時作用於控制器並直接生效。deploy是聲明式配置，replicas屬性的值可直接修改資源配置文件，然后使用kubectl apply進行應用，也可以使用kubectl edit對其進行實時修改。而前一種方式能夠將修改結果予以長期留存。另外，kubectl scale命令是專用於擴展某些控制器類型的應用規模的，包括deploy和job等。而deploy通過replicaset控制其pod資源，因此擴縮容的方式是相同的。