很多人问我平时是怎么看技术书的。今天我就用一个案例来说明。你会看到我主要靠“猜”，自己想办法，然后在书上验证。.干货很多，建议慢慢看。1我知道Docker是怎么回事，但是我不知道Kubernetes到底是干什么的，它解决什么问题？它有什么功能？在网上搜索了一些文章，没有一个让我满意的，因为都是非常宏观的讲完一讲，然后马上进入使用的细节，让人还是一头雾水。之前说过要深入了解一门技术最好的方法就是看书，于是就去书城淘了一本书《Kubernetes in Action》。看了一会儿，觉得是本好书。只是用它来学习。（在这里插一句，我的公众号文章只能说一门技术的精髓，给大家一个大概的了解，具体细节还得看相关书籍，有人抱怨学不了一门技术我的文章，真是冤枉我了。）2这本书一开始就提到了微服务，这是一个很好的切入点。脑海里立刻想到了微服务的特点，可以独立部署，方便扩展。扩容时应该怎么做？比如有一个订单服务，我想部署10个副本。我应该运行到服务器并手动启动10个实例吗？这肯定不符合自动化运维的方式。也许你可以写一个脚本接受一个参数或者读取一个配置文件来自动创建一个实例。但是仔细想想，这是不可能的，因为现实中会有很多服务器，脚本怎么管理呢？脚本如何获取他们的IP和他们的负载，然后分发创建Docker实例到合适的服务器上呢？所以第一个猜测来了：最好有一个可以管理所有服务器的系统。我只需要告诉他部署10份订单服务的docker镜像，其他的不用我管，全部靠这个系统搞定。这时候隐约感受到了Kubernetes的核心功能。于是略过微服务和Docker的介绍，这些都是老生常谈了，赶紧翻到第16页：这张图挺好的，清晰的展示了K8s的核心功能，但仔细一看，发现是两个微服务放在一起，整体部署，这是我以前没有想到的！部署的最小粒度不是Docker镜像，而是另外一回事！从系统设计的角度来说，一定要有一个词来表达，这是什么东西？于是我又回过头来，哦，原来这个词叫豆荚。作者告诉我在第三章有详细的介绍，我迫不及待地回过头来，试图满足我的好奇心：pod到底是什么。原来这些pod就像局域网中独立的逻辑主机，每个Docker实例就是一个进程。3至此，我理解k8s本质上是一层抽象。这一抽象层屏蔽了服务器的细节。程序员不需要知道程序运行在哪个服务器上，只需要告诉k8s自己的需求即可。那怎么告诉k8s呢？很容易猜到，可以：1.通过命令行参数传递给k8s，但是参数太有限了。2.使用一个配置文件，里面可以指定pod的名称，docker的镜像名称……可以是XML格式，JSON格式，YAML格式……当然，这些想法转瞬即逝，我翻开了这本书的第3章，主要讲的是pod。果然，YAML和JSON用于创建Pod。因为已经预料到了，没什么新意，所以略读略过。没想到的是pod可以使用tags和namespaces进行分组，但是解释的有点啰嗦，似乎也不是核心概念，所以稍微翻了翻就完了。等一下！为什么在创建Pod时不指定Pod的数量？比如我要为订单服务创建10个docker实例，应该在哪里指定呢？仔细查看那些YAML文件。确实没有份数。这个k8s到底在干什么？这里没有指定，一定是在别处，也就是说：除了pod之外，还有一个概念来指定pod和replica的关系。这是什么概念？4赶紧翻到第4章，哈哈，原来这个概念叫ReplicationController（简称RC）。它确保Pod的数量满足要求。从设计的角度来看，它再次体现了关注点分离。Pod负责“静态描述”，像模板，像类，RC负责运行时管理生成pod对象。YAML也用于创建RC。令我惊讶的是，在指定pod时，使用了上面提到的标签。标签似乎是组织pod的重要方式。我有时间回去看看细节。需要注意的是，在管理pod数量时，使用的语句是：“我要运行10个订单实例”，而不是“我要添加3个订单实例”或“我要删除3个订单实例”。您不需要告诉k8s做什么或如何做，只需指定所需的状态即可。5如果你也善于思考，这时候就会出现一个新的问题：这些pod在不断的被删除，不断的添加，不断的变化，那么外界怎么访问它们呢？比如客户端正在访问pod1，然后pod1所在的机器挂了，ReplicationController在另一台机器上创建了pod2，IP就变了。那么客户端下次访问pod2呢？如果我设计的话，我必须再提供一个抽象层，让这个抽象层来屏蔽后端的变化，让客户端去连接这个抽象层。k8s会做什么？第4章给出了答案：服务。我个人认为这个词定义不好，太抽象太宽泛。可以看出，k8s和其他系统一样，也在不断地通过关注点分离和抽象来解决问题。到目前为止，我脑子里想的都是那些“无状态”的pod，可以随意增删，但是一定要有“有状态”的pod，有持久化的需求，可以把数据存到硬盘上。我应该怎么办？带着这个疑问，让我们继续上路吧！6好了，说了这么多，我总结一下：我想跟大家分享的是，看书要主动思考，不要被动接受。看问题，先想办法，再去书上验证。效率会很高，读取也会很快。如果我的问题在书中得到了快速解答，我会认真阅读；如果我很长时间没有得到答案，或者这本书一直在不厌其烦地描述细节，那么我很快就会失去兴趣，把书扔掉。当然，由于每个人的基础不同，刚开始看书的时候不一定能提出问题，也不一定能提出有价值的问题。这时候可以直接看具体内容，但千万不能放弃思考：这个技术点要解决什么？问题是什么？如何解决？希望每个人都能建立自己的知识体系，从中伸出许多触角，像海绵一样吸取外界的知识，不断补充自己的知识体系。
