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

創(chuàng)新互聯(lián)是一家專注于成都網站建設、網站設計與策劃設計,象州網站建設哪家好?創(chuàng)新互聯(lián)做網站,專注于網站建設十余年,網設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:象州等地區(qū)。象州做網站價格咨詢:13518219792

問題一

問題描述

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

環(huán)境

• 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
...

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

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

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

根據(jù)Mesos state API得到當前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，這直接導致沒有足夠的CPU資源。這是Marathon無法部署container到Mesos Agent的根本原因。

解決問題

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

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

總結

1. 遇到問題先去查看log

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

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

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

問題二

問題描述

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

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

環(huán)境描述

同問題一

排錯過程

查看失敗的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都被我刪除了，上述輸出是根據(jù)現(xiàn)有container修改的，但是信息是和之前對應的。自己分析

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

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

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

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

解決方案

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

到此，相信大家對“Marathon/Mesos集群排錯方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！

名稱欄目：Marathon/Mesos集群排錯方法是什么
網站路徑：http://chinadenli.net/article24/goseje.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、ChatGPT、微信小程序、服務器托管、網站建設、網站維護

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)