有很多人问我，平时是怎么看技术书的，我今天拿一个案例来讲一下，你会看到，我主要靠“猜”，自己想想解决方案，然后到书中去验证。干货内容较多，建议静心慢慢看。
1
我知道Docker是怎么回事，但是不太清楚Kubernetes究竟在干什么，它要解决什么问题?有哪些功能?在网上搜索了一些文章，可是都无法让我满意，因为他们都是非常宏观地讲一讲，然后马上就进入使用细节，让人还是云里雾里。
之前我就说过，想深入地了解一门技术，最好的办法就是看书，于是就去购书中心转了一圈，发现一本书籍《Kubernetes in Action》，翻了一会儿我就觉得这本书不错，就拿它来学习吧。
(这里插入一句，我的公众号文章只能讲述一个技术的本质问题，给大家一个大局观，具体的细节还得去读相关的书，有些人抱怨说通过我的文章学不会一个技术，那真是冤枉我了。)
2
这本书一开始就提到了微服务，这是个非常好的切入点，我脑海中立刻想到了微服务的特点，可以独立部署，轻松扩容。
那扩容的时候具体该怎么做呢?例如有个订单服务，我想把部署10份，难道我跑到服务器端，手工启动10个实例?
这肯定不符合自动化运维的方式，也许可以写个脚本，接受一个参数或者读取配置文件，把实例自动创建起来。
但是仔细一想，这样是不行的，因为现实中会有很多服务器，脚本怎么去管理呢?脚本怎么获取它们的IP以及它们的负载情况，然后把Docker实例分发创建到合适的服务器中呢?
于是第一个猜测来了：
最好是有个系统，它能管理所有的服务器，我只要告诉他，把订单服务的docker镜像部署10份，剩下的事情就不用我管了，都由这个系统来搞定。
这时候我隐隐约约地感觉到了Kubernetes的核心功能。
于是我跳过了微服务的介绍，Docker的介绍，这些都是老掉牙的东西了，迅速翻到了第16页：
这幅图画得相当棒，清楚地展示了K8s的核心功能，但是仔细看以后，就发现有两个微服务被放到了一起，作为一个整体来部署，这是我之前没有想到的!
部署的最小粒度并不是Docker镜像，而是另外一个东西!从系统设计的角度来看，必须得有个词来表达，这个东西是什么?
于是我又往后翻，哦，原来这个词叫做pod。
作者告诉我在第3章有详细介绍，我迫不及待地往后翻，试图满足好奇心：pod到底是什么东西。
原来这些pod就像局域网中的一个个独立的逻辑主机啊，每个Docker实例都是一个进程。
3
到目前为止，我就明白了k8s本质上是一层抽象，这一层抽象屏蔽了服务器的细节，程序员不需要知道程序运行在哪个服务器上，只需要告诉k8s自己的需求就好。
那用什么方式来告诉k8s呢?这很容易猜测到，可以:
1. 通过命令行参数传递给k8s, 但是参数太受限。
2. 用配置文件，在其中可以指明pod的名称，docker的镜像名称...... 可以用XML格式， JSON格式，YAML格式.....
当然，这些念头都是一闪而过，我翻开这本书的第3章，主要讲pod，果然是用YAML,JSON去创建pod, 由于已经预料到了，没什么新意，稍微看了看就跳过。
让我没有想到的是可以使用标签和命名空间对pod进行分组，但是讲解有点啰嗦，似乎也不是核心概念，稍微翻了一下就过去了。
稍等 !为什么不在创建pod的时候指定pod的数量啊?比如我想创建10个订单服务的docker实例，在哪里指定?仔细看看那些YAML文件，确实没有副本数量，这k8s搞什么鬼?这里没有指定，肯定在别的地方，那就是说：
除了pod之外，还有一个概念，用来指定pod和副本之间的关系，这个概念是什么?
4
快速翻到第4章，哈哈，原来这个概念叫做ReplicationController(简称RC)，由它来保证pod的数目符合要求，多了就删除，少了就添加。
从设计角度来看，再次体现了关注点分离，pod负责“静态描述”，像一个模板，就像class， RC负责运行时管理，来产生pod的object。
创建RC也是使用YAML，比较让我意外的是，在指定pod时，用了前面所讲的标签，看来标签是组织pod的重要方法，有时间回去看看细节。
需要注意的是，在管理pod数目的时候，用的是声明式：“我想要运行10个订单实例”， 而不是“我想增加3个订单实例”或“我想删除3个订单实例”。 你不用告诉k8s做什么、如何做，只是指定期望的状态就好。
5
如果你也善于思考的话，这时候就会冒出了一个新问题：
这些pod 不断地被删除，被增加，不断地变化，那外界怎么去访问他们呢?
比如客户端正在访问pod1,然后pod1所在的机器挂掉，ReplicationController在另外一台机器上创建了pod2，IP都变了，那客户端下一次去访问pod2呢?
如果让我设计，我肯定得提供另外一个抽象层，让这个抽象层来屏蔽后端的变化，让客户端连接到这个抽象层上。
k8s 会怎么做呢?第4章给出了答案：服务。 我个人觉得这个词起得不好，太抽象，太广泛。
可以看出，k8s和其他系统一样，也是不断地通过分离关注点，不断地抽象来解决一个个问题的。
到目前为止，我脑海中想的都是那些“无状态”的pod，可以随意增加和删除， 但肯定存在“有状态”的pod，有持久化的需求，可以把数据存储到硬盘上，这该怎么办?
带着这个问题，继续上路吧!
6
好了，啰嗦了这么多，稍微总结一下：我希望给大家分享的就是，看书的时候要主动思考，不要被动接受。
带着问题去看，自己先想想解决方案，然后到书中去验证，效率会非常高，读起来会非常快。
如果自己的问题在书中很快就得到回答，那读起来就会酣畅淋漓;如果迟迟得不到回答，或者书中一直不厌其烦地描述细枝末节，那我很快就丧失兴趣，把书扔掉。
当然，由于每个人的基础不同，可能刚开始读书的时候提不出问题，或者提不出有价值的问题，这时候可以去直接看具体内容，但是不能放弃思考：这个技术点是要解决什么问题的?是怎么解决的?
希望每个人都建立一套自己的知识体系，从这个知识体系中能伸出很多的触角，能像海绵一样吸收外界的知识，不断地为自己的知识体系添砖加瓦。
