Deployment的主要职责同样是为了保证Pod的数量和健康,而且绝大多数的功能与Replication Controller完全一样,因此可以被看作新一代的Replication Controller。

1. 什么是Deployment?

Kubernetes提供了一种更加简单的更新RC和Pod的机制,叫做Deployment。通过在Deployment中描述期望的集群状态,Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成期望的集群状态。Deployment过程如下图所示:

deployment-process

2. Deployment作用

Deployment的主要职责同样是为了保证Pod的数量和健康,而且绝大多数的功能与Replication Controller完全一样,因此可以被看作新一代的Replication Controller。但是,它又具备了Replication Controller不具备的新特性:

  • 事件和状态查看:可以查看升级的详细进度和状态。
  • 回滚:当升级Pod镜像或者相关参数的时候发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本
  • 版本记录:每一次对Deployment的操作都能保存下来,给予后续可能的回滚使用。
  • 暂停和启动:对于每一次升级,都能够随时暂停和启动
  • 多种升级方案:
    • Recreate: 删除所有已存在的Pod,重新创建新的。
    • RollingUpdate: 滚动升级,即逐步替换的策略。滚动升级时支持更多的附加参数,例如,设置最大不可用Pod数量、最小升级间隔时间等。

3. 创建Deployment

Deployment是标准的Kubernetes API资源,它建构于ReplicaSet资源之上,于是其spec字段中嵌套使用的字段包含了ReplicaSet控制器支持的replicas、selector、template和minReadySeconds,它也正是利用这些信息完成了其二级资源ReplicaSet对象的创建。

下面是一个Deployment控制器资源的配置清单(nginx-deployment.yaml)示例:

apiVersion: apps/v1   #与k8s集群版本有关,使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment #该配置的类型,我们使用的是 Deployment
metadata: #译名为元数据,即 Deployment 的一些基本属性和信息
name: nginx-deployment #Deployment 的名称
labels: #标签,可以灵活定位一个或多个资源,其中key和value均可自定义,可以定义多组,目前不需要理解
app: nginx #为该Deployment设置key为app,value为nginx的标签
spec: #这是关于该Deployment的描述,可以理解为你期待该Deployment在k8s中如何使用
replicas: 1 #使用该Deployment创建一个应用程序实例
selector: #标签选择器,与上面的标签共同作用,目前不需要理解
matchLabels: #选择包含标签app:nginx的资源
app: nginx
template: #这是选择或创建的Pod的模板
metadata: #Pod的元数据
labels: #Pod的标签,上面的selector即选择包含标签app:nginx的Pod
app: nginx
spec: #期望Pod实现的功能(即在pod中部署)
containers: #生成container,与docker中的container是同一种
- name: nginx #container的名称
image: nginx:1.7.9 #使用镜像nginx:1.7.9创建container,该container默认80端口可访问
ports:
- containerPort: 80

创建命令

# 创建deployment资源
[root@master deployments]# kubectl apply -f nginx-deployment.yaml --record
deployment.apps/nginx-deployment created

为了保存版本升级的历史,需要在创建Deployment对象时于命令中使用--record选项

4. 查看deployment

查看创建的deployment资源状态

# 查看创建的deployment资源
[root@master deployments]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 1/1 1 1 16s
  • UP-TO-DATE : 表示已经达到期望状态的Pod副本数量。
  • AVAILABLE:则表示当前处于可用状态的应用程序的数量。

查看创建的deployment详细信息

[root@master deployments]# kubectl describe deployments nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Mon, 20 Jul 2020 13:35:52 +0800
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
kubernetes.io/change-cause: kubectl apply --filename=nginx-deployment.yaml --record=true
Selector: app=nginx
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate # 滚动更新
MinReadySeconds: 0 # 控制应用升级的速度
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.7.9
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-6dd8bc586b (1/1 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 6m50s deployment-controller Scaled up replica set nginx-deployment-6dd8bc586b to 1
  • StrategyType : 更新策略类型,默认RollingUpdate 滚动更新
  • MinReadySeconds : 控制应用升级的速度。新旧更替过程中,新创建的Pod对象一旦成功响应就绪探测即被视作可用,而后即可立即开始下一轮的替换操作。而spec.minReadySeconds能够定义在新的Pod对象创建后至少要等待多久才会将其视作就绪,在此期间,更新操作会被阻塞。
  • RollingUpdateStrategy : 升级期间pod具体方案。默认是总Pod对象数量最多25%不可用,最多不超过期望值的25%。

5. 修改Deployment

由于修改Pod模板相关的配置参数,会触发Deployment控制器资源的更新。这里只整理修改非Pod模板相关的配置参数示例。由于是声明式配置,因此对Deployment控制器资源的修改尤其适合使用apply和patch命令来进行。

使用 Kubectl patch 修改

修改·spec.minReadySeconds属性,便于观测升级过程

[root@master deployments]# kubectl patch deployments nginx-deployment -p '{"spec":{"minReadySeconds":5}}'
deployment.apps/nginx-deployment patched

## 查看修改结果
[root@master deployments]# kubectl describe deployments nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Mon, 20 Jul 2020 13:35:52 +0800
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
kubernetes.io/change-cause: kubectl apply --filename=nginx-deployment.yaml --record=true
Selector: app=nginx
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 5 # 此时已经修改为5秒
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.7.9
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-6dd8bc586b (1/1 replicas created)
Events: <none>

修改Deployment控制器的minReadySeconds、replicas和strategy等字段的值并不会触发Pod资源的更新操作,因为它们不属于模板的内嵌字段,对现存的Pod对象不产生任何影响。

6. 删除Deployment

# 查看Deployment
[root@master deployments]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 1/1 1 1 4d20h
# 删除Deployment nginx-deployment
[root@master deployments]# kubectl delete deployment nginx-deployment
deployment.apps "nginx-deployment" deleted
# 再次查看Deployment
[root@master deployments]# kubectl get deployment
No resources found in default namespace.