Mik*_*ike 3 kubernetes kubernetes-helm
我们在 Kubernetes 集群中有多个使用 Apache Ignite 的应用程序。Ignite 创建各种大小如下的线程池:
Math.max(8, Runtime.getRuntime().availableProcessors())
Run Code Online (Sandbox Code Playgroud)
因此基本上线程池的大小始终至少为 8,但如果系统认为有更多处理器,则可能会更大。
我们遇到的问题是,一些 pod 使用池大小 8 旋转,而其他 pod 使用池大小 36,这是节点上的 CPU 数量。
我们使用 Helm 来部署所有应用程序,但我们没有为任何 pod 设置任何 CPU 限制。理论上,它们都应该看到相同数量的可用 CPU。
还有什么可能导致同一节点上的 Pod 查看可用处理器数量的不同视图?
我们的所有应用程序都有一个运行状况端点,它使用与 Ignite 使用的相同方法显示 JVM 报告的 CPUS 数量Runtime#availableProcessors()。
我们的所有应用程序(包括 Ignite 认为有 36 个 CPU 的应用程序)都会在进程启动后报告 2 个处理器。
我在该方法的 Java 文档中发现了这一有趣的行:
该值可能会在虚拟机的特定调用期间发生变化。因此,对可用处理器数量敏感的应用程序应偶尔轮询此属性并适当调整其资源使用情况。
我们似乎处于竞争状态,在应用程序启动初期,该值报告为 36,但在某些时候会下降到 2。根据 Ignite beans 的触发时间,它们会看到 36 或 2。
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());
}
}
Run Code Online (Sandbox Code Playgroud)
我打包成 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
Run Code Online (Sandbox Code Playgroud)
我在本地 RedHat 7 机器上运行了这个程序,该机器有 24 个内核。预期输出:
Number of CPUs = 24
Run Code Online (Sandbox Code Playgroud)
然后,我将各种 CPU 资源请求应用于部署:
Number of CPUs = 24
Run Code Online (Sandbox Code Playgroud)
并重新部署。结果很有趣:
因此,只有在设置了 CPU 请求时才会出现问题1000m(也尝试过1并得到相同的结果,它认为它拥有所有 24 个 CPU)。
我回去查看了我们所有的应用程序。果然,我们准确设置 CPU 请求的那些1000m就是有问题的。任何其他值都按预期工作。
当然,当我也将 CPU 限制设置为 时1000m,问题就消失了,JVM 报告 1 个 CPU。
这很可能是预期的,而且我不完全理解 Kubernetes 如何使用 CPU 资源和限制,或者可能是我们使用的版本 (1.12.7) 的问题。
不管怎样,我至少知道为什么我们的一些 Pod 会看到不同的 CPU。
| 归档时间: |
|
| 查看次数: |
2410 次 |
| 最近记录: |