k8s的deployment是最常用的workload，也是基础设施扩缩容基础。deployment的作用：
- 发布应用
- 升级应用
- 回退应用
- 扩缩容
deployment的yaml
deployment.yaml
从上到下四个圈依次是:
- deployment元信息
- 选择器信息
- replicate信息
- pod模板信息
deployment的结构
deployment
deployment创建出replicate，然后由replicate负责pod的创建。
使用命令实验一下
kubectl apply -f deployment.yaml
kubectl get deployments
deploy,ent
kubectl get rs
rs
kubectl get pods
pods
从名字上可以很清楚的看到ref关系，rs的名字是deployment的名字+rs编号，pod的名字是rs的名字+pod的Hash。
pod升级
可以有两种方法，一种是将yaml中的容器版本修改一下，重新apply一次，另外一种显示的进行修改，这里我们看一看显示的进行修改
···
set image deployment nginx-deploy nginx-deployment=nginx:1.8
···
升级完成后kubectl get pods,
pods
可以看到ReplicaSet的编号和pods的编号都改变了，说明发生了一些事情
kubectl get rs
rs
可以看到rs，其中编号尾号77的rs是正在运行中的，那这个过程发生了什么呢？
升级
如图升级的过程，是创建出新的rs，旧的rs上的pod逐个删除掉，rscontroller在新的rs上创建出新的pod。
扩容
···
kubectl edit deployment nigix-deploy
···
修改replica为3，然后使用kubectl get pods查看
pods
可以看到原有的两个pod没有变化，并且在同样一个rs上新增了一个pod
scale
扩容的示意图如上
回滚
此时我们先查看一下历史
kubectl rollout history deployment nginx-deploy
history
一共有两次历史，一次是首次，第二次是升级，然后就是当前的扩容了。
kubectl rollout undo deployment nginx-deploy
可以看到会回退到老的rs上
为什么会这么工作
主要是k8s控制器的工作原理，控制器会执着的循环，直到当前状态达到期望状态，这里有两个控制器，一个deployment控制器，一个rs控制器
deployment controller
- 我们看到如果是扩缩容，就会创删rs
-
否则，仅仅更新rs
rs controller - 如果接到的是创删rs，则会调api进行创建删除pod
- 如果仅仅是对rs更新，则会调api对pod进行更新
小结
通过原理可以看到，rs是维系多版本的关键，而rs的数量是进行扩缩容的关键，这样一个设计是比较巧妙而且强大的。
