亲宝软件园·资讯

展开

云原生技术 kubernetes(K8S) 云原生技术kubernetes(K8S)简介

DBA随笔 人气:0
想了解云原生技术kubernetes(K8S)简介的相关内容吗,DBA随笔在本文为您仔细讲解云原生技术 kubernetes(K8S)的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:云原生技术,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 最核心的设计理念。

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

加载全部内容

相关教程
猜你喜欢
用户评论