【问题标题】:Kubernetes - what happens if you don't set a pod CPU request or limit?Kubernetes - 如果不设置 pod CPU 请求或限制会发生什么?
【发布时间】:2022-03-28 11:56:45
【问题描述】:

我理解在 Kubernetes pod 上为 CPU 和/或 memory 资源设置 requestlimit 的概念,但我想了解如果您不设置会发生什么requestlimit 表示 CPU?

我们已经配置了一个 NGINX pod,但它的CPU 没有设置requestlimit。我假设它至少有1 millicore,并且会根据需要为该 pod 提供尽可能多的毫核,并且在节点上可用。如果节点用尽了所有可用的内核,那么它​​会停留在 1 毫内核吗?

【问题讨论】:

    标签: kubernetes


    【解决方案1】:

    如果您没有为 CPU 设置请求或限制,会发生什么情况?

    当你没有指定 CPU 请求时,你是在说你没有 关心在你的容器中运行的进程有多少 CPU 时间 已分配。

    在最坏的情况下,它可能根本得不到任何 CPU 时间(发生这种情况 当 CPU 上存在其他进程的大量需求时)。虽然 这对于低优先级的批处理作业可能没问题,这不是 时间紧迫,显然不适合集装箱处理 用户请求。

    您还为容器请求1 millicore 的内存。经过 这样做,你是说你期望进程运行 在容器内最多使用 N mebibytes 的 RAM。他们 可能会使用更少,但您不希望他们使用更多 在正常情况下。

    了解资源请求如何影响调度

    通过指定资源请求,您可以指定 pod 所需的最低资源量。此信息是调度程序在将 pod 调度到节点时使用的信息。

    每个节点都有一定数量的 CPU 和内存,可以分配给 pod。在调度 Pod 时,Scheduler 只会考虑具有足够未分配资源的节点来满足 Pod 的资源需求。

    如果未分配的 CPU 或内存量小于 pod 请求的量,Kubernetes 不会将 pod 调度到该节点,因为该节点无法提供 pod 所需的最小量。

    了解如果超出限制会发生什么

    使用 CPU

    CPU 是一种可压缩资源,进程想要在不等待 I/O 操作时消耗所有 CPU 时间是很自然的。

    进程的 CPU 使用率受到限制,因此当为容器设置 CPU 限制时,不会为进程分配超过配置限制的 CPU 时间。

    有记忆

    有了记忆,情况就不同了。当一个进程试图分配超过其限制的内存时,该进程被杀死(据说容器是OOMKilled,其中OOM代表内存不足)。 如果 pod 的重启策略设置为 Always 或 OnFailure,则该进程会立即重启,因此您甚至可能不会注意到它被杀死。但是,如果它继续超过内存限制并被杀死,Kubernetes 将开始重新启动它,并且重新启动之间的延迟会增加。在这种情况下,您会看到 CrashLoopBackOff 状态。

    kubectl get po
    NAME        READY     STATUS             RESTARTS   AGE
    memoryhog    0/1   CrashLoopBackOff         3       1m
    

    注意:CrashLoopBackOff 状态并不意味着 Kubelet 已放弃。这意味着每次崩溃后,Kubelet 都会增加重启容器之前的时间。

    了解检查容器崩溃的原因

    kubectl describe pod
    Name:
    ...
    Containers:
    main: ...
        State: Terminated
          Reason: OOMKilled
    ...
    

    注意原因属性OOMKilled。当前容器因内存不足 (OOM) 而被杀死。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2023-03-24
      • 2020-03-28
      • 1970-01-01
      • 2021-09-03
      • 1970-01-01
      • 2023-03-03
      • 2021-05-17
      • 2018-03-07
      相关资源
      最近更新 更多