为什么内存使用量比我在 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下的部署、pods 和服务
2. 由于只有kube-system和test-ns有 pods，所以每个分配 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 调整值，以支持在其内存请求下的容器，使其更有可能杀死处于其内存请求和限制之间的容器中的进程，并使其最有可能杀死进程。在没有内存限制的容器中。 但是，这只是从长远来看才显示出相当有效，有时内核可以杀死您最喜欢的容器中表现良好的您最喜欢的进程（使用少于其内存请求）。 请参阅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

（您需要删除没有内存限制的现有Pod才能生效；它们将被重新创建）

这不会完全消除问题，因为您最终可能会得到一个过度使用的节点； 然而，内存使用是有意义的，oom 事件将更可预测。