通过

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

Azure Kubernetes 服务的操作管理注意事项

  • 项目

Kubernetes 是一项相对较新的技术，发展迅速且生态系统令人印象深刻。 因此，它的管理和保护可能非常具有挑战性。

AKS 的操作基线

通过正确设计Azure Kubernetes 服务（AKS）解决方案，考虑到管理和监视，你可以努力实现卓越运营和客户的成功。

设计注意事项

请考虑下列因素：

  • 了解 AKS 限制。 使用多个 AKS 实例来超出这些限制。
  • 了解如何在群集中以逻辑方式隔离工作负载，以及如何在独立群集中以物理方式隔离工作负载。
  • 了解如何控制工作负载的资源占用。
  • 了解如何帮助 Kubernetes 理解工作负载的运行状况。
  • 请注意各种虚拟机大小以及使用一个或多个虚拟机的影响。 更大的虚拟机可以处理更多的负载。 当较小的 VM 无法进行计划内和计划外维护时，可以更容易地使用其他 VM 将其替换。 此外，请注意规模集中的节点池和 VM，从而允许同一群集中不同大小的虚拟机。 较大的 VM 更最佳，因为 AKS 会保留其资源所占的较小百分比，从而使其更多资源可供工作负荷使用。
  • 了解如何监视和记录 AKS。 Kubernetes 由各种组件组成，监视和日志记录应提供有关其运行状况、趋势和潜在问题的见解。
  • 在监视和日志记录的基础上，Kubernetes 或上面运行的应用程序可能会生成许多事件。 警报可帮助区分历史日志条目和需立即处理的日志条目。
  • 了解应执行的更新和升级。 在 Kubernetes 级别，有主要版本、次要版本和修补程序版本。 客户应应用这些更新，以便根据上游 Kubernetes 中的策略继续受支持。 在辅助角色主机级别，OS 内核修补程序可能需要重启，客户应重新启动，并升级到新的 OS 版本。 除了手动升级群集之外，还可以在群集上设置自动升级通道。
  • 请注意群集的资源限制和单个工作负荷。
  • 了解水平 Pod 自动缩放程序和群集自动缩放程序之间的差异
  • 考虑使用网络策略和 Azure 策略插件保护 Pod 之间的流量
  • 若要帮助排查 AKS 上运行的应用程序和服务问题，可能需要查看控制平面组件生成的日志。 你可能想要 为 AKS 启用资源日志，因为默认情况下未启用日志记录。

建议

  • 了解 AKS 限制：

  • 在命名空间级别使用逻辑隔离来分隔应用程序、团队、环境和业务部门。 多租户和群集隔离。 此外，节点池可以帮助节点具有不同节点规范的节点，以及 Kubernetes 升级 多个节点池等维护

  • 在命名空间级别规划和应用资源配额。 如果 Pod 未定义资源请求和限制，则使用策略拒绝部署，诸如此类。 这不适用于 kube 系统 Pod，因为并非所有 kube 系统 Pod 都有请求和限制。 监视资源用量并根据需要调整配额。 基本计划程序功能

  • 向 Pod 添加运行状况探测。 确保 Pod 包含livenessProbe和 readinessProbestartupProbe AKS 运行状况探测。

  • 使用足够大的 VM 大小来包含多个容器实例，因此可以获得密度增加的好处，但群集无法处理失败节点的工作负荷。

  • 使用监视解决方案。 默认情况下，Azure Monitor 容器见解 已设置，提供对许多见解的轻松访问。 如果想要深入了解或获取使用 Prometheus 的经验，可以使用 Prometheus 集成。 如果还想在 AKS 上运行监视应用程序，还应使用 Azure Monitor 监视该应用程序。

  • 使用 Azure Monitor 容器见解 指标警报 在需要直接操作时提供通知。

  • 结合使用自动节点池缩放功能与水平 Pod 自动缩放程序，以满足应用程序需求并减少高峰时段的负载。

  • 使用 Azure 顾问获取有关成本、安全性、可靠性、卓越运营和性能的最佳做法建议。 此外，使用 Microsoft Defender for Cloud 来预防和检测映像漏洞等威胁。

  • 使用 已启用 Azure Arc 的 Kubernetes 使用 Azure Policy、Defender for Cloud、GitOps 等管理 Azure 中的非 AKS Kubernetes 群集。

  • 可使用 Pod 请求和限制管理 AKS 群集中的计算资源。 Pod 请求和限制将通知 Kubernetes 计划程序要分配给 Pod 的计算资源。

业务连续性/灾难恢复，以保护和恢复 AKS

你的组织需要设计合适的 Azure Kubernetes 服务 (AKS) 平台级功能来满足其特定要求。 这些应用程序服务具有与恢复时间目标 (RTO) 和恢复点目标 (RPO) 相关的要求。 AKS 灾难恢复需要解决多个注意事项。 第一步，为基础结构和应用程序定义服务级别协议 (SLA)。 了解适用于 Azure Kubernetes 服务 (AKS) 的 SLA。 有关每月运行时间计算的信息，请参阅 SLA 详细信息部分。

设计注意事项

请考虑下列因素：

  • AKS 群集应在节点池中使用多个节点为应用程序提供最低的可用性级别。

  • 设置 Pod 请求和限制。 通过设置这些限制，Kubernetes 可以：

    • 高效地为 Pod 提供 CPU 和内存资源。
    • 在节点上拥有更高的容器密度。

    由于硬件得到更好的使用，所以限制还可以提高可靠性，同时降低成本。

  • AKS 适用于可用性区域或可用性集。

    • 选择支持可用性区域的一个地区。
    • 可用性区域只能在创建节点池时设置，以后无法更改。 多区域支持仅适用于节点池。
    • 为获得完全的区域优势，所有服务依赖项还必须支持区域。 如果依赖服务不支持区域，则区域故障可能会导致该服务失败。
    • 在不同的配对区域中运行多个 AKS 群集，以实现更高的可用性，超出可用性区域可以实现的目标。 如果 Azure 资源支持异地冗余，请提供冗余服务具有其次要区域的位置。

  • 你应该知道 AKS 中灾难恢复 的准则。 然后考虑它们是否适用于用于 Azure Dev Spaces 的 AKS 群集。

  • 为应用程序和数据创建一致的备份。

    • 可以高效地复制非有状态服务。
    • 如果需要在群集中存储状态，可以在配对区域频繁备份数据。 一个考虑因素是，在群集中正确存储 状态 可能很复杂。

  • 群集更新和维护。

    • 始终使群集保持最新。
    • 请注意发布和弃用过程。
    • 规划更新和维护。

  • 发生故障转移时的网络连接。

    • 选择一个可跨区域分发流量的流量路由器，具体取决于你的需求。 此体系结构部署 Azure 负载均衡器，因为它可以跨区域分发非 Web 流量。
    • 如果需要跨区域分发流量，请考虑使用 Azure Front Door。

  • 计划内和计划外故障转移。

    • 设置每个 Azure 服务时，请选择支持灾难恢复的功能。 例如，此体系结构为异地复制启用Azure 容器注册表。 如果某个区域出现故障，仍然可以从复制区域拉取映像。

  • 维护工程 DevOps 功能，以实现服务级别目标。

  • 确定是否需要为 Kubernetes API 服务器终结点提供财务支持的 SLA。

设计建议

下面是设计最佳做法：

  • 对系统节点池使用三个节点。 对于用户节点池，从不少于两个节点开始。 如需更高可用性，请设置更多节点。

  • 通过将应用程序放置在单独的节点池中，将其与系统服务隔离开。 这样，Kubernetes 服务在专用节点上运行，不会与其他服务竞争。 使用标记、标签和标志来标识节点池以计划工作负荷。

  • 定期维护群集（例如及时更新）对于可靠性至关重要。 请注意 AKS 上的 Kubernetes 版本的支持窗口并规划更新。 此外，建议通过探测监视 Pod 的运行状况。

  • 尽可能从容器内删除服务状态。 而是使用支持多区域复制的 Azure 平台即服务（PaaS）。

  • 确保 Pod 资源。 强烈建议部署指定 Pod 资源要求。 然后，计划程序可以适当地计划 Pod。 未计划 Pod 时可靠性会弃用。

  • 在部署中设置多个副本，以处理硬件故障等中断事件。 对于计划内事件（如更新和升级），中断预算可以确保存在所需的 Pod 副本数来处理预期的应用程序负载。

  • 应用程序可能会为其数据使用 Azure 存储。 由于应用程序分布在不同区域中的多个 AKS 群集中，因此必须保持存储同步。 下面是复制存储的两种常用方法：

    • 基于基础结构的异步复制
    • 基于应用程序的异步复制

  • 估计 Pod 限制。 测试和建立基线。 从请求和限制的相等值开始。 然后，逐步调整这些值，直到建立可导致群集不稳定的阈值。 可以在部署清单中指定 Pod 限制。

    内置功能为处理服务体系结构中的故障和中断的复杂任务提供解决方案。 这些配置有助于简化设计和部署自动化。 组织为 SLA、RTO 和 RPO 定义了标准后，可以使用 Kubernetes 和 Azure 的内置服务来实现业务目标。

  • 设置 Pod 中断预算。 此设置检查在更新或升级事件期间可以关闭的部署中的副本数。

  • 在服务命名空间上强制实施资源配额。 命名空间上的资源配额可确保在部署上正确设置 Pod 请求和限制。

    • 在群集级别设置资源配额可能会导致部署没有适当请求和限制的合作伙伴服务时出现问题。

  • 将容器映像存储在 Azure 容器注册表，并将注册表异地复制到每个 AKS 区域。

  • 使用正常运行时间 SLA 为托管生产工作负载的所有集群启用有财务支持的更高 SLA。 对于使用可用性区域的群集，运行时间 SLA 可保证 Kubernetes API 服务器终结点 99.95% 的可用性，对于不使用可用性区域的群集，可保证 99.9% 的可用性。 节点、节点池和其他资源在其 SLA 下涵盖。 AKS 为其控制平面组件提供服务级别目标（SLO）为 99.5% 的免费层。 不启用运行时间 SLA 的群集不应用于生产工作负荷。

  • 使用多个区域以及对等互连位置进行 Azure ExpressRoute 连接。

    如果中断影响 Azure 区域或对等互连提供商位置，冗余混合网络体系结构有助于确保不间断的跨界连接。

  • 使用全局虚拟网络对等互连将区域互连。 如果群集需要相互通信，可以通过虚拟网络对等互连将两个虚拟网络相互连接。 这项技术将虚拟网络相互互连，跨Microsoft主干网络提供高带宽，甚至跨不同的地理区域。

  • Azure Front Door 使用基于拆分 TCP 的任意广播协议确保最终用户能够立即连接到最近的 Front Door 接入点。 Azure Front Door 的其他功能包括：

    • TLS 终止
    • 自定义域
    • Web 应用程序防火墙
    • URL 重写
    • 会话相关性

    查看应用程序流量的需求，以了解哪种解决方案最合适。