我的应用程序中的 pod 按照每个用户 1 个 pod 进行扩展（每个用户都有自己的 pod）。我对应用程序容器的限制设置如下：
resources:
limits:
cpu: 250m
memory: 768Mi
requests:
cpu: 100m
memory: 512Mi
我的节点池中的每个节点都有 8GB 内存。我启动了一堆用户实例来开始测试，并观察了资源指标在启动每个实例时上升的情况：
中央处理器：
记忆：
在 15:40，我看到事件日志显示此错误（注意：第一个节点使用污点排除）：
0/2 nodes are available: 1 Insufficient memory, 1 node(s) didn't match node selector.
当内存/CPU 请求仍远低于总容量（CPU 约占 50%，内存约占 60%）时，为什么会发生这种情况？
以下是一些相关信息kubectl describe node：
Non-terminated Pods: (12 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ide theia-deployment--ac031811--football-6b6d54ddbb-txsd4 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 13m
ide theia-deployment--ac031811--footballteam-6fb7b68794-cv4c9 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 12m
ide theia-deployment--ac031811--how-to-play-football-669ddf7c8cjrzl 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 14m
ide theia-deployment--ac031811--packkide-7bff98d8b6-5twkf 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 9m54s
ide theia-deployment--ac032611--static-website-8569dd795d-ljsdr 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 16m
ide theia-deployment--aj090111--spiderboy-6867b46c7d-ntnsb 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 2m36s
ide theia-deployment--ar041311--tower-defenders-cf8c5dd58-tl4j9 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 14m
ide theia-deployment--np091707--my-friends-suck-at-coding-fd48ljs7z 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 4m14s
ide theia-deployment--np091707--topgaming-76b98dbd94-fgdz6 110m (5%) 350m (18%) 528Mi (9%) 832Mi (15%) 5m17s
kube-system csi-azurefile-node-nhbpg 30m (1%) 400m (21%) 60Mi (1%) 400Mi (7%) 12d
kube-system kube-proxy-knq65 100m (5%) 0 (0%) 0 (0%) 0 (0%) 12d
lens-metrics node-exporter-57zp4 10m (0%) 200m (10%) 24Mi (0%) 100Mi (1%) 6d20h
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1130m (59%) 3750m (197%)
memory 4836Mi (90%) 7988Mi (148%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
attachable-volumes-azure-disk 0 0
答案1
根据 kubernetes文档：
如何调度有资源请求的 Pod
当您创建 Pod 时，Kubernetes 调度程序会选择一个节点供 Pod 运行。每个节点对每种资源类型都有最大容量：它可以为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度容器的资源请求总和小于节点的容量。请注意，尽管节点上实际内存或 CPU 资源使用率非常低，但如果容量检查失败，调度程序仍然会拒绝将 Pod 放置在节点上。当资源使用量随后增加时（例如，在请求率达到每日峰值期间），这可以防止节点出现资源短缺的情况。
有关如何运行 pod 限制的更多信息，请参见这里。
更新：
可以通过重新调整内存限制并添加符合您偏好的驱逐策略来优化资源消耗。您可以在 kubernetes 文档中找到更多详细信息这里和这里。
更新 2：
为了更好地理解为什么调度程序拒绝将 Pod 放置在节点上，我建议在 AKS 集群中启用资源日志。请查看 AKS 的指南文档. 从常见日志中查找kube-scheduler日志以查看更多详细信息。
答案2
我发现，查看可用容量时，需要注意Allocatable，而不是Capacity。来自 Azure 支持：
请查看此文档“资源预留”，如果我们按照该文档中的示例（使用每个节点 8GB 的整数）：
0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 8GB = 29.37% reserved对于 8GB 的服务器，保留的量约为 29.37%，这意味着：
节点预留的内存量 =
29.37% * 8000 = 2349。可分配剩余内存 =5651前 9 个 Pod 将使用 =9 * 528 = 4752第一个 Pod 之后的可分配剩余内存 =899（kubectl describe node 中显示的可分配内存应为 OS 预留后可用的数量）在最后一个数字中，我们必须考虑运行所需的操作系统预留，因此在使用操作系统预留内存后，可能没有足够的空间容纳节点上的更多 pod，因此出现消息。
根据计算结果，这将导致预期的行为。