我仅将资源分配给 1 个 pod，内存为 650MB/30%（对于其他内置 pod，限制内存仅为 69%）
然而，在 Pod 处理过程中，Pod 的使用量在 650MB 以内，但 Node 的总体使用率为 94%。
为什么会出现这种情况，因为它的上限应该是 69%？是不是其他内置pod没有设置限制的原因？如果内存使用率 > 100%，有时我的 pod 会出错，如何防止这种情况发生？
My allocation setting (kubectl describe nodes):
Memory usage of Kubernetes Node and Pod when idle:
kubectl top nodes
kubectl top pods
Memory usage of Kubernetes Node and Pod when running task:
kubectl top nodes
kubectl top pods
进一步测试的行为：
1. 准备命名空间下的deployment、pods和servicetest-ns
2. 因为只有kube 系统 and test-ns有 pod，因此为每个 pod 分配 1000Mi（从kubectl describe nodes) 目标小于 2GB
3. 假设内存使用于kube 系统 and test-ns会小于2GB，小于100%，为什么内存使用率可以是106%？
In .yaml 文件：
apiVersion: v1
kind: LimitRange
metadata:
name: default-mem-limit
namespace: test-ns
spec:
limits:
- default:
memory: 1000Mi
type: Container
---
apiVersion: v1
kind: LimitRange
metadata:
name: default-mem-limit
namespace: kube-system
spec:
limits:
- default:
memory: 1000Mi
type: Container
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: devops-deployment
namespace: test-ns
labels:
app: devops-pdf
spec:
selector:
matchLabels:
app: devops-pdf
replicas: 2
template:
metadata:
labels:
app: devops-pdf
spec:
containers:
- name: devops-pdf
image: dev.azurecr.io/devops-pdf:latest
imagePullPolicy: Always
ports:
- containerPort: 3000
resources:
requests:
cpu: 600m
memory: 500Mi
limits:
cpu: 600m
memory: 500Mi
imagePullSecrets:
- name: regcred
---
apiVersion: v1
kind: Service
metadata:
name: devops-pdf
namespace: test-ns
spec:
type: LoadBalancer
ports:
- port: 8007
selector:
app: devops-pdf
这种影响很可能是由该节点上运行的 4 个 Pod 引起的without指定的内存限制，显示为0 (0%)。当然0并不意味着它不能使用哪怕一个字节的内存，因为不使用内存就无法启动程序；相反，这意味着没有限制，可以使用尽可能多的东西。此外，不在 pod 中运行的程序（ssh、cron 等）也包含在总使用量中，但不受 kubernetes（cgroup）限制。
现在，kubernetes 以一种巧妙的方式设置内核 oom 调整值，以支持其内存下的容器request，使其更有可能杀死内存之间的容器中的进程request and limit，并使其最有可能杀死没有内存的容器中的进程limits。然而，这仅在长期运行中表现得相当好，有时内核可以杀死你最喜欢的容器中表现良好的你最喜欢的进程（使用少于其内存的进程）request). See https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior
在这种特殊情况下，没有内存限制的 pod 来自 aks 系统本身，因此在 pod 模板中设置其内存限制不是一个选项，因为有一个协调器将恢复它（最终）。为了解决这种情况，我建议您在 kube-system 命名空间中创建一个 LimitRange 对象，该对象将为所有 pod 分配内存限制，而没有限制（在创建它们时）：
apiVersion: v1
kind: LimitRange
metadata:
name: default-mem-limit
namespace: kube-system
spec:
limits:
- default:
memory: 150Mi
type: Container
（您需要删除已经存在的Pods没有内存限制才能生效；他们将被重新创建）
这并不能完全消除问题，因为您最终可能会遇到过度使用的节点；然而，内存使用将是有意义的，并且 oom 事件将更可预测。