Marathon/Mesos集群排錯方法是什么

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

問題一

問題描述

部署某個鏡像到Mesos集群的某個Agent一直停留在Waiting，但是在Mesos UI上發現這個Agent的資源是夠的（4CPU/14G mem，只使用了1CPU/256M mem）。為了重現這個問題，我在這臺Agent上部署了2048鏡像，對應的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": {}    }
  ]}

環境

• 5 Mesos Slave/3 Mesos Master

• CentOS 64bit

• Marathon 1.0

• Mesos 0.28.1

排錯過程

查看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
...

沒發現異常。

查看Martathon文檔

目前位置筆者一直認為問題處在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.

根據提示去找Mesos的/state信息。

根據Mesos state API得到當前Mesos集群的所有狀態信息的Json文件：

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

 "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]"
      }

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

解決問題

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

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

總結

1. 遇到問題先去查看log

2. 因為是開源項目，log中沒發現問題可以去瀏覽項目的documentation，一般像Marathon/Spark開源項目都會提供Troubleshooting類似的文檔說明

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

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

問題二

問題描述

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

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

環境描述

同問題一

排錯過程

查看失敗的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"
        }

因為之前失敗的container都被我刪除了，上述輸出是根據現有container修改的，但是信息是和之前對應的。自己分析

隨著個項目的更新以及重新構建鏡像后，這個問題解決了，但是我分析出了原因：

1. container需要掛在主機的/proc目錄

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

3. 容器中的服務會寫進程信息到容器的/proc目錄，主機同時也會寫信息到主機的/proc目錄，因為容器的/proc和主機的/proc掛載在一起，這就導致讀寫沖突了，所以容器一直啟動失敗。

解決方案

將主機的/proc掛在到容器的非/proc目錄，同時傳餐告訴容器中的服務要到哪讀取/proc信息

到此，相信大家對“Marathon/Mesos集群排錯方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！