为什么内存使用量大于我在 Kubernetes 的节点中设置的？

Question

我只为 1 个 pod 分配了 650MB/30% 内存的资源（对于其他内置 pod，限制内存仅为 69%）

但是，在处理 pod 的过程中，pod 的使用率在 650MB 以内，但 node 的总体使用率是 94%。

为什么会发生，因为它应该有 69% 的上限？是不是因为其他内置的 pod 没有设置限制？如果内存使用率 > 100%，如何防止这种情况发生，因为有时我的 pod 会出错？

我的分配设置（kubectl describe nodes）：

Kubernetes Node 和 Pod 空闲时的内存使用情况：
kubectl top nodes

kubectl top pods

Kubernetes Node 和 Pod 运行任务时的内存使用情况：
kubectl top nodes

kubectl top pods

---

进一步测试的行为：
1. 准备命名空间test-ns下的deployment、pods和service
2. 由于只有 kube-system 和 test-ns 有 pod，因此为它们每个分配 1000Mi（来自kubectl describe nodes），目标是小于 2GB
3. 假设 kube-system 和 test-ns 使用的内存小于 2GB 小于 100%，为什么内存使用率可以达到 106%？

在 .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

Answer 1

这种影响很可能是由于在该节点上运行的 4 个 Pod没有指定的内存限制，显示为 0 (0%)。当然 0 并不意味着它甚至不能使用一个字节的内存，因为不使用内存就无法启动任何程序；相反，它意味着没有限制，它可以尽可能多地使用。不在 pod 中运行的程序（ssh、cron、...）也包括在总使用量中，但不受 kubernetes 的限制（由 cgroups）。

现在 kubernetes 以一种巧妙的方式设置内核 oom 调整值，以支持在其内存 request 下的容器，使其更有可能杀死在其内存之间的容器中的进程 request 和 limit，并使其最有可能杀死没有内存limits 的容器中的进程。然而，从长远来看，这仅显示为正常工作，有时内核可以杀死您最喜欢的容器中表现良好的您最喜欢的进程（使用少于其内存request）。见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 事件将更可预测。