5

采用 Kubernetes?这里有一些你应该避免的陷阱

 1 year ago
source link: https://www.51cto.com/article/743266.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

采用 Kubernetes?这里有一些你应该避免的陷阱

作者:科技狠活与软件技术 2022-12-27 14:52:31
你认为你了解 K8s 吗?多学一点总是明智的——尤其是当这样做可以使你的理解与情境相关时。

了解使用工具的方式是善用它的关键,这个概念不仅仅适用于您的周末爱好项目。就像 Kubernetes 这样的 DevOps 要素一样,艺术家最喜欢的画笔或木工的车床也是如此——培养对系统的透彻理解可以提高您的工作效率。

...或者至少应该如此。许多开发人员几乎没有足够的时间来学习他们喜欢的工具包的基础知识,更不用说深入研究使它们具有企业价值的复杂性了。事实上,掌握 Kubernetes 并非易事。虽然它的复杂性对于这样一个强大的工具来说并不过分,但它往往会与那些试图找到立足点的人背道而驰。

这正是我们创建2022 Kubernetes 基准研究的原因。随着采用率以健康的速度增长,越来越多的团队正在利用云原生工作流(但并不总能获得他们预期的结果)。因此,我和我的团队花了几个月的时间研究整个行业的 1160 多个开发团队,以对他们的 K8s 设置和实践进行基准测试。在此过程中,我们探讨了以下问题:

  • 高性能组织的 K8s 使用有什么区别?
  • 团队的结构、文化和方法如何影响其在争论 K8s 方面的成功?
  • 从表现不佳的 K8s 新手到成功的容器化大师,是否有可行的途径?
  • 是否有正确的方法来创建面向未来的 K8s 设置?

我们的研究纳入了自定义 Kubernetes 性能分数或 KPS。根据他们对我们问题的回答和广泛的数据点,我们授予组织 KPS,范围从 0(低绩效者)到 100(高绩效者)。然后,我们将分析重点放在提供完整信息的团队上。尽管这极大地限制了受访者群体,但我们认为它描绘了当前 K8s 生态系统中更公平的使用情况。

成功需要的不仅仅是良好的意愿:容器化实施和规划能力作为绩效衡量标准

我们的工作揭示了低绩效者和高绩效者之间的许多明显区别。最令人痛心的是实施领域:超过 66% 的顶级绩效领导者将他们的所有服务容器化,而略高于 22% 的低绩效者效仿。

Kubernetes 采用的趋势相同,这意味着适应容器化是充分利用 K8s 的关键。这是完全有道理的,因为 K8s 是一个容器编排系统,但在推动成功的 K8s 迁移向前发展时,我们也听到了一些其他常见的反对意见:

  • 低估 K8s 的复杂性:高绩效者和低绩效者都经历过这一点,两组之间的差异很小。因此,在开始启动集群或购买云提供商之前,进行深入的培训可能是值得的。
  • 在采用之前有不切实际或不准确的期望:许多潜在的采用者遇到了一些问题,比如发现 K8s 很难使用——或者至少比他们想象的要难。其他人发现他们节省的钱比他们预期的要少,或者在整个过程中被云服务不兼容所绊倒。

简而言之,如果你脚踏实地,你可能会过得更好。K8s 可以解决很多问题,但前提是要有适当的规划,而且更重要的是,要愿意全面致力于容器化。

技术障碍:安全、团队管理和开发人员自助服务程度

我们发现的一件有趣的事情是,在 K8s 迁移过程中,一些常见的技术障碍反复出现。您的里程可能会有所不同,但在考虑采用时应牢记这些潜在的挑战:

实施适当的安全性比看起来更难

K8s 安全性是超过 70% 的受访者的重要话题,但这并不意味着他们都处理得当。尽管所有领导者都使用秘密管理工具,但仍有相当一部分表现不佳的人犯下了一些严重的失礼行为。例如,许多存储在其 repos 中的明文机密手动应用更改或未能分离特定于环境和环境不可知的配置。此外,有些人对什么是最佳做法缺乏清晰的认识。

不合适的组织文化可能会使 Kubernetes 迁移停止

迁移到 K8s 可能是一个巨大的文化转变。但是,与大多数此类变化一样,这些转变似乎在自上而下发生时效果更好。

899fa3976f38aa1c70b148d1c895945f78d31d.jpg

相比之下,低绩效者通常会错误地在需要知道的基础上传播 K8s 知识,引入关键个体依赖性,这些依赖性后来可能成为主要弱点。与高绩效者相比,低分者也未能准确记录和可视化他们的设置。他们还花更少的时间在 K8s 上引导开发人员。

自助服务需要更好地为开发人员服务

自助服务是另一个重要的划分因素。尽管近 90% 的表现最好的人声称他们的开发人员可以独立或按需部署,但只有 39% 的表现不佳的人这样说。

763311327ffe08a2d637925aa2a8b1d0e711a2.jpg

令人担忧的是,超过 31% 的低绩效者认为他们的大多数团队成员都不敢部署到 K8s 集群,因为害怕破坏某些东西!从组织的角度来看,这并不是一个好兆头,但与其他领域相比,它给容器化操作带来了更多的潜在问题。取决于人力资源瓶颈的集中式工作流程抵消了容器化的一些主要优势,例如能够自主工作和快速配置基础设施。

那么团队如何着手提高他们的 K8s 性能呢?我们发现,大多数成功的推出都存在于由平台工程团队构建的更大的内部开发人员平台(IDP) 框架内。换句话说,高绩效者构建工具、支持系统和基础设施,使他们的开发人员能够有效地自助服务。

这应该不足为奇;我们的 2022 年基准报告并不是第一个将 DevOps 熟练程度与具有自助服务能力的内部平台相关联的研究(例如,查看Puppet 的 2021 年 DevOps 状态报告或Humanitec 的 2021 年 DevOps 基准研究)。

同时,我们不能不指出有效的开发者生态系统必须追求整体理想。有效的 IDP 默认执行标准化和最佳实践。在此过程中,他们让开发人员与 K8s 交互,同时避免其不可否认的复杂性的陷阱。通过这种方式,他们可以最大限度地减少开发团队的认知负担,让他们能够专注于重要的事情。

通过学习更多来展现你最好的一面

K8s 是一个复杂但功能强大的系统,可以改善您团队的运营。问题是您是否准备好付出必要的努力来掌握它——并在采取这些关键的第一步之前为成功的迁移之旅构建框架。

在更广泛的方案中,Kubernetes 只是一个起点。它本身不能充当您的整个开发人员平台,但可以为您的平台工程计划打下坚实的基础。

责任编辑:华轩 来源: 今日头条

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK