Kubernetes Pod获得不同的CPU限制

在Kubernetes集群中,我们有几个使用Apache Ignite的应用程序。 Ignite创建各种大小如下的线程池:

Math.max(8,Runtime.getRuntime().availableProcessors())

因此,基本上,线程池将始终至少具有大小8,但如果系统认为存在更多处理器,则可以更大。

我们遇到的问题是,某些pod的池大小为8,而其他pod的大小为36,这是节点上的CPU数量。

我们正在使用Helm来部署所有应用程序,但是我们为任何pod设置任何CPU限制。从理论上讲,他们都应该看到相同数量的可用CPU。

还有什么可能导致同一节点上的pod看到多少个可用处理器的不同视图?

更新

我们所有应用程序中都有一个运行状况端点,它使用与Ignite相同的Runtime#availableProcessors()方法来显示JVM报告的CPUS数量。

我们所有的应用程序(包括Ignite认为有36个CPU的应用程序)在进程启动后都会报告2个处理器。

我在Java文档中找到了该方法的有趣之处:

  

在虚拟机的特定调用期间,此值可能会更改。因此,对可用处理器数量敏感的应用程序应该偶尔轮询此属性并适当地调整其资源使用情况。

似乎我们处于竞争状态,在应用程序启动初期,该值报告为36,但有时会降至2。根据何时点燃Ignite bean,它们看到的是36还是2。 / p>

qhslz 回答:Kubernetes Pod获得不同的CPU限制

tl; dr 根本的问题似乎是当resources.requests.cpu精确设置为1000m时。

我编写了一个简单的Java应用程序,该应用程序转储了可用数量的处理器:

public class CpuTest {
  public static void main(String[] args) {
    System.out.println("Number of CPUs = " + Runtime.getRuntime().availableProcessors());   
  }
}

我打包到一个Dockerfile中并创建了一个简单的部署:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cputest
  labels:
    app: cputest
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cputest
  template:
    metadata:
      labels:
        app: cputest
    spec:
      containers:
      - name: cputest
        image: dev/cputest:latest
        imagePullPolicy: Never

我在具有24个核心的本地RedHat 7机器上运行了该程序。预期输出:

Number of CPUs = 24

然后我将各种CPU资源请求应用于部署:

        resources:
          requests:
            cpu: 1000m

,然后重新部署。结果很有趣:

  • CPU请求设置为500m:该应用报告1个CPU
  • CPU请求设置为1000m:该应用报告24个CPU
  • CPU请求设置为1001m:该应用报告2个CPU
  • CPU请求设置为2000m:该应用报告2个CPU
  • CPU请求设置为4000m:该应用报告4个CPU

因此,仅当将CPU请求设置为1000m(也尝试1并获得相同的结果(认为它具有全部24个CPU))时,才会出现此问题。

我回头查看了我们所有的应用程序。当然,我们将CPU请求设置为完全1000m的地方就是有问题的地方。任何其他值都可以正常工作。

最重要的是,当我还将CPU限制设置为1000m时,问题就消失了,JVM报告了1个CPU。

这很可能是预料之中的,我不完全了解Kubernetes如何使用CPU资源和限制,或者我们使用的版本(1.12.7)可能存在问题。

无论哪种方式,我至少都有一个答案,为什么我们的某些吊舱会看到不同的CPU。

,

确实很奇怪。它们在同一个名称空间中吗?掌舵表是否有quotaLimit range或您已设置?

还可以通过运行kubectl get nodes -o custom-columns='NAME:metadata.name,CPU:status.capacity.cpu'来验证cpu的限制吗?

本文链接:https://www.f2er.com/3156255.html

大家都在问