服装 公司 网站建设,做网站外包创业,面备案网站建设,什么页游好玩人多一、Kubernetes是什么
Kubernetes是什么? 首先#xff0c;它是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新#xff0c;但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的一个重要成果。确切地说#xff0c;Kubernetes是谷歌严格保密十几年的…一、Kubernetes是什么
Kubernetes是什么? 首先它是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的一个重要成果。确切地说Kubernetes是谷歌严格保密十几年的秘密武器——Borg 的一个开源版本。Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统它基于容器技术目的是实现资源管理的自动化以及跨多个数据中心的资源利用率的最大化。十几年来谷歌一直通过Borg系统管理着数量庞大的应用程序集群。由于谷歌员工都签署了保密协议即便离职也不能泄露Borg的内部设计所以外界一直无法了解关于它的更多信息。直到2015 年4月传闻许久的Borg 论文伴随Kubernetes的高调宣传被谷歌首次公开大家才得以了解它的更多内幕。正是由于站在Borg这个前辈的肩膀上吸取了Borg过去十年间的经验与教训所以Kubermetes 一经开源就一鸣惊人并迅速称霸了容器技术领域。 其次如果我们的系统设计遵循了Kubermetes的设计思想那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块都可以立刻从我们的视线中消失我们不必再费心于负载均衡器的选型和部署实施问题不必再考虑引入或自己开发一个复杂的服务治理框架不必再头疼于服务监控和故障处理模块的开发。总之使用Kubernetes 提供的解决方案我们不仅节省了不少于30%的开发成本同时可以将精力更加集中于业务本身而且由于Kubernetes提供了强大的自动化机制所以系统后期的运维难度和运维成本大幅度降低。 然后Kubernetes 是-一个 开放的开发平台。与J2EE不同它不局限于任何一种语言没有限定任何编程接口所以不论是用Java、Go、C还是用Python编写的服务都可以毫无困难地映射为Kubernetes 的Service并通过标准的TCP通信协议进行交互。此外由于Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。 最后Kubernetes是一个完备的分布式系统支撑平台。Kubermetes具有完备的集群管理能力包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes 提供了完善的管理工具这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此Kubernetes是一个全新的基于容器技术的分布式架构解决方案并且是一个一站式的完备的分布式系统开发和支撑平台。 我们首先要学习Kubernetes 的一些基本知识 这样我们才能理解Kubernetes提供的解决方案。 在Kubernetes中Service (服务)是分布式集群架构的核心一个Service对象拥有如下关键特征。
拥有一个唯一指定的名字(比如mysql-server)。拥有一个虚拟IP (Cluster IP、 Service IP或VIP)和端口号。能够提供某种远程服务能力。被映射到了提供这种服务能力的一组容器应用上。 Service的服务进程目前都基于Socket通信方式对外提供服务比如Redis、 Memcache、MySQL、Web Server或者是实现了某个具体业务的一个特定的TCP Server 进程。虽然一个Service通常由多个相关的服务进程来提供服务每个服务进程都有一个独立的Endpoint(IPPort)访问点但Kubernetes能够让我们通过Service (虚拟Cluster IP Service Port)连接到指定的Service上。有了Kubernetes 内建的透明负载均衡和故障恢复机制,不管后端有多少服务进程也不管某个服务进程是否会由于发生故障而重新部署到其他机器都不会影响到我们对服务的正常调用。更重要的是这个Service本身一旦创建就不再变化,这意味着在Kubernetes集群中我们再也不用为了服务的IP地址变来变去的问题而头疼了。 容器提供了强大的隔离功能所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此Kubernetes设计了Pod 对象将每个服务进程包装到相应的Pod中使其成为Pod中运行的一个容器(Container)。 为了建立Service和Pod间的关联关系Kubernetes 首先给每个Pod贴上一个标签(Label),给运行MySQL的Pod贴上namemysql 标签给运行PHP的Pod贴上namephp标签然后给相应的Service 定义标签选择器(Label Selector)比如MySQLService的标签选择器的选择条件为name--mysql,意为该Service要作用于所有包含namemysqlLabel的Pod上。这样一来就巧妙地解决了Service 与Pod的关联问题。 说到Pod我们这里先简单介绍其概念。首先Pod 运行在一个我们称之为节点(Node)的环境中这个节点既可以是物理机也可以是私有云或者公有云中的一个虚拟机通常在一个节点上运行几百个Pod;其次每个Pod里运行着一个特殊的被称之为Pause的容器其他容器则为业务容器这些业务容器共享Pause容器的网络栈和Volume挂载卷因此它们之间的通信和数据交换更为高效在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中:最后需要注意的是并不是每个Pod和它里面运行的容器都能“映射”到一个Service.上只有那些提供服务(无论是对内还是对外)的一组Pod才会被“映射”成一个服务。 在集群管理方面, Kubernetes将集群中的机器划分为一个Master节点和一群工作节点(Node)。其中在Master节点上运行着集群管理相关的一组进程kube-apiserver. kube-controller-manager和kube scheduler,这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能并且都是全自动完成的。Node 作为集群中的工作节点,运行真正的应用程序在Node.上Kubernetes 管理的最小运行单元是Pod。 Node. 上运行着Kubernetes 的kubelet、kube-proxy 服务进程这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。 最后我们再来看看传统的IT 系统中服务扩容和服务升级这两个难题以及Kubernetes所提供的全新解决思路。服务的扩容涉及资源分配(选择哪个节点进行扩容)、实例部署和启动等环节在一个复杂的业务系统中这两个问题基本上靠人工一步步操作才得以完成费时费力又难以保证实施质量。 在Kubernetes集群中你只需为需要扩容的Service 关联的Pod创建-一个ReplicationController (简称RC)则该Service的扩容以至于后来的Service升级等头疼问题都迎刃而解。在一个RC定义文件中包括以下3个关键信息。
目标Pod的定义。目标Pod需要运行的副本数量(Replicas)。要监控的目 标Pod的标签(Label)。 在创建好RC (系统将自动创建好Pod)后Kubernetes 会通过RC中定义的Label 筛选出对应的Pod实例并实时监控其状态和数量如果实例数量少于定义的副本数量(Replicas), 则会根据RC中定义的Pod模板来创建一个新的Pod,然后将此Pod调度到合适的Node.上启动运行直到Pod实例的数量达到预定目标。这个过程完全是自动化的无须人工千预。有了RC服务的扩容就变成了一个纯粹的简单数字游戏了只要修改RC中的副本数量即可。后续的Service升级也将通过修改RC来自动完成。
二、为什么要用Kubernetes 使用Kubernetes的理由很多最根本的一一个理由就是: IT 从来都是一个由新技术驱动的行业。Docker这个新兴的容器化技术当前已经被很多公司所采用,其从单机走向集群已成为必然而云计算的蓬勃发展正在加速这一-进程。 Kubernetes 作为当前唯一被 业界广泛认可和看好的Docker分布式系统解决方案可以预见在未来几年内会有大量的新系统选择它不管这些系统是运行在企业本地服务器上还是被托管到公有云上。 使用了Kubernetes 又会收获哪些好处呢? 首先最直接的感受就是我们可以“轻装上阵”地开发复杂系统了。以前动不动就需要十几个人而且团队里需要不少技术达人一起分工协作才能设计实现和运维的分布式系统在采用Kubernetes解决方案之后只需一个精悍的小团队就能轻松应对。在这个团队里一名架构师专注于系统中“服务组件”的提炼几名开发工程师专注于业务代码的开发一名系统兼运维工程师负责Kubermnetes的部署和运维从此再也不用“996”了,这并不是因为我们少做了什么.而是因为Kubernetes已经帮我们做了很多。 其次使用Kubernetes就是在全面拥抱微服务架构。微服务架构的核心是将一个巨大的单体应用分解为很多小的互相连接的微服务一个微服务背后可能有多个实例副本在支撑副本的数量可能会随着系统的负荷变化而进行调整内嵌的负载均衡器在这里发挥了重要作用。微服务架构使得每个服务都可以由专门的开发团队来开发开发者可以自由选择开发技术这对于大规模团队来说很有价值另外每个微服务独立开发、升级、扩展因此系统具备很高的稳定性和快速迭代进化能力。谷歌、亚马逊、eBay、NetFlix 等众多大型互联网公司都采用了微服务架构此次谷歌更是将微服务架构的基础设施直接打包到Kubernetes解决方案中让我们有机会直接应用微服务架构解决复杂业务系统的架构问题。 然后我们的系统可以随时随地整体“搬迁”到公有云上。Kubernetes 最初的目标就是运行在谷歌自家的公有云GCE中未来会支持更多的公有云及基于OpenStack的私有云。同时在Kubernetes的架构方案中底层网络的细节完全被屏蔽,基于服务的Cluster IP甚至都无须我们改变运行期的配置文件就能将系统从物理机环境中无缝迁移到公有云中或者在服务高峰期将部分服务对应的Pod副本放入公有云中以提升系统的吞吐量,不仅节省了公司的硬件投入还大大改善了客户体验。我们所熟知的铁道部的12306 购票系统在春节高峰期就租用了阿里云进行分流。 最后Kubernetes 系统架构具备了超强的横向扩容能力。对于互联网公司来说用户规模就等价于资产谁拥有更多的用户谁就能在竞争中胜出因此超强的横向扩容能力是互联网业务系统的关键指标之一。不用修改代码一个Kubernetes 集群即可从只包含几个Node的小集群平滑扩展到拥有上百个Node的大规模集群我们利用Kubernetes提供的工具甚至可以在线完成集群扩容。只要我们的微服务设计得好结合硬件或者公有云资源的线性增加系统就能够承受大量用户并发访问所带来的巨大压力。
三、Kubernetes架构图 Kubernetes系统用于管理分布式节点集群中的微服务或容器化应用程序并且其提供了零停机时间部署、自动回滚、缩放和容器的自愈其中包括自动配置、自动重启、自动复制的高弹性基础设施以及容器的自动缩放等等功能。 Kubernetes系统最重要的设计因素之一是能够横向扩展即调整应用程序的副本数以提高可用性。设计一套大型系统且保证其运行时健壮、可扩展、可移植和非常具有挑战性尤其是在系统复杂度增加时系统的体系结构会直接影响其运行方式、对环境的依赖程度及相关组件的耦合程度。 微服务是一种软件设计模式适用于集群上的可扩展部署。开发人员使用这一模式能够创建小型、可组合的应用程序通过定义良好的HTTP REST API接口进行通信。Kubernetes也是遵循微服务架构模式的程序具有弹性、可观察性和管理功能可以适应云平台的需求。 Kubernetes的系统架构设计与Borg的系统架构设计理念非常相似如Scheduler调度器、Pod资源对象管理等。Kubernetes总架构图如图1-1所示。 Kubernetes系统架构遵循客户端/服务端C/S架构系统架构分为Master和Node两部分Master作为服务端Node作为客户端。Kubernetes系统具有多个Master服务端可以实现高可用。在默认的情况下一个Master服务端即可完成所有工作。 Master服务端也被称为主控节点它在集群中主要负责如下任务。
1集群的“大脑”负责管理所有节点Node。2负责调度Pod在哪些节点上运行。3负责控制集群运行过程中的所有状态。 Node客户端也被称为工作节点它在集群中主要负责如下任务。
1负责管理所有容器Container。2负责监控/上报所有Pod的运行状态。 Master服务端主控节点主要负责管理和控制整个Kubernetes集群对集群做出全局性决策相当于整个集群的“大脑”。集群所执行的所有控制命令都由Master服务端接收并处理。Master服务端主要包含如下组件。
kube-apiserver组件 集群的HTTP REST API接口是集群控制的入口。kube-controller-manager组件 集群中所有资源对象的自动化控制中心。kube-scheduler组件 集群中Pod资源对象的调度服务。 Node客户端工作节点是Kubernetes集群中的工作节点Node节点上的工作由Master服务端进行分配比如当某个Node节点宕机时Master节点会将其上面的工作转移到其他Node节点上。 Node节点主要包含如下组件。
kubelet组件 负责管理节点上容器的创建、删除、启停等任务与Master节点进行通信。kube-proxy组件 负责Kubernetes服务的通信及负载均衡服务。container组件 负责容器的基础管理服务接收kubelet组件的指令。
四、总结与扩展
4.1、Kubernetes的优秀特性
Kubermetes有着如下的优秀特性。
强大的容器编排能力 Kubernetes可以说是同Docker-起发展起来的 深度集成了Docker,天然适应容器的特点设计出强大的容器编排能力比如容器组合、标签选择和服务发现等可以满足企业级需求。
轻量级 Kubermetes遵循微服务架构理论整个系统划分出各个功能独立的组件组件之间边界清晰部署简单可以轻易地运行在各种系统和环境中。同时Kubermetes 中的许多功能都实现了插件化可以非常方便地进行扩展和替换。
开放开源 Kubermetes顺应了开放开源的趋势吸引了大批开发者和公司参与其中协同工作共同构建生态圈。同时Kubernetes 同OpenStack、Docker 等开源社区积极合作、共同发展企业和个人都可以参与其中并获益。
同时Kubernetes系统还具有如下特点 ●可移植支持公有云、私有云、混合云、多重云Multi-cloud。 ● 可扩展 模块化、插件化、可挂载、可组合。 ● 自动化 自动部署、自动重启、自动复制、自动伸缩/扩展。
4.2、Kubernetes和Docker Kubernetes和Docker是两个互补的技术。比如通常人们会使用Docker进行应用的开发然后用Kubernetes在生产环境中对应用进行编排。 在这样的模式中开发者使用自己喜欢的语言编写代码然后用Docker进行打包、测试和交付。但是最终在测试环境或生产环境中运行的过程是由Kubernetes来完成的。从运行架构上来说假设在某生产环境中的Kubernetes集群是由10个节点构成的。那么其中的每个节点都是以Docker作为其容器运行时Container Runtime。也就是说Docker是一种更加偏向底层的技术它负责诸如启停容器的操作而Kubernetes是一种更加偏向上层的技术它注重集群范畴的管理比如决定在哪个节点上运行容器、决定什么适合进行扩缩容或升级。 图1.2阐释了由多个以Docker为容器运行时的节点构成的Kubernetes集群。 如图1.2所示Docker并非Kubernetes唯一支持的容器运行时。事实上Kubernetes基于一系列特性实现了对容器运行时的抽象从而可以兼容不同的底层容器运行时。 1容器运行时接口Container Runtime Interface, CRI是Kubernetes用来与第三方容器运行时进行对接的标准化的抽象层。这样容器运行时与Kubernetes是解耦的同时又能够以一种标准化的方式予以支持。 2运行时类Runtime Class是Kubernetes 1.12引入的新特性并在1.14版中升级为beta。它对不同的运行时进行了归类。例如gVisor或Kata容器运行时或许比Docker和Containerd能提供更优的隔离性。 至本文撰写时Containerd已经赶超Docker成为Kubernetes中最普遍使用的容器运行时。它实际上是Docker的精简版本只保留了Kubernetes需要的部分。 虽有提及不过这些底层技术不会影响到Kubernetes的学习体验。无论使用哪种容器运行时Kubernetes层面的操作命令等都是一样的。
4.3、Kubernetes为什么叫K8s K8S由google的Borg系统(博格系统google内部使用的大规模容器编排工具)作为原型后经Go语言延用Borg的思路重写并捐献给CNCF基金会开源。 kubernetes的名字来自希腊语意思是“舵手” 或 “领航员”,K8s是将8个字母“ubernete”替换为“8”的缩写。
