k8s-No.1-概述与架构

本章目录

1. k8s概述
2. k8s系统架构
3. k8s工作流程图

一  概述

• k8s是什么

　　k8s是谷歌公司基于内部容器管理系统borg开源出的一个容器集群管理工具，它是用go语言开发，提供了容器的应用部署，规划，更新，维护等功能。

　   相信你读这篇文章之前，你已经有了docker基础。并且对k8s已经有个大概的理解，所以关于k8s的背景知识不做过多赘婿，下面我们直接上干货

二  系统架构

• k8s系统架构

　　学习新知识之前，一定要先对知识的整体框架有个大概的了解，为了更加生动形象的理解k8s框架，我在网上找了一张图（图片出处见水印），我们日后的

　   学习也会按照架构图上的知识点一点一点的铺散开来

　　

　　下面我们将架构图逐一拆解

1. k8s操作对象

　　pod，service，replication  controller三种就是我们日常经常操作的三类对象，当然，在k8s中，不仅仅只有这几种类型的资源，还有namespace，secret，node，

　　ingress，configmap等等

　　下面我们简单的对这三种资源做下介绍

• pod

　　pod在英文中的意思是豆荚，我们可以把容器想象成一个个的豆子，pod就是包裹住这些豆子的豆荚

　　

　　Pod是K8s集群中所有业务类型的基础，也是k8s集群中可操作的最小单元。可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前

　　K8s中的业务主要可以分为长期伺服型（long-running） 、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用  型（stateful application）；分别对应的小机

　　器人控制器为Deployment、Job、DaemonSet和PetSet（现在不叫petset而叫statefulset）。

• replication  controller

　　RC是K8s集群中最早的保证Pod高可用的API对象。比如有这样一个场景，你要启动俩个或者更多相同功能的pod容器来提供服务，我们总不能手动的一个个的去启动这些pod，然

　　后再去手动管理他吧？这种做法明显很low，k8s早已经为我们做好一个pod管理器，叫做replication controller，专门为我们管理那些带有副本的pod。replication controller通过监控

　　运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod

　　副本，控制器在做这些操作的时候完全不用我们去人工参与，他已经自己为我们做好这一切。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可

　　以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制pod提供高可用的Web服务。当前RS已经取代了历史

　　版本的RC，RS是最新一代的RC控制器，他提供了更多的匹配模式，而且RS一般也不单独使用，而是作为deployment的理想化参数去使用

• service

　　service一种抽象的服务，RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod

　　只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。

　　要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，

　　客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服

　　务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这

　　一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时

　　在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

　　2. 功能组件

　　在k8s集群中，共有俩部分，分为master节点与node节点，master节点还有node节点都对应一台实体服务器或者虚拟机

　　上面的功能组建遗漏了俩个最重要的部分，所以我们给他补上

　　

　　针对以上组件，我们做一下简要说明

　　  apiserve：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

　　  controller manager：维护集群的状态，比如故障检测、自动扩展、滚动更新等；

　　 scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

　　  flannel： 负责让不同机器上面pod跨节点进行网络通信

　　  etcd： 提供强一致型的数据库与服务发现，在k8s集群中，网络配置还有资源对象的信息都存储在ETCD中

三  工作流程

　　

　　上面的流程图意在通过yaml文件创建一个deployment资源，先画个图说一下pod，replicaset，deployment三者关系，不然下面的流程解释初学者看不懂

　　

　　因为deployment包含replicaset包含pod，所以创建deployment的时候会连续创建三种资源

　　1、准备好一个包含应用程序的Deployment的yml文件，然后通过kubectl客户端工具发送给ApiServer，ApiServer接收到客户端的请求并将资源内容存储到数据库(etcd)中。

　　2、deloyment Controlle监控apiserver状态发生了改变，知道了apiserver需要创建一个deployment资源

　　3、deployment controller 根据apiserver的状态信息，想要去创建一个ReplicaSet，此时apiserver检测到了deployment controller的期望状态的变化，再次记录到数据库etcd中

　　4、replicaset 监控到了apiserver状态发生了改变，知道了apiserver需要创建一个replicaset

　　5、replicaset controller根据apiserver的状态信息，想要去创建一个pod，此时apiserver检测到了replicaset controller的期望状态的变化，再次记录到数据库etcd中，此时

　　     最低级别的pod的创建准备工作也完成，此时实际上pod，replicaset，deployment三种资源都没有实际被创建，刚才所说的创建类似于一种演习

　　6、Scheduler再次检查数据库变化，发现尚未被分配到具体执行节点(node)的Pod

　　7、根据一组相关规则将pod分配到可以运行它们的节点上，并更新数据库，记录pod分配情况。

　　8、Kubelete监控数据库变化，此时kubelet知道自己该创建pod了，但是它本身并没有创建容器的功能，所以它通知了有创建容器功能的docker引擎，并把创建的约束信息

　　    （如镜像名称，镜像源等）传递给docker引擎

　　9、docker引擎根据收到的信息开始拉取镜像，创建容器，此时，deployment才算真正创建成功

四  小结

　　以上就是k8s的简单介绍，后续我们将更深入的讲解每一个组件与功能

　　文中如有错误之处，请大家向我及时指出，谢谢