dcos服务无缘无故卡住了

oxosxuxt  于 2021-06-26  发布在  Mesos
关注(0)|答案(2)|浏览(392)

我的服务很可能因为资源不可用而卡住了

dcos marathon debug summary /my-service
RESOURCE     REQUESTED  MATCHED  PERCENTAGE  
ROLE         [*]        5 / 6    83.33%      
CONSTRAINTS  ---        5 / 5    100.00%     
CPUS         4          0 / 5    0.00%       
MEM          416        0 / 0    ---         
DISK         10         0 / 0    ---         
PORTS        [0]        0 / 0    ---

我百分之百肯定 cpu 以及 memory 我请求你有空;
此外,这个角色约束没有得到满足是什么?
编辑:尽管当鼠标悬停在gui上时,它会对cpu(我找不到)说 Requested: 0.4 / Received 4 但还是失败了。。
编辑:这里是一个扩展mesos奴隶的信息要点

ep6jt1vc

ep6jt1vc1#

此外,这个角色约束没有得到满足是什么?
角色,也称为“资源角色”,有助于将不同的资源组彼此分开。例如,在标准dc/os集群中,公共节点的所有资源都保留给角色 slave_public .
当marathon收到资源提供时,它会考虑保留这些资源的角色。在您的案例中,marathon拒绝了一个资源提供,因为这些资源不属于名为 * .
请阅读mesos文档中有关资源角色的更多信息。
我回顾了 /mesos/slaves 端点,并发现群集中除一个代理之外的所有代理都没有可用于您的服务的资源: 10.11.17.23 , 10.11.17.250 , 10.11.17.41 , 10.11.17.72 ,和 10.11.17.123 只有2个CPU。 10.11.16.12 有4个CPU,但都是为 spave_public 角色。 10.11.17.46 共有8个cpu,预留2.5个cpu给 slave_public 角色,剩下的5.5对于 /my-service . 似乎出于某种原因,这个mesos代理不向主服务器发送资源提供。
检查此代理的日志( journalctl -u dcos-mesos-slave )任何错误。它在集群中的注册时间比其他代理晚了4个小时(13:39:44 vs.09:42:51),这一事实有点可疑。
检查主日志( journalctl -u dcos-mesos-master )如果mesos将此代理提供的任何资源发送到马拉松。
查看马拉松日志( journalctl -u dcos-marathon )如果marathon收到了此代理提供的资源,如果收到了,则说明拒绝的原因。
这篇中间层博客文章可以给你更多的想法。

doinxwow

doinxwow2#

在dcos中,您可以轻松地调试卡住的部署。这是怎么做的指南。
基本上,您需要转到debug页面,您应该了解拒绝资源提供的原因。

相关问题