Deployment 样板文件：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: ngx-dep
name: ngx-dep
spec:
replicas: 2
selector:
matchLabels:
app: ngx-dep
template:
metadata:
labels:
app: ngx-dep
spec:
containers:
- image: nginx:alpine
name: nginx
Kubernetes 会持续地监控 Pod 的运行状态，万一有 Pod 发生意外消失了，数量不满足“期望状态”，它就会通过 apiserver、scheduler 等核心组件去选择新的节点，创建出新的 Pod，直至数量与“期望状态”一致。
这里面的工作流程很复杂，但对于我们这些外部用户来说，设置起来却是非常简单，只需要一个 replicas 字段就搞定了，不需要再用人工监控管理，整个过程完全自动化。
我们看另一个关键字段 selector，它的作用是“筛选”出要被 Deployment 管理的 Pod 对象，下属字段“matchLabels”定义了 Pod 对象应该携带的 label，它必须和“template”里 Pod 定义的“labels”完全相同，否则 Deployment 就会找不到要控制的 Pod 对象，apiserver 也会告诉你 YAML 格式校验错误无法创建。
为什么要这么麻烦？
为什么不能像 Job 对象一样，直接用“template”里定义好的 Pod 就行了呢？
这是因为在线业务和离线业务的应用场景差异很大。
离线业务中的 Pod 基本上是一次性的，只与这个业务有关，紧紧地绑定在 Job 对象里，一般不会被其他对象所使用。
而在线业务就要复杂得多了，因为 Pod 永远在线，除了要在 Deployment 里部署运行，还可能会被其他的 API 对象引用来管理，比如负责负载均衡的 Service 对象。
Deployment 和 Pod 实际上是一种松散的组合关系，Deployment 实际上并不“持有”Pod 对象，它只是帮助 Pod 对象能够有足够的副本数量运行，仅此而已。
如果像 Job 那样，把 Pod 在模板里“写死”，那么其他的对象再想要去管理这些 Pod 就无能为力了。
好明白了这一点，那我们该用什么方式来描述 Deployment 和 Pod 的组合关系呢？
Kubernetes 采用的是这种“贴标签”的方式，通过在 API 对象的“metadata”元信息里加各种标签（labels），我们就可以使用类似关系数据库里查询语句的方式，筛选出具有特定标识的那些对象。通过标签这种设计，Kubernetes 就解除了 Deployment 和模板里 Pod 的强绑定，把组合关系变成了“弱引用”。
画了一张图，用不同的颜色来区分 Deployment YAML 里的字段，并且用虚线特别标记了 matchLabels 和 labels 之间的联系，希望能够帮助你理解 Deployment 与被它管理的 Pod 的组合关系。
image.png
$ kubectl get deployment -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system coredns 2/2 2 2 283d
kube-system heapster 1/1 1 1 283d
kube-system metrics-server 1/1 1 1 283d
kubernetes-dashboard dashboard-metrics-scraper 1/1 1 1 283d
kubernetes-dashboard kubernetes-dashboard 1/1 1 1 283d
monitoring generic-exporter 1/1 1 1 114d
monitoring grafana 1/1 1 1 114d
monitoring kube-state-metrics 1/1 1 1 114d
monitoring prometheus-adapter 1/1 1 1 114d
monitoring prometheus-operator 1/1 1 1 114d
test test01 2/2 2 2 283d
test test02 2/2 2 2 283d
$ kubectl get pod --show-labels -A
$ kubectl get pod --show-labels -n test
kubectl scale --replicas=4 deploy test01 -n test
kubectl scale --replicas=4 deploy test02 -n test
注意： kubectl scale 是命令式操作，扩容和缩容只是临时的措施，如果应用需要长时间保持一个确定的 Pod 数量，最好还是编辑 Deployment 的 YAML 文件，改动“replicas”，再以声明式的 kubectl apply 修改对象的状态。
我们通过 labels 为对象“贴”了各种“标签”，在使用 kubectl get 命令的时候，加上参数 -l，使用 ==、!=、in、notin 的表达式，就能够很容易地用“标签”筛选、过滤出所要查找的对象（有点类似社交媒体的 #tag 功能），效果和 Deployment 里的 selector 字段是一样的。
看两个例子，第一条命令找出“app”标签是 nginx 的所有 Pod，第二条命令找出“app”标签是 ngx、nginx、ngx-dep 的所有 Pod：
kubectl get pod -l app=nginx
kubectl get pod -l 'app in (ngx, nginx, ngx-dep)'
image.png
简单小结一下今天的内容：
- Pod 只能管理容器，不能管理自身，所以就出现了 Deployment，由它来管理 Pod。
- Deployment 里有三个关键字段，其中的 template 和 Job 一样，定义了要运行的 Pod 模板。
- replicas 字段定义了 Pod 的“期望数量”，Kubernetes 会自动维护 Pod 数量到正常水平。
- selector 字段定义了基于 labels 筛选 Pod 的规则，它必须与 template 里 Pod 的 labels 一致。
- 创建 Deployment 使用命令 kubectl apply，应用的扩容、缩容使用命令 kubectl scale。
学了 Deployment 这个 API 对象，我们今后就不应该再使用“裸 Pod”了。
即使我们只运行一个 Pod，也要以 Deployment 的方式来创建它，虽然它的 replicas 字段值是 1，但 Deployment 会保证应用永远在线。
两个思考题：
- 如果把 Deployment 里的 replicas 字段设置成 0 会有什么效果？有什么意义呢？
- 你觉得 Deployment 能够应用在哪些场景里？有没有什么缺点或者不足呢？
将replicas设置为0，对应应用的pod数量为0，应用停止服务。这样的方式保存了deployment，如果需要启动应用，将replicas设置为需要的数量即可。
deploy是只能用在应用是无状态的场景下，对于有状态的应用它就无能为力了，需要使用其他的API。
Pod YAML 只能创建一个对象，而Deployment里的pod定义是一个“模板”，可以创建出任意多个对象。而且Kubernetes就是规定要这么使用Deployment。
image.png
网友评论