Marathon/Mesos集群排錯(cuò)方法是什么

本篇內(nèi)容主要講解“Marathon/Mesos集群排錯(cuò)方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Marathon/Mesos集群排錯(cuò)方法是什么”吧!

問題一

問題描述

部署某個(gè)鏡像到Mesos集群的某個(gè)Agent一直停留在Waiting，但是在Mesos UI上發(fā)現(xiàn)這個(gè)Agent的資源是夠的（4CPU/14G mem，只使用了1CPU/256M mem）。為了重現(xiàn)這個(gè)問題，我在這臺Agent上部署了2048鏡像，對應(yīng)的Marathon Json文件：

{
  "id": "/2048-test",
  "cmd": null,
  "cpus": 0.01,
  "mem": 32,
  "disk": 0,
  "instances": 1,
  "constraints": [
    [      "hostname",      "CLUSTER",      "10.140.0.15"
    ]
  ],
  "container": {
    "type": "DOCKER",
    "volumes": [],
    "docker": {
      "image": "alexwhen/docker-2048",
      "network": "BRIDGE",
      "privileged": false,
      "parameters": [],
      "forcePullImage": false
    }  },
  "portDefinitions": [
    {
      "port": 10008,
      "protocol": "tcp",
      "labels": {}    }
  ]}

環(huán)境

• 5 Mesos Slave/3 Mesos Master

• CentOS 64bit

• Marathon 1.0

• Mesos 0.28.1

排錯(cuò)過程

查看Marathon log

docker logs marathon_container
...
run_jar --task_launch_timeout 900000 --zk zk://10.140.0.14:2181/marathon --event_subscriber http_callback --https_address 10.140.0.14 --http_address 10.140.0.14 --hostname 10.140.0.14 --master zk://10.140.0.14:2181/mesos --logging_level warn
run_jar --task_launch_timeout 900000 --zk zk://10.140.0.14:2181/marathon --event_subscriber http_callback --https_address 10.140.0.14 --http_address 10.140.0.14 --hostname 10.140.0.14 --master zk://10.140.0.14:2181/mesos --logging_level warn
...

沒發(fā)現(xiàn)異常。

查看Martathon文檔

目前位置筆者一直認(rèn)為問題處在Marathon這邊，所以就嘗試去Marathon的Doc看看有沒有常見的Troubleshooting。

果然有！An app Does Not Leave “Waiting”

This means that Marathon does not receive “Resource Offers” from Mesos that allow it to start tasks of this application. The simplest failure is that there are not sufficient resources available in the cluster or another framework hords all these resources. You can check the Mesos UI for available resources. Note that the required resources (such as CPU, Mem, Disk) have to be all available on a single host.

If you do not find the solution yourself and you create a github issue, please append the output of Mesos /state endpoint to the bug report so that we can inspect available cluster resources.

根據(jù)提示去找Mesos的/state信息。

根據(jù)Mesos state API得到當(dāng)前Mesos集群的所有狀態(tài)信息的Json文件：

然后到在線Json編輯器中格式化后查看Agent中的資源分配現(xiàn)狀：

 "resources": {
        "cpus": 4,
        "disk": 97267,
        "mem": 14016,
        "ports": "[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180, 8182-32000]"
      },
      "used_resources": {
        "cpus": 1,
        "disk": 0,
        "mem": 128,
        "ports": "[16957-16957]"
      },
      "offered_resources": {
        "cpus": 0,
        "disk": 0,
        "mem": 0
      },
      "reserved_resources": {
        "foo": {
          "cpus": 3,
          "disk": 0,
          "mem": 10000
        }
      },
      "unreserved_resources": {
        "cpus": 1,
        "disk": 97267,
        "mem": 4016,
        "ports": "[1025-2180, 2182-3887, 3889-5049, 5052-8079, 8082-8180, 8182-32000]"
      }

從中可以發(fā)現(xiàn)：雖然只使用了1CPU 128M mem，但是為foo保留了3CPU 10000M mem，這直接導(dǎo)致沒有足夠的CPU資源。這是Marathon無法部署container到Mesos Agent的根本原因。

解決問題

只需要將這個(gè)Agent上的資源疼出來就好了：

更改Marathon上的Json文件將這個(gè)Agent上的App部署到其它Agent上。

總結(jié)

1. 遇到問題先去查看log

2. 因?yàn)槭情_源項(xiàng)目，log中沒發(fā)現(xiàn)問題可以去瀏覽項(xiàng)目的documentation，一般像Marathon/Spark開源項(xiàng)目都會(huì)提供Troubleshooting類似的文檔說明

3. Mesos/Marathon集群雖然是開源項(xiàng)目，但是涉及的知識點(diǎn)還是很多的。這里要把大問題化解成小問題或者在筆記本上分析問題，標(biāo)記出重要的問題都是很好的方法

4. Mesos /state API是分析集群的好幫手

問題二

問題描述

簡言之就是Marathon部署的container一直顯示waiting，但是這個(gè)可不是資源的問題，這個(gè)是docker image的問題。

公司同事開發(fā)了開源項(xiàng)目linkerConnector，主要目的就是讀取Linux的/proc目錄，收集進(jìn)程的信息。為了方便部署，我把這個(gè)Golang Project容器化了，容器化的使用方法在這里。但是部署到Mesos Cluster一直失敗，Marathon一直顯示waiting。

環(huán)境描述

同問題一

排錯(cuò)過程

查看失敗的container

登錄到Mesos Agent，docker ps -a：

b13e79caca0a        linkerrepository/linker_connector        "/bin/sh -c '/linkerC"   17 minutes ago      Created                                    mesos-c64aa327-a803-40bb-9239-91fbd

docker inspect container:

"State": {
            "Status": "Created",
            "Running": false,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 0,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2016-08-26T08:22:40.713934966Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        }

因?yàn)橹笆〉腸ontainer都被我刪除了，上述輸出是根據(jù)現(xiàn)有container修改的，但是信息是和之前對應(yīng)的。自己分析

隨著個(gè)項(xiàng)目的更新以及重新構(gòu)建鏡像后，這個(gè)問題解決了，但是我分析出了原因：

1. container需要掛在主機(jī)的/proc目錄

2. 我直接-v /proc:/proc

3. 容器中的服務(wù)會(huì)寫進(jìn)程信息到容器的/proc目錄，主機(jī)同時(shí)也會(huì)寫信息到主機(jī)的/proc目錄，因?yàn)槿萜鞯?proc和主機(jī)的/proc掛載在一起，這就導(dǎo)致讀寫沖突了，所以容器一直啟動(dòng)失敗。

解決方案

將主機(jī)的/proc掛在到容器的非/proc目錄，同時(shí)傳餐告訴容器中的服務(wù)要到哪讀取/proc信息

到此，相信大家對“Marathon/Mesos集群排錯(cuò)方法是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！