Day15-Kubernetes 那些事 - Deployment 与 ReplicaSet（三）

前言

终於进入 Deployment 系列文的最後一篇也是非常重要的一篇了，在 K8s 系列文中的第一篇文章提到 Deployment 是可以进行 Pod 内容更新，接下来就要好好谈谈 Deployment 是如何更新 Pod 的内容。

要如何更新 Deployment 内部的 Pod

大家都知道 Pod 为 K8s 最小的运行单位，所以更新 Pod 意思就是把内部运行的 container 进行更新，也就是说我们只要更新 Pod 的 image 就可以顺利的让 Pod 运行最新的内容， Deployment 就是运用这个原理才进行 Pod 的内容更新，方法也很简单只要利用 set 这个参数就好，下 kubectl set -h 可以看到 set 这个参数真正的用法。

可以看到 set 後面还要再接 SUBCOMMAND 而这个 SUBCOMMAND 就是 Available Commands 的内容，由於我们要更新的是 image 所以这边的 SUBCOMMAND 会是 image，这时候就可以很开心的下 kubectl set image deployment/deploymentName imageResource 结果却发生错误了。

原因在於 image 不能单纯给来源而已，必须要把这个 image 定义一个名字这样才能套用到 Deployment 内，所以这边稍微改写一下整个指令变成 kubectl set image deployment/deploymentName imageName=imageResource，这里笔者建议多加一个 --record 的参数，这样就会记录每次更新的时候到底是更新什麽内容进去，这样日後要进行 rollback 的时候也比较容易知道要 rollback 回哪个 revision。

接下来可以查看 ReplicaSet 以及 Pod 在更新过程中的变化。

可以发现 strategy 为 RollingUpdate 的时候并不会把旧有的 Pod 移除反而会让新旧 Pod 同时上线，以达到无停机服务的作用，但这样在网页中就有可能会同时出现新旧内容。

如果今天 strategy 设定为 Recreate 就会在更新的过程中出现 503 的错误。

Deployment 回朔版本

讲完了更新之後接下来讲讲如何 rollback 回之前的版本，首先我们必须要用到 rollout 这个参数，下 kubectl rollout -h 之後可以看到 rollout 真正的用法，是不是觉得跟 set 用法很像呢XD

由於这边我们要 rollback ，所以这边的 SUBCOMMAND 会使用 undo，还记得笔者上面提到的 revision 吗？其实笔者还是建议用 revision 的方式来决定要 rollback 到哪个版本去，所以整体写法就会像这样： kubectl rollout undo deployment/deploymentName --to-revision=revisionNumber

这边如果想知道这个 Deployment 有哪些历史的话也可以利用 history 这个 SUBCOMMAND 来查看，这样就可以知道要用哪个 revision 了。

为何要舍弃 Replication Controller

由於现在练习的东西都比较简单，所以用 Replication Controller 就可以达到控制 Pod 了，但其实真正实务上在使用 K8s 时用的架构可是会比练习的复杂很多，所以用 ReplicaSet 让 selector 用更弹性的方式来选取 Pod 会是比较好的做法。

其实官网在 Replication Controller 後面有加这段文字：

NOTE: A Deployment that configures a ReplicaSet is now the recommended way to set up replication.

连官网自己都说用 ReplicaSet 来产生 Pod 的 replication 是比较推荐的做法了，所以读者如果要玩 Pod 的 replication 还是建议用 Deployment 搭配 ReplicaSet 比较好。

小结

终於把整个 Deployment 介绍完了，相信内容真的很多很难消化，但 Deployment 是个非常重要的观念。

接下来要讲的东西都会基於 Deployment 的设定来做更深入的改写，如果对於文章有任何问题都欢迎留言给我，那我们就下篇文章见喽～