方案 1

教程 - 资源分配

IMPORTANT: Tutorials are intended to give you hands-on experience working with a limited set of DC/OS features with no implied or explicit warranty of any kind. None of the information provided--including sample scripts, commands, or applications--is officially supported by Mesosphere. You should not use this information in a production environment without independent testing and validation.

方案 1:资源分配

设置

对于第一个方案,请按如下方式部署此应用定义

dcos marathon app add https://raw.githubusercontent.com/dcos-labs/dcos-debugging/master/1.10/app-scaling1.json

使用 DC/OS Web 界面检查应用程序状态,您应该看到如下内容:

Web 界面图片

图 1. 显示应用程序状态的 DC/OS Web 界面

应用程序的状态最可能是“等待”,然后是一些千分位数“x/1000”。“等待”是指整体应用状态和数字;“x”表示已成功部署多少个实例(本示例中为 6)。

您也可以从 CLI 检查此状态:

dcos marathon app list

会在响应中产生以下输出:

ID              MEM   CPUS  TASKS   HEALTH  DEPLOYMENT  WAITING  CONTAINER  CMD

/app-scaling-1  128    1    6/1000   ---      scale     True       mesos    sleep 10000

或者,如果您想查看所有正在进行的部署,请输入:

dcos marathon deployment list

看到如下内容:

APP             POD  ACTION  PROGRESS  ID

/app-scaling-1  -    scale     1/2     c51af187-dd74-4321-bb38-49e6d224f4c8

现在我们知道应用程序的某些 (6/1000) 实例已成功部署,但整体部署状态为“等待”。但这是什么意思?

解析度

“等待”状态表示 DC/OS(或更准确地说是 Marathon)正在等待合适的资源提供。这似乎是一个部署问题,我们应该先检查可用的资源。

如果我们查看 DC/OS 仪表盘,我们应该看到与以下相似的相当高的 CPU 分配(当然,确切的百分比取决于您的群集):

CPU 分配图片

图 2. DC/OS 资源分配显示

由于我们还没有 100% 分配,但我们仍在等待部署,因此正在发生一些有趣的事情。让我们来看看 DC/OS Web 界面调试视图中的最新资源提供。

Web 界面相关实例图片

图 3. 最新资源提供

我们可以看到,没有匹配的 CPU 资源。但同样,整体 CPU 分配仅为 75%。更令人费解的是,当我们进一步查看以下“详细信息”部分时,我们会看到不同主机的最新提供符合我们应用程序的资源要求。所以,举例而言,来自主机 10.0.0.96 的第一个提供与角色、约束(此 app-definition 中不存在)、内存、磁盘、端口资源要求匹配,— 但 CPU 资源要求不合格。在此之前的提供似乎应该符合资源要求。因此,尽管看起来我们有足够的 CPU 资源可用,但应用程序似乎只因为这个原因而失败

让我们更加仔细地看一看“详细信息”。

详细信息图片

图 4. 资源分配详细信息

有意思。据此,其余一些 CPU 资源分配给了不同的 Mesos 资源角色,因此,我们的应用程序无法使用(它以角色“*”运行,默认角色)。

要检查不同资源的角色,让我们看看 state-summary 端点,其访问地址为 https://<master-ip>/mesos/state-summary.

该端点将为我们提供相当长的 json 输出,所以使用 jq 使输出可读非常有用:

curl -skSL

-X GET

-H "Authorization: token=$(dcos config show core.dcos_acs_token)"

-H "Content-Type: application/json"

"$(dcos config show core.dcos_url)/mesos/state-summary" |

jq '.'

查看代理程序信息时,我们可以看到两种不同类型的代理程序。

群集信息图片

图 5. 群集信息

第一种类型没有可用的 CPU 资源,也没有保留资源。当然,如果您在这些练习之前在群集上运行了其他工作负载,这可能会有所不同。请注意,这些未保留资源对应于默认角色“*” — 我们试图部署任务的角色。

第二种类型有未使用的 CPU 资源,但这些资源在“slave_public”角色中保留。

我们现在知道问题在于整个群集中所需资源角色中没有足够的资源。作为一种解决方案,我们可以减少应用程序(1000 个实例似乎过多),或者我们需要向群集添加更多资源。

一般模式

当您的应用程序框架(例如 Marathon)不接受资源提供时,请检查相应资源角色中是否有足够的可用资源。

这是一个简单的方案,CPU 资源太少。通常,资源问题更可能是由更复杂的因素引起的 - 如未正确配置的端口资源布局约束. 尽管如此,这种一般工作流模式仍然适用。

清除

使用以下命令从群集中删除应用程序:

$ dcos marathon app remove /app-scaling-1