不要管理 Deployment 所拥有的 ReplicaSet。 如果存在下面未覆盖的使用场景，请考虑在 Kubernetes 仓库中提出 Issue。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
.spec.selector.matchLabels 字段是 {key,value} 键值对映射。
在 matchLabels 映射中的每个 {key,value} 映射等效于 matchExpressions 中的一个元素，
即其 key 字段是 “key”，operator 为 “In”，values 数组仅包含 “value”。
在 matchLabels 和 matchExpressions 中给出的所有条件都必须满足才能匹配。
你必须在 Deployment 中指定适当的选择算符和 Pod 模板标签（在本例中为 app: nginx）。
标签或者选择算符不要与其他控制器（包括其他 Deployment 和 StatefulSet）重叠。 Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符， 它们可能会发生冲突执行难以预料的操作。
不要更改此标签。
仅当 Deployment Pod 模板（即 .spec.template）发生改变时，例如模板的标签或容器镜像被更新，
才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
Kubernetes 在计算 availableReplicas 数值时不考虑终止过程中的 Pod，
availableReplicas 的值一定介于 replicas - maxUnavailable 和 replicas + maxSurge 之间。
因此，你可能在上线期间看到 Pod 个数比预期的多，Deployment 所消耗的总的资源也大于
replicas + maxSurge 个 Pod 所用的资源，直到被终止的 Pod 所设置的
terminationGracePeriodSeconds 到期为止。
Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。
这意味着仅当 Deployment 的 Pod 模板（.spec.template）发生更改时，才会创建新修订版本
-- 例如，模板的标签或容器镜像发生变化。
其他更新，如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。
这是为了方便同时执行手动缩放或自动缩放。
换言之，当你回滚到较早的修订版本时，只有 Deployment 的 Pod 模板部分会被回滚。
Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。
这行为取决于所指定的 rollingUpdate 参数（具体为 maxUnavailable）。
默认情况下，Kubernetes 将此值设置为 25%。
在 Kubernetes 旧版本中，可以使用 kubectl 命令的 --record 标志自动填充 CHANGE-CAUSE 字段。
此标志已弃用，并将在未来的版本中移除。
你不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。
除了报告 Reason=ProgressDeadlineExceeded 状态之外，Kubernetes 对已停止的
Deployment 不执行任何操作。更高级别的编排器可以利用这一设计并相应地采取行动。
例如，将 Deployment 回滚到其以前的版本。
如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 上线的进展。 你可以在上线过程中间安全地暂停 Deployment 再恢复其执行，这样做不会导致超出最后时限的问题。
显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空，因此 Deployment 将无法回滚。
你不应直接创建与此选择算符匹配的 Pod，也不应通过创建另一个 Deployment 或者类似于 ReplicaSet 或 ReplicationController 这类控制器来创建标签与此选择算符匹配的 Pod。 如果这样做，第一个 Deployment 会认为它创建了这些 Pod。 Kubernetes 不会阻止你这么做。
这只会确保为了升级而创建新 Pod 之前其他 Pod 都已终止。如果你升级一个 Deployment， 所有旧版本的 Pod 都会立即被终止。控制器等待这些 Pod 被成功移除之后， 才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的， 后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。 如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用 StatefulSet。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
Kubernetes v1.35 [beta]（默认启用）