云原生技术kubernetes(K8S)简介
今天我们看看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......最终,你会看到下面的一张图:
具体的内容,我们后续慢慢分析。。。
说这么多,主要是为了表达kubernetes 项目并没有像其他项目那样,为每一个管理功能创建一个指令,然后在项目中实现其中的逻辑。
相比之下,在 kubernetes 项目中,我们所推崇的使用方法是:
1、首先,通过一个“编排对象”,比如 pod、job、cronjob 等,来描述你试图管理的应用;
2、然后,再为它定义一些“服务对象”,比如 service、secret、horizontal pod autoscaler(自
动水平扩展器)等。这些对象,会负责具体的平台级功能。
这种使用方法,就是所谓的“声明式 api”。这种 api 对应的“编排对象”和“服务对象”,都是kubernetes 项目中的 api 对象(api object)。
这就是 kubernetes 最核心的设计理念。
今天的内容就先到这里了。
以上就是云原生技术kubernetes(k8s)简介的详细内容,更多关于云原生技术 kubernetes(k8s)的资料请关注其它相关文章!
上一篇: 西安钟鼓楼广场简介 西安钟鼓楼广场好玩吗
推荐阅读
-
云原生技术kubernetes(K8S)简介
-
云原生技术kubernetes调度单位pod的使用详解
-
利用K8S技术栈打造个人私有云--私有云客户端打造
-
《两地书》--Kubernetes(K8s)基础知识(docker容器技术)
-
阿里云OpenYurt最新动态:成为 CNCF 沙箱项目,加速原生 Kubernetes 边缘场景全覆盖
-
首次公开!阿里巴巴云原生实时数仓核心技术揭秘
-
阿里云高级技术专家李晓成:面向5G的云网一体及云原生应用实践
-
阿里云叔同:以容器为代表的云原生技术,已成为释放云价值的最短路径 云计算
-
PouchContainer 容器技术演进助力阿里云原生升级 阿里巴巴windows
-
系列文章:云原生Kubernetes日志落地方案 虚拟机阿里巴巴工作linuxibm