Kubernetes 能否帮助解决自动化挑战？

云真的能交付吗？

尚有一线机会，这主要归功于 ​​Kubernetes​​ 的设计方式。Kubernetes 的指数级普及推动了创新，取代了管理平台和应用的标准传统做法。 Kubernetes 需要使用 “万物皆代码Everything-as-Code”（EaC）来定义从简单的计算节点到 TLS 证书的所有资源的期望状态。Kubernetes 强制使用三种主要的设计结构：

• 一个标准接口，以减少内部和外部组件之间的整合问题
• API 优先及仅 API 的方法来标准化其所有组件的 CRUD（创建、读取、更新、删除）操作
• 使用​​YAML​​ 作为通用语言，以简单易读的方式定义这些组件的所有所需状态

这三个关键组成部分基本上是选择自动化平台的相同要求，至少如果你想让跨职能团队轻松采用是这样的。这也模糊了团队之间的职责分工，有助于提高跨越孤岛的协作，这是一件好事！

事实上，采用 Kubernetes 的客户和合作伙伴正在加速进入超自动化状态。Kubernetes 有机地推动团队采用多种 ​​DevOps 基础和实践​​​，如：EaC、​​使用 Git 进行版本控制​​​、同行评审、​​文档即代码​​Documentation as Code，并鼓励跨职能协作。这些实践有助于提高团队的自动化技能，并帮助团队在处理应用生命周期和基础架构的 GitOps 和 CI/CD 管道方面取得良好的开端。

让自动化成为现实

你没看错！网络商店或政府报告等复杂系统的整个栈可以用清晰、可理解、通用的术语定义，可以在任何本地或云提供商上执行。可以定义具有自定义指标的自动伸缩器以触发所需栈的即时部署，以解决季节性高峰期间客户或市民的涌入问题。当指标恢复正常，且云计算资源不再有存在的理由时，你将它们回收并恢复常规运营，而由一组核心资产在本地接管业务，直到下一次激增。

鸡和蛋的悖论

考虑到 Kubernetes 和云原生模式，自动化是必须的。但它提出了一个重要的问题：一个组织可以在解决自动化战略之前采用 Kubernetes 吗？

似乎从 Kubernetes 开始可以激发更好的自动化，但这并不是一个一成不变的结论。工具不是对技能、实践和文化问题的解决方案。但是，设计良好的平台可以成为 IT 组织内学习、变革和跨职能协作的催化剂。

开始使用 Kubernetes

即使你觉得自己错过了自动化列车，也不要害怕从简单、不复杂的栈上开始使用 Kubernetes。当你 ​​掌握了初始步骤​​，就可以拥抱这个出色的编排系统的简单性，并根据更复杂的需求进行迭代。