快盘下载:好资源、好软件、快快下载吧!

快盘排行|快盘最新

当前位置:首页软件教程电脑软件教程 → 云原生技术之kubernetes学习笔记(1)

云原生技术之kubernetes学习笔记(1)

时间:2022-09-18 20:56:00人气:作者:快盘下载我要评论

云原生技术之kubernetes学习笔记(1)

云原生技术之kubernetes学习笔记(1)

今天我们看看kubernetes技术的介绍,最近在极客时间上看张磊老师的深入kubernetes技术,讲的非常好,有兴趣的同学可以去收听一下,对于理解kubernetes技术非常有帮助,这里我会按照自己的进度,分享一下学习的笔记。

今天站的角度比较高,概念性质的东西会多一点。

01 kubernetes是什么?

曾经我认为这个问题很好回答,直到不断的去理解kubernetes,不断的深入之后,我发现这个问题很难回答的全面。

要想搞明白这个问题,首先你得知道容器是什么?在前面的文章中,我们说过,容器是一个特殊的进程,实际上是由Namespace、Cgroup、以及rootfs三种技术构建出来的一种特殊的进程的隔离环境。 这个隔离环境最主要的目的,是要运行我们自己的应用程序。

对于云厂商来说,如果能够将用户提交上来的docker镜像运行在自己平台的容器环境中,并很好的管理起来,那么这个云平台就有了商业价值。事实上,也确实是这么实现的。

然而,想要得到用户的认可,绝不仅仅是支持一个容器、一个用户的docker镜像,更多的是支持无数开发者,庞大的容器集群,才能让你的平台得到云原生整个生态的认可。基于这个现实情况,不难发现,谁能够更好的组织、调度、编排、规范化管理容器集群,谁就能够得到容器领域的青睐。

这里面,我标红了2个词语,分别是调度和编排,对这两个词语,有必要解释一下:

调度:把一个容器,按照某种规则,放置在某个最佳节点上运行起来

编排:按照用户的意愿和整个系统的规则,完全自动化地处理好容器之间的各种关系

在这样的背景下面,docker公司原生的Compose+Swarm组合、以及Google公司的kubernetes项目应运而生。为什么kubernetes最终胜出?我们慢慢来看。

Kubernetes项目的理论基础要比工程实践走得更靠前,kubernetes项目起源于Borg,一个Google公司基础设施的核心系统,相比于其他的容器编排项目,它体现出了一系列的"先进性"和"完备性",而这些特性,成为了kubernetes项目赖以生存的核心价值。

kubernetes的问世,解决了容器的编排、调度和集群管理中的瓶颈,它解决了用户一个痛点问题:我有一个应用程序的容器镜像,请帮我在一个集群上将这个应用程序运行起来。然而,这并不足以让它替代Compose+Swarm的架构,因为docker公司原生的Compose+Swarm架构也能够解决容器的运行和基本的运维管理功能。

kubernetes更有价值的地方在于,它从一开始,就不是围绕docker这个特定的容器去设计的,它将docker仅仅看成是底层的一个容器实现,它着重解决的问题是:运行在大规模的任务之间,实际上存在着各种各样的关系,这些关系的处理,才是任务编排和系统管理最困难的地方。

这些任务之间的关系有很多类型,例如,一个web应用和mysql数据库之间的关系、一个负载proxy和后端服务之间的关系等等。

传统的虚拟机处理这种类型的任务,通常情况是将它们部署在一起,因为各个任务之间会有tcp或者http的请求发生。但是容器技术出现之后,各个任务都可以通过镜像的方式,封装在不同的容器中,它们之间不相互干涉,拥有各自的资源配置,也可以被集群调度在不同的机器上。如下:

容器

02 kubernetes和Compost+Swarm之间的区别

这种任务之间的关系处理,也是kubernetes项目区别于Compost+Swarm架构最明显的地方。

以web应用和MySQL这两个服务为例,在Compost+Swarm架构中,会为这两个服务中间定义一个"link",Docker项目会负责维护这个"link"。Docker会在这个web应用的容器中,将DB容器的IP、port以环境变量的方法给注入进去,供应用进程使用,当DB容器的连接信息发生变化的时候,更新环境变量。

Compost+Swarm这种设计模式,可以比较好的支持web应用和MySQL的服务之间联系,但是未来可能出现更多类型的任务之间的联系,这种简单的处理依赖关系的能力,一定会遇到瓶颈。

Kubernetes 项目最主要的设计思想是:从更宏观的角度,以统一的方式来定义任务之间的各种关系,并且为将来支持更多种类的关系留有余地。

例如,Kubernetes为容器之间的相互调用进行了分类,来区分哪些交互式频繁的tcp交互,哪些交互仅仅是磁盘文件的交互等等。对于这些需要交互的任务,常规的做法是各种任务部署在同一台机器上,通过Localhost进行通信,而Kubernetes引入Service的概念,让两个本来互相依赖的服务,甚至可以部署在不同的机器上。每一个Service的背后,都是若干个Pod,Service的作用就是为Pod提供固定的代理入口,而Pod的分布,完全是随机的。

这样,对于 Web 应用的 Pod 来说,它需要关心的就是数据库 Pod 的 Service 信息。不难想象,Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自动更新、维护,则是 Kubernetes 项目的职责。

03 一点总结

今天我们从容器这个最基础的概念出发,提出了k8s产生的背景,又通过web应用和MySQL服务之间的“紧密协作”关系,扩展到了 Pod,有了 Pod 之后,我们希望能一次启动多个应用的实例,这样就需要Deployment 这个 Pod 的多实例管理器(后面会讲到);而有了这样一组相同的 Pod 后,我们又需要通过一个固定的 IP 地址和端口以负载均衡的方式访问它,于是就有了 Service,如果web应用访问MySQL需要账号密码,我们又会引出Secret......最终,你会看到下面的一张图:

Docker

具体的内容,我们后续慢慢分析。。。

说这么多,主要是为了表达Kubernetes 项目并没有像其他项目那样,为每一个管理功能创建一个指令,然后在项目中实现其中的逻辑。 相比之下,在 Kubernetes 项目中,我们所推崇的使用方法是: 1、首先,通过一个“编排对象”,比如 Pod、Job、CronJob 等,来描述你试图管理的应用; 2、然后,再为它定义一些“服务对象”,比如 Service、Secret、Horizontal Pod Autoscaler(自 动水平扩展器)等。这些对象,会负责具体的平台级功能。 这种使用方法,就是所谓的“声明式 API”。这种 API 对应的“编排对象”和“服务对象”,都是Kubernetes 项目中的 API 对象(API Object)。

这就是 Kubernetes 最核心的设计理念。

今天的内容就先到这里了。

相关文章

网友评论

快盘下载暂未开通留言功能。

关于我们| 广告联络| 联系我们| 网站帮助| 免责声明| 软件发布

Copyright 2019-2029 【快快下载吧】 版权所有 快快下载吧 | 豫ICP备10006759号公安备案:41010502004165

声明: 快快下载吧上的所有软件和资料来源于互联网,仅供学习和研究使用,请测试后自行销毁,如有侵犯你版权的,请来信指出,本站将立即改正。