适用于: ✔️ AKS 自动 ✔️ AKS 标准
在 Azure Kubernetes 服务(AKS)中管理群集时,通常需要隔离团队和工作负荷。 通过逻辑隔离,可以将单个 AKS 群集用于多个工作负荷、团队或环境。 Kubernetes 命名空间构成了工作负载和资源的逻辑隔离边界。 执行逻辑隔离涉及实现脚本和过程来创建命名空间、设置资源限制、应用网络策略,以及通过基于角色的访问控制授予团队访问权限。 了解如何在 Azure Kubernetes 服务(AKS)中使用托管命名空间来简化命名空间管理、群集多租户和资源隔离。
群集的逻辑分离通常提供比物理隔离群集更高的 Pod 密度,群集中空闲的计算容量不足。 与 群集自动缩放程序 或 节点自动预配结合使用时,可以纵向扩展或缩减节点数以满足需求。 此最佳做法方法仅运行所需的节点数,从而最大程度地降低成本。
网络策略
网络策略 是 Kubernetes 资源,可用于控制 Pod、命名空间和外部终结点之间的流量流。 网络策略允许你定义入口(传入)和出口(传出)流量的规则,确保只允许经过授权的通信。 通过应用网络策略,可以增强群集中工作负荷的安全性和隔离性。
注释
“允许同一命名空间”的默认入口网络策略规则默认选择采用安全的立场。 如果需要从部署它们的命名空间外部访问 Kubernetes 服务、入口或网关,例如,需要从部署在单独命名空间中的入口控制器访问,则需要选择 “全部允许”。 然后,可以应用自己的网络策略来限制入口仅来自该命名空间。
托管命名空间附带一组内置策略。
- 全部允许:允许所有网络流量。
- 允许同一命名空间:允许同一命名空间中的所有网络流量。
- 全部拒绝:拒绝所有网络流量。
可以对 入口 和 出口 规则应用任何内置策略,并且它们具有以下默认值。
| Policy | 默认值 |
|---|---|
| 流入量 | 允许同一命名空间 |
| Egress | 全部允许 |
注释
对所分配的 Microsoft Entra ID 角色执行 Microsoft.ContainerService/managedClusters/networking.k8s.io/networkpolicies/write 操作(例如 Azure Kubernetes Service RBAC Writer)的用户可以通过 Kubernetes API 添加更多网络策略。
例如,如果管理员为入口/出口应用 Deny All 策略,并且用户通过 Kubernetes API 为命名空间应用 Allow 策略,则 Allow 策略优先于 Deny All 策略,并允许流量流向命名空间。
资源配额
资源配额 是用于管理和限制群集中命名空间的资源消耗的 Kubernetes 资源。 它们允许管理员定义命名空间中工作负荷使用的 CPU、内存、存储或其他资源量的约束。 通过应用资源配额,可以确保资源分配公平、防止资源过度使用和维护群集稳定性。
可以使用以下资源配额创建托管命名空间:
- CPU 请求和限制:定义命名空间中工作负荷可以请求或使用的最小和最大 CPU 资源量。 配额可确保工作负荷有足够的 CPU 资源运行,同时防止过度使用可能会影响其他命名空间。 配额以 milliCPU 形式定义。
-
内存请求和限制:指定命名空间中工作负荷可以请求或使用的最小和最大内存资源量。 配额通过避免内存过度使用并确保跨命名空间公平资源分配来帮助保持稳定性。 配额以两种等效项的形式定义,例如
Ei,Pi、TiGiMiKi。
标签和批注
Kubernetes 标签 和 注释 是附加到 Kubernetes 对象(如命名空间)的元数据,可提供其他信息。 标签是用于组织和选择资源的键值对,可实现高效的分组和查询。 批注存储不具标识性的元数据,例如配置详细信息或操作说明,供工具或系统使用。
可以选择性地设置要应用于命名空间的 Kubernetes 标签和批注。
采用策略
采用策略确定在创建托管命名空间时如何处理 Kubernetes 中的现有命名空间。
警告
载入要管理的现有命名空间可能会导致中断。 如果应用 的资源配额 小于 Pod 请求的资源配额,则会拒绝超过配额的新部署和 Pod。 现有部署不受影响,但缩放被拒绝。 将 网络策略 应用于现有命名空间可能会影响现有流量。 确保测试并验证策略,以避免 Pod 或外部终结点之间的通信发生意外中断。
可以使用以下选项:
- 从不:如果群集中已存在命名空间,则尝试将该命名空间创建为托管命名空间失败。
- IfIdentical:接管要管理的现有命名空间,前提是现有命名空间与所需配置之间没有任何差异。
- 始终:始终接管要管理的现有命名空间,即使可能会覆盖命名空间中的某些字段。
删除策略
删除策略指定删除托管命名空间资源时 Kubernetes 命名空间的处理方式。
警告
使用 Delete 策略删除托管命名空间会导致删除该命名空间中的所有资源,例如部署、服务、入口和其他 Kubernetes 对象。 在继续作之前,请确保备份或迁移任何关键资源。
可以使用以下选项:
-
保留:仅在使 Kubernetes 命名空间保持不变时删除托管命名空间资源。 此外,
ManagedByARM标签将从命名空间中删除。 - 删除:同时删除托管命名空间资源和 Kubernetes 命名空间。
托管命名空间内置角色
托管命名空间对控制平面使用以下内置角色。
| 角色 | Description |
|---|---|
| Azure Kubernetes 服务命名空间参与者 | 允许访问群集上的创建、更新和删除托管命名空间。 |
| Azure Kubernetes 服务命名空间用户 | 允许对群集上的托管命名空间进行只读访问。 允许访问命名空间上的凭据。 |
托管命名空间对数据平面使用以下内置角色。
| 角色 | Description |
|---|---|
| Azure Kubernetes 服务 RBAC 读取器 | 允许进行只读访问并查看命名空间中的大多数对象。 它不允许查看角色或角色绑定。 此角色不允许查看机密,因为读取机密的内容允许访问命名空间中的 ServiceAccount 凭据,这将允许 API 访问作为命名空间中的任何 ServiceAccount(特权升级形式)。 |
| Azure Kubernetes 服务 RBAC 编写器 | 允许对命名空间中的大多数对象进行读/写访问。 此角色不允许查看或修改角色或角色绑定。 但是,允许此角色以命名空间中任何 ServiceAccount 的身份访问机密和运行 Pod,因此可用它获取命名空间中任何 ServiceAccount 的 API 访问级别。 |
| Azure Kubernetes 服务 RBAC 管理员 | 允许对命名空间中的大多数资源进行读/写访问,包括能够在命名空间中创建角色和角色绑定。 此角色不允许对资源配额或命名空间本身进行写入访问。 |
托管命名空间用例
正确设置命名空间以及关联的配额或网络策略可能很复杂且耗时。 托管命名空间允许在 AKS 群集中设置预配置的命名空间,这些命名空间可以使用 Azure CLI 进行交互。
以下部分概述了托管命名空间的一些常见用例。
在 AKS 上管理团队和资源
假设你是一个小型初创公司的管理员。 你已预配 AKS 群集,并希望从财务、法律和设计团队为开发人员设置命名空间。 在设置公司环境时,需要确保严格控制访问权限、正确限定资源范围,并正确组织环境。
财务团队从公司各个团队中收集表单和文件,但这些材料包含敏感信息,理想情况下不应离开财务团队所在的环境。 其应用程序和工作流在计算端较轻,但占用大量内存。 因此,你决定设置一个命名空间,该命名空间允许所有网络入口、网络出口仅在其命名空间内,并相应地限定其资源范围。 命名空间的标签有助于轻松确定哪个团队正在使用它。
az aks namespace add \ --name $FINANCE_NAMESPACE \ --cluster-name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --cpu-request 250m \ --cpu-limit 500m \ --memory-request 512Mi \ --memory-limit 2Gi \ --ingress-policy AllowAll \ --egress-policy AllowSameNamespace \ --labels team=finance法律团队主要处理敏感数据。 其应用程序使用大量内存,但需要很少的计算资源。 你决定为入口/出口策略设置极其严格的命名空间,并相应地确定其资源配额的范围。
az aks namespace add \ --name $LEGAL_NAMESPACE \ --cluster-name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --cpu-request 250m \ --cpu-limit 500m \ --memory-request 2Gi \ --memory-limit 5Gi \ --ingress-policy DenyAll \ --egress-policy DenyAll \ --labels team=legal设计团队需要能够自由流动数据,以在整个公司展示其工作。 他们还鼓励团队向他们发送内容以供参考。 其应用程序很密集,需要大量内存和 CPU。 你决定使用限制最少的命名空间进行设置,并为其分配大量资源。
az aks namespace add \ --name $DESIGN_NAMESPACE \ --cluster-name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --cpu-request 2000m \ --cpu-limit 2500m \ --memory-request 5Gi \ --memory-limit 8Gi \ --ingress-policy AllowAll \ --egress-policy AllowAll \ --labels team=design
设置这些命名空间后,你现在在组织中拥有三个团队的环境,该环境应允许每个团队在最适合其需求的环境中启动和运行。 管理员可以使用 Azure CLI 调用 根据需要更新命名空间。
查看托管命名空间
随着你处理的团队数量的增长,或者随着组织的增长,你可能会发现自己需要查看你设置的命名空间。
假设你想要从 上一部分 查看群集中的命名空间,以确保有三个命名空间。
使用az aks namespace list命令来查看命名空间。
az aks namespace list \
--cluster-name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--output table
输出应类似于以下示例输出:
Name ResourceGroup Location
------------------ --------------- ----------
$CLUSTER_NAME/$DESIGN_NAMESPACE $RESOURCE_GROUP <LOCATION>
$CLUSTER_NAME/$LEGAL_NAMESPACE $RESOURCE_GROUP <LOCATION>
$CLUSTER_NAME/$FINANCE_NAMESPACE $RESOURCE_GROUP <LOCATION>
控制对托管命名空间的访问
可以进一步使用作用域为每个命名空间的 Azure RBAC 角色来确定哪些用户有权访问命名空间中的某些操作。 使用适当的配置,可以确保用户拥有命名空间内所需的所有访问权限,同时限制用户对其他命名空间或群集范围资源的访问权限。
后续步骤
- 了解如何 在 Azure Kubernetes 服务(AKS)上创建和使用托管命名空间。
- 了解使用 Azure Kubernetes Fleet Manager 的多 群集托管命名空间 。