為什麼當節點有足夠的可用資源時，Pod 無法調度？
我的應用程序中的 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%，mem 約為 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
我發現在查看可用容量時，您需要注意
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%，這意味著：
node = 保留的記憶體量
29.37% * 8000 = 2349。Allocatable剩餘記憶體=5651前9個pods將使用=9 * 528 = 4752第一個pods後分配的剩餘記憶體=899（kubectl describe節點中顯示的可分配記憶體，應該是OS預留後可用的數量）在最後一個數字中，我們必須考慮它需要執行的作業系統預留，因此可能在佔用作業系統預留記憶體之後，節點上沒有足夠的空間容納更多的 pod，因此消息。
考慮到計算，這將導致預期的行為。
根據 kubernetes文件：
如何調度具有資源請求的 Pod
更新：
可以通過重新調整記憶體限制和添加適合您偏好的驅逐策略來優化資源消耗。您可以在此處和此處的 kubernetes 文件中找到更多詳細資訊。
更新 2：
為了更好地理解調度程序拒絕將 Pod 放置在節點上的原因，我建議在您的 AKS 群集中啟用資源日誌。查看 AKS文件中的本指南。從常見日誌中查找
kube-scheduler日誌以查看更多詳細資訊。