组织层面的自动化一直是一个难以捉摸的目标，但 Kubernetes 可能能够改变这一切。

2002 年，当 CTO 技术共享采用 Gentoo Linux 作为主要操作系统时，CTO 技术共享开始了自动化之旅。20 年后，自动化还没有完成。当笔者与客户和合作伙伴会面时，他们分享自动化的胜利，同时也描述在组织层面实现类似成功的挑战。

大多数 IT 组织都能够端到端地调配虚拟机，将过去四周的交付周期缩短到五分钟。这一自动化级别本身就是一个复杂的工作流，需要联网（IP 地址管理、DNS、代理、联网区域等）、身份访问管理、虚拟机监控程序、存储、备份、更新操作系统、应用最新配置文件、监控、安全和强化以及合规性基准测试。

要满足高速、可扩展和按需自动化的业务需求并不容易。例如，考虑一下经典的网上商店或在线政府服务来提交纳税申报表。工作负载有明确定义的峰值，需要吸收。

处理此类负载的一种常见方法是拥有一个超大的服务器场，供专门的 IT 专业团队使用，监控季节性的客户或市民涌入。每个人都希望及时部署整个堆栈。他们希望基础设施在混合云场景中运行工作负载，使用“构建—消耗—垃圾”模型优化成本，同时受益于无限弹性。

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

云真的能交付吗？

归功于 Kubernetes 的设计方式，一切还有希望。Kubernetes 的迅速采用推动了创新，取代了管理平台和应用程序的标准传统做法。Kubernetes 需要使用 Everything as Code（EaC）来定义所有资源的期望状态，从简单的计算节点到 TLS 证书。Kubernetes 强制使用三种主要设计结构：

——减少内部和外部组件之间集成摩擦的标准接口。

——标准化所有组件的 CRUD（创建、读取、更新、删除）操作的 API 优先且仅限 API 的方法。

——使用 YAML 作为通用语言，以简单易读的方式定义这些组件的所有期望状态。

这三个关键组件基本上是选择自动化平台的相同要求，至少如果你希望简化跨职能团队的采用。这也模糊了团队之间的职责划分，有助于改善跨孤岛的协作，这是一件好事！

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

实现自动化

你没看错，复杂系统（如网络商店或政府报告）的整个堆栈可以用清晰、易懂、通用的术语定义，可以在任何内部部署或云提供商上执行。可以定义一个具有自定义指标的自动标尺，以触发所需堆栈的即时部署，以解决季节性高峰期间客户或用户的涌入。当指标恢复正常，云计算资源没有理由再存在时，你可以将其丢弃并恢复正常运维，内部部署的一组核心资产将接管业务，直到下一次激增。

鸡和蛋的矛盾

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

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

开始用 Kubernetes

即使你觉得自己错过了自动化火车，也不要害怕从简单、简单的堆栈上开始 Kubernetes。接受这个奇妙的编排器的简单性，一旦掌握了最初的步骤，就可以迭代更复杂的需求。