在“Kubernetes是一辆自卸车”中,我谈到了一种工具,它可以很好地解决其设计要解决的问题,一旦您学会了如何使用它。在本系列的第2部分中,我将更深入地了解Kubernetes的学习曲线。
通往Kubernetes的旅程通常始于在一台主机上运行一个容器。您很快就会发现运行新版本的软件有多容易,与他人共享该软件有多容易,以及那些用户按您期望的方式运行它有多容易。
但是那你需要
使用容器在端口80上启动一个Web服务器很容易,但是当您需要在端口80上启动另一个容器时会发生什么呢?当您构建生产环境并且需要容器化的Web服务器故障转移到第二台主机时会发生什么?不管是哪种情况,最简单的答案是您必须进入容器编排。
不可避免地,当您开始处理两个容器或两个主机的问题时,您将引入复杂性,并因此而获得学习曲线。两个服务(一个更通用的容器版本)/两个主机的问题已经存在了很长时间,并且总是引入了复杂性。
从历史上看,这将涉及负载平衡器,集群软件,甚至集群文件系统。每个服务的配置逻辑都嵌入每个系统(负载平衡器,群集软件和文件系统)中。在负载均衡器后面运行60或70个群集的服务非常复杂。添加另一项新服务也很复杂。更糟糕的是,停止服务是一场噩梦。回想我对生产和生产MySQL和Apache服务器进行故障排除的日子,它们的逻辑分别嵌入在三个,四个或五个不同的位置,并且格式各异,这仍然让我很头疼。
Kubernetes用一款软件优雅地解决了所有这些问题:
等等,看起来Kubernetes是非常优雅而强大的,它确实是的。您可以在Kubernetes中为整个微型IT领域建模。
因此,在开始使用巨型自卸车(或任何专业设备)时需要学习。使用Kubernetes也有一条学习曲线,但这是值得的,因为您可以使用一种工具解决这么多问题。如果您对学习曲线感到不安,请仔细考虑一下IT基础架构中所有潜在的网络,存储和安全问题,并设想当今的解决方案,这并不容易。特别是当您引入越来越多的服务时,速度越来越快。速度是当今的目标,因此应特别考虑供应和取消供应问题。
但是不要将学习曲线用于构建或装备Kubernetes(为自卸车挑选合适的挡泥板可能很困难,大声笑)与使用它的学习曲线相混淆。学习在这么多不同的层次(容器引擎,日志记录,监视,服务网格,存储,网络)上拥有如此多的不同选择来构建自己的Kubernetes,然后每六个月维护每个组件的更新选择,可能不值得投资—但是学会使用它绝对值得。
我每天都在吃饭,睡觉和呼吸Kubernetes和容器,甚至我也几乎每天都在努力跟踪所有宣布的重大新项目。但是,没有一天,我对使用单个工具为整个IT miniverse建模的操作优势感到兴奋。另外,请记住,Kubernetes已经成熟了很多,并将继续这样做。像之前的Linux和OpenStack一样,每一层的接口和事实上的项目都将成熟并变得更容易选择。
在本系列的第三篇文章中,我将深入探讨在驾驶Kubernetes“卡车”之前您需要了解的知识。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。