Azure Kubernetes 服务的支持策略

  • 项目

本文介绍 Azure Kubernetes 服务 (AKS) 的技术支持策略和限制。 本文还详细介绍了代理节点管理、托管控制平面组件、第三方开源组件，以及安全性或补丁管理。

服务更新和版本

AKS 中的托管功能

通过基本的基础结构即服务 (IaaS) 云组件（例如计算或网络组件），可以访问低级别的控件机制和自定义选项。 相比之下，AKS 提供统包式的 Kubernetes 部署，为你的群集提供了一组所需的通用配置和功能。 作为 AKS 用户，你可选的自定义和部署选项并不完整。 但在这种情况下，你无需考虑或无需直接管理 Kubernetes 群集。

借助 AKS，可以获取一个完全托管的控制平面。 该控制平面包含执行操作并向最终用户提供 Kubernetes 群集所需的所有组件和服务。 所有 Kubernetes 组件都由 Azure 维护和操作。

Azure 通过控制平面管理和监视以下组件：

  • Kubelet 或 Kubernetes API 服务器
  • Etcd 或兼容的键-值存储，提供服务质量 (QoS)、可伸缩性和运行时
  • DNS 服务（例如 kube-dns 或 CoreDNS）
  • Kubernetes 代理或网络（使用 BYOCNI 时除外）
  • 在 kube-system 命名空间中运行的任何其他加载项或系统组件。

AKS 不是平台即服务 (PaaS) 解决方案。 某些组件（例如代理节点）实行分担责任制，你需要帮助维护 AKS 群集。 例如，必须提供用户输入才能应用代理节点操作系统 (OS) 安全补丁。

服务是托管型的，Azure 和 AKS 团队将部署、操作并负责服务的可用性和功能。 客户无法改动这些托管组件。 为确保一致且可缩放的用户体验，Azure 将限制自定义。

共担责任

创建群集时，你将定义 AKS 创建的 Kubernetes 代理节点。 你的工作负载将在这些节点上执行。

由于代理节点会执行专用代码并存储敏感数据，Azure 支持只能以受限的方式访问这些信息。 在未得到你的明确许可或者协助的情况下，Azure 支持不能登录到这些节点、在其中执行命令或查看其日志。

使用任何一种 IaaS API 直接对代理节点进行的任何修改都将导致群集不受支持。 对代理节点进行的任何修改都必须使用本机 Kubernetes 机制（如 Daemon Sets）来完成。

同样，虽然你可以将任何元数据添加到群集和节点（如标记和标签），但更改任何系统创建的元数据都会导致群集不受支持。

AKS 支持范围

Azure 为以下示例提供技术支持：

  • 连接到 Kubernetes 服务提供和支持的所有 Kubernetes 组件，例如 API 服务器。
  • Kubernetes 控制平面服务（例如 Kubernetes 控制平面、API 服务器、etcd 和 coreDNS）的管理、运行时间、QoS 和操作。
  • Etcd 数据存储。 支持包括每隔 30 分钟以透明方式自动备份所有 etcd 数据，以实现灾难规划和群集状态还原。 你或任何其他人都不可直接使用这些备份。 这些备份用于确保数据的可靠性和一致性。 不支持按需回退或还原功能。
  • 适用于 Azure 云提供程序驱动程序中的任何集成点。 这包括与其他 Azure 服务的集成，这些服务包括负载均衡器、持久卷或网络（Kubernetes 和 Azure CNI，使用 BYOCNI 时除外）。
  • 有关控制平面组件（例如 Kubernetes API 服务器、etcd 和 coreDNS）的自定义的问题。
  • 有关网络的问题，例如 Azure CNI、kubenet 或其他网络访问和功能问题（使用 BYOCNI 时除外）。 问题可能包括 DNS 解析、数据包丢失、路由等。 Azure 支持各种网络方案：
    • 使用托管 VNET 或自定义（自带）子网的 Kubenet 和 Azure CNI。
    • 连接到其他 Azure 服务和应用程序
    • 入口控制器以及入口或负载均衡器配置
    • 网络性能和延迟
    • 网络策略

注意

Microsoft/AKS 所执行的任何群集操作都是经你同意，在内置 Kubernetes 角色 aks-service 和内置角色绑定 aks-service-rolebinding 下执行的。 此角色允许 AKS 对群集问题进行故障排除和诊断，但不能修改权限，也不能创建角色或角色绑定，或者执行其他高特权操作。 仅在具有实时 (JIT) 访问权限的活动支持票证下启用角色访问。

Azure 不为以下方案提供技术支持：

  • 有关 Kubernetes 用法的问题。 例如，Azure 支持部门不提供有关如何创建自定义入口控制器、使用应用程序工作负荷，或者应用第三方/开源软件包或工具的建议。

    注意

    Azure 支持部门可以提供有关 AKS 群集功能、自定义和优化的建议（例如 Kubernetes 操作问题和过程）。

  • 不是作为 Kubernetes 控制平面的一部分提供的，或者不是在 AKS 群集中部署的第三方开源项目。 这些项目可能包括 Istio、Helm、Envoy 等等。

    注意

    Azure 可以尽最大努力为 Helm 等第三方开源项目提供支持。 如果需要将第三方开源工具与 Kubernetes Azure 云提供程序相集成，或者存在其他特定于 AKS 的 bug，则 Azure 可以通过 Azure 文档提供示例和应用程序方面的支持。

  • 第三方闭源软件。 此类软件可能包括安全扫描工具以及网络设备或软件。

  • AKS 文档中未列出的网络自定义。

  • 在 BYOCNI 模式下使用的自定义或第三方 CNI 插件。

针对代理节点的 AKS 支持范围

Azure 对 AKS 代理节点的责任

在以下情况下，由 Azure 和你共同承担 Kubernetes 代理节点的责任：

  • 基本 OS 映像收到了必需的新增功能（例如监视和网络代理）。
  • 代理节点自动收到了 OS 补丁。
  • 在代理节点上运行的 Kubernetes 控制平面组件的问题会自动修复。 组件包括以下各项：
    • Kube-proxy
    • 为 Kubernetes 主控组件提供通信路径的网络隧道
    • Kubelet
    • containerd

注意

如果代理节点不可操作，AKS 可能会重启单个组件或整个代理节点。 这些重启操作会自动执行，并为常见问题提供自动修正。 如果要了解有关自动修正机制的详细信息，请参阅节点自动修复

客户对 AKS 代理节点的责任

Azure 每周为你的映像节点提供补丁和新映像，但默认情况下不会自动对其进行修补。 要保持对代理节点 OS 和运行时组件进行修补，应定期执行节点映像升级计划或使其自动化。

同样，AKS 会定期发布新的 Kubernetes 补丁和次要版本。 这些更新可能包含 Kubernetes 的安全或功能改进。 你负责根据 AKS Kubernetes 支持版本策略来持续更新集群的 Kubernetes 版本。

代理节点的用户自定义

注意

AKS 代理节点在 Azure 门户中显示为标准 Azure IaaS 资源。 但是这些虚拟机被部署到自定义的 Azure 资源组（前缀为 MC_*）中。 不能更改基础 OS 映像，或使用 IaaS API 或资源对这些节点进行任何直接的自定义。 非通过 AKS API 执行的任何自定义更改都不会通过升级、缩放、更新或重启保留。 此外，对节点扩展的任何更改（如 CustomScriptExtension）都可能导致意外行为，应予以禁止。 除非 Azure 支持指示你进行更改，否则请避免更改代理节点。

AKS 代表你管理代理节点的生命周期和操作，不支持修改与该代理节点关联的 IaaS 资源。 不支持的操作的一个示例是通过 Azure 门户或 API 手动更改配置来自定义节点池虚拟机规模集。

对于工作负载特定的配置或包，AKS 建议使用 Kubernetes daemon sets。

使用 Kubernetes 特权 daemon sets 和 init 容器，可以在群集代理节点上优化/修改或安装第三方软件。 此类自定义的示例包括添加自定义安全扫描软件或更新 sysctl 设置。

虽然当满足上述要求时，这是建议的路径，但 AKS 工程和支持人员无法协助排查或诊断导致节点因自定义部署 daemon set 而不可用的修改。

安全问题和修补

如果在 AKS 的一个或多个托管的组件中发现了安全缺陷，则 AKS 团队会修补所有受影响的群集以缓解此问题。 或者，AKS 团队会提供升级指南。

对于受安全缺陷影响的代理节点，Azure 会将有关影响的详细信息以及解决或缓解安全问题的步骤以通知的形式告知你。

节点维护和访问

尽管可以登录并更改代理节点，但不建议这样做，因为更改可能会导致群集不受支持。

网络端口、访问和 NSG

只能在自定义子网中自定义 NSG。 不能在托管子网上或代理节点的 NIC 级别上自定义 NSG。 AKS 对特定终结点有流出量要求，目的是控制流出量并确保必要的连接性，请参阅限制出口流量。 对于入口，相关要求取决于部署到群集的应用程序。

已停止、取消分配和“未就绪”节点

如果不需要 AKS 工作负载持续运行，可以停止停止所有节点池和控制平面的 AKS 群集。 可以在需要时将其再次启动。 使用 az aks stop 命令停止群集时，群集状态会保留长达 12 个月。 12 个月后，群集状态及其所有资源都会被删除。

不支持从 IaaS API、Azure CLI 或 Azure 门户手动解除分配所有群集节点以停止 AKS 群集或节点池。 群集将被视为不受支持，并将由 AKS 在 30 天后停止。 然后，群集会受到与正确停止的群集相同的 12 个月保留策略的约束。

30 天后，具有 0 个“就绪”节点（或所有为“未就绪”节点）的群集和 0 个正在运行的 VM 将被停止。

对于已配置了“停止支持”规则以将支持期限延长至等于或超过 30 天的控制平面，AKS 保留了将其存档的权利。 AKS 维护群集 etcd 元数据的备份，并可轻松地重新分配群集。 此重新分配会由任何使群集重获支持的 PUT 操作（例如升级或缩放到活动代理节点）启动。

已暂停订阅中的所有群集将立即停止，并在 90 天后删除。 已删除订阅中的所有群集将立即删除。

不受支持的 alpha 和 beta Kubernetes 功能

AKS 仅支持上游 Kubernetes 项目中的稳定和 beta 版功能。 除非另有说明，否则，AKS 不支持上游 Kubernetes 项目中可用的任何 alpha 功能。

预览功能或功能标志

对于需要扩展测试和用户反馈的功能，Azure 会发布新的预览功能或在采用了功能标志的情况下发布功能。 请将这些功能视为预发行版或 beta 功能。

预览功能或功能标志功能不适用于生产环境。 API 和行为的不断变化、bug 修复和其他更改可能会导致群集不稳定和停机。

公共预览版中的功能属于“尽最大努力”支持，因为这些功能处于预览状态，不适用于生产环境。 AKS 技术支持团队仅在工作时间提供支持。 有关详细信息，请参阅 Azure 支持常见问题解答。

上游 bug 和问题

由于上游 Kubernetes 项目的开发速度，不可避免地会出现 bug。 其中的某些 bug 无法在 AKS 系统内部得到修补或解决。 相反，bug 修复需要对上游项目（例如 Kubernetes、节点或代理操作系统及内核）应用更大的补丁。 对于 Azure 拥有的组件（例如 Azure 云提供程序），AKS 和 Azure 人员承诺在社区中解决上游问题。

如果某个技术支持问题的根本原因是一个或多个上游 bug，则 AKS 支持和工程团队会采取以下措施：

  • 使用任何支持详细信息来识别并链接上游 bug，以帮助解释为何此问题会影响群集或工作负荷。 客户会收到所需存储库的链接，以便可以观察问题，并了解何时有新的版本可以提供修复措施。

  • 提供可能的解决方法或缓解措施。 如果可以缓解此问题，则会在 AKS 存储库中存档一个已知问题。 已知问题备案将会解释：

    • 该问题，包括上游 bug 的链接。
    • 解决方法，以及有关解决方案升级或其他持久化措施的详细信息。
    • 问题包含内容的大致时间线，根据上游版本发布频率提供。