为什么所有人都想要使用Kubernetes?


说实话,我是一个Kubernetes爱好者。Kubernetes可以说是软件开发领域迈出的一大步。当我知道Kubernetes的时候,我就想这才是在生产环境使用容器的正确之道。我没有任何迟疑就接受了Kubernetes。像我这样的,还有数以千计的架构师已经成功拥抱了这一技术。

首先让我们了解一下Kubernetes是如何解决在大多数在云端部署应用时碰到的问题,它是如何支持我们的基础设施向云端迁移。

牢记你的目标

在万物云化的时代,对于所有公司都有一些共同的目标。

以下一些目标一般都会具有高优先级:
  • 尽快迁移到云上(云端迁移)
  • 减少系统管理的成本,基础设施的成本,人力成本(成本缩减)
  • 减少完成项目所需的时间(尽快面向市场)
  • 系统高性能、高可用(质量提升)


牢记这些目标,我们就能迈上云端,然后思索下一步的动作。

我们为什么需要容器?

在我们思考为什么需要Kubernetes之前,我们需要先问自己,为什么我们需要容器?容器在软件开发的历史上是一次巨大的变革,因为它将生产环境带入到每个开发者的本地环境中,我们不再需要担心Linux和Windows的兼容问题。通过使用容器,我们可以在任何工作站上轻易地重现出任何问题。并且,我们也能轻易地将容器迁移到任何一个平台上,不需要做任何其他多余的操作。在容器出现之前,开发者就懂得把应用程序打包进行发布,因为他们知道应用程序如何能够正常运行,比如你可以将依赖组件和应用一起打包。站在DevOps的角度,容器非常优雅,因为每个发布系统只需要处理一件事物,那就是容器。不仅如此,所有的容器构建过程可以由开发者通过Dockerfile来描述,这意味着无论在本地开发环境还是持续集成环境,你都使用同样的方法来构建应用。

容器意味着维护的事项更少,屏蔽环境的细节做到无差异化,那么也就会有更少的错误。

我们能够把容器的镜像推送到Registry。通过Registry,我们在任何地方都能下载、部署,无论是笔记本电脑还是虚拟机(本地或者云端)甚至是Serverless的场景,比如Heroku。相较于虚拟机,容器真正的优势在于它虚拟了操作系统你那个而不是外部资源。这样更高级别的抽象使得我们拥有一种更轻量级、更简单也更经济的方式来部署应用。

为什么需要Kubernetes?

在之前的一节中我们解释了为什么大家都会使用容器,但并没有提及我们为什么需要Kubernetes。不管怎么说,我们已经接受了容器这个事物。这带来了一个新的需求,我们如何管理容器?我们如何可靠地编排容器?我们的答案是Kubernetes!

拥有了Kubernetes,你所需要做的事就是将镜像推送到Registry,然后等待Kubernetes来完成剩余的工作。所有部署环节的任务都由Kubernetes来管理,我们根本无需去担心基础设施。

Kubernetes是业界领先的容器编排解决方案。它是在Google对容器的实践中逐渐开发完善的,同时也是开源的。它的架构允许容器编排,也允许与旧的系统集成。这意味着你能在本地安装Kubernetes,也可以在云端安装、使用,甚至允许你是用混合云的架构。

所以,我们之所以会使用Kubernetes,是因为它的稳定性、可靠性和易用性。简单来说,Kubernetes是部署容器的最佳方式。

Kubernetes是Serverless吗?

Kubernetes是不是Serverless?我认为Kubernetes和Serverless是两个不同领域的词。Serverless更多是一种哲学,而Kubernetes则是一个具体的工具。让我们暂且先回顾一下我们最初的目标,我们说我们需要减少对操作系统的依赖以及减少维护它的成本,而这就是Serverless。

那么问题就变成了,Kubernetes是否让我们实现了这个目标呢?简单来说,是的。

Serverless的严格定义是,我们不需要关心到底是什么应用容器、什么系统、什么硬件在运行我的代码,甚至我都不知道它位于世界的哪个角落。虽然Kubernetes确实向开发者隐藏了诸多的复杂性,但我们确实还是需要了解服务器的相关部分,比如,你仍然依赖于某个特定的容器提供的操作系统。同时,你也依赖于某个特定版本的Kubernetes。这意味着,理论上来说Kubernetes并不算Serverless。

接着,让我们来看几个Serverless的解决方案。

Heroku Runtime的底层是依赖于容器,当然你也可以在Heroku上直接部署自己的容器。大部分的Lambda函数都是运行在容器中。

这就是为什么我们认为部署在云端的Kubernetes不是Serverless,因为它是基于容器的,并且还依赖于操作系统。然而,同样依赖于容器的Heroku Runtime或是Lambda计算服务却被认为是Serverless。

所以我仍然认为Kubernetes是一种Serverless的解决方案,即使它不满足严格的定义。这个世界并不是非黑即白的,云端版本的Kubernetes提供的抽象程度(如屏蔽了操作系统以及底层资源)对我来说已经足够了。

我不希望在这里咬文嚼字。除开我们是否要给Kubernetes贴上Serverless这个标签的问题,Kubernetes确实能够让我们迅速上云,是减少系统管理成本、基础设施维护成本,提高业务质量的一大利器。所以我们实际上无须去关心那些标签,黑猫白猫抓到老鼠就是好猫。

Kubernetes的优势

Kubernetes是一个非常优秀的平台,使我们能够脱下传统虚拟机的戎装去拥抱云。它带来活力,减少系统管理成本,并且将服务的质量推上一个新的高度,在Kubernetes诞生之前我们很难做到这一步。许多传统的问题比如网络,数据保护等在Kubernetes中都能够通过高级配置来实现。

以下是Kubernetes带来的一些优势:
  • 可扩展性:你只需要部署一个容器,就能够毫无障碍地设置扩容策略。然后,你只需要保证你的账户里有足够的余额就行了。
  • 透明化:每个容器只完成一项工作。容器之间的关系被映射成配置文件,不需要担心遗漏什么,当然细节也无法被隐藏。
  • 节约时间:流程非常简单,所有的步骤都能够被重复。
  • 版本控制:从设计上来看,每一次部署都被版本化。当然,稍微花点时间,你也可以将配置文件用Git管理起来。


与其他方式相比,Kubernetes简化了所有开发运维的事项,将开发者带入到一个几乎不需要运维的理想状态。开发团队和运维团队之间的摩擦也减少了,因为原本两者职责的模糊地带现在也划清了界线,系统本身也保持了相当的透明度。

其他的一些优点列举如下:
  • 水平扩展:Kubernetes本身能够自动扩展,支持在集群中增加节点或者调整可用的物理资源。同时,他也能扩展逻辑资源,如调整一个服务的Pod数目。
  • 智能升级:每次你升级容器镜像的时候,升级的过程是平滑的。旧的Pod会一直保持可用的状态直到新的Pod启动完成才会被销毁。这就是我们常说的零宕机部署。
  • 支持本地搭建或是云端服务:使用使用云以外还有别的选择吗?当然!我总是偏好完全云端的解决方案,当然在一些场景下,可能也需要在本地环境或者机房部署,当然Kubernetes也能够完美支持。
  • 远离厂商捆绑:Kubernetes在每个通过认证的公有云平台具有一致性。如果你对你的服务商不满,你只需要花费少量的时间就可以更换厂商。
  • 对开发者没有额外的成本:任何已经被容器化的软件都能一键部署。开发团队不需要学习额外的知识。


我们到底如何选择?

Kubernetes的灵活性很强,利用云端的方案,你可以轻松地管理Kubernetes集群。当我了解到Kubernetes的时候,我就认为它是一个可行的、安全的方案,能够有效减少开发者的负担。它具备所有传统基础设施的优势,同时让我们在不重构应用的同时,享受不需要运行维护的便利。和很多其他看上去闪闪发亮的解决方案(如Serverless)相比,Kubernetes更加实在。Serverless确实很不错,但是很多复杂的场景,它并不能很自如地应付。并且从逻辑上来看,全盘接受像Lambda这样前沿的技术需要一个巨大的思维转变。对于运维团队来说,这样的改变并不容易。

如今,减少系统管理的工作量,拥有能够易于部署、能够简化运维核心痛点的基础设施对大部分团队来说都是核心需求。而Kubernetes满足这所有的需求。

如果让我现在去设计一套架构,尤其是面向企业的解决方案,我会首选容器技术和Kubernetes。或许我会选择云服务商提供的Kubernetes来减少运维成本。我也有可能会用Git来管理DevOps流水线相关的配置。

这个方案对操作系统的依赖很少,对云厂商的依赖也很少,所有的基础设施及其配置都依赖于代码。

有人会说,这个方案并不完全摆脱了运维,也不完全摆脱了服务器。但Kubernetes具有稳定、模块化、可伸缩的特性,能够满足最重要的架构设计目标。所以我们为什么不用Kubernetes呢?

那我们能不能做得更好?毫无疑问。我们能努力摆脱更多的负担吗?当然可以。我们当然能百尺竿头更进一步。然而,仰望星空也要脚踏实地,我们必须要承认Kubernetes是一个极佳的折中方案:在大部分案例中,Kubernetes是成功的保障。

原文链接:Why Does Everybody Want to Use Kubernetes?(翻译:小灰灰)

0 个评论

要回复文章请先登录注册