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的数量是进行扩缩容的关键，这样一个设计是比较巧妙而且强大的。