通过

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

Azure Kubernetes 服务 (AKS) 的核心 Kubernetes 概念

  • 项目

本文介绍 Azure Kubernetes 服务 (AKS) 的核心概念，这是一种托管的 Kubernetes 服务，可用于在 Azure 上大规模部署和操作容器化应用程序。 它可帮助你了解 Kubernetes 的基础结构组件，并更深入地了解 Kubernetes 在 AKS 中的工作原理。

什么是 Kubernetes？

Kubernetes 是一个快速发展的平台，用于管理基于容器的应用程序及其相关网络和存储组件。 Kubernetes 重点关注应用程序工作负载，而不是底层基础结构组件。 Kubernetes 提供了一种声明性的部署方法，由一组针对管理操作的强大 API 提供支持。

你可以生成和运行可移植的、基于微服务的新式应用程序，这些应用程序可使用 Kubernetes 安排和管理这些应用程序组件的可用性。 Kubernetes 支持无状态和有状态应用程序。

作为开放平台，Kubernetes 可使用首选的编程语言、OS、库或消息总线生成应用程序。 现有的持续集成和持续交付 (CI/CD) 工具可以与 Kubernetes 集成，以计划和部署版本。

AKS 提供了一个托管的 Kubernetes 服务，可简化部署和核心管理任务。 由 Azure 平台来管理 AKS 控制平面，你只需为运行应用程序的 AKS 节点付费。

Kubernetes 群集体系结构

Kubernetes 群集分为两个组件：

  • 控制平面，提供核心 Kubernetes 服务和应用程序工作负载的编排，以及
  • 节点，用于运行应用程序工作负载。

Kubernetes 控制平面和节点组件

控制面板

创建 AKS 群集时，Azure 平台会自动创建并配置与之关联的控制平面。 这个单一租户控制平面作为从用户那里抽象出来的托管 Azure 资源免费提供。 你只需为附加到 AKS 群集的节点付费。 控制平面及其资源仅驻留在创建群集的区域。

控制平面包括以下 Kubernetes 核心组件：

组件 说明
kube-apiserver API 服务器会公开基础 Kubernetes API，并为管理工具（例如 kubectl 或 Kubernetes 仪表板）提供交互。
etcd etcd 是 Kubernetes 中高度可用的键值存储，可帮助维护 Kubernetes 群集和配置的状态。
kube-scheduler 创建或缩放应用程序时，计划程序可确定哪些节点可运行工作负载，并启动识别到的节点。
kube-controller-manager 控制器管理器可监视许多较小的控制器，这些控制器执行 Pod 复制和节点处理等操作。

请记住，无法直接访问控制平面。 Kubernetes 控制平面和节点升级通过 Azure CLI 或 Azure 门户进行协调。 要排查可能出现的问题，可使用 Azure Monitor 查看控制平面日志。

注意

如果想要配置或直接访问控制平面，可使用群集 API 提供程序 Azure 来部署自托管 Kubernetes 群集。

节点

要运行应用程序和支持服务，需要 Kubernetes 节点。 每个 AKS 群集至少有一个节点，这是运行 Kubernetes 节点组件和容器运行时的 Azure 虚拟机 (VM)。

节点包括以下 Kubernetes 核心组件：

组件 描述
kubelet Kubernetes 代理，用于处理来自控制平面的业务流程请求以及计划并运行请求的容器。
kube-proxy 代理处理每个节点上的虚拟网络、路由网络流量，并管理服务和 Pod 的 IP 寻址。
container runtime 容器运行时允许容器化应用程序运行并与其他资源（例如虚拟网络或存储）进行交互。 有关详细信息，请参阅容器运行时配置。

Azure 虚拟机和 Kubernetes 节点的支持资源

节点的 Azure VM 大小定义了 CPU、内存大小以及可用的存储类型（例如高性能 SSD 或常规 HDD）。 围绕应用程序是否需要大量 CPU、内存或高性能存储来计划节点大小。 根据需要横向扩展 AKS 群集中的节点数。 有关缩放的详细信息，请参阅 AKS 中应用程序的缩放选项。

在 AKS 中，群集节点的 VM 映像基于 Ubuntu Linux、Azure Linux 或 Windows Server 2022。 创建 AKS 群集或横向扩展节点数时，Azure 平台会自动创建和配置所请求数量的 VM。 代理节点按标准 VM 计费，因此会自动应用任何 VM 大小折扣（包括 Azure 预留）。

对于托管磁盘，根据所选 VM SKU 和 vCPU 计数分配默认磁盘大小和性能。 有关详细信息，请参阅默认 OS 磁盘大小调整。

注意

如果需要对 Kubernetes 节点容器运行时和 OS 进行高级配置和控制，可使用群集 API 提供程序 Azure 来部署自托管群集。

OS 配置

AKS 支持 Ubuntu 22.04 和 Azure Linux 2.0 作为具有 Kubernetes 1.25 及更高版本的群集的节点操作系统 (OS)。 也可以在为 Kubernetes 版本 1.24 及更低版本创建节点池时指定 Ubuntu 18.04。

在具有 Kubernetes 1.25 及更高版本的群集中，AKS 支持将 Windows Server 2022 用作 Windows 节点池的默认 OS。 也可以在为 Kubernetes 版本 1.32 及更低版本创建节点池时指定 Windows Server 2019。 Windows Server 2019 将在 Kubernetes 版本 1.32 生命周期结束后停用，并且在将来的版本中不再受支持。 有关此停用的详细信息，请参阅 AKS 发行说明。

容器运行时配置

容器运行时是在节点上执行容器和管理容器映像的软件。 运行时有助于抽象出系统调用或 OS 特定功能，以便在 Linux 或 Windows 上运行容器。 对于 Linux 节点池，containerd 用于 Kubernetes 1.19 及更高版本。 对于 Windows Server 2019 和 2022 节点池，containerd 已正式发布，并且是 Kubernetes 1.23 及更高版本中唯一的运行时选项。 截至 2023 年 5 月，Docker 已停用，并且不再受支持。 有关此停用的详细信息，请参阅 AKS 发行说明。

Containerd 是一个符合 OCI（开放式容器计划）要求的核心容器运行时，该运行时提供在节点上执行容器和管理映像所需的最小功能集。 如果使用了基于 containerd 的节点和节点池，kubelet 会使用 CRI（容器运行时接口）插件直接与 containerd 通信，使数据流中没有额外的跃点（与 Docker CRI 实现相比）。 因此，你会看到 Pod 启动延迟情况得到改善，资源（CPU 和内存）使用量降低。

Containerd 适用于 AKS 中的每个 Kubernetes GA 版本（从 v1.19 开始的每个 Kubernetes 版本），并支持所有 Kubernetes 和 AKS 功能。

重要

如果群集的 Linux 节点池基于 Kubernetes v1.19 或更高版本创建，则这些群集默认为 containerd 容器运行时。 在早期受支持的 Kubernetes 版本上具有节点池的群集支持使用 Docker 作为其容器运行时。 将节点池 Kubernetes 版本更新为支持 containerd 的版本后，Linux 节点池将更新为 containerd。

containerd 已正式发布用于具有 Windows Server 2019 和 2022 节点池的群集，而且是 Kubernetes v1.23 及更高版本中唯一的容器运行时选项。 可以在 1.23 之前的版本上继续使用 Docker 节点池和群集，但自 2023 年 5 月起，Docker 不再受支持。 有关详细信息，请参阅使用 containerd 添加 Windows Server 节点池。

强烈建议在将群集与支持 containerd 的 Kubernetes 版本结合用于节点池之前使用 containerd 来测试 AKS 节点池上的工作负载。

containerd 限制/差异

  • 对于 containerd，建议将 crictl 用作 Docker CLI 替换项，以便对 Kubernetes 节点上的 Pod、容器和容器映像进行故障排除。 有关 crictl 的详细信息，请参阅常规用法和客户端配置选项。

    • Containerd 不提供 Docker CLI 的完整功能。 它仅用于故障排除。
    • crictl 提供了一个对 Kubernetes 更友好的容器视图，其中包含了 Pod 等概念。

  • Containerd 使用标准化的 cri 日志记录格式来设置日志记录。 日志记录解决方案需要支持 cri 日志记录格式（例如用于容器的 Azure Monitor）。

  • 你无法再访问 Docker 引擎 /var/run/docker.sock，也无法再使用 Docker-in-Docker (DinD)。

    • 如果目前从 Docker 引擎提取应用程序日志或监视数据，请改用容器见解。 AKS 不支持在可能导致不稳定的代理节点上运行任何带外命令。
    • 不建议生成映像或直接使用 Docker 引擎。 Kubernetes 并不能完全感知这些已使用的资源，并且这些方法会导致许多问题，如此处和此处所述。

  • 生成映像时，可以继续像往常一样使用当前的 Docker 生成工作流，除非是在 AKS 群集中生成映像。 在这种情况下，请考虑切换到建议的方法，以便使用 ACR 任务或更安全的群集中选项（如 Docker Buildx）来生成映像。

资源预留

AKS 使用节点资源来帮助节点作为群集的一部分运行。 这种用法可能会造成节点的资源总数与 AKS 中可分配的资源数之间存在差异。 在为用户部署的 Pod 设置请求和限制时，请注意此信息。

若要查找节点的可分配资源，可以使用 kubectl describe node 命令：

kubectl describe node [NODE_NAME]

为了维护节点性能和功能，AKS 在每个节点上预留两种类型的资源（CPU 和内存）。 随着资源中节点的扩大，由于管理用户部署的 Pod 的需求更高，资源预留也会增加。 请记住，无法更改资源预留。

注意

使用容器见解 (OMS) 等 AKS 加载项会消耗更多节点资源。

CPU

预留的 CPU 取决于节点类型和群集配置，这可能会由于运行额外功能而导致可分配的 CPU 较少。 下表显示了 CPU 预留（以 millicore 为单位）：

主机上的 CPU 核心数 1 2 4 8 16 32 64
Kube 预留 (millicore) 60 100 140 180 260 420 740

内存

AKS 中的预留内存包括两个值的总和：

重要

AKS 1.29 在 2024 年 1 月开始预览，包含对内存预留的某些更改。 以下部分详细介绍了这些更改。

AKS 1.29 及更高版本

  1. 默认情况下，kubelet 守护程序具有 memory.available<100Mi 逐出规则。 此规则确保节点至少有 100Mi 可供分配。 当主机低于该可用内存阈值时，kubelet 会触发以终止其中一个正在运行的 Pod，并释放主机上的内存。

  2. 根据以下较小值设置的内存预留率：20MB * 节点上支持的最大 Pod 数 + 50MB 或总系统内存资源的 25%。

    示例：

    • 如果 VM 提供 8GB 内存，并且节点最多支持 30 个 Pod，则 AKS 将为预留的 kube 预留 20MB * 最多 30 个 Pod + 50MB = 650MB。 Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
    • 如果 VM 提供 4GB 内存，并且节点最多支持 70 个 Pod，AKS 将将为预留的 kube 预留 25% * 4GB = 1000MB，因为这小于 20MB * 最多 70 个 Pod + 50MB = 1450MB。

    有关详细信息，请参阅配置 AKS 群集中每个节点的最大 Pod 数。

1.29 之前的 AKS 版本

  1. 默认情况下，kubelet 守护程序具有 memory.available<750Mi 逐出规则。 此规则确保节点至少有 750Mi 可供分配。 当主机低于该可用内存阈值时，kubelet 会触发终止其中一个正在运行的 Pod，并释放主机上的内存。
  2. 为 kubelet 守护程序正常运行而预留 (kube-reserved) 的内存的递减速率。
    • 前 4GB 内存的 25%
    • 下一个 4GB 内存的 20%（最多 8GB）
    • 下一个 8GB 内存的 10%（最多 16GB）
    • 下一个 112GB 内存的 6%（最多 128GB）
    • 任何超过 128 GB 的内存的 2%

注意

AKS 为计算内存中未包含的 Windows 节点中的系统进程额外保留 2 GB。

内存和 CPU 分配规则设计为：

  • 使代理节点保持正常运行，包括某些对群集运行状况至关重要的托管系统 Pod。
  • 使节点报告的可分配内存和 CPU 数量少于它不属于 Kubernetes 群集时报告的数量。

例如，如果一个节点提供 7 GB 内存，它会报告 34% 的内存不可分配，包括 750Mi 硬逐出阈值。

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

除了 Kubernetes 本身的预留外，基础节点 OS 还预留了一定数量的 CPU 和内存资源以维持 OS 功能的运行。

如需相关的最佳做法，请参阅 AKS 中适用于基本计划程序功能的最佳做法。

节点池

注意

Azure Linux 节点池现已正式发布 (GA)。 若要了解权益和部署步骤，请参阅适用于 AKS 的 Azure Linux 容器主机简介。

具有相同配置的节点将统一合并成节点池。 每个 Kubernetes 群集至少包含一个节点池。 在创建 AKS 群集时定义初始节点数和大小，这会创建一个默认节点池。 AKS 中的此默认节点池包含运行代理节点的基础 VM。

注意

为了确保群集可靠运行，应至少在默认节点池上运行 2 个节点。

针对默认节点池缩放或升级 AKS 群集。 你可选择缩放或升级特定节点池。 对于升级操作，将在节点池中的其他节点上计划正在运行的容器，直到成功升级所有节点。

有关详细信息，请参阅创建节点池和管理节点池。

默认 OS 磁盘大小调整

在创建新群集或向现有群集添加新节点池时，OS 磁盘大小默认由 vCPU 数确定。 vCPU 数量根据 VM SKU 来决定。 下表列出了每个 VM SKU 的默认 OS 磁盘大小：

VM SKU 核心 (vCPU) 默认 OS 磁盘层 预配的 IOPS 预配吞吐量 (Mbps)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2300 150
64+ P30/1024G 5000 200

重要

仅当不支持临时 OS 磁盘且未指定默认 OS 磁盘大小时，才在新的群集或节点池上使用默认 OS 磁盘大小调整。 默认 OS 磁盘大小可能会影响群集的性能或成本。 创建群集或节点池后，无法更改 OS 磁盘大小。 此默认磁盘大小会影响 2022 年 7 月或之后创建的群集或节点池。

节点选择器

在包含多个节点池的 AKS 群集中，可能需要告知 Kubernetes 计划程序要将哪个节点池用于给定的资源。 例如，入口控制器不应在 Windows Server 节点上运行。 使用节点选择器来定义各种参数（例如节点 OS），从而控制对 Pod 进行计划的位置。

以下基本示例使用节点选择器 "kubernetes.io/os": linux 在 Linux 节点上调度 NGINX 实例：

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

有关详细信息，请参阅有关 AKS 中高级计划程序功能的最佳做法。

节点资源组

在创建 AKS 群集时，需要指定要在其中创建群集资源的 Azure 资源组。 除了此资源组外，AKS 资源提供程序还会创建和管理一个名为“节点资源组”的单独资源组。 节点资源组包含以下基础结构资源：

  • 节点池中每个节点的虚拟机规模集和 VM
  • 群集的虚拟网络
  • 群集的存储

默认情况下，会按以下格式向节点资源组分配一个名称：MC_resourceGroupName_clusterName_location。 在群集创建期间，可以指定分配给节点资源组的名称。 使用 Azure 资源管理器模板时，可以使用 nodeResourceGroup 属性定义名称。 使用 Azure CLI 时，将 --node-resource-group 参数与 az aks create 命令结合使用，如下例所示：

az aks create \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --node-resource-group myNodeResourceGroup \
    --generate-ssh-keys

在删除 AKS 群集时，AKS 资源提供程序会自动删除节点资源组。

节点资源组具有以下限制：

  • 不能为节点资源组指定现有资源组。
  • 不能为节点资源组指定不同的订阅。
  • 不能在创建群集后更改节点资源组名称。
  • 不能为节点资源组内的受管理资源指定名称。
  • 不能修改或删除节点资源组内受管理资源的由 Azure 创建的标记。

在 AKS 群集中的节点资源组下修改资源上任何 Azure 创建的标记是不受支持的操作，这会中断服务级别目标 (SLO)。 如果修改或删除节点资源组中 Azure 创建的标记或其他资源属性，可能会导致意外结果，例如缩放和升级错误。 AKS 管理节点资源组中的基础结构生命周期时，因此任何更改都会将群集移动到不受支持的状态。 有关详细信息，请参阅 AKS 是否提供服务级别协议？

使用 AKS，可以创建和修改传播到节点资源组中资源的标记，并且可以在创建或更新群集时添加这些标记。 有时，你可能想要创建或修改自定义标记，例如，在指定业务部门或成本中心时。 还可创建具有托管资源组范围的 Azure 策略。

要降低节点资源组中发生影响群集的更改的可能性，可以启用节点资源组锁定以将拒绝分配应用于 AKS 资源。 有关详细信息，请参阅完全受管理资源组（预览版）。

警告

如果没有启用节点资源组锁定，则可以直接修改节点资源组中的任何资源。 直接修改节点资源组中的资源可能会导致群集变得不稳定或无响应。

Pod

Kubernetes 使用 Pod 来运行应用程序的实例。 单个 Pod 表示应用程序的单个实例。

Pod 通常与容器是一对一映射关系。 在高级方案中，Pod 可能包含多个容器。 在同一个节点上共同计划这些多容器 Pod，并允许容器共享相关资源。

创建 Pod 时，可定义资源请求来获取一定数量的 CPU 或内存。 Kubernetes 计划程序尝试通过计划将要在具有可用资源的节点上运行的 Pod 来满足请求。 你还可指定最大资源限制，防止某 Pod 从基础节点消耗过多计算资源。 建议的最佳做法是包括所有 Pod 的资源限制，以帮助 Kubernetes 计划程序确认必需和允许的资源。

有关详细信息，请参阅 Kubernetes Pod 和 Kubernetes Pod 生命周期。

Pod 是逻辑资源，但应用程序工作负载在容器中运行。 Pod 通常是临时的、可释放的资源。 单个计划的 Pod 缺少某些高可用性和冗余 Kubernetes 功能。 相反，Pod 由 Kubernetes 控制器（例如部署控制器）进行部署和管理。

部署和 YAML 清单

部署表示由 Kubernetes 部署控制器管理的相同 Pod。 部署定义了要创建的 Pod 副本数量。 Kubernetes 计划程序可确保当 Pod 或节点出现故障时，将在正常节点上计划额外的 Pod。 可更新部署来更改 Pod 的配置、容器映像或附加存储。

部署控制器会管理部署生命周期并执行以下操作：

  • 排出并终止给定数量的副本。
  • 根据新的部署定义创建副本。
  • 继续此过程，直到部署中的所有副本都已更新。

AKS 中的大多数无状态应用程序应使用部署模型，而不是计划单个 Pod。 Kubernetes 可监视部署运行状况和状态，确保在群集中运行所需数量的副本。 单独计划 Pod 时，如果 Pod 出现故障，则不会重启；如果当前节点出现故障，则不会在正常节点上重新计划。

如果你的应用程序需要最低数量的可用实例，那么你不希望更新过程干扰管理决定。 Pod 中断预算定义了在更新或节点升级期间部署中可删除的副本数。 例如，如果你的部署中有 5 个副本，你可以定义 4 个 Pod 中断，以便一次只允许删除/重新计划一个副本。 使用 Pod 资源限制，建议的最佳做法是在需要始终存在最少数量副本的应用程序上定义 Pod 中断预算。

通常使用 kubectl create 或 kubectl apply 来创建和管理部署。 可通过定义 YAML 格式的清单文件来创建部署。 以下示例演示 NGINX Web 服务器的基本部署清单文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

YAML 清单文件中的部署规范明细如下：

规格 说明
.apiVersion 指定想要在创建资源时使用的 API 组和 API 资源。
.kind 指定想要创建的资源类型。
.metadata.name 指定部署的名称。 此示例 YAML 文件从 Docker 中心运行 nginx 映像。
.spec.replicas 指定要创建的 Pod 数量。 此示例 YAML 文件创建 3 个重复的 Pod。
.spec.selector 指定将受此部署影响的 Pod。
.spec.selector.matchLabels 包含 {key, value} 对的映射，通过该键值对，部署可以查找并管理已创建的 Pod。
.spec.selector.matchLabels.app 必须匹配 .spec.template.metadata.labels。
.spec.template.labels 指定附加到该对象的 {key, value} 对。
.spec.template.app 必须匹配 .spec.selector.matchLabels。
.spec.spec.containers 指定属于 Pod 的容器列表。
.spec.spec.containers.name 指定指定为 DNS 标签的容器名称。
.spec.spec.containers.image 指定容器映像名称。
.spec.spec.containers.ports 指定要从容器公开的端口列表。
.spec.spec.containers.ports.containerPort 指定要在 Pod 的 IP 地址上公开的端口数。
.spec.spec.resources 指定容器所需的计算资源。
.spec.spec.resources.requests 指定所需的最小计算资源量。
.spec.spec.resources.requests.cpu 指定所需的最小 CPU 量。
.spec.spec.resources.requests.memory 指定所需的最小内存量。
.spec.spec.resources.limits 指定允许的最大计算资源量。 kubelet 强制实施此限制。
.spec.spec.resources.limits.cpu 指定允许的最大 CPU 量。 kubelet 强制实施此限制。
.spec.spec.resources.limits.memory 指定允许的最大内存量。 kubelet 强制实施此限制。

通过在 YAML 清单中包含负载均衡器等服务，可以创建更复杂的应用程序。

有关详细信息，请参阅 Kubernetes 部署。

使用 Helm 进行包管理

Helm 通常用于管理 Kubernetes 中的应用程序。 可生成和使用包含应用程序代码打包版本和 Kubernetes YAML 清单的现有公共 Helm 图表来部署资源。 Helm 图表可存储在本地，也可存储在远程存储库中，例如 Azure 容器注册表 Helm 图表存储库。

要使用 Helm，请在计算机上安装 Helm 客户端，或使用 Azure Cloud Shell 中的 Helm 客户端。 搜索或创建 Helm 图表，然后将其安装到 Kubernetes 群集。 有关详细信息，请参阅在 AKS 中使用 Helm 安装现有应用程序。

StatefulSet 和 DaemonSet

部署控制器使用 Kubernetes 计划程序，并在具有可用资源的任何可用节点上运行副本。 虽然这种方法对于无状态应用程序可能已经足够，但但对于需要以下规范的应用程序来说，部署控制器并不理想：

  • 永久性命名约定或存储。
  • 群集中每个特选节点上存在的副本。

不过，通过以下两种 Kubernetes 资源可以管理这类应用程序：StatefulSet 和 DaemonSet。

StatefulSet：维护超出单个 Pod 生命周期的应用程序的状态。 DaemonSet 确保在 Kubernetes 启动进程早期每个节点上都有正在运行的实例。

StatefulSet

现代应用程序开发通常以无状态应用程序为目标。 对于有状态应用程序（例如包含数据库组件的应用程序），可使用 StatefulSets。 与部署类似，StatefulSet 创建和管理至少一个相同的 Pod。 StatefulSet 中的副本按照正常有序的方法来部署、缩放、升级和终止操作。 以副本形式保存的命名约定、网络名称和存储用 StatefulSet 重新计划。

可使用 kind: StatefulSet 定义 YAML 格式的应用程序。 从这里，由 StatefulSet 控制器处理所需副本的部署和管理。 数据写入到由 Azure 托管磁盘或 Azure 文件提供的永久性存储。 基础持久性存储仍然保持不变，即使删除 StatefulSet 也是如此，除非将 spec.persistentVolumeClaimRetentionPolicy 设置为 Delete。 有关详细信息，请参阅 Kubernetes StatefulSet。

重要

计划 StatefulSet 中的副本，并在 AKS 群集中的任何可用节点上运行这些副本。 为了确保你的集中至少有一个 Pod 在节点上运行，应转而使用 DaemonSet。

DaemonSet

对于特定的日志集合或监视，可能需要在所有节点或选定的一组节点上运行 Pod。 可以使用 DaemonSets 部署到一个或多个相同的 Pod。 DaemonSet 控制器可确保指定的每个节点都运行一个 Pod 实例。

在默认的 Kubernetes 计划程序启动之前，DaemonSet 控制器可以在群集启动进程的早期计划节点上的 Pod。 此功能可确保在计划 Deployment 或 StatefulSet 中的传统 Pod 之前启动 DaemonSet 中的 Pod。

与 StatefulSet 一样，可使用 kind: DaemonSet 将 DaemonSet 定义为 YAML 定义的一部分。

有关详细信息，请参阅 Kubernetes DaemonSet。

注意

如果使用虚拟节点加载项，DaemonSet 不会在虚拟节点上创建 Pod。

命名空间

Kubernetes 资源（如 Pod 和部署）按逻辑合并到一个命名空间中，以划分 AKS 群集并创建、查看资源或管理对资源的访问。 例如，可创建命名空间来分隔业务组。 用户只能与分配的命名空间内的资源进行交互。

Kubernetes 命名空间以逻辑方式划分资源和应用程序

创建 AKS 群集时，可使用以下命名空间：

命名空间 说明
default 不提供任何命名空间时，默认在此命名空间中创建 Pod 和部署。 在小型环境中，可以将应用程序直接部署到默认命名空间，而无需创建其他逻辑分隔。 与 Kubernetes API（例如 kubectl get pods）交互时，如果未指定命名空间，则使用默认值。
kube-system 此命名空间中有核心资源，例如 DNS 和代理等网络功能或 Kubernetes 仪表板。 通常不会将应用程序部署到此命名空间中。
kube-public 通常不使用此命名空间，但你可使用它来使资源在整个群集中可见，并且可供任何用户查看。

有关详细信息，请参阅 Kubernetes 命名空间。

后续步骤

有关核心 Kubernetes 和 AKS 概念的详细信息，请参阅以下文章：