【重识云原生】第四章容器基础6.4.5.2节——Deployment配置详细说明

  《重识云原生系列》专题索引：

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
4. 第二章计算第3节——主流虚拟化技术之Xen
5. 第二章计算第4节——主流虚拟化技术之KVM
6. 第二章计算第5节——商用云主机方案
7. 第二章计算第6节——裸金属方案
8. 第三章云存储第1节——分布式云存储总述
9. 第三章云存储第2节——SPDK方案综述
10. 第三章云存储第3节——Ceph统一存储方案
11. 第三章云存储第4节——OpenStack Swift 对象存储方案
12. 第三章云存储第5节——商用分布式云存储方案
13. 第四章云网络第一节——云网络技术发展简述
14. 第四章云网络4.2节——相关基础知识准备
15. 第四章云网络4.3节——重要网络协议
16. 第四章云网络4.3.1节——路由技术简述
17. 第四章云网络4.3.2节——VLAN技术
18. 第四章云网络4.3.3节——RIP协议
19. 第四章云网络4.3.4节——OSPF协议
20. 第四章云网络4.3.5节——EIGRP协议
21. 第四章云网络4.3.6节——IS-IS协议
22. 第四章云网络4.3.7节——BGP协议
23. 第四章云网络4.3.7.2节——BGP协议概述
24. 第四章云网络4.3.7.3节——BGP协议实现原理
25. 第四章云网络4.3.7.4节——高级特性
26. 第四章云网络4.3.7.5节——实操
27. 第四章云网络4.3.7.6节——MP-BGP协议
28. 第四章云网络4.3.8节——策略路由
29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
30. 第四章云网络4.3.10节——VXLAN技术
31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
32. 第四章云网络4.3.10.3节——VXLAN隧道机制
33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
34. 第四章云网络4.3.10.5节——VXlan组网架构
35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
36. 第四章云网络4.4节——Spine-Leaf网络架构
37. 第四章云网络4.5节——大二层网络
38. 第四章云网络4.6节——Underlay 和 Overlay概念
39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
41. 第四章云网络4.7.3节——Vhost-net方案
42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
45. 第四章云网络4.7.8节——SR-IOV方案
46. 第四章云网络4.7.9节——NFV
47. 第四章云网络4.8.1节——SDN总述
48. 第四章云网络4.8.2.1节——OpenFlow概述
49. 第四章云网络4.8.2.2节——OpenFlow协议详解
50. 第四章云网络4.8.2.3节——OpenFlow运行机制
51. 第四章云网络4.8.3.1节——Open vSwitch简介
52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
53. 第四章云网络4.8.4节——OpenStack与SDN的集成
54. 第四章云网络4.8.5节——OpenDayLight
55. 第四章云网络4.8.6节——Dragonflow

56.  第四章云网络4.9.1节——网络卸载加速技术综述

57. 第四章云网络4.9.2节——传统网络卸载技术

58. 第四章云网络4.9.3.1节——DPDK技术综述

59. 第四章云网络4.9.3.2节——DPDK原理详解

60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

61. 第四章云网络4.9.4.2节——智能网卡实现

62. 第六章容器6.1.1节——容器综述

63. 第六章容器6.1.2节——容器安装部署

64. 第六章容器6.1.3节——Docker常用命令

65. 第六章容器6.1.4节——Docker核心技术LXC

66. 第六章容器6.1.5节——Docker核心技术Namespace

67. 第六章容器6.1.6节—— Docker核心技术Chroot

68. 第六章容器6.1.7.1节——Docker核心技术cgroups综述

69. 第六章容器6.1.7.2节——cgroups原理剖析

70. 第六章容器6.1.7.3节——cgroups数据结构剖析

71. 第六章容器6.1.7.4节——cgroups使用

72. 第六章容器6.1.8节——Docker核心技术UnionFS

73. 第六章容器6.1.9节——Docker镜像技术剖析

74. 第六章容器6.1.10节——DockerFile解析

75. 第六章容器6.1.11节——docker-compose容器编排

76. 第六章容器6.1.12节——Docker网络模型设计

77. 第六章容器6.2.1节——Kubernetes概述

78. 第六章容器6.2.2节——K8S架构剖析

79. 第六章容器6.3.1节——K8S核心组件总述

80. 第六章容器6.3.2节——API Server组件

81. 第六章容器6.3.3节——Kube-Scheduler使用篇

82. 第六章容器6.3.4节——etcd组件

83. 第六章容器6.3.5节——Controller Manager概述

84. 第六章容器6.3.6节——kubelet组件

85. 第六章容器6.3.7节——命令行工具kubectl

86. 第六章容器6.3.8节——kube-proxy

87. 第六章容器6.4.1节——K8S资源对象总览

88. 第六章容器6.4.2.1节——pod详解

89. 第六章容器6.4.2.2节——Pod使用(上)

90. 第六章容器6.4.2.3节——Pod使用(下)

91. 第六章容器6.4.3节——ReplicationController

92. 第六章容器6.4.4节——ReplicaSet组件

93. 第六章容器基础6.4.5.1节——Deployment概述

94. 第六章容器基础6.4.5.2节——Deployment配置详细说明

95. 第六章容器基础6.4.5.3节——Deployment实现原理解析

96. 第六章容器基础6.4.6节——Daemonset

97. 第六章容器基础6.4.7节——Job

98. 第六章容器基础6.4.8节——CronJob

1 deployment配置说明

1.1 deployment的资源清单文件

主要字段说明：

全量字段说明：

apiVersion: apps/v1 #版本号 
kind: Deployment #类型 
metadata: #元数据 
  name: #rs名称 
  namespace: #所属命名空间 
  labels: #标签 
  controller: deploy 
spec: #详情描述 
  replicas: #副本数量 
  revisionHistoryLimit: #保留历史版本，默认是10 
  paused: #暂停部署，默认是false 
  progressDeadlineSeconds: #部署超时时间(s)，默认是600 
  strategy: #策略 
    type: RollingUpdates #滚动更新策略 
    rollingUpdate: #滚动更新 
      maxSurge: #最大额外可以存在的副本数，可以为百分比，也可以为整数 
      maxUnavaliable: #最大不可用状态的pod的最大值，可以为百分比，也可以为整数 
  selector: #选择器，通过它指定该控制器管理哪些pod 
    matchLabels: #Labels匹配规则 
      app: nginx-pod 
    matchExpressions: #Expression匹配规则 
      - {key: app, operator: In, values: [nginx-pod]} 
  template: #模板，当副本数量不足时，会根据下面的模板创建pod副本 
    metadata: 
      labels: 
        app: nginx-pod 
    spec: 
      containers: 
        - name: nginx 
          image: nginx:1.17.1 
          ports: 
            - containerPort: 80

1.2 编写 Deployment Spec

        在所有的 Kubernetes 配置中，Deployment 也需要 apiVersion，kind 和 metadata 这些配置项。配置文件的通用使用说明查看 部署应用，配置容器，和使用 kubeclt 管理资源 文档。

Deployment 也需要 .spec section.

1.2.1 Pod Template

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

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

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

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

1.2.2 Replicas

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

1.2.3 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。

注意：你不应该再创建其他 label 跟这个 selector 匹配的 pod，或者通过其他 Deployment，或者通过其他 Controller，例如 ReplicaSet 和 ReplicationController。否则该 Deployment 会被把它们当成都是自己创建的。Kubernetes 不会阻止你这么做。

        如果你有多个 controller 使用了重复的 selector，controller 们就会互相打架并导致不正确的行为。

1.2.4 策略

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

1.2.4.1 Recreate Deployment

        .spec.strategy.type==Recreate 时，在创建出新的 Pod 之前会先杀掉所有已存在的 Pod。

1.2.4.2 Rolling Update Deployment

        .spec.strategy.type==RollingUpdate 时，Deployment 使用 rolling update 的方式更新 Pod 。你可以指定 maxUnavailable 和 maxSurge 来控制 rolling update 进程。

• Max Unavailable

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

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

• Max Surge

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

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

1.2.5 Progress Deadline Seconds

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

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

1.2.6 Min Ready Seconds

        .spec.minReadySeconds 是一个可选配置项，用来指定没有任何容器 crash 的 Pod 并被认为是可用状态的最小秒数。默认是 0（Pod 在 ready 后就会被认为是可用状态）。进一步了解什么时候 Pod 会被认为是 ready 状态，参阅 Container Probes。

1.2.7 Rollback To

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

1.2.7.1 Revision

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

1.2.8 Revision History Limit

        Deployment revision history 存储在它控制的 ReplicaSets 中。

        .spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的 ReplicaSet 数量。该理想值取决于新 Deployment 的频率和稳定性。如果该值没有设置的话，默认所有旧的 Replicaset 或会被保留，将资源存储在 etcd 中，使用 kubectl get rs 查看输出。每个 Deployment 的该配置都保存在 ReplicaSet 中，然而，一旦你删除的旧的 RepelicaSet，你的 Deployment 就无法再回退到那个 revison 了。

        如果你将该值设置为 0，所有具有 0 个 replica 的 ReplicaSet 都会被删除。在这种情况下，新的 Deployment rollout 无法撤销，因为 revision history 都被清理掉了。

1.2.9 Paused

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

参考链接

Deployment

k8s中的deployment_遂言的博客-CSDN博客_deployment k8s

k8s之deployment详解 - 王叫兽 - 博客园

k8s之Deployment 资源详解 - 知乎

k8s之Deployment详解_Jeremy_Lee123的博客-CSDN博客_deployment k8s

k8s deployment

k8s之deployment - 路过的柚子厨 - 博客园

K8S-pod之Deployment - 简书

每天5分钟｜轻松掌握开发工作必会的k8s-deployment与rs

kubernetes-Deployment部署无状态服务的原理详解（二十五） - Andya_net - 博客园

详解 Kubernetes Deployment 的实现原理 - 面向信仰编程