kubernetes Deployment控制器
Deployments介绍
Deployment（简写为deploy）是Kubernetes控制器的一种高级别实现，它构建于ReplicaSet控制器之上，它可用于为Pod和ReplicaSet资源提供声明式更新。相比较来说，Pod和ReplicaSet是较低级别的资源，以至于很少被直接使用。Deployment控制器资源的主要职责同样是为了保证Pod资源健康运行，其大部分功能通过调用ReplicaSet控制器实现，并增添了部分特性。
▪事件和状态查看：必要时可以查看Deployment对象的更新进度和状态。
▪版本记录：将Deployment对象的更新操作予以保存，以便后续可能执行的回滚操作使用。
▪回滚：更新操作启动后的任一时刻（包括完成后）发现问题，都可以通过回滚机制将应用返回到前一个或由用户指定的历史记录中的版本。
▪暂停和启动：更新过程中能够随时暂停和继续完成后面的步骤。
▪多种更新方案：一是Recreate，即重建更新机制，单批次更新所有Pod对象；另一个是RollingUpdate，即滚动更新机制，多批次逐步替换旧有的Pod至新的版本。Deployment资源的扩缩容机制与ReplicaSet相同，修改.spec.replicas即能实时触发其规模变动操作。另外，kubectl scale是专用于扩展特定控制器类型的应用规模的命令，包括Deployment、ReplicaSet和StatefulSet等。创建 Deployment
depoly-demoapp-v10.yaml
apiVersion: v1
kind: Namespace
metadata:
name: demoapp
---
apiVersion: v1
kind: Service
metadata:
labels:
app: demoappv10
name: demoappv10
namespace: demoapp
spec:
ports:
- name: http-8080
port: 8080
protocol: TCP
targetPort: 8080
selector:
app: demoapp
version: v1.0
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: demoappv10
version: v1.0
name: demoappv10
namespace: demoapp
spec:
replicas: 2
selector:
matchLabels:
app: demoapp
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: demoapp
version: v1.0
spec:
containers:
- image: ikubernetes/demoapp:v1.0
name: demoapp
env:
- name: PORT
value: "8080"
resources: {}创建deployment资源
# kubectl apply -f depoly-demoapp-v10.yamlnamespace/demoapp created
deployment.apps/demoappv10 created访问服务
# curl `kubectl get svc/demoappv10 -n demoapp -o jsonpath="{.spec.clusterIP}"`:8080iKubernetes demoapp v1.0 !! ClientIP: 172.20.151.128, ServerName: demoappv10-69f6cf9477-v9m6g, ServerIP: 172.20.154.216!查看deployment资源
# kubectl get deploy -n demoappNAME READY UP-TO-DATE AVAILABLE AGE
demoappv10 2/2 2 2 104s在检查集群中的 Deployment 时，所显示的字段有：
NAME 列出了名字空间中 Deployment 的名称。
READY 显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。
UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
AVAILABLE 显示应用可供用户使用的副本数。
AGE 显示应用程序运行的时间。查看 Deployment 滚动更新状态
# kubectl rollout status deploy/demoappv10 -n demoappdeployment "demoappv10" successfully rolled out查看ReplicaSet
# kubectl get rs -n demoappNAME DESIRED CURRENT READY AGE
demoappv10-78b6586d58 2 2 2 4m59sReplicaSet 输出中包含以下字段：
NAME 列出名字空间中 ReplicaSet 的名称；
DESIRED 显示应用的期望副本个数，即在创建 Deployment 时所定义的值。 此为期望状态；
CURRENT 显示当前运行状态中的副本个数；
READY 显示应用中有多少副本可以为用户提供服务；
AGE 显示应用已经运行的时间长度。注意 ReplicaSet 的名称格式始终为 [Deployment 名称]-[哈希]。 该名称将成为所创建的 Pod 的命名基础。 其中的哈希字符串与 ReplicaSet 上的 pod-template-hash 标签一致。查看pod 标签
# kubectl get pods -n demoapp --show-labelsNAME READY STATUS RESTARTS AGE LABELS
demoappv10-78b6586d58-64hq4 1/1 Running 0 6m48s app=demoapp,pod-template-hash=78b6586d58,version=v1.0
demoappv10-78b6586d58-f72jw 1/1 Running 0 6m48s app=demoapp,pod-template-hash=78b6586d58,version=v1.0查看Deployment 修订历史
# kubectl rollout history deployment/demoappv10 -n demoappdeployment.apps/demoappv10
REVISION CHANGE-CAUSE
1 <none>Deployment 添加注解
# kubectl annotate deployment/demoappv10 kubernetes.io/change-cause="kubectl apply -f depoly-demoapp-v10.yaml" -n demoappdeployment.apps/demoappv10 annotated确认Deployment 添加注解
# kubectl rollout history deployment/demoappv10 -n demoappdeployment.apps/demoappv10
REVISION CHANGE-CAUSE
1 kubectl apply -f depoly-demoapp-v10.yamlPod-template-hash 标签
Deployment 控制器将 pod-template-hash 标签添加到 Deployment 所创建或收留的每个 ReplicaSet 。
此标签可确保 Deployment 的子 ReplicaSets 不重叠。 标签是通过对 ReplicaSet 的 PodTemplate 进行哈希处理。 所生成的哈希值被添加到 ReplicaSet 选择算符、Pod 模板标签，并存在于在 ReplicaSet 可能拥有的任何现有 Pod 中。
不要更改此标签。Deployment 更新策略
Deployment控制器支持滚动更新（rolling updates）和重新创建（recreate）两种更新策略，默认使用滚动更新策略。重建式更新类同前文中ReplicaSet的第一种更新方式，即先删除现存的Pod对象，而后由控制器基于新模板重新创建出新版本资源对象。通常，只有当应用的新旧版本不兼容（例如依赖的后端数据库的格式不同且无法兼容）时才会使用recreate策略。但重建策略会导致应用在更新期间不可用，因而建议用户使用蓝绿部署的方式进行，除非系统资源不足以支撑蓝绿部署的实现。Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源，而是将它们分置于两个不同的控制器之下，当前ReplicaSet对象的Pod副本数量不断减少的同时，新ReplicaSet对象的Pod对象数量不断增加，直到现有ReplicaSet对象的Pod副本数为0，而新控制器的副本数量变得完全符合期望值，如图8-9所示。新旧版本之间区别彼此Pod对象的关键标签为pod-templatehash。多批次更新模式的默认间隔标准是前一批次的所有Pod对象均已就绪，方可启动后一批次的更新。而Deployment还提供了两个配置滚动更新批次的字段，以允许用户自定义更新过程的滚动速率，这两个字段分别用于定义滚动更新期间的Pod总数可向上或向下偏离期望值的幅度。
spec.strategy.rollingUpdate.maxSurge：指定升级期间存在的总Pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是相对于期望值的一个百分比；例如，如果期望值为10，maxSurge属性值为2，则表示Pod对象总数至多不能超过12个。
spec.strategy.rollingUpdate.maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望值的个数，其值可以是0或正整数，也可以是相对于期望值的一个百分比；默认值为1，这意味着如果期望值是10，则升级期间至少要有9个Pod对象处于正常提供服务的状态。
maxSurge和maxUnavailable属性的值不可同时为0，否则Pod对象的副本数量在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。Deployment还支持使用spec.minReadySeconds字段来控制滚动更新的速度，其默认值为0，表示新建的Pod对象一旦“就绪”将立即被视作可用，随后即可开始下一轮更新过程。而为该字段指定一个正整数值能够定义新建的Pod对象至少要成功运行多久才会被视作可用，即就绪之后还要等待minReadySeconds指定的时长才能开始下一批次的更新。在一个批次内新建的所有Pod就绪后但转为可用状态前，更新操作会被阻塞，并且任何一个Pod就绪探测失败，都会导致滚动更新被终止。因此，为minReadySeconds赋予一个合理的正整数值，不仅能够减缓滚动更新的速度，还能够让Deployment提前发现一部分程序Bug导致的升级故障。Deployment可保留一部分滚动更新历史（修订记录）中旧版本的ReplicaSet对象。Deployment资源可保存的历史版本数量由spec.revisionHistoryLimit属性进行定义。为了保存升级历史，需要在创建Deployment对象时为命令使用--record选项。 新版本已废弃。尽管滚动更新以节约系统资源著称，但它也存在着一些劣势。直接改动现有环境，会为系统引入不确定性风险，而且一旦在更新过程中遇到问题，回滚操作的过程会较为缓慢。有鉴于此，金丝雀部署可能是较为理想的实现方式。当然，如果不考虑系统资源的可用性，那么传统的蓝绿部署将是更好的选择。策略
先增新，后减旧：将maxSurge设定为小于等于期望值的正整数或相对于期望值的一个百分比，而maxUnavailable的值为0。
先减旧，后增新：将maxUnavailable设定为小于等于期望值的正整数或相对于期望值的一个百分比，而maxSurge的值为0。
同时增减（少减多增）：将maxSurge和maxUnavailabe字段的值同时设定为小于等于期望值的正整数或相对于期望值的一个百分比，二者可以使用不同值。Deployment默认为滚动更新设置了同时增减的策略，增减的幅度为期望值的25%，它通过两个批次的创建和3个批次的删除即能完成整个应用的更新，若Pod对象的整体副本数小于4的话，就只能按一次1个Pod对象的方式进行。扩缩容 Deployment
手动扩缩容
# kubectl scale deployment/demoappv10 --replicas=10 -n demoapp自动扩缩容
# kubectl autoscale deployment/demoappv10 --min=10 --max=15 --cpu-percent=80 -n demoapp可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的 Pod 个数下限和上限暂停Deployment 的上线过程
在你更新一个 Deployment 的时候，或者计划更新它的时候， 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 当你准备应用这些变更时，你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment 上线被暂停期间不会产生任何效果。暂停上线
# kubectl rollout pause deployment/demoappv10 -n demoapp更新 Deployment
# kubectl set resources deployment/demoappv10 -c=nginx --limits=cpu=200m,memory=512Mi -n demoapp恢复 Deployment 的上线过程
恢复 Deployment 上线并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新# kubectl rollout resume deployment/demoappv10 -n demoappDeployment 状态
Deployment 的生命周期中会有许多状态。上线新的 ReplicaSet 期间可能处于 Progressing（进行中），可能是 Complete（已完成），也可能是 Failed（失败）以至于无法继续进行。进行中的 Deployment
执行下面的任务期间，Kubernetes 标记 Deployment 为进行中（Progressing）_：
Deployment 创建新的 ReplicaSet
Deployment 正在为其最新的 ReplicaSet 扩容
Deployment 正在为其旧有的 ReplicaSet(s) 缩容
新的 Pod 已经就绪或者可用（就绪至少持续了 MinReadySeconds 秒）。当上线过程进入“Progressing”状态时，Deployment 控制器会向 Deployment 的 .status.conditions 中添加包含下面属性的状况条目：
type: Progressing
status: "True"
reason: NewReplicaSetCreated | reason: FoundNewReplicaSet | reason: ReplicaSetUpdated你可以使用 kubectl rollout status 监视 Deployment 的进度。完成的 Deployment
当 Deployment 具有以下特征时，Kubernetes 将其标记为完成（Complete）;
与 Deployment 关联的所有副本都已更新到指定的最新版本，这意味着之前请求的所有更新都已完成。
与 Deployment 关联的所有副本都可用。
未运行 Deployment 的旧副本。当上线过程进入“Complete”状态时，Deployment 控制器会向 Deployment 的 .status.conditions 中添加包含下面属性的状况条目：
type: Progressing
status: "True"
reason: NewReplicaSetAvailable这一 Progressing 状况的状态值会持续为 "True"，直至新的上线动作被触发。 即使副本的可用状态发生变化（进而影响 Available 状况），Progressing 状况的值也不会变化。
你可以使用 kubectl rollout status 检查 Deployment 是否已完成。 如果上线成功完成，kubectl rollout status 返回退出代码 0。失败的 Deployment
你的 Deployment 可能会在尝试部署其最新的 ReplicaSet 受挫，一直处于未完成状态。 造成此情况一些可能因素如下：
配额（Quota）不足
就绪探测（Readiness Probe）失败
镜像拉取错误
权限不足
限制范围（Limit Ranges）问题
应用程序运行时的配置错误检测此状况的一种方法是在 Deployment 规约中指定截止时间参数： （.spec.progressDeadlineSeconds）。 .spec.progressDeadlineSeconds 给出的是一个秒数值，Deployment 控制器在（通过 Deployment 状态） 标示 Deployment 进展停滞之前，需要等待所给的时长。以下 kubectl 命令设置规约中的 progressDeadlineSeconds，从而告知控制器 在 10 分钟后报告 Deployment 的上线没有进展：# kubectl patch deployment/demoappv10 -p '{"spec":{"progressDeadlineSeconds":600}}' -n demoapp超过截止时间后，Deployment 控制器将添加具有以下属性的 Deployment 状况到 Deployment 的 .status.conditions 中：
type: Progressing
status: "False"
reason: ProgressDeadlineExceeded
这一状况也可能会比较早地失败，因而其状态值被设置为 "False"， 其原因为 ReplicaSetCreateError。 一旦 Deployment 上线完成，就不再考虑其期限。除了报告 Reason=ProgressDeadlineExceeded 状态之外，Kubernetes 对已停止的 Deployment 不执行任何操作。更高级别的编排器可以利用这一设计并相应地采取行动。 例如，将 Deployment 回滚到其以前的版本。如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 上线的进展。 你可以在上线过程中间安全地暂停 Deployment 再恢复其执行，这样做不会导致超出最后时限的问题。对失败 Deployment 的操作
可应用于已完成的 Deployment 的所有操作也适用于失败的 Deployment。 你可以对其执行扩缩容、回滚到以前的修订版本等操作，或者在需要对 Deployment 的 Pod 模板应用多项调整时，将 Deployment 暂停。清理策略
你可以在 Deployment 中设置 .spec.revisionHistoryLimit 字段以指定保留此 Deployment 的多少个旧有 ReplicaSet。其余的 ReplicaSet 将在后台被垃圾回收。 默认情况下，此值为 10。显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空，因此 Deployment 将无法回滚。金丝雀发布
Deployment资源允许用户控制更新过程中的滚动节奏，例如“暂停”或“继续”更新操作，尤其是借助于前文讲到的maxSurge和maxUnavailable属性还能实现更为精巧的过程控制。例如，在第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅有一小部分新版本的应用存在，主体部分还是旧的版本。然后，通过应用层路由机制根据请求特征精心筛选出小部分用户的请求路由至新版本的Pod应用，并持续观察其是否能稳定地按期望方式运行。默认，Service只会随机或轮询地将用户请求分发给所有的Pod对象。确定没有问题后再继续进行完余下的所有Pod资源的滚动更新，否则便立即回滚至第一步更新操作。这便是所谓的金丝雀部署。为了尽可能降低对现有系统及其容量的影响，基于Deployment的金丝雀发布过程通常建议采用“先增后减且可用Pod对象总数不低于期望值”的方式进行。首次添加的Pod对象数量取决于其接入的第一批请求的规则及单个Pod的承载能力，视具体需求而定。Deployment资源规范
Deployment是标准的API资源类型，它以ReplicaSet资源为基础资源进行应用编排，并能够自动实现策略式滚动更新或单批次重建式更新，因而它的spec字段中嵌套使用的字段包含了ReplicaSet控制器支持的所有字段，而Deployment也正是利用这些信息完成其二级资源ReplicaSet对象的创建。另外，Deployment还支持几个专用于定义部署及相关策略的字段，具体使用说明如下。apiVersion: apps/v1 # API群组及版本
kind: Deployment # 资源类型特有标识
metadata:
name <string> # 资源名称，在作用域中要唯一
namespace <string> # 名称空间, Deployment隶属名称空间级别
labels <map[string]string> # 该资源对象的标签，键值型数据，常被用作标签选择器的挑选条件
annotations <map[string]string> # 非标识目的的元数据，键值格式，但不可作为标签选择器的挑选条件，其意义或解释方式一般由客户端自行定义。
spec:
minReadySeconds <integer> # Pod就绪后多少秒内任一容器无崩溃方可视为“就绪”
replicas <integer> # 期望的Pod副本数，默认为1
selector <object> # 标签选择器，必须匹配template字段中Pod模板的标签
matchExpressions <[]Object> # 基于表达式指定的标签选择器列表，每个选择器形如{key: KEY_NAME, operator: OPERATOR, value: [VALUE1,VALUE2,...]},选择器列表间为 逻辑与关系；使用In或NotIn操作符时，其value必须为非空的字符串列表，而使用Exists或DostNotExist时，其value必须为空。
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: Exists, values:}
matchLabels <map[string]string> # 定义匹配的标签，必须要设置，直接给定键值对指定标签选择器
app: nginx
template <object> # Pod模板对象
metadata <Object> # 定义模板元数据
labels <map[string]string> #定义模板label，Deployment.spec.template.metadata.labels
spec <Object> # 定义pod信息
volumes <[]Object> # 定义一个存储卷
name <string> # 存储卷名称标识，仅可使用DNS标签格式的字符，在当前Pod中必须唯一
containers <[]Object> -required- # 定义pod中容器列表，可以多个至少一个
name <string> -required- # 容器名称
image <string> # 镜像地址
command <[]string> # 容器启动执行的命令或脚本
args <[]string> # 参数传递，它们将覆盖镜像中默认定义的参数。
env <[]Object> # 配置环境变量
name <string> -required- # 变量名称。必须要用引号引起来
value <string> # 当前变量的值
valueFrom <Object> # 环境变量值的引用源，例如当前Pod资源的名称、名称空间、标签等，不能与非空值的value字段同时使用，即环境变量的值要么源于value字段，要么源于valueFrom字段，二者不可同时提供数据。
fieldRef <Object> # 当前Pod资源的指定字段，目前支持使用的字段包括metadata.name、metadata.namespace、metadata.labels、metadata.annotations、spec.nodeName、spec.serviceAccountName、status.hostIP和status.podIP等。
configMapKeyRef <Object> # ConfigMap对象中的特定Key。
secretKeyRef <Object> # Secret对象中的特定Key。
resourceFieldRef <Object> # 当前容器的特定系统资源的最小值（配额）或最大值（限额），目前支持的引用包括limits.cpu、limits.memory、limits.ephemeral-storage、requests.cpu、requests.memory和requests.ephemeral-storage。
envFrom <[]Object> # 直接将ConfigMap资源中的所有键值一次性地导入。
prefix <string> # 为引用的ConfigMap对象中的所有变量添加一个前缀名
configMapRef # 定义引用的ConfigMap对象
name <string> # ConfigMap对象的名称
optional <boolean> # 该ConfigMap对象是否为可选
secretRef <Object> # Secret对象中的特定Key。
name <string> # 引用的Secret对象名称
key <string> # 引用的Secret对象上的键，其值将传递给环境变量
optional <boolean> # 是否为可选引用
imagePullPolicy <string> # 拉取镜像策略有三种：Always(每次创建都会拉取镜像),IfNotPresent(优先使用本地镜像)，none(从不下载镜像)
ports <[]Object> # 定义容器端口列表
containerPort <integer> -required- # 定义一个端口
name <string> # 端口名称
protocol <string> # 端口协议 SCTP、TCP、UDP
resources <Object> # #对资源的请求设置和限制设置
limits <map[string]string> # 资源限制设置，上限
requests <map[string]string> # 资源请求的设置
livenessProbe <Object> # 存活探针
exec <Object> # 命令式探针
httpGet <Object> # http GET类型的探针
tcpSocket <Object> # tcp Socket类型的探针
initialDelaySeconds <integer> # 发起初次探测请求的延后时长
periodSeconds <integer> # 请求周期
timeoutSeconds <integer> # 超时时长
successThreshold <integer> # 成功阈值
failureThreshold <integer> # 失败阈值
volumeMounts <[]Object> #
volumeDevices <[]Object> #
workingDir <string> #
revisionHistoryLimit <integer> # 滚动更新历史记录数量，默认为10
strategy <Object> # 滚动更新策略
type <string> # 滚动更新类型，可用值有Recreate和Rollingupdate
rollingUpdate <Object> # 滚动更新参数，专用于RollingUpdate类型
maxSurge <string> # 更新期间可比期望的Pod数量多出的数量或比例，默认值为 25%。指定升级期间存在的总Pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是相对于期望值的一个百分比；例如，如果期望值为10，maxSurge属性值为2，则表示Pod对象总数至多不能超过12个。
maxUnavailable <string> # 更新期间可比期望的Pod数量缺少的数量或比例，默认值为 25%。升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望值的个数，其值可以是0或正整数，也可以是相对于期望值的一个百分比；默认值为1，这意味着如果期望值是10，则升级期间至少要有9个Pod对象处于正常提供服务的状态。
progressDeadlineSeconds <integer> # 滚动更新故障超时时长，默认为600秒
paused <boolean> # 是否暂停部署过程示例
kind: Deployment #类型，是deployment控制器，kubectl explain Deployment
apiVersion: apps/v1 #API版本，# kubectl explain Deployment.apiVersion
metadata: #pod的元数据信息，kubectl explain Deployment.metadata
labels: #自定义pod的标签，# kubectl explain Deployment.metadata.labels
app: wgs-nginx-deployment-label #标签名称为app值为wgs-nginx-deployment-label，后面会用到此标签
name: wgs-nginx-deployment #pod的名称
namespace: wgs #pod的namespace，默认是defaule
spec: #定义deployment中容器的详细信息，kubectl explain Deployment.spec
replicas: 1 #创建出的pod的副本数，即多少个pod，默认值为1
selector: #定义标签选择器
matchLabels: #定义匹配的标签，必须要设置
app: wgs-nginx-selector #匹配的目标标签，
template: #定义模板，必须定义，模板是起到描述要创建的pod的作用
metadata: #定义模板元数据
labels: #定义模板label，Deployment.spec.template.metadata.labels
app: wgs-nginx-selector #定义标签，等于Deployment.spec.selector.matchLabels
spec: #定义pod信息
containers: #定义pod中容器列表，可以多个至少一个，pod不能动态增减容器
- name: wgs-nginx-container #容器名称
image: nginx:1.16.1 #镜像地址
#command: ["/apps/tomcat/bin/run_tomcat.sh"] #容器启动执行的命令或脚本
#imagePullPolicy: IfNotPresent
imagePullPolicy: Always #拉取镜像策略有三种：Always(每次创建都会拉取镜像),IfNotPresent(优先使用本地镜像)，none(从不下载镜像)
ports: #定义容器端口列表
- containerPort: 80 #定义一个端口
protocol: TCP #端口协议
name: http #端口名称
- containerPort: 443 #定义一个端口
protocol: TCP #端口协议
name: https #端口名称
env: #配置环境变量
- name: "password" #变量名称。必须要用引号引起来
value: "123456" #当前变量的值
- name: "age" #另一个变量名称
value: "18" #另一个变量的值
resources: #对资源的请求设置和限制设置
limits: #资源限制设置，上限
cpu: 500m #cpu的限制，单位为core数，可以写0.5或者500m等CPU压缩值
memory: 512Mi #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: 200m #cpu请求数，容器启动的初始可用数量,可以写0.5或者500m等CPU压缩值
memory: 256Mi #内存请求大小，容器启动的初始可用数量，用于调度pod时候使用
nodeSelector:
group: web参考文档
https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
