Share via

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

AKS 平台自动化和 DevOps

  • 项目

作为一个云原生构造，Kubernetes 需要云原生方法来进行部署和操作。 Azure 和 Kubernetes 是开放的、可扩展的平台，具有丰富且架构良好的 API，提供完全自动化的机会和功能。 依靠自动化和常规 DevOps 最佳做法来规划 DevOps和高度自动化的方法。

设计注意事项

下面是 AKS 平台自动化和 DevOps 的一些设计注意事项：

  • 在确定工程和自动化方法时，请考虑 Azure 服务限制以及持续集成和持续交付 (CI/CD) 环境。 如需其他示例，请参阅 GitHub 使用限制。

  • 在保护和保护对开发、测试、Q&A 和生产环境的访问权限时，请考虑从 CI/CD 的角度来看的安全选项。 部署是自动进行的，因此请相应地映射访问控制。

  • 请考虑将前缀和后缀与定义明确的约定一起使用，来唯一标识每个已部署的资源。 这些命名约定避免了在相邻部署解决方案时发生冲突，并提高团队的整体敏捷性和吞吐量。

  • 创建工作流的清单，以支持在正常方案和灾难恢复计划 (DRP) 方案中设计、更新和部署解决方案。 请考虑根据这些工作流映射管道，从而最大程度地提高熟悉度和工作效率。

    要考虑的一些示例方案和管道包括：

    • 部署、修补和升级群集
    • 部署和升级应用程序
    • 部署和维护加载项
    • 对灾难恢复进行故障转移
    • 蓝绿部署
    • 维护 Canary 环境

  • 请考虑使用服务网格向工作负载添加更多的安全性、加密和日志功能。

  • 请考虑部署其他资源（例如订阅、标记和标签），通过跟踪和跟进部署和相关项目来支持 DevOps 体验。

  • 请考虑“宠物和牛”(cattle versus pets) 这种思维模式的转变带来的影响。 预期 Pod 和 Kubernetes 的其他方面是暂时的，并相应地调整自动化和管道基础结构。 不要指望 IP 地址或其他资源是固定的或永久的。

设计建议

下面是 AKS 平台自动化和 DevOps 的一些设计建议：

  • 依赖管道或操作来：

    • 在整个团队中最大程度地落实已应用的做法。
    • 消除重复工作带来的很多负担。
    • 在整体质量和敏捷性方面提供可预测性和见解。

  • 通过使用基于触发器的管道和计划的管道，尽早且经常进行部署。 基于触发器的管道可确保更改通过适当的验证，而计划的管道可管理不断变化的环境中的行为。

  • 将基础结构部署与应用程序部署分开。 与应用程序相比，核心基础结构的更改更少。 将每种类型的部署视为一个单独的流和管道。

  • 使用云原生进行部署。 使用基础结构即代码部署基础结构（包括控制平面），并使用 Helm 和 Kubernetes 中的 Operator 模式来部署和维护 Kubernetes 原生组件。

  • 使用 GitOps 来部署和维护应用程序。 GitOps 使用 Git 存储库作为单一可信源，从而避免配置偏移，并在回滚和相关过程中提高工作效率和可靠性。

  • 将 Pod 托管标识和机密存储 CSI 驱动程序的 Azure Key Vault 提供程序一起使用，来保护机密、证书和连接字符串。

  • 通过避免硬编码的配置项目和设置，努力最大程度地实现部署并发性。

  • 在基础结构和应用程序相关部署中遵守总所周知的约定。 将许可控制器与 用于 Kubernetes 的 Azure Policy 加载项结合使用，来验证和强制执行其他已定义的策略之间的约定。

  • 在以下方面始终如一地采用左移方法：

    • 安全性，通过尽早在管道中添加漏洞扫描工具（例如容器扫描）。
    • 策略，通过将策略用作代码，并通过许可控制器以云原生方式强制实施策略。

  • 将每个故障、错误或中断看作是可实现自动化和提高整体解决方案质量的机会。 将此方法集成到左移方法和站点可靠性工程 (SRE) 框架中。