观看视频：藏经阁电子书发布会：《深入浅出Kubernetes》分享:
大家对Kubernetes技术有一定了解，我主要分享自己一些观点和理解，通过俩个形象易懂的案例分享学习Kubernetes的方法。
什么是Kubernetes？可以从以下四个角度来理解
第一，Kubernetes未来处于什么样的位置？
未来，大部分公司IT基础设施可能的架构图如下图，IT基础设施都会部署在云上，用户基于Kubernetes把底层的云资源拆分成集群单元给不同的业务使用，随着业务微服务化的深入，服务网格等服务治理的逻辑会变得跟下边的这两层一样，成为基础设施的范畴。
目前阿里云基本所有的业务都跑在云上，其中，约一半的业务已迁移到自己定制的Kubernetes集群，并计划在今年完成百分百业务基于Kubernetes集群部署。目前这个趋势非常明显，未来几年，Kubernetes会像Linux一样，作为集群的操作系统无处不在。
第二，Kubernetes和传统操作系统的比较
下图，传统的操作系统Linux或Windows等扮演的角色就是底层硬件的抽样层，向下管理计算机的硬件如内存、CPU等，把底层硬件抽象成应用的编程接口对应用层提供支持。
Kubernetes可以被理解成操作系统，但它向下管理的硬件不像是单机系统有自己的CPU资源等硬件，它管理的硬件可以理解成“底层多台计算机组成的集群”。
这些集群位于云上或本地的一些硬件的集群，Kubernetes把它们当成一个资源池统一管理，并向上对应用提供支持，而其上边的应用都是容器化的，可以把它们理解成一些安装包，包里自己打包了所有依赖库，就像libc或者Java的runtime等东西，不需要再去依赖于底层的操作系统的依赖库或者runtime来运行。
第三，Kubernetes和《Google运维解密》
如下图，左为Kubernetes集群，右为《Google运维解密》，这本书相信很多人都看过，很多公司也在实践这本书的运维方法，像故障管理，运维排班之类的东西，Kubernetes和Google运维解密这本书的关系可以比作《笑傲江湖的》里的剑法和气功的关系。
Kubernetes源自Google集群自动化和调度管理Borg系统，也是这本书里运维方法所管理的对象，Borg系统和书里各种运维方法可以看作是一个事情的两个方面，如果一个公司只学习我们的运维方法，开了很多SRE职位，其实是学了葵花宝典其中一部分，Borg是Google的内部系统，我们一般是看不到的，而Kubernetes基本上继承了Borg在集群自动化管理方面非常核心的技术，所以看了这本书并且觉得这本书非常厉害或者已经在实践这本书里的方法的人，一定要深入理解下Kubernetes。
第四、技术演进史
早期建立网站，只需把所有的模块放一个可执行文件里，如下左图，把UI、业务和数据三个模块编译成一个可执行文件跑在一台服务器上。
随着业务量的快速增长，没有办法通过升级底层服务器配置的方法来扩容，这个时候就必须要做微服务化的处理，微服务化的架构把单体的应用拆成小的应用，这些应用各自负责一个模块，每个应用实例独占一个服务器，它们之间通过网络来互相调用，如下中间的图，这里最关键在于我们可通过增加应用的实例来做横向扩容，解决单台服务器无法扩容的问题。
而一个实例占一台服务器，这种方式造成严重的资源浪费。如果把这些应用实例混部到底层服务器上，底层的服务器组成一个集群，就可以节省很多资源，而混部又会引入两个新的问题：
首先，UI，业务和数据，这些应用可能用不同语言写的，依赖的库版本不一样，如果安装在一个系统里会出现兼容性问题。
其次，是应用的调度和集群资源管理的问题，混部需要解决一些应用出来之后放到哪个节点去运行、放到这个节点之后资源够不够用这些问题。
兼容性问题是通过容器化解决，每个应用自带依赖库，只跟其他应用共享内核，调度和资源管理就是Kubernetes所解决的问题，而业务规模持续增长的话，集群里混部的应用会很多，像淘宝的后端有很多的微服务，互相关系错综复杂，出现一些请求蛮多问题都无法去排查，于是新的如服务网格这类服务治理的技术被引入，所以下一个技术便是服务网格的技术，大家可以去了解。
怎样学习Kubernetes
理解了Kubernetes之后，应该怎样学习Kubernetes呢？
首先你需要知道，Kubernetes之所以门槛较高，一是因为技术栈很深，涉及的内容很多，如下图右上框所列，这类绝对称得上全栈的技术。
其次，Kubernetes的云环境的实现牵扯到产品广度很广，如在阿里云涉及的产品如下图左边框所示，这些一个个学起来是相当复杂的。
最后一点是Kubernetes的适用边界相当广泛，因为Kubernetes是通用的计算平台，会被应用到各种应用场景，如下图右下角框所列。
这么复杂的东西，应该从了解、动手、思考三个方面去把握：
首先，需要了解技术的演进历史，以及技术的全景图。知道各种技术的演进历史，如容器技术是如何从一个命令发展而来，以及技术演进背后解决的问题，只有知道技术的演进史和发展的动力，才能判断未来发展的方向和下一步的需求。
同时对Kubernetes来说，需要了解整个云原生的技术栈，包括容器，持续集成、持续交付、微服务、服务网格等，知道Kubernetes在整个技术栈里所处的位置。
除背景知识外，动手实践也非常关键，据我和大量工程师一起解决问题经验来看，很多人不会深入研究技术细节，我们常开个玩笑把工程师分两种中，Search Engineer（搜索工程师）和Research Engineer（研究工程师），很多工程师遇到问题就Google一把，找不到答案就直接问别人或者开工单，这样是很难深入理解一个技术的。
最后一点是如何思考和总结，我们需要在理解一些技术之后，不断地探索这些技术背后有没有更本质的东西，把复杂的细节看简单，找出比较普遍的模式出来，有利于理解和应用。
《深入浅出Kubernetes》中有两个例子，如下图，关于集群控制器，在学习Kubernetes的时候，会有些概念如声明式API ，operater等，这些概念本质上就是控制器模式，如何理解Kubernetes的控制器？下图最左边的小图，经典的Kubernetes的架构图，它有集群的管控节点和工作节点，管控节点有中心数据库，API Server，调度器，以及一些控制器：
中心数据库是整个集群的核心重组系统。API Server是集群的管控入口，调度器负责把应用调度到资源充沛的节点上。
控制器是一个重点，它的作用可比作是“让梦想照进现实”的作用，从一定意义上来讲，我自己经常扮演控制器的角色，比如我女儿说“爸爸，我要吃冰激凌”，她就是集群的用户，我就是负责把她愿望实现的人，扮演了控制器的角色。
除了管控节点之外，Kubernetes集群许多工作节点，这些节点部署了Kubelet和Proxy两个代理，Kubelet管理工作节点，包括应用在节点上的启动和停止之类的工作，Proxy负责把服务概念的定义落实成具体的iptables或者 ipvs的规则，这里服务简单来说就是利用iptables或者ipvs来实现的负载均衡。
如果从控制器的角度来看，第一张图得到第二张图，集群实际上就包括一个中间数据库，1个集群接口、很多控制器，这些控制器包括调度器、Kubelet等，这些组件通过不断地从API Server观察集群里边资源的定义，需求的定义，将其落实成为具体的配置，如容器启停，iptables的配置，扮演的都是控制器的角色。
从控制器角度来观察Kubernetes集群，就会得到Kubernetes集群最根本的原理，控制器的模式，控制器的模式在生活中无处不在。
用冰箱做个例子：我们控制冰箱的时候并非直接控制冰箱的制冷系统或者照明系统，打开冰箱，灯就会自动亮起；设置了想要的温度的话，即使人不在家，制冷系统也会一直保持这个温度，背后就是控制器模式在起作用。
第二个例子，来看一个真实问题的排查过程——为什么删除不掉命名空间，问题稍微复杂，来一步步看下：
命名空间是Kubernetes的收纳机制，如图中的盒子，里面收纳橡皮铅笔等，命名空间其实是可以删除和创建的，经常遇到命名空间不能删除的问题，遇到这个问题，如果完全不知如何排查，可研究下API Server，因为它是集群的入口，总归需要知道API Serverr遇到删除之后它做了什么。
API Serverr本身就是个普通的应用，可通过提升应用的日志级别来深入理解它的操作流程，在这个问题里，可通过看API Serverr高级别的日志，会发现它收到删除命令后，它其实就没有其他信息了。
这里需要理解下删除命名空间的操作，用户在删除一个命名空间的时候，命名空间并不会被直接删除掉，而是会被改成正在删除中的状态，这时命名空间的控制器会如前文所说去不断观察集群里的资源的状态，不断地监视所有的命名空间，发现了命名空间变成了正在被删除的状态的话，就去做些操作。
了解这些概念之后，想去理解命名空间控制器行为的话，可以像处理API Server一样，把命名空间的日志级别提高起来，看详细日志，这时，会发现控制器正尝试获取所有API 分组。
这里需要理解两件事：一、删除命名空间的时候，控制器为什么要获取API 分组。二、API 分组是什么，它就是集群API 的分类机制，如网络相关的API 都会分在networking.Kubernetes.iovlbeta1这个分组里，而通过网络API 创建的资源，就属于这个分组。
为什么删除命名空间的时候，控制器要去获取API 分组呢？因为删除命名空间的时候控制器需要删除命名空间里所有的资源，这操作不像我们平时删除文件夹一样会直接吧里边的文件一起删掉。
命名空间收纳资源实际上类似于索引的方式指向了命名空间，而不是命名空间里包括了这些资源，所以集群只有遍历所有的API 分组，找出指向这个命名空间的资源，才能逐个把这些资源删掉，而遍历API 分组这个操作会是集群的API Server和它的扩展进行通信。
这里的扩展是API Server可能会定义集群比较核心的API 或者API 分组，有时候需要对这些集群做一些扩展，如接一些外接的功能，开发新的应用，扩展里边又有新的API 分组。
所以如果想知道命名空间里正在被删除的资源都是什么，那就需要通信，把所有的API 分组拿出来，因此，到了这里之后问题就变成API Server及其扩展进行通信的问题，于是删除资源的问题变成了网络的问题了。
接下来讲下阿里云Kubernetes集群网络相关的实现，阿里云Kubernetes集群在VPC网络，虚拟局域网创建的，默认情况下VPC只认识VPC的网段地址，一般情况，集群里边的容器不会使用VPC相同的网段，通过在VPC的路由表里增加一些容器网段相关的路由项，如下图右下角的图，一个跑的是API 另一个跑的是扩展，就可以让容器使用VPC网络进行通信了。
以上就关于Kubernetes的一些理解和学习经验分享，更多干货知识可以在点子书《深入浅出Kubernetes》中了解到。
这本书是最近一年多，我们在Kubernetes和服务网格领域一部分的技术沉淀，其中一些内容已经在InfoQ，阿里云技术、阿里巴巴云原生公众号上有发表过，这次在阿里云开发者社区和自己团队的帮助下做了本电子书，希望通过这本电子书分享阿里云线上问题的诊断经验。
我们每天都会处理大量的线上问题，以后也会新增新的问题、案例出来，本书就当做1.0 的版本，后续新的案例和新的文章会通过2.0或者3.0的方式分享给大家。
总体来说，书有3大特点
1、简单易懂分析Kubernetes集群核心原理
2、是阿里云真实线上问题诊断的集锦
3、难得的Kubernetes诊断方法和调制方法
我们是阿里云售后技术团队，重要的一项工作就是服务，经常需要相对易懂和比较有创意的方法把晦涩难懂的技术解释给客户听，所以书中的很多原理的解释都非常形象易懂的（如本次分享就是个例子）。
其次阿里云售后技术兜底团队，需要解决大量疑难取决的问题，部分问题复现概率极低，可能需要几个月才有一个客户碰到，这类问题也只有在阿里云这样大的平台才会复现和诊断出结果，书中也包括这样的案例，案例分析会关联多个Kubernetes组件，针对这些组件的调试方法，在其他地方一般看不到，给大家献上啦，不容错过哦：开放下载！《深入浅出Kubernetes》
