美丽的本质是什么

  介绍

这篇文章给大家介绍k8的本质是什么,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

<节>

当下k8算是比较火的一个内容,那么它到底是什么呢,它为什么会这么火呢,它解决的是什么问题呢。

当我们谈美丽的时候,总是会想起来码头工人。是的,如果想要知道k8解决的是什么问题,我们不可避免的再回到码头工人上面,回到容器上面来。

在“开发——测试,发布“的流程中,真正承载着容器信息进行传递的,是容器镜像。所以,当码头工人项目成功后不久,它就迅速走向“容器编排“的重要原因:作为一家云服务商或者基础设施提供商,我只要能够将用户提交的码头工人镜像以容器的方式运行起来,就能成为容器生态圈上的一个承载点,从而将整个容器技术栈上的价值,沉淀在我的这个节点上。此外,只要从我这个承载点向码头工人镜像制作者和使用者方向回溯,整条路径上的各个服务节点,比如监控,安全,网络,存储等等,都有可以发挥和盈利的地方。

所以,这也是为什么云计算提供商如此热衷于容器技术的重要原因:我可以通过容器镜像,和潜在用户(开发者)直接关联起来。

基于以上,容器从一个开发者手里的小工具,一跃成为了云计算领域的绝对主角;而能够定义容器组织和管理规范的“容器编排“技术,则当仁不让的成为了当下最火热的技术。

那么,美丽要解决的问题是什么?编排?调度?还是集群管理吗?

这个问题,到现在也没有固定的答案,因为在不同的发展阶段,k8需要着重解决的问题是不一样的。对于大多数用户来说,有一点是确定的:现在我有了应用的容器镜像,请帮我在一个给定的集群上把这个应用运行起来。更进一步说,我现在有了一个能够应用的容器镜像,那么我还希望k8能够给我提供路由网关,监控,备份等一系列运维能力。说到这里,我们就需要来讲讲美丽的架构了。

<人物> 美丽的本质是什么”>
  图>,</<p>从上图中我们能够看的到,k8项目的架构,由主节点和两种节点组成。主节点(即控制节点),由三个紧密协作的独立组件组合而成,它们分别是负责API服务的kube-apiserver,负责调度的kube-scheduler,以及负责容器编排的kube-controllermanager。而整个集群的持久化数据,则由kube-apiserver处理后保存在Etcd中。</p> <p>计算节点上最核心的部分,是一个叫做kubelet的组件。在k8项目中,kubelet主要负责同容器运行时(比如码头工人项目)打交道。而这个交互所依赖的,是一个称作CRI(容器运行时界面)的远程调用接口,这个接口定义了容器运行时的各项核心操作。这也是为什么,k8项目并不关心你部署的是什么容器在运行,使用的什么技术实现,只要你的容器运行时能够运行标准的容器镜像,它就可以通过实现CRI接入到k8项目当中。</p> <p>正是因为如此,k8项目没有像同时期的各种“容器云“项目那样,把码头工人作为整个架构的核心,而仅仅把它作为最底层的一个容器运行时实现。</p> <p>运行在大规模集群中的各种任务之间,实际上存在着各种各样的关系,这些关系的处理,才是作业编排和管理系统最困难的地方。而这也是k8项目要着重解决的问题。</p> <p> k8着重解决的问题,也比较好理解。在容器技术普及之前,传统虚拟机环境对各种关系的处理方法都是比较“粗粒度“的。如果你善于发现,你会经常看到很多功能并不相关的应用被一股脑儿的部署在同一台虚拟机中,只是因为它们之间偶尔会互相发起几个HTTP请求。更常见的情况就是,当一个应用被部署在虚拟机里之后,你还需要手动维护很多跟它协作的守护进程,用来处理它的日志搜集,灾难恢复等辅助工作。</p> <p>但当容器技术出现后,你会发现,在“功能单位“的划分上,容器有着独一无二的“细粒度“的优势:因为容器的本质,就是一个进程而已。</p> <p>这样的意思就是说,只要你愿意,那些原来拥挤在同一个虚拟机里的各个应用,组件,守护进程,都可以被分别做成镜像,然后运行在一个个专属容器中。它们之间互不干涉,拥有各自的资源配额,可以被调度在整个集群里的任何一台机器上。这也是“微服务“思想能够落地的前提条件。</p> <p>, k8项目着重要处理的问题是,对于各种关系的处理。先来一张k8项目核心功能的“全景图“:<img src=

美丽的本质是什么