Kubernetes 是否协助处明智能化应战

当我在 2002 年驳回 Gentoo Linux 作为我的关键操作系统时，我开局了我的智能化之旅。二十年后，智能化还没有成功。当我与客户和协作同伴会面时，他们分享了团队外部的智能化成绩，但他们也形容了在组织层面成功相似成功所面临的应战。

大少数 IT 组织都能够端到端地提供虚构机，从而将过去 4 周的交付周期缩短到仅 5 分钟。这种级别的智能化自身就是一个复杂的上班流程，须要网络（IP 地址治理、DNS、代理、网络区域等）、身份访问治理、​ ​虚构机治理程序​ ​、存储、备份、降级操作系统、运行最新的性能文件、监控、安保和强化以及合规性基准测试，等等。哇，这么多！

满足高速、可裁减和按需智能化的业务需求并不容易。例如，来看看经典的网上商店或提交征税申报表的在线政府服务，其上班负载有明白的峰值须要面对。

处置此类负载的一种经常出现方法是领有一个超大的主机集群，以供 IT 专业人员的特定团队经常使用，监控客户或公民的节令性涌入。每团体都宿愿及时部署整个栈。他们宿愿基础架构在混合云场景的高低文中运转上班负载，经常使用“构建-消耗-回收build-consume-trash”模型来优化老本，同时从有限弹性中受益。

换句话说，每团体都想要乌托邦式的“云体验”。

云真的能交付吗？

尚有一线时机，这关键归功于​ ​Kubernetes​ ​的设计形式。Kubernetes 的指数级遍及推进了翻新，取代了治理平台和运行的规范传统做法。 Kubernetes 须要经常使用 “万物皆代码Everything-as-Code”（EaC）来定义从繁难的计算节点到 TLS 证书的一切资源的希冀形态。Kubernetes 强迫经常使用三种关键的设计结构：

这三个关键组成局部基本上是选用智能化平台的相反要求，至少假设你想让跨职能团队轻松驳回是这样的。这也含糊了团队之间的职责分工，有助于提高超过孤岛的协作，这是一件善报！

理想上，驳回 Kubernetes 的客户和协作同伴正在减速进入超智能化形态。Kubernetes 无机地推进团队驳回多种​ ​DevOps 基础和通常​ ​​，如：EaC、​ ​经常使用 Git 启动版本控制​ ​​、同行评审、​ ​文档即代码​ ​Documentation as Code，并激励跨职能协作。这些通常有助于提高团队的智能化技艺，并协助团队在处置运行生命周期和基础架构的 GitOps 和 CI/CD 管道方面取得良好的开局。

让智能化成为理想

你没看错！网络商店或政府报告等复杂系统的整个栈可以用明晰、可了解、通用的术语定义，可以在任何本地或云提供商上口头。可以定义具备自定义目的的智能伸缩器以触发所需栈的即时部署，以处置节令性高峰时期客户或市民的涌入疑问。当目的复原反常，且云计算资源不再有存在的理由时，你将它们回收并复原惯例运营，而由一组外围资产在本地接收业务，直到下一次性激增。

鸡和蛋的悖论

思考到 Kubernetes 和云原生形式，智能化是必定的。但它提出了一个关键的疑问：一个组织可以在处明智能化策略之前驳回 Kubernetes 吗？

仿佛从 Kubernetes 开局可以激起更好的智能化，但这并不是一个原封不动的论断。工具不是对技艺、通常和文明疑问的处置打算。但是，设计良好的平台可以成为 IT 组织内学习、改革和跨职能协作的催化剂。

开局经常使用 Kubernetes

即使你感觉自己错过了智能化列车，也不要惧怕从繁难、不复杂的栈上开局经常使用 Kubernetes。当你​ ​把握了初始步骤​ ​，就可以拥抱这个杰出的编排系统的繁难性，并依据更复杂的需求启动迭代。