这篇文章向你介绍了k8s的精髓，内容非常详细。感兴趣的朋友可以参考一下，希望对你有所帮助。
现在k8s是热门内容，那么它是什么，为什么这么热门，解决了什么问题？
当我们谈论k8s时，我们总是会想到Docker。是的，如果我们想知道k8s解决了什么问题，我们将不可避免地回到Docker和容器。
在‘开发-测试-发布’的过程中，真正承载容器信息进行传输的是容器图像。因此，在Docker项目成功后不久，就迅速走向了‘集装箱排列’3360的重要原因。作为云服务提供商或基础设施提供商，只要能把用户提交的Docker镜像作为一个容器运行，就能成为容器生态系统中的一个承载点。因此，整个容器技术堆栈的价值将存放在我的节点上。另外，只要我们从我的方位点追溯到Docker镜像生产者和用户的方向，整个路径上的所有服务节点，比如监控、安全、网络、存储等。有一些地方可以玩和赚钱。
因此，这也是云计算提供商如此热衷于容器技术的重要原因。我可以通过容器镜像与潜在用户(开发人员)直接关联。
基于以上，容器从一个开发者手中的小玩意，变成了云计算领域的绝对主角；能够定义集装箱组织和管理规范的“集装箱排列”技术已经成为目前最热门的技术。
那么，k8s要解决的问题是什么呢？安排？调度？还是集群管理？
到目前为止，这个问题还没有固定的答案，因为在不同的发展阶段，k8s需要专注于解决不同的问题。对于大多数用户来说，有一点是肯定的：现在我有了应用程序的容器映像，请帮我在给定的集群上运行这个应用程序。此外，我现在有一个可以应用的容器映像，所以我也希望k8s能为我提供路由网关、监控和备份。
从上图可以看出，k8s项目的架构由Master和Node两个节点组成。主节点(即控制节点)由三个紧密协作的独立组件组成，即用于应用编程接口服务的kube-apiserver和用于调度的kube-scheduler。kube-controllermanager负责集装箱安排。整个集群的持久数据经过kube-apiserver处理后存储在Etcd中。
计算节点的核心部分是一个名为kubelet的组件。在k8s项目中，kubelet主要负责处理容器运行时(比如Docker项目)。这种交互依赖于一个叫做CRI(容器运行时接口)的远程调用接口。这个接口定义了容器运行时的核心操作。这就是为什么k8s项目不关心您部署的容器在运行什么，使用什么技术。只要您的容器运行时可以运行标准容器映像，就可以通过实现CRI将其连接到k8s项目。
正因为如此，k8s项目并没有像同时期的各种‘容器云’项目一样，将Docker作为整个架构的核心，而只是将其实现为底层容器运行时。
实际上，大规模集群中运行的各种任务之间存在着各种各样的关系，而这些关系的处理是作业调度管理系统中最难的部分，也是k8s项目中需要解决的关键问题。
K8s侧重于解决问题，这些问题也很容易理解。在容器技术普及之前，传统的虚拟机环境以相对粗粒度的方式处理各种关系。如果你善于发现，你会经常看到很多功能不相关的应用部署在同一个虚拟机中，只是因为它们偶尔会互相发送几个HTTP请求。更常见的情况是，在虚拟机中部署应用程序后，您需要手动维护许多连接。
然而，当容器技术出现时，你会发现容器在划分“功能单元”3360方面具有独特的“细粒度”优势，因为容器的本质只是一个过程。
这意味着，只要您愿意，过去拥挤在同一虚拟机中的所有应用程序、组件和守护程序都可以单独镜像，然后在独占容器中运行。它们互不干扰，有自己的资源配额，并且可以在整个集群中的任何机器上进行调度。这也是“微服务”理念落地的前提。
k8s项目的关键问题是如何处理各种关系。首先，让我们对k8s项目
的核心功能有一个“全景”:
在这张图中，我们从最基本的容器概念出发，首先遇到了容器之间‘紧密协作’的问题，然后扩展到Pod。
;有了 Pod 之后,我们希望能一次启动多个应用的实例,此时就需要 Deployment 这个 Pod 的多实例管理器;而有了这样一组相同的 Pod 后,我们又需要通过一个固定的 IP 地址和端口以负载均衡的方式访问它,于是就有了 Service .
讲了这么多,那么 k8s 的本质是什么呢? 它的本质是为用户提供一个具有普遍意义的容器编排工具.如果非要一个很形象的比喻的话,你可以把它理解为操作系统.
过去很多集群管理项目所擅长的都是把一个容器,按照某种规则,放置在某个最佳节点上运行起来,这种功能我们称为"调度".但 k8s 项目所擅长的,是按照用户的意愿和整个系统的规则,完全自动化处理好容器之间的各种关系,这种功能,叫做编排.
但是 k8s 为用户提供的不仅限于一个工具,它真正的价值,在于提供了一套基于容器构建分布式系统的基础依赖.
最后,上一张导图吧,算是对
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/147382.html