我在 2002 年采用 Gentoo Linux 作为我的主要操作系统时开始了我的自动化之旅。二十年后，自动化尚未完成。当我与客户和合作伙伴会面时，他们分享了团队内部的自动化成功案例，但他们也描述了在组织层面实现类似成功的挑战。
大多数 IT 组织都能够端到端地配置虚拟机，从而将以前需要四周的交付周期缩短到仅五分钟。这种程度的自动化本身就是一个复杂的工作流程，需要网络（IP 地址管理、DNS、代理、网络区域等）、身份访问管理、hypervisor、存储、备份、更新操作系统、应用最新的配置文件、监控、安全和强化以及合规性基准测试。哇！
满足业务对高速、可扩展性和按需自动化的需求并非易事。例如，考虑经典的网上商店或在线政府服务来申报纳税。工作负载具有需要吸收的明确定义的峰值。
处理这种负载的常用方法是拥有一个超大的服务器集群，准备由专门的 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 开始。拥抱这个出色编排器的简洁性，并在您掌握了初始步骤后，根据更复杂的需求进行迭代。
2 条评论