该去写什么样的内容？

最开始学习的时候我并没有十分明确需要到达的目的地，学的过程中知识树是一点一点生长起来的，我作为一个后端开发，更多的是带着想把 Go 写好的心态，去学习优秀作者的代码和想了解云原生相关内容。

所以我想写读源码的时候想写大而全的内容，但是后来发现相应的课程其实很多，然后在看的过程中会发现一个很严重的问题：没有重点。

如果每个模块我都花同样的精力去写，不仅产出的内容质量得不到保障，深度不够，读者学后也很难有用的上的内容，而且对我自己的精力也是一个巨大的挑战，可能还没开始写我就会劝退了，所以果断放弃了这个思路。

学习的过程中积累了一些自己的读代码包含实操的方法论，所以也写了一篇《开发同学应该如何学习 Kubernetes》，也算是对自己的学习阶段的总结和实用的方法论，可以立即去尝试做起来的指引。

然后我通过自己感兴趣的网络知识点去深入打磨了 《一文了解 kubernetes 网络》和《一文了解kubernetes 负载均衡》，这里面是我倾注了比较多的心血，通过数据也发现是收藏较多，内容相对较多，读起来会有阻力，所以收藏下来无可厚非，但给我的感觉总是那种会在收藏夹中吃灰，而不会产生实际作用的感觉。

不想做曲高和寡的内容，只有足够多的人愿意看和提意见，才能真正打磨出大家乐意接受的，也可以让读者们有一个养成系的过程，最开始有些地方读不懂，随着逐渐的深入，慢慢领会到其中的精妙，甚至能够碰撞出一些想法，这个才是我想要的。

如果是曲高和寡的内容无非是自娱自乐，没有实际应用场景，不能解决实际问题的知识不会产生价值。

在这个过程中读了《技术的本质》，回过来看Kubernetes 写作主题的时候，我觉得可以从技术的演进来看K8s，本身是依赖操作系统的功能来实现，更多的是对node节点资源的管理和pod 资源的调度分配。

同一个信息，拥有越多的视角，则能获得的信息越多。同样是K8s，作为运维开发能看到的是应用部署操作的简易程度。作为后端研发则是看到它在并发编程的优雅处理，作为产品经理能看到的是云原生带来的持续高可用。因此我写了一篇从《多个角度去看k8s》。

在过程中从理论知识的串联，到源代码的剖析，记录起来后逐渐对 Kubernetes 有一个整体的认知。这个时候我的目标变成了如何通过学习来反哺自己的业务设计，从 Kubernetes 整体设计来提升自己设计组件的复用性、扩展性及性能等。

我转而尝试了一些实用性非常强的内容，如《看了Kubernetes 源码后，我的Go水平突飞猛进》和《看了Kuberentes源码后，得到的 Golang 工程化实践》，也是对我平时遇到的问题实在读过 Kubernetes 后的一些实践经验总结，发现文章的数据目前来说是最好的。

最终这个问题我还是暂时得到了答案，**首先得先让人愿意看、能看懂并且能够立马用到自己的实际工作中，然后才是垂直加入深度。**所以我目前的方向还是选择了实用性强的内容去展开。

打开技术黑盒

Kubernetes的诞生本身也是为了解决运维环境的困难，我在一个工具百花齐放的时代做程序员是一件乐事，但是也会带来苦恼，有些想做的小工具大部分已经成熟，但是这样也证明了自己遇到的问题是大部分人都会需要去解决的。

因为长期处于应用层没办法完全领略到计算机可选从最底层开始创造的快乐，很多东西因为分层让我看到的大部分处于黑盒的状态。

好在大学的课程中为我计算机基础的知识打下基石，包括网络七层协议、操作系统、算法、编译原理及汇编等，都让我对计算机这门学科有了比较基础的认知和了解，也因此在 Kubernetes 整个的深入学习中，不断的让我将应用层的知识和大学学到的理论知识不断连接，打开分层技术也让我不停获得快乐，我也想把这一份打开黑盒的快乐分享给大家，让我们对整体的技术更有掌控感和可解释性，毕竟计算机是一门人造的科学，如果我们自己人创造的科学我们都讲不清楚未免不太合理。

技术产品思维

领固定工资的程序员很难去感受到自己创造的价值，大部分时候离产品端很远，我们不能理解为什么只要花两周做一个很小的MVP 而不是几个月把产品打磨好，我们要尝试以产品的角度去思考，比如K8s在演进的时候，如果不把网络开放给第三方插件来做然后专心去研发容器调度的内容的话，等到docker一统天下，那个时候再推出自己的产品替换的成本就太大了。

每次在看源码的时候都能让我接触到底层实现和理论结合验证带来的快乐，把黑盒变的不黑就是我得到的乐趣。思考求证带来的快乐就已经是价值了。

技术的原理不是无中生有的，而是从之前的回顾中、组合中发现来的，所以想要创造就要先熟悉相关已有的技术。

• kubelet 的资源利用状态的维护，最开始则是使用 cadvisor 来进行实现，然后后面因为不同容器运行时的不同，一些场景下 cadvisor 已经无法满足需求，则逐渐交由 CriStatsProvider 来实现。
• 有了操作系统隔离技术cgroup的支持，才有容器化部署的基础。
• 有了操作系统提供的 netlink和netfilter功能， 才有了网络功能的基础。

Kubernetes 将这些模块功能进行重新组合，用来解决部署运维时需要手工创建虚拟环境和网络设置等的问题。

从0到1做一款产品也并非所有内容都是去创造，更多时候是通过搭积木的方式，去实现我们的想法，然后再去攻克业务上关键的难点。

生长的专栏

这个 Kubernetes 的专栏可能不会像其他的专栏那样围绕一个很清晰的脉络，而是在我不断工作、实际解决问题和学习的过程中，找到问题、解决问题、沉淀出经验后，对内容进行产出，争取把整个过程讲明白、说透彻。

也许会有几篇文章有机会能汇总成一个大的专题，我会将它组织到一起，但是整个专栏可能会一直处于比较零散的状态，毕竟我现在的方向也是处于比较零散的状态，但是我会让它持续去生长，或许生长到最后它可能更大，会变成云原生技术栈的一个持续更新的内容，但是我并没有打算让这个停下来，我觉得从 Kubernetes 发散出去后还会有很多值得聊的地方。

比如我之前写的一篇 《Kubernetes 为什么选择ETCD做存储？》，也是延伸到了技术选型和存储的方向，我本身对存储也是相对感兴趣并且一直在学习的过程中。

如果大家有好的方向和实际想要搞清楚的问题，如果跟我的方向有重合，我会让它往这个方向去生长。