服务器之家:专注于服务器技术及软件下载分享
分类导航

云服务器|WEB服务器|FTP服务器|邮件服务器|虚拟主机|服务器安全|DNS服务器|服务器知识|Nginx|IIS|Tomcat|

服务器之家 - 服务器技术 - 服务器知识 - 云原生技术kubernetes(K8S)简介

云原生技术kubernetes(K8S)简介

2021-06-26 17:55DBA随笔 服务器知识

这篇文章主要介绍了云原生技术kubernetes的相关资料,帮助大家更好的理解和学习使用K8S,感兴趣的朋友可以了解下

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

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

01 kubernetes是什么?

 

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

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

云原生技术kubernetes(K8S)简介

    对于云厂商来说,如果能够将用户提交上来的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的请求发生。但是容器技术出现之后,各个任务都可以通过镜像的方式,封装在不同的容器中,它们之间不相互干涉,拥有各自的资源配置,也可以被集群调度在不同的机器上。如下:

云原生技术kubernetes(K8S)简介

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......最终,你会看到下面的一张图:

云原生技术kubernetes(K8S)简介

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

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

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

以上就是云原生技术kubernetes(k8s)简介的详细内容,更多关于云原生技术 kubernetes(k8s)的资料请关注服务器之家其它相关文章!

延伸 · 阅读

精彩推荐