标签：kubectl deploymentdemo1 template Deployment Pod spec

Deployment是kubernetes在1.2版本中引入的新概念，用于更好的解决Pod的编排问题，为此，Deployment在内部使用了ReplicaSet来实现目的，我们可以把Deployment理解为ReplicaSet的一次升级，两者的相似度超过90%

Deployment的使用场景有以下几个：

• 创建一个Deployment对象来生成对应的ReplicaSet并完成Pod副本的创建
• 检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到了预期的值）
• 更新Deployment以创建新的Pod（比如镜像升级）
• 如果当前Deployment不稳定，可以回滚到一个早先的Deployment版本
• 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后在恢复Deployment，进行新的发布
• 扩展Deployment以应对高负载
• 查看Deployment的状态，以此作为发布是否成功的标志
• 清理不在需要的旧版本ReplicaSet

详细信息

kubectl explain deploy
kubectl explain deploy.spec
kubectl explain deploy.spec.template.spec

部署

deploymentdemo.yml

apiVersion: apps/v1
kind: Deployment
metadata:
name: deploymentdemo1
labels:
 app: deploymentdemo1
spec:
replicas: 10
template:
 metadata:
  name: deploymentdemo1
  labels:
   app: deploymentdemo1
 spec:
  containers:
   - name: deploymentdemo1
    image: nginx:1.17.10-alpine
    imagePullPolicy: IfNotPresent
    ports:
     - containerPort: 80
  restartPolicy: Always
selector:
 matchLabels:
  app: deploymentdemo1

运行

kubectl apply -f deploymentdemo.yml

查看deployment
kubectl get rs
查看rs:deployment名称+hashcode码组成

查看pod
kubectl get pod

镜像更新升级

命令行方式

升级nginx镜像版本为1.18.0
kubectl set image deployment deploymentdemo1 deploymentdemo1=nginx:1.18.0-alpine

查看pod升级情况
kubectl get pods -w

进去某一个pod内部，查看nginx升级版本信息
kubectl exec -it deploymentdemo1-df6bc5d4c-flc7b sh
nginx -v
exit

yml文件方式

升级nginx镜像版本为1.19.2-alpine
kubectl edit deployments.apps deploymentdemo1

查看pod升级情况
kubectl get pods -w

进去某一个pod内部，查看nginx升级版本信息
kubectl exec -it deploymentdemo1-584f6b54dd-4l62t sh
nginx -v
exit

Deployment扩容

命令行方式

kubectl scale deployment deploymentdemo1 --replicas=15

kubectl get pods

yml文件方式

kubectl edit deployments.apps deploymentdemo1

kubectl get pods

滚动更新

微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布

1. 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。 蓝绿部署无需停机，并且风险较小。
2. 滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。 这种部署方式相对于蓝绿部署，更加节约资源，它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。
3. 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。
4. 金丝雀发布：Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布（Canary Release）

更新deployment的nginx:1.18.0-alpine版本，并配置暂停deployment
kubectl set image deployment deploymentdemo1 deploymentdemo1=nginx:1.18.0-alpine && kubectl rollout pause deployment deploymentdemo1

观察更新状态
kubectl rollout status deployments deploymentdemo1

监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl get pods -l app=deploymentdemo1 -w

确保更新的pod没问题了，继续更新
kubectl rollout resume deploy deploymentdemo1

查看最后的更新情况
kubectl get pods -l app=deploymentdemo1 -w

进去某一个pod内部，查看nginx更新版本信息
kubectl exec -it deploymentdemo1-df6bc5d4c-flc7b sh
nginx -v

Deployment版本回退

默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便可以随时回退（可以修改 revision history limit 来更改保存的revision数）。

注意：只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当Deployment 的 Pod template（如.spec.template ）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。

其他的更新，比如扩容 Deployment 不会创建 revision，因此可以很方便的手动或者自动扩容。这意味着当回退到历史 revision时，只有 Deployment 中的 Pod template 部分才会回退。

rollout常见命令

子命令	功能说明
history	查看rollout操作历史
pause	将提供的资源设定为暂停状态
restart	重启某资源
resume	将某资源从暂停状态恢复正常
status	查看rollout操作状态
undo	回滚前一rollout

history操作

kubectl rollout history deployment deploymentdemo1 

status操作

kubectl rollout status deployment deploymentdemo1 

undo操作

回滚版本信息
kubectl rollout undo deployment deploymentdemo1

查看pod回滚情况
kubectl get pods -w

进去某一个pod内部，查看nginx回滚版本信息
kubectl exec -it deploymentdemo1-df6bc5d4c-flc7b sh
nginx -v

Deployment 更新策略

Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少
一个是up状态（最多一个不可用）

Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望
的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）

Kuberentes 版本v1.17.5中，从1-1变成25%-25%

kubectl describe deployments.apps deploymentdemo1

查看到属性：
RollingUpdateStrategy:  25% max unavailable, 25% max surge

总结

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。也可以定义一个全新的 Deployment 来创建 ReplicaSet或者删除已有的 Deployment 并创建一个新的来替换。

Replicas（副本数量）：

​ .spec.replicas 是可以选字段，指定期望的pod数量，默认是1。

Selector（选择器）：

​ .spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果.spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。

在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。

Pod Template（Pod模板）：

.spec.template 是 .spec中唯一要求的字段。

.spec.template 是 pod template. 它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。

另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。

.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

strategy（更新策略）：

.spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是"Recreate"或者是"RollingUpdate"。"RollingUpdate"是默认值。

• Recreate： 重建式更新，就是删一个建一个。类似于ReplicaSet的更新方式，即首先删除现有的Pod对象，然后由控制器基于新模板重新创建新版本资源对象。

• rollingUpdate：滚动更新，简单定义 更新期间pod最多有几个等。可以指定 maxUnavailable和 maxSurge 来控制 rolling update 进程。

• maxSurge： .spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值（例如5）或者是期望的Pod数量的百分比（例如10%）。当 MaxUnavailable 为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。

  例如，该值设置成30%，启动rolling update后新的ReplicatSet将会立即扩容，新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后，新的ReplicaSet将继续扩容，旧的ReplicaSet会进一步缩容，确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。

• maxUnavailable： .spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值（例如5），也可以是期望Pod数量的百分比（例如10%）。通过计算百分比的绝对值向下取整。 如果 .spec.strategy.rollingUpdate.maxSurge 为0时，这个值不可以为0。默认值是1。

  例如，该值设置成30%，启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的70%。新的Pod ready后，随着新的ReplicaSet的扩容，旧的ReplicaSet会进一步缩容确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。

rollbackTo：

.spec.rollbackTo 是一个可以选配置项，用来配置Deployment回退的配置。设置该参数将触发回退操作，每次回退完成后，该值就会被清除。

• revision： .spec.rollbackTo.revision 是一个可选配置项，用来指定回退到的revision。默认是0，意味着回退到上一个revision。

progressDeadlineSeconds：

.spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing——表现为resource的状态中 type=Progressing 、 Status=False 、
Reason=ProgressDeadlineExceeded 前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。

如果设置该参数，该值必须大于 .spec.minReadySeconds 。

paused：

.spec.paused 是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。

标签：kubectl,deploymentdemo1,template,Deployment,Pod,spec
来源： https://www.cnblogs.com/ltaodream/p/15320463.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。