概念
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可以设置为系统完全启动起来所需的最大时间+若干秒。
本文转自CSDN-k8s使用deployment升级
