程序员修神之路–Kubernetes是微服务发展的必然产物

程序员修神之路--Kubernetes是微服务发展的必然产物

程序员修神之路--Kubernetes是微服务发展的必然产物

程序员修神之路--Kubernetes是微服务发展的必然产物

kubernetes介绍

在许多项目的早期开发中,它们是小型或大型的单个项目,部署在单个或多个服务器上,并在单个过程中运行。随着对这些项目需求的增加,发布周期逐渐增加,迭代速度显著降低。传统的发布方法是:开发人员打包项目并将其发送部署和分配资源的操作和维护人员。

随着软件行业架构的变化,这些大型的单个应用程序逐渐分解成可以根据业务或其他维度独立运行的组件,我们称之为微服务。微服务是独立开发、部署、升级和扩展的,以真正分离大规模应用。

软件开发行业是如此美妙的工作。每个问题在解决后总是伴随着另一个问题,就像程序员改变错误一样。为什么总是有不能完全改变的错误?它真的很大!

程序员修神之路--Kubernetes是微服务发展的必然产物

microservice已经解决了一些问题,但是随着microservice数量的增加,实现配置、管理、扩展、高可用性等要求变得越来越困难。包括运营和维护团队如何更好地利用硬件资源并降低服务器成本,以及部署和故障处理的自动化变得越来越困难。

上述问题正是库本内斯想要解决并擅长的领域。它允许开发人员独立部署应用程序,独立控制迭代频率,并完全解放操作和维护团队。运营和维护团队的重点已经从以前的服务器资源管理转移到kubernetes的资源管理。Kubernetes最大的优势在于它封装和抽象了硬件基础设施,因此开发人员不需要理解硬件的基本原理,也不需要关注底层服务器。Kubernetes将集合服务器抽象成资源池。部署应用程序时,Kubernetes会自动为应用程序分配适当合理的服务器资源,并确保这些应用程序能够正常与其他应用程序通信。kubernetes集群的总体结构如下:

程序员修神之路--Kubernetes是微服务发展的必然产物

程序员修神之路--Kubernetes是微服务发展的必然产物

kubernetes优势

micro services是好的,但是当数量很大时,就会出现数量问题。随着系统组件的不断增长,这些组件的管理问题逐渐浮出水面。首先,我们应该理解kuber nes是一个软件系统,它依赖于linux容器的特性来管理组件(kuber nes和容器不是一个概念,请不要混淆它们)。无论您集群在通过kubernes部署应用程序时包含多少节点,kubernes都没有区别。这完全是由于它对底层基础设施设置抽象,这使得几个节点在运行时表现得像一个节点。

自动扩容

在kubernetes系统中,它可以实时监控每个应用程序,并根据策略对突发流量做出响应。例如,kubernetes可以根据高峰流量期间每个节点的资源利用率自动添加节点或减少节点操作,这在以前的传统应用程序部署模式中并不容易做到。

简化部署流程

发布传统应用程序时,开发人员需要打包项目,检查项目的配置文件是否正确,然后将其发送给操作和维护人员,他们随后备份在线应用程序版本,然后停止服务进行更新。在kubernetes中,我们可以只使用一条指令将应用程序升级到最新版本,或者在大多数情况下单击一个按钮,并且我们可以在升级过程中不间断地提供服务。当然,整个过程也涉及容器的操作,所以我们在这里不会介绍太多。

但是这里有一个意想不到的情况。如果库本内斯集群中有具有不同CPU架构的服务器,并且您的应用程序是具有特定CPU架构的软件,则在部署传统应用程序时,您可能需要在库本内斯中指定一个节点来运行您的应用程序

提高服务器资源的利用率

在大多数情况下,一定比例的资源将始终被保留作为资源的缓冲,以应对流量高峰。很少有人将单台服务器的资源利用率提高到90%以上。从服务器故障的概率来看,服务器资源的利用率远远高于50%。此外,一旦服务器fai

Kubernetes对集群的管理将应用程序与基础设施分开,因为它抽象了底层硬件设施。当您告诉kubernetes运行您的应用程序时,它将根据程序的资源需求和集群中每个节点的可用资源选择适当的节点来运行。此外,通过容器技术,应用程序可以随时迁移到群集中的任何机器上。就服务器的最佳组合而言,kubernetes优于手工操作。它将根据集群中每台服务器的负载将硬件利用率提高到最高。

自动修复

在传统的应用程序架构中,如果一台服务器出现故障,该服务器上的应用程序将全部关闭,这在大多数情况下需要操作和维护人员来处理。这也是操作和维护人员需要全天候待命的一个重要原因。我相信你也看到了维修人员因为半夜的故障而被责骂的情况。

在kubernetes中,它监控和管理所有节点和应用程序。当一个节点出现故障时,kubernetes可以自动将该节点上的应用程序迁移到其他健康节点,并将故障节点从资源池中移除。如果kubernetes集群基础设施有足够的备用资源来支持系统的正常运行,操作和维护人员可以在处理故障之前延迟到正常工作时间,从而允许程序员和操作和维护人员在965工作。程序员修神之路--Kubernetes是微服务发展的必然产物

这有点像演员模型的设计理论,它提倡让它崩溃的原则。

一致的运行环境

无论你是开发人员还是操作维护人员,在传统的部署方案中,总是存在操作环境差异的麻烦。这种差异的范围从每台服务器的差异到开发环境、仿真环境和生产环境,每种环境中的服务器都会随着时间的推移而变化。我相信您一定遇到过开发环境程序正常运行但生产环境异常的情况。

这种差异不仅仅是因为生产环境由运营和维护团队管理,开发环境由开发人员管理。更要的是,这两组对系统有不同的要求。操作和维护团队将定期修补在线生产环境,并执行安全监控和其他操作,而开发人员可能根本不会抓住这些问题不放。此外,应用系统所依赖的第三方库在开发、模拟和生产环境中可能有不同的版本。反正我也遇到过这样的问题。

和kubernetes所使用的容器技术,当应用程序打包时,运行环境也一起放入包中,这确保了相同版本的容器包(mirror)在任何服务器

程序员修神之路--Kubernetes是微服务发展的必然产物

kubernetes上都有相同的运行环境,这就要求开发人员对容器技术和网络知识有一定的了解,所以是否使用kubernetes取决于团队的综合技能和项目,而不是所有项目都有利于使用kubernetes。

 

极牛网精选文章《程序员修神之路–Kubernetes是微服务发展的必然产物》文中所述为作者独立观点,不代表极牛网立场。如若转载请注明出处:https://geeknb.com/4137.html

(0)
打赏 微信公众号 微信公众号 微信小程序 微信小程序
主编的头像主编认证作者
上一篇 2019年11月26日 上午9:20
下一篇 2019年11月26日 上午9:26

相关推荐

发表回复

登录后才能评论
扫码关注
扫码关注
分享本页
返回顶部