Minikube 与 Virtualbox 或 KVM 在 Centos 7 上使用大量 CPU答案

【问题标题】：Minikube with Virtualbox or KVM using lots of CPU on Centos 7Minikube 与 Virtualbox 或 KVM 在 Centos 7 上使用大量 CPU
【发布时间】：2019-09-10 01:48:21
【问题描述】：

我已经按照 kubernetes 的说明安装了 minikube。启动它并等待一段时间后，我注意到它正在使用大量 CPU，尽管我没有什么特别的运行。

top 显示：

%Cpu(s):  0.3 us,  7.1 sy,  0.5 ni, 92.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 32521856 total,  2259992 free,  9882020 used, 20379844 buff/cache
KiB Swap:  2097144 total,   616108 free,  1481036 used. 20583844 avail Mem 

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                     
4847 root      20   0 3741112  91216  37492 S  52.5  0.3   9:57.15 VBoxHeadless

lscpu 显示：

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD Opteron(tm) Processor 3365

如果我使用 KVM 而不是 VirtualBox，我会看到相同的效果

kubectl get services

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   20m

我安装了 metrics-server，它输出了这个：

kubectl top node minikube

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
minikube   334m         16%    1378Mi          76%

kubectl top pods --all-namespaces

NAMESPACE                NAME                                    CPU(cores)   MEMORY(bytes)   
default                  hello-minikube-56cdb79778-rkdc2         0m           3Mi             
kafka-data-consistency   zookeeper-84fb4cd6f6-sg7rf              1m           36Mi            
kube-system              coredns-fb8b8dccf-2nrl4                 4m           15Mi            
kube-system              coredns-fb8b8dccf-g6llp                 4m           8Mi             
kube-system              etcd-minikube                           38m          41Mi            
kube-system              kube-addon-manager-minikube             31m          6Mi             
kube-system              kube-apiserver-minikube                 59m          186Mi           
kube-system              kube-controller-manager-minikube        22m          41Mi            
kube-system              kube-proxy-m2fdb                        2m           17Mi            
kube-system              kube-scheduler-minikube                 2m           11Mi            
kube-system              kubernetes-dashboard-79dd6bfc48-7l887   1m           25Mi            
kube-system              metrics-server-cfb4b47f6-q64fb          2m           13Mi            
kube-system              storage-provisioner                     0m           23Mi

问题：

1) 是否有可能找出它为什么使用这么多 CPU？（请注意，我没有产生负载，并且我的容器都没有处理任何数据）

2) 这正常吗？

【问题讨论】：

您可以运行命令kubectl top node <node-name> 和kubectl top pod <pod-name> --containers 以查看更详细的指标。
kubectl top node minikube 有效。但我没有运行任何 pod，这就是为什么使用这么多 CPU 如此疯狂的原因。
嗨！你找到解决办法了吗？
P.S.如果有人有兴趣，我注意到 Minikube 无法在超过 2-4 个内核上正常运行，它似乎是一个带有活锁的可怕未优化软件，它在空闲模式下占用 40% 的资源，如果我给它启动速度会慢几倍它更多的 CPU（6,7.. 在我的 12 核桌面上）
Minikube 在 2020 年的表现有所改善，但 the main source of hogging is the apiserver and etcd implementation of Kubernetes。目前还没有我知道的解决方案。

标签： virtualbox kvm minikube

【解决方案1】：

你确定什么都没有运行吗？如果你输入kubectl get pods --all-namespaces 会发生什么？默认情况下，Kubernetes 只显示默认命名空间内的 Pod（因此不包括系统命名空间内的 Pod）。

另外，虽然我不是 CPU 专家，但对于您拥有的硬件来说，这似乎是一个合理的消耗。

【讨论】：

OK @alassane-ndiaye，真的，还有 kube-system 的东西——我用新信息更新了帖子。请注意，虽然我没有产生任何负载，而且我的容器都没有处理任何数据，所以说 minikube 应该占用这么多 CPU 是很奇怪的。它在做什么？
它必须编排所有容器，这不是一件容易的事。如您所见，要使 Kubernetes 功能达到最低限度，需要许多组件，例如 API 服务器、etcd 存储、各种管理器等。一般来说，高度分布式系统必须做大量工作才能确保系统保持一致和高可用性，这使得它们比单体系统使用更多的资源。
我也不是 kubernetes 内部的专家：P
您好，您应该验证一下为什么有 o 大的 SWAP 空间。您还可以在启动期间更改 minikube 参数：minikube start --v=10 --cpus 4 --memory 8192。请同时考虑并禁用交换。

【解决方案2】：

回答问题 1)：

您可以 ssh 进入 minikube 并从那里运行 top 以查看正在运行的进程：

minikube ssh
top

有很多 docker 和 kublet 的东西在运行：

top - 21:43:10 up  8:27,  1 user,  load average: 10.98, 12.00, 11.46
Tasks: 148 total,   1 running, 147 sleeping,   0 stopped,   0 zombie
%Cpu0  :  15.7/15.7   31[||||||||||||||||||||||||||||||||                                                                    ]
%Cpu1  :   6.0/10.0   16[||||||||||||||||                                                                                    ]
GiB Mem : 92.2/1.9      [                                                                                                    ]
GiB Swap:  0.0/0.0      [                                                                                                    ]

11842 docker    20   0   24.5m   3.1m   0.7   0.2   0:00.71 R                  `- top                                                                                           
 1948 root      20   0  480.2m  77.0m   8.6   4.1  27:45.44 S  `- /usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --tlsverify --tlscacert /etc/docker/ca+ 
...
 3176 root      20   0   10.1g  48.4m   2.0   2.6  17:45.61 S              `- etcd --advertise-client-urls=https://192.168.39.197:2379 --cert-file=/var/lib/minikube/certs/etc+

处理器时间分别为 27 和 17 小时的两个进程是罪魁祸首。

回答问题 2)：不知道，但可能是。查看@alassane-ndiaye 的回答

【讨论】：