当我在2002年采用GentooLinux作为我的主要操作系统时，我开始了我的自动化之旅。二十年后，自动化还没有完成。当我与客户和合作伙伴会面时，他们在团队中分享了自动化的成功，但他们也描述了在组织层面实现类似成功所面临的挑战。大多数IT组织都能够端到端地供应虚拟机，将过去4周的交付时间缩短到仅5分钟。这一级别的自动化本身就是一个复杂的工作流程，需要网络（IP地址管理、DNS、代理、网络区域等）、身份访问管理、管理程序、存储、备份、更新操作系统、应用最新的配置文件、监控、安全和强化、合规性基准测试等。哇，这么多！满足对高速、可扩展性和按需自动化的业务需求并不容易。例如，看看一家经典的在线商店或提交纳税申报表的在线政府服务，它们的工作量有明确的峰值需要应对。处理此类负载的一种常见方法是拥有一个非常大的服务器集群，由特定的IT专业人员团队使用，监控客户或市民的季节性涌入。每个人都希望及时部署整个堆栈。他们希望基础架构在混合云场景的上下文中运行工作负载，使用构建-消费-垃圾模型来优化成本，同时受益于无限弹性。换句话说，每个人都想要一种乌托邦式的“云体验”。云真的可以交付吗？有一线希望，主要是由于Kubernetes的设计方式。Kubernetes的指数级采用推动了创新，取代了管理平台和应用程序的标准遗留实践。Kubernetes需要使用“一切即代码”(EaC)来定义从简单的计算节点到TLS证书的一切事物的理想状态。Kubernetes强制执行三个主要设计结构：一个标准接口以减少内部和外部组件之间的集成问题一个API优先和仅API的方法来标准化跨所有组件的CRUD（创建、读取、更新、删除）操作使用YAML作为通用以简单易读的方式定义这些组件的所有所需状态的语言。这三个关键组件与选择自动化平台的要求基本相同，至少如果您希望跨职能团队轻松采用是这样的。这也模糊了团队之间的职责划分，有助于改善孤岛之间的协作，这是一件好事！事实上，采用Kubernetes的客户和合作伙伴正在加速进入超级自动化。Kubernetes有机地推动团队采用多种DevOps基础和实践，例如：EaC、Git版本控制、同行评审、文档即代码，并鼓励跨职能协作。这些实践有助于提高您团队的自动化技能，并让您的团队在处理应用程序生命周期和基础架构的GitOps和CI/CD管道方面抢占先机。让自动化成为现实您没有看错！复杂系统（如网上商店或政府报告）的整个堆栈可以用清晰、易于理解的通用术语定义，并且可以在任何本地或云提供商上执行。可以定义具有自定义指标的自动缩放器，以触发所需堆栈的即时部署，以解决季节性高峰期间客户或市民涌入的问题。当指标恢复正常并且云资源不再存在时，您可以回收它们并恢复正常操作，同时一组核心资产接管内部部署，直到下一次激增。鸡和蛋的悖论考虑到Kubernetes和云原生范例，自动化是必须的。但这提出了一个重要问题：组织能否在解决自动化战略之前采用Kubernetes？似乎从Kubernetes入手可以激发更好的自动化，但这并不是一个一成不变的结论。工具不是解决技能、实践和文化问题的方法。但是，设计良好的平台可以成为IT组织内学习、变革和跨职能协作的催化剂。开始使用Kubernetes即使您觉得自己错过了自动化列车，也不要害怕从一个简单、不复杂的堆栈开始使用Kubernetes。当您掌握了最初的步骤后，您可以拥抱这个伟大的编排系统的简单性，并迭代更复杂的需求。
