k8s的知识图谱

第二部分我们的知识图谱的学习，那这章呢主要任务呢就是带大家去掌握一下我们在 k 8s学习的时候，我们需要去学习的一些详细的知识点，那这个呢并不能让大家去得到什么样的启发，但是可以在你的脑海中去建立一个深刻的印象，唉哪一张该干嘛，对吧？这是我们的一个讲解顺序。好，那我们去打开我们的xmad，我去给大家画了一个我们的思维导图，对吧？好，我们看一看,最开始的时候呢,在这里我们会分为这么几个部分给大家讲解，对吧？

 

 

介绍说明 

发展经历

发展经历我们刚才已经介绍过了，那下一个呢就是我们的组件说明

组件说明

会先从我们的博格系统开始说，原因是他是我们k8s的老祖宗嘛对吧？那当然他先优先他讲完以后你再去讲k8s的结构的时候，你会发现有大量参照我们的博格系统这么一些组件，你就会更好的理解。以及k8s的一些关键字的解释，那我们到时候再去学习它的时候，你就不会感到感觉到我们的陌生了

 

 

 

 

你要知道它是怎样的一个前身今世，这还是很重要的。那你要掌握我们的kubernetes的这么一个结构框架以及组件和功能，要在脑海中建立一个印象，给大家写一下对吧？在我们的介绍说明里你需要去掌握的东西，前世今生，第二部分呢是我们的一个组件说明，也就是你要掌握我们kubernetes的框架，好以及kubernetes的一些关键字的含义，这是需要我们在这一章里去一定要掌握的。

基础概念

那第二个部分呢给大家讲解的是我们的基础概念，在这一章里呢我们会学习我们的pod的概念以及网络通讯模式，那什么是pod的呢？那在kubernetes这里的概念就是它是最小的封装集合，在我们的容器化里，每一个运行的容器是不是就是一个封装集合？那一个pod的里面会封装多个容器，达到一个子节点的运行环境，它是我们kubernetes管理的最小单位，需要大家注意一下。Out。好，并且会给大家讲一些管理pod的一些控制器，包括服务发现是怎样去实现的，以及每个pod之间是怎样去沟通的，对吧？

会在这一个章节里给大家去讲解

 

那通讯模式里你需要掌握在kubernetes，pod的与pod的之间是怎样通讯的，比如本节点通讯和pod主机通讯，一定要去掌握。那在这一章里，你必须要掌握的知识点，什么是pod的？对吧？以及控制器类型。现在是不是听的有点一头雾水，对吧？先简单听一听，给大家去建立一个印象，后面我们会详细学习，不要担心，对吧？

 

 

 

好，那再到我们的 k8s中的网络通讯模式，对吧？这都是需要我们在基础概念里进行掌握的。第二个部分很关键。

 

 

 kubernetes的安装

 

再到后面呢是到我们的kubernetes的安装了，我们必须要掌握这些基础的概念以后，我们才能进行我们的kubernetes安装，不然的话你会装的一头雾水，对吧？好，那在这一章里那需要掌握的点，我不说大家都知道对吧？一定要去自己去构建一个我们的 k8s的集群，一定要去构建一个k8s集群，别眼高手低对吧？看着我构建唉还挺简单，那我就先看着吧我就不做了，这种事情大家切记切记不要去犯，因为我们的课程难度会逐渐逐渐升级，对吧？

 

 

 

那前面如果你大意的话，你可能到后面已经完全跟不上了，那你学习的时间就浪费了。一定一定每一个部分我只要讲是重要的，大家都最好去把它手动实现。别光看 Linux运维这个东西，他并不是能看出来的，一定要你通过我们的动手实践对吧？去操作去做，去犯错，犯很多错，这样的话才能转化成你自己的东西。需要注意一下。

资源清单

那再往下的一个部分是我们的资源清单，资源清单，那资源清单到底是什么呢？

 

 

 

 

 

 

 

我再换一个定义，大家可能就有一定了解了。那比如导演如果要导戏的话，会发给每个演员什么一些剧本，那这些演员只要去根据这个剧本去执行即可。那这里的导演和我们的演员，你可以理解为就是我们的kubernetes的集群，导演呢把这些剧本分发给对应的一些什么所谓的我们的演员，也就是不同的子节点，k8s的子节点，他们去根据这个剧本去做自己对应的事情，达到了这么一个整个集群化的运行。那在我们的kubernetes中，剧本就是这里的资源清单，资源清单，在这张里呢我们会去给大家讲一下什么是资源，以及资源清单的输血的格式，并且我们会通过一个词编清单去编写一个pod的，就是我们刚才所说的 k 8s里运行的最小单位，对吧？

好，再去讲解一下我们pod的生命周期，从它的诞生啊对吧？到运行啊到死亡，它要经历哪些过程？这个是重点更是难点，一定一定一定一定需要好好的把它掌握一下，我们去给大家写一下它的重点，对吧？首先你要知道什么是资源，其次掌握资源清单的语法，再继续编写 pod。再继续掌握pod的的生命周期，并且我在这里会打三个信号，之前都没打过信号对吧？这里一下打三个，你就知道它的重要性了，能理解我的意思吧？

pod的控制器

那这是我们的第四部分。再往后到我们的pod的控制器，pod的控制器可以理解为是我们的kubernetes的灵魂。在我们的kubernetes里，比如我运行了一个pod的或者叫运行了一组容器，这些容器如果死亡的话，我们的控制器会发现，并且把这些死亡的容器给它重建，重建它的副本，那可能可以给大家举个例子对吧？比如我现在养了4盆花，我说我的期望值就是这4盆花都在唉有一天有花死了，那死了我怎么办？我又不会魔法对吧？我又不能把它变活，那怎么办？

啪我一脚把这盆花踢了，我再去买一本，是吧？很简单，我再去买一本，把这4盆花给它补全，那这样的话是不是达到我心中的理想的一个状态，唉还是十分的话，那这个功能到底在k8s里是怎样去完成的？

 

 

 

就是通过我们这里的所谓的控制器，并且在k8s里有一堆的控制器，看到了吗？有一堆的控制器，大家不要头皮发麻对吧？这些东西呢我会大家一个一个一个去讲，只要你根据我的步伐，我们走下去，一定能够去把这些知识点给它吃掉，对吧？掌握掉，不用担心，反正我是很有自信的，大家一定要跟着我对吧？一定要建立这种自信。那我们现在写一下在这里我们需要去掌握的重点知识，掌握各种控制器的特点，以及使用定义方式，对吧？很重要。

服务发现

 那这是我们的下一部分内容。那再往后到我们的服务发现，服务发现这个篇章怎么给大家解释？举个例子，我现在是不是刚才运行了很多的pod的，通过我们的控制器运行的对吧？这些pod的其实是没办法提供给我们所谓的客户端去访问的，这些客户端可能是一种服务，可能是一个用户，但不好意思，由于我们kubernetes集群内部都是一些私有的IP地址，没办法提供给这些客户端的访问，那怎么办？我们通过这里的服务发现，把这个服务暴露给我们的客户端，听清楚我就要暴露给我们的客户端，那这样的客户端就可以根据我暴露的地址加端口的方式访问至我们的多个 pod，也就意味着我们可以先定义一组pod的，就类似于我们刚才说的这4盆花，然后我再给他定义一个统一的访问入口，那如果有用户想去访问这些服务的话，我们只需要访问到这个统一的入口即可。

 

 

 

 

 

并且这里还是一个负载均衡的方案，那他选择的选择的算法呢是我们的rubbion，也就是我们的轮巡算法，需要注意一下。

 

服务发现掌握service svc就是service的缩写，在ks8里也是适用的。好，然后 svc的原理及其构建方式。好，那这是我们的svc章节去带大家去讲的一些东西。

存储

再往后到我们的存储，对吧？到我们的存储，我们之前给大家强调过的一个概念就是对于我们的pod的来说，或对于我们的docker来说，它其实更更适用于是我们的叫做什么？

 

无状态服务，无状态服务的含义。这里给大家解释一下，服务的分类，其中一个分类是有状态服务和无状态服务。那什么叫有状态服务和无状态服务呢？举个例子，我现在是一个高级的这么一个项目的管理人员。有一天的老板呢由于一些私活，把我从这个项目里给他踢出去了，让我去干一些别的，帮他去干一些别的，干完以后再把我扔到这个项目里，你觉得这时候我还能很好的去跟进这个项目，或者是维护管理这个项目，其实已经很难了，对吧？

 

那再换一个，我不是项目经理，我不是项目的管理者，我就是一个流水线上的工人，当有一些娃娃过来的时候，我去检测这些娃娃是不是可用的，对吧？那有一天同理老板把我提溜出去了，让我去干一些别的活，干完以后再把我去放到这个流水线上继续工作。你会发现不管什么时候把他提溜走，什么时候放回来，我都能继续完成我自己的工作，这就是典型的一个无状态，那有状态服务放在我们的整个我们的it圈里呢有状态服务比较有特点的，比如数据库 dms对吧？

 

Database manage System，也就是我们的数据库管理系统，它就是典型的一个有状态服务，你把我踢出这个集群，有一天再放回来，不好意思，我已经不能正常工作了，对吧？已经有很大的一部分数据缺失了。那无状态服务有哪些特点？比如我们的iOS调度器对吧？比如我们的阿帕奇，这些其实都是我们的无状态服务。有些人可能会问了，阿帕奇无状态服务，你怕不是脑子烧坏了吧对吧？那原因是什么呢？它的数据我们是不是可以通过我们的共享服务去完成？

 

对于组件本身它需要数据吗？它需要有一些数据的更新吗？并没有。所以阿帕奇会被定义到无状态服务里。

 

对于docker来说，它更适用于运行的是无状态服务，而不是由状态服务，但是k8s斯的目标是以后未来的对吧？基础设施的平台，它必须要攻克的一个难点就是这里的有状态服务，那有状态服务，它有些数据需要持久化，需要保存，那这时候我们就会引入一个新的概念，就是这里的存储，就是这里的存储，那k8s给我们去建立的存储有很多很多，比如我们这里的configMap，它是我们专门去存我们的配置文件的，那比如secret啊,去存一些比较重要的一些数据，比如用户密码需要加密的.volume可以去存一些我们的数据，对吧？

 

一些基本的数据，比如我们的网页文件，那 Pv是一个动态的创建过程，动态的调度过程，那后面我们会给大家去说，总共有这么几个分类，都是我们k8s里能够去给我们提供的存储的类型。

 

那我们去看一下存储。掌握多种存储类型的特点.肯定要掌握的，并且能够不同环境中选择合适的存储方案，这个呢并不能光听了，这个要思考了，有自己的见解很重要很重要，因为我会给大家去举一些例子，但是在未来的生产环境中，我是不是不能给大家举例了，这时候就要靠你自己了，听懂我意思吗？

 

一定要有自己的见解，对吧？

 

 

 

 

 

 

 

 

 

 

调度器

那我们再看下一个到我们的调度器，k8s意思呢会自己完成，把这个所谓的容器或pod的调度到对应的节点，对应的节点。

 

但问题是如果有一天我就想把它调度给note1节点或note2节点，那这个能完成吗？并不能完成对吧？或者说我们在学习这个调度之前并不能去完成。那比如有一天我想唉有个叫pod1的，有个叫pod2的，我想把这两个pod的调度到同一个节点，或者调度到不同的节点。像我刚才所说的这些比较有特点的一些功能，那我们在没有学习调度器之前，你是没办法去掌握的，也就意味着我们学习过调度器以后，你能够掌握的点就是可以根据自己的想法，把pod放在不同的节点，或者是根据自己的想法把pod的进行对应的节点组装，这都是我们可以掌握的内容。

 

能理解我的意思吧？好。那这一章的内容你需要掌握的点那就非常清晰了，对吧？掌握调度器原理，能够根据要求，吧 pod定义到想要的节点运行，这个就是我们的调度器你需要能够掌握的点，对吧？

 

根据自己的想法，想把pod放到哪个节点就放在哪个节点，想跟谁放一起就跟谁放一起，你必须要掌握到这种级别才可以。

 

 

 

 

 

 

 

 

 

 

集群安全

那接下来我们继续下一个节点到我们的集群安全机制，就是对于企业应用的一些软件来说，没有人会说把安全当作儿戏，在我们的k8s里面也是一样的，安全这个篇章呢很重要，但是也非常生涩难懂，需要大家好好的反复的把视频进行观看，获取里面的一些重要的精华的部分，转化为自己的知识进行存储。

 

需要注意一下，很难也很重要。那在这里你需要掌握的点呢就是我们的集群的认证，鉴权，访问控制原理及其流程很重要，这是我们在这一部分你需要去掌握的点。到时候大家每学完一章以后，回过头来看，我这些所说的你需要掌握的点，如果没有完成的话，重新学习，不然的话最后学一个鸡零狗碎的，肯定不太好，对吧？好，需要注意一下。

 

 

 

 

 

 

 

 

 

 helm

 

 

那下一个呢到到我们的 helm，那这个东西如果转换成咱们已经理解过的概念，就是我们的linux操作系统里的yum管理器，并且在这一章里我们会给大家衍生一些东西，比如我们的hpa就是能够根据我们的CPU当前使用率去进行我们的平滑扩展，在这里是可以做到的，比如我们的日志收集对吧？比如我们的日志展示在这里都会去给大家讲到。给大家写一下我们在这里需要去掌握的对于它的定义，我们把它理解为的是一个 Linux系统中yam的包管理工具，对吧？

 

我们可以通过简单的命令就去把对应的一些服务给安装，那只不过要么安装的是我们的IPM包，对于我们的helm的安装的是我们的一个集群，比如一个mongodb的群，比如一个redis的机群，我们只需要通过一条命令就可以把它部署至我们的K8S环境中，所以他的地位是非常非常非常之高的，那它的重点也是非常非常非常非常激动的，对吧？

 

掌握helm原理，比如还有就是helm的模板，自定义,一定也要掌握对吧？那通过我们的helm去部署一些常用的插件或附件。好，那这是我们在helm里我们需要去掌握的内容

 

 

 

 

 

 

 

 运维

 

那再往后呢就到我们的最后一个篇章了，到我们的运维部分，这里需要给大家说明一下，我们后面呢还会再放出我们的k8s-2。

 

第二期视频，在这里呢我们就是给大家去讲的是我们的k8s的集群本身的一些东西，那还有跟我们的k8s能够相融的一些东西，比如我们的k8s的构建对吧？通过我们的jenkins进行我们的自动化部署，流程控制的，包括我们一些节点的运维的管理，包括一些我们的pod的一些特殊的创建管理方式，在我们的后面的篇章中会给大家补充，包括可以带大家分析一些源码对吧？都是可以的。好，那第一部分内容呢对于运维部分呢我们讲的对方稍微少一点，那包含两个部分，第一个就是 kubeadm的源码修改，为什么要进行源码修改？

 

主要的原因就是我们通过kubeadm去创建的k8s集群的话，他有一个比较不是确定的确定，就是它的默认的证书只有一年，只有一年，也就一年以后，这里的证书就会过期。

 

你可以理解为这个集群就正常访问不了了。那你觉得过分吗？其实不过分，为什么？后面有个定义对吧？就是每年你只要更新一次，我就会自动的把你的证书的是可用周期给它更新为一年也就一年，你只要去更新一次你的 k8s集群即可。这个应该对于很多企业来说不是问题，甚至一年能够更新个好几次对吧？可能会出现一些漏洞，那你就需要更新了。好，但是如果有一些完全跑在内网的一些服务，并且一些新的功能我不需要，我可能就不会去更新，但是一年的可用期会阻碍我的这种部署的思想，那怎么办？

 

我们去修改kubeadm的源码，把这个分配的证书的一年期限把它改为10年100年1000年，可能你都不在了，这个证书还继续可用，对吧？

 

我们可以做到这一步，这是第一部分。那第二部分呢会大家去构建一个k8s的高可用集群，高可用机器，这是非常有必要的，不能因为某个节点的死亡，就造成我们整个k8s集群的瘫痪，这肯定是不现实的。所以在这个篇章里呢会大家进行高可用构建，那这就是我们的这么一两张那你需要掌握的就是修改 kubeadm达到证书可用期限为10年，甚至更多对吧？我们这里就改成10年了。