你好，我是程远。

今天是我们专栏必学内容的最后一讲。当你读到这一讲内容的时候，刚好是元旦。首先我要祝你元旦快乐，2021 年一切顺利！

在过去的二十多讲内容里，我们从基础开始，一起学习了容器进程、内存、存储、网络以及安全这几部分的内容。在每一讲里，我们都会从一个实际问题或者现象出发，然后一步步去分析和解决问题。一路走来，真是百感交集，我有好多心里话，但又不知该从何说起。

所以最后一讲，我想和你聊聊我个人的一些成长感悟，在辞旧迎新的元旦，正适合回顾过去和展望未来。所以这既是专栏的一次总结交流，也是我们开启新征程的“号角”。

在多年以前，我在书里读到一句话，说的是“每个人都有潜在的能量，只是很容易被习惯所掩盖，被时间所迷离，被惰性所消磨。”

今天再次回看这段话，还真是一语中的，感触良多，回想起专栏写作的整个过程，这件事带给我的最大感悟就是：跳出自己的舒适区，才能有所突破。

突破舒适区是很难的事儿

我们都知道，突破舒适区是一件很难的事儿。这里我给你分享一个我自己的故事，也许你也会从这个故事里找到自己的影子。

记得在 2 年前，我参加过 eBay 的一个内部培训，培训的目标就是要让自己有所“突破”。我必须承认，这个培训是我经历过的所有培训中最接地气的一个培训，在培训过程里我也是情绪激昂的，准备带着学到的东西回到工作里去大展身手，好好突破一番的。

不过等培训结束，再回到日常工作的时候，之前的雄心壮志、激情澎湃又被日常的琐事所淹没，积蓄的那股劲儿又慢慢被消磨了。周围的同事会开玩笑地对我说：“程远啊，我觉得你没有突破啊。”

其实，我心里也知道，所谓的“突破”就要跳出自己的舒适区。不过我始终不知道怎么跳出来，哪怕自己手上的工作再多，工作到再晚，但这仍然是处于自己舒适区。这是因为这一切的工作节奏还有思考的问题，都是我自己熟悉的。

这种熟悉很可能让我们沉湎其中，裹足不前。那问题来了，意识到自己处于舒适区，产生想要“跳出去”的念头的确是良好开局，难的是怎么有效突破。这就要聊到突破方法路径的问题了，我想结合自己的感悟给你说一说。

主动迎接挑战，在实战中进步

不知道你有没有听过热力学里熵增的定律，大概说的是：封闭系统的熵（能量）会不可逆地增加，最终导致整个系统崩溃。那怎么才能保持这个系统的活力呢？就是能量交换，不断去引入外部的能量，也就是负熵。

我们可以引申一下，自然会想到走出舒适区这件事，也是同样的道理。我们要有一种冒险家的勇气，主动去迎接挑战，在实战里迫使自己不断进步。

其实选择做这样一个专栏，对我来说就是走出舒适区的一项“挑战”。在今年 7 月份，那还是我们这个专栏筹备的前期，我当时就一个想法，就是把我这些年来在容器方面的积累给记录下来。

从 7 月份决定写容器这个专栏开始，到现在差不多也有半年的时间了，我真的觉得，在工作的同时把写专栏的这件事给坚持下来，真的是一件不容易的事情。这里不仅仅是一个简单的时间投入问题，更多的是迫使自己再去思考的问题。

估计你也发现了，我每一讲都涉及不少知识点。我在专栏写作的过程中，花时间最多的就是怎么把问题说清楚，这里要解释哪些关键知识点，适合用什么样的例子做解释，每个知识点要讲到什么程度，需要查阅哪些代码和资料来保证自己所讲内容的正确性。

这样的思考模式和我日常思考工作问题的模式是完全不同的。但也正是借着这样的机会，我才从自己原先的舒适区里跳了出来，工作之余同时也在思考写专栏的问题，每天都有大量的 context switch，也就是上下文切换。

我很高兴自己可以坚持下来，完成了专栏的主体部分。可以说，这门课既是容器的实战课，也是我自己走出舒适区的实战训练。

突破舒适区，本质是突破思考的惰性

这次的专栏写作，还让我意识到，突破舒适区的本质就是突破思考的惰性。只有不断思考，才能推着自己不断往前走，才能让我们更从容地解决工作上的问题。

在 2020 年的 12 月初，Kubernetes 宣布不再支持 dockershim，也就是说 Kubernetes 节点上不能再直接用 Docker 来启动容器了。当时我看到这条新闻，觉得这是理所当然的，因为我们的容器云平台上在 2019 年初就从 Docker 迁移到了 Containerd。

不过，后来我在专栏留言回复的过程中，连续有三位同学留言，问我怎么看 Kubernetes 的这个决定，这让我又回忆起了当初我们团队是怎么做的迁移决定。

这件事还要追溯到 2018 年的时候，我们发现 kubelet 通过 CRI 接口就可以集成 Containerd 了，于是我们就开始思考，是不是应该用 Containerd 来替换 Docker 呢？

当时我们看到的好处有两点。第一点是这样替换之后架构上的优势，CRI 可以说是 kubelet 连接 Runtime 的标准了，而用 Dockershim 接 Docker 再转 Containerd，这样很累赘。第二点好处就是降低了维护成本。Containerd 只是 Docker 中的一部分，维护 Containerd 明显要比维护庞大的 Docker 容易。

当然，这么做的挑战也是很大的。当时，我们在生产环境中已经有 2 万台物理机节点以及几十万个容器，而且那时候业界还几乎没有人在生产环境中用 kubelet 直接调用 Containerd。没有前人的尝试可以借鉴，只能咬牙打一场硬仗。

后来我们通过一个多月的测试，发现直接使用 Containerd，无论是稳定性还是性能都没有问题。有了实际测试做保障，我们在 2019 年初又花了 3 个月时间，才把生产环境上的 Docker 全部替换成 Containerd。

这样的结果看似轻描淡写，一两句话就带过了。但实际过程里，已经不是过五关斩六将了，而是一直在发现问题、解决问题，大大小小的战役才汇聚成了最后的战果。其实，我在这个专栏里和你分享的一些容器问题，也来源于我们当时的迁移实践。

现在回想起来，当初的这个决定无疑是非常正确的了。不过再想想，如果当时看到 Kubernetes 的变化，我们没有主动思考，等到现在 Kubernetes 宣布不再支持 Dockershim 才去做应对，结果又会怎样呢？

这个问题，我觉得用数字来说话更直观。刚才提到当时迁移的时候，有 2 万台物理机节点以及几十万个容器。但如果等到现在才迁移，我们需要面对的就是 6 万台物理机和上百万的容器了。

你看，无论是写专栏也好，还是我们实际工作也好，呆在舒适区里，短期成本看着挺小，不需要你大动干戈，消耗脑细胞和精力。但是，当你习惯了这种思考的惰性，就会变成温水煮青蛙而不自知，等到外部条件发生变化时会很被动。

最后的彩蛋

前面我们聊了很多突破舒适区的事儿，不知道你有没有被触动呢？

其实学习也好，工作也罢，就是要有一种突破意识，走出舒适区，才能“开疆拓土”。那为了让你我都知行合一，我还要给你聊聊后面的专题加餐安排。

在开篇词我也提到了这个安排。虽然这一讲是我们课程的结束语，但我们课程的内容并没有结束。在这个专题里，我选择了一个真实案例。那这个案例我是怎么选的呢？

其实这是 2020 年初，我们在生产环境里遇到的一个真实的容器网络问题。我觉得这是一个很好的调试案例，它的好就在于可以用到 Linux 内核的最主要的几个调试工具，包括 perf，ftrace 和 ebpf。我们逐个使用这些工具，就可以层层递进地揭开问题的本质。

通过这个案例的学习，我会带你掌握每种工具的特性。这样你在理解了容器基本原理的基础上，就能利用这些好的工具系统化地分析生产环境中碰到的容器问题了，就像我们开篇中说的那样——变黑盒为白盒。

写完结束语之后，我会认真为你准备这个专题加餐。而这一个月的时间，你还可以继续消化理解课程主体部分的内容，打牢基础，这样对你学习后面的专题加餐也有很大帮助。

最后的最后，我想和你说的是，希望你我都能主动思考，不断突破自己，走出舒适区，一起共勉吧！

这里我为你准备了一份毕业问卷，题目不多，希望你可以花两分钟填一下。也十分期待能听到你的声音，说说你对这门课程的想法和建议。