Azure Arc 为 AKS 启用的 Kubernetes 群集体系结构和工作负载
适用于：Azure Stack HCI 22H2 上的 AKS、Windows Server 上的 AKS
Azure Stack HCI 和 Windows Server 上的 Azure Kubernetes 服务 (AKS) 是由 Azure Stack HCI 提供支持的企业级 Kubernetes 容器平台。 它包括 Microsoft 支持的核心 Kubernetes、专门构建的 Windows 容器主机和 Microsoft 支持的 Linux 容器主机，其目标是提供简单的部署和生命周期管理体验。
本文介绍了 Kubernetes 核心基础结构组件，例如控制平面、节点和节点池。 还介绍了 Pod、部署和集等工作负荷资源，以及如何将资源分组到命名空间 。
Kubernetes 群集体系结构
Kubernetes 是由 Azure Arc 启用的 AKS 的核心组件。AKS 使用一组预定义的配置来有效地部署 Kubernetes 群集 () ，并考虑到可伸缩性。
部署操作会创建多个 Linux 或 Windows 虚拟机，并将其联接在一起，以 () 创建 Kubernetes 群集。
注意
为了帮助提高系统的可靠性，如果在群集中运行多个群集共享卷 (CSV) ，则默认情况下，虚拟机数据会自动分散到群集中的所有可用 CSV。 这可确保应用程序在 CSV 中断的情况下继续运行。 这仅适用于新安装（不适用于升级）。
部署的系统已准备好接收标准 Kubernetes 工作负载、缩放这些工作负载，甚至根据需要纵向扩展和缩减虚拟机数量和群集数量。
Azure Kubernetes 服务群集具有以下组件：
- 管理群集也称为 AKS 主机，它提供核心业务流程机制和接口来部署和管理一个或多个工作负载群集。
- 工作负载群集（也称为目标群集）是部署容器化应用程序的位置。
管理由 Arc 启用的 AKS
可以使用以下管理选项来管理 AKS：
- Windows Admin Center为 Kubernetes 操作员提供了一个直观的 UI，用于管理群集的生命周期。
- 借助 PowerShell 模块，可以轻松下载、配置和部署 AKS。 PowerShell 模块还支持部署和配置其他工作负载群集，并且支持重新配置现有工作负载群集。
管理群集
创建 Kubernetes 群集时，会自动创建并配置管理群集。 此管理群集负责预配和管理工作负载在其中运行的工作负载群集。 管理群集包括以下核心 Kubernetes 组件：
-
API 服务器：API 服务器是公开基础 Kubernetes API 的方式。 此组件为管理工具（如 Windows Admin Center、PowerShell 模块或
kubectl）提供交互。 - 负载均衡器：负载均衡器是单个专用 Linux VM，具有管理群集 API 服务器的负载均衡规则。
工作负载群集
工作负载群集是 Kubernetes 的高度可用部署，使用 Linux VM 运行 Kubernetes 控制平面组件和 Linux 工作器节点。 基于 Windows Server Core 的 VM 用于建立 Windows 工作器节点。 一个管理群集可以管理一个或多个工作负载群集。
工作负载群集组件
工作负载群集包含许多组件，详见以下部分。
控制面板
-
API 服务器：API 服务器允许与 Kubernetes API 交互。 此组件为管理工具（如 Windows Admin Center、PowerShell 模块或
kubectl）提供交互。 - Etcd：Etcd 是一个分布式键值存储，用于存储群集生命周期管理所需的数据。 它存储控制平面状态。
负载均衡器
负载均衡器是运行 Linux 和 HAProxy + KeepAlive 的虚拟机，用于为管理群集部署的工作负载群集提供负载均衡服务。 对于每个工作负载群集，AKS 至少添加一个负载均衡器虚拟机。 在工作负载群集上创建的任何 类型的 LoadBalancer Kubernetes 服务最终都会在 VM 中创建负载均衡规则。
辅助角色节点
若要运行应用程序和支持服务，需要一个 Kubernetes 节点。 AKS 工作负载群集包含一个或多个工作器节点。 工作器节点充当运行 Kubernetes 节点组件的虚拟机 (VM)，并托管构成应用程序工作负载的 pod 和服务。
可以在 AKS 工作负载群集上部署核心 Kubernetes 工作负载组件，例如 Pod 和部署。
Pod
Kubernetes 使用 Pod 来运行应用程序的实例。 Pod 表示应用程序的单个实例。 通常，Pod 具有与容器的 1：1 映射，但在高级方案中，Pod 可以包含多个容器。 在同一个节点上共同计划这些多容器 Pod，并允许容器共享相关资源。 有关详细信息，请参阅 Kubernetes Pod 和 Kubernetes Pod 生命周期。
部署
部署表示由 Kubernetes Deployment 控制器管理的一个或多个相同 Pod。 部署定义) 创建的 pod (副本 数，Kubernetes 计划程序确保如果 Pod 或节点遇到问题，则会在正常的节点上计划其他 Pod。 有关详细信息，请参阅 Kubernetes 部署。
StatefulSet 和 DaemonSet
部署控制器使用 Kubernetes 计划程序在具有可用资源的任何可用节点上运行给定数量的副本。 对于无状态应用程序，这种使用部署的方法可能已足够，但对于需要持久命名约定或存储的应用程序则不行。 对于群集内需要在每个节点（或选定节点）上存在副本的应用程序，Deployment 控制器不会查看副本在节点间的分布情况。
- StatefulSets：StatefulSet 类似于部署，即创建和管理一个或多个相同的 Pod。 StatefulSet 中的副本按照正常有序的方法来部署、缩放、升级和终止。 使用 StatefulSet（重新计划副本时），命名约定、网络名称和存储将保持不变。 StatefulSet 中的副本在 Kubernetes 群集中的任何可用节点上进行计划和运行。 如果需要确保集中至少有一个 Pod 在节点上运行，可以改用 DaemonSet。 有关详细信息，请参阅 Kubernetes StatefulSet。
- DaemonSets：对于特定的日志收集或监视需求，可能需要在所有或所选节点上运行给定的 Pod。 DaemonSet 再次用于部署一个或多个相同的 Pod，但 DaemonSet 控制器可确保指定的每个节点运行 Pod 实例。 有关详细信息，请参阅 Kubernetes DaemonSet。
命名空间
Kubernetes 资源（如 Pod 和部署）以逻辑方式分组到命名空间中。 这些分组提供了一种以逻辑方式划分工作负载群集并限制创建、查看或管理资源的访问权限的方法。 例如，可创建命名空间来分隔业务组。 用户只能与分配的命名空间内的资源进行交互。 有关详细信息，请参阅 Kubernetes 命名空间。
在 Arc 启用的 AKS 上创建Azure Kubernetes 服务群集时，可以使用以下命名空间：
-
default：一个命名空间，如果未提供 Pod 和部署，则默认在其中创建 Pod 和部署。 在小型环境中，可以将应用程序直接部署到默认命名空间，而无需创建其他逻辑分隔。 与 Kubernetes API（例如
kubectl get pods）交互时，如果未指定命名空间，则使用默认值。 - kube-system：存在核心资源的命名空间，例如 DNS 和代理等网络功能，或 Kubernetes 仪表板。 通常不会将应用程序部署到此命名空间中。
- kube-public：通常不使用命名空间，但可用于在整个群集中可见的资源，并且可供任何用户查看。
机密
Kubernetes 机密 使你能够存储和管理敏感信息，例如密码、OAuth 令牌和安全外壳 (SSH) 密钥。 默认情况下，Kubernetes 将机密存储为未加密的 base64 编码字符串，并且具有 API 访问权限的任何人都可以以纯文本形式检索机密。 有关详细信息，请参阅 Kubernetes 机密。
永久性卷
永久性卷是 Kubernetes 群集中的存储资源，由管理员预配或使用存储类进行动态预配。 若要使用永久性卷，Pod 会使用 PersistentVolumeClaim 请求访问权限。 有关详细信息，请参阅永久性卷。
混合 OS 部署
如果给定的工作负载群集由 Linux 和 Windows 工作器节点组成，则需要将它安排到可支持预配工作负载的 OS 上。 Kubernetes 提供了两种机制来确保工作负载进入具有目标操作系统的节点：
- 节点选择器 是 Pod 规范中的一个简单字段，将 Pod 限制为仅计划到与操作系统匹配的正常节点上。
- 排斥和容许一起工作，以确保不会无意中将 Pod 安排到节点。 节点可能受到“污染”，使其不接受未通过 Pod 规范中的“容忍”显式容忍其污点的 Pod。
后续步骤
本文介绍了 Azure Arc 启用的 AKS 的群集体系结构以及工作负载群集组件。 有关这些概念的详细信息，请参阅以下文章：