Kubernetes 真的很难吗?
【CSDN 编者按】Kubernetes 提供了许多开箱即用的好东西,可以推进业务的发展。但这是否意味着,所有服务都要放到 Kubernetes 上运行?当然不是。
原文链接:https://rcwz.pl/2023-03-26-kubernetes-is-hard/
未经授权,禁止转载!
作者 | Artur Rychlewicz 译者 | 弯月
责编 | 王子彧
出品 | CSDN(ID:CSDNnews)
最近,37signals 发布了内部开发的工具 mrsk,用于简化服务的部署。但随工具一起发布的博客文章在网上引发了热议。
Kubernetes 很难吗?
许多人认为 Kubernetes 很复杂,从某种程度上,我认同他们的看法。
Kubernetes 的复杂性部分源于功能的多样化,几乎可以在 Kubernetes 上运行任何工作负载。功能的多样化需要资源可组合。这些资源必须像乐高积木一样,用户可以将多个组件连接起来构建有意义的产品。以容器为例,Kubernetes 有一个 Pod 的概念,指的是一组紧密耦合的一个或多个容器。但即便使用 Pod,你也不太可能单独运行它们。通常,你会通过部署、进程集或状态集来运行 Pod。这些只是在向外界公开服务之前需要涉及的组件。
但这仅仅是其中一个方面,任何生产级别的 Kubernetes 集群都包含了许多 Kubernetes 本来不需要的组件。当然,你可以构建一个最低限度的 Kubernetes 集群,但没必要。
构建生产环境很难
在构建服务时,最不希望看到的情况之一便是让用户失望。比如提供的服务不可靠。可能你的服务不需要一直运行,甚至不需要以 99.999% 的正常运行时间为目标,但停机次数太多,用户就无法信任服务。比如用户将图片上传到服务,一天后却发现图片不见了?
服务无法提供出色体验的原因很多,比如新推出了一款新产品,因新用户注册太多,服务不堪重负。换一个角度看,这是一个好现象。但更多的时候,是因为服务存在导致应用程序崩溃的错误。
因此,我们可以认为:构建生产环境很难。需要管理应用程序、日志、指标、存储、数据库、备份、负载均衡、部署、机密数据以及许多其他的方面。如果你使用了微服务,那么工作量更大。
无论是否使用 Kubernetes,这些工作都要完成。有了云,只要花一些钱就能省却很多工作,如果你愿意花钱,而且愿意接受被供应商锁定的风险,就可以大幅简化构建生产环境的工作。在 Kubernetes 出现之前,我们就采用了这种方式,而且事实证明没有任何问题。
姑且抛开炒作不谈,Kubernetes 被这么多公司采用是有原因的。它可以减轻开发团队的负担,只要编写一个简单的 YAML 文件就可以完成服务的部署。更重要的是,团队不再需要开发运维或基础设施工作人员添加 DNS 条目并创建负载均衡器来公开服务。如果你有操作员,他们可以以声明的方式完成这些工作。
必须使用 Kubernetes 吗?
如果使用 Kubernetes,维护集群的“负担”就落到了开发运维或基础设施工作人员的肩上。Kubernetes 适合每一家公司吗?不一定,如果你有三个微服务,或者公司达到一定规模,或许应该采用 Kubernetes。但如果实际情况很简单,采用 Kubernetes 的成本太高。
采用 Kubernetes 意味着拥有统一的开发体验,可以根据公司的成长进行调整。在有需要的时候,混合搭配使用,创建强大的自动化。还有自动扩展,如何按照正确的方式自动扩展服务?应该采用水平扩展,还是垂直扩展?服务应该通过开放连接进行扩展吗?也许你根本不需要自动扩展。
我喜欢 Kubernetes。非常喜欢。但无论遇到何种情况,我都会使用 Kubernetes 吗?不会,我会根据每家公司的实际情况综合考虑。Kubernetes 提供了许多开箱即用的好东西,可以推进业务的发展。但这是否意味着,所有服务都要放到 Kubernetes 上运行?当然不是。
本文文字及图片出自 CSDN
你也许感兴趣的:
- 【外评】为什么以及何时需要使用 Kubernetes?
- 【译文】用 Kubernetes 值得吗?
- Kubernetes 开源9年,但我们已经有了 8 年的踩坑血泪史
- 为什么大型工程团队要在 Kubernetes 上进行测试?
- WebAssembly 真能取代 Kubernetes?
- 是否应该在 Kubernetes 上运行数据库?
- 人手一套的 K8S 命令集合,它来了!
- Kubernetes 之父:他们现在在哪里?
- 必看:Kubernetes 开发环境对比
- 既然有了Docker, 为什么还要Kubernetes ?
你对本文的反应是: