问题1. mesos leader选举不一致
使用下面的命令在mesosmaster容器内查看其日志,看它认为哪台服务器是mesos leader
不同的服务器选出的leader可能不一样！！
导致这个问题出现的原因目前不明，怀疑是不同机器的时间不一致导致！
不同的服务器选出的leader可能不一样！！
导致这个问题出现的原因目前不明，怀疑是不同机器的时间不一致导致！
问题2. marathon选举leader出错!
查了半天也没有任何有用的资料！建议是删除掉ZooKeeper的/marathon目录后重启marathon服务！！
也不知道 在哪能看谁是leader，总之先使用ntp保证服务器时间一致再说吧,然后使用 journal 查看日志，哪个有问题就把哪个重启一下吧。
也不知道 在哪能看谁是leader，总之先使用ntp保证服务器时间一致再说吧,然后使用 journal 查看日志，哪个有问题就把哪个重启一下吧。
问题3. An app Does Not Leave "Waiting"
这意味着marathon没有从mesos收到“Resource Offers”。最简单的可能是没有足够的资源，或者其他的framework持有了所有的资源。你可以检查Mesos UI，看看可用的资源。
问题4. app需要一个特定的端口
一般来说，并不建议配置你的app去基于一个特定的端口，因为它限制了scheduling。
在portBindings中设置hostPort为非0值。
设置requirePorts为true
在portBindings中设置hostPort为非0值。
设置requirePorts为true
问题5: 当运行mesos-slave的服务器重启或直接关闭mesos-slave服务时，Marathon中的task的状态会变为Unscheduled--因为TASK_LOST。此时kill task会失败。
目前查到的解决办法是:
(1) Marathon 1.4.3之后，每个app的定义文件中加入
"unreachableStrategy": {
"inactiveAfterSeconds": 30,
"expungeAfterSeconds": 60
}
inactiveAfterSeconds: 如果task实例不可达大于这个值，它会被标记为inactive并且一个新的实例将被launch。
此时，不可达的task还没有被expunged(消除)。
默认值是300s，最小值是1s。
expungeAfterSeconds: 如果task实例不可达大于这个值，它会被expunged(消除)。
被expunged的task会被killed如果它不再回来。
task实例在被expunged之前，一般会首先被标记为unreasonable。
这个值必须大于 inactiveAfterSeconds。
默认值是600s。
(2) mesos-slave 启动命令行增加:
此时，不可达的task还没有被expunged(消除)。
默认值是300s，最小值是1s。
expungeAfterSeconds: 如果task实例不可达大于这个值，它会被expunged(消除)。
被expunged的task会被killed如果它不再回来。
task实例在被expunged之前，一般会首先被标记为unreasonable。
这个值必须大于 inactiveAfterSeconds。
默认值是600s。
(2) mesos-slave 启动命令行增加:
recovery_timeout=1mins
实际效果待续（目前的问题是不能实现自动launch新的task实例）
[实际效果欠佳]
问题6: marathon任务无法启动, deployments无法完成
实际现象为 marathon 显示任务状态为 "Staged" , 而实际上到目标机器上查看 docker容器 并未启动,
查看 mesos-slave 日志, 发现是因为 该slave认为 下发任务指令的 master 不是 leader, 从而忽略了该任务指令.
但此后该任务却进入了死锁状态,无法 kill, 甚至 appid 无法 stop.
因为 marathon 请求该 task 状态或请求 杀死该任务都不会有任何 ack .
目前没有找到解决办法.
只能强制杀掉 deployment (或强制杀掉 task, 未经实验,但api中有, 不知道管不管用)
(1) 强制杀掉 deployment:
查看 mesos-slave 日志, 发现是因为 该slave认为 下发任务指令的 master 不是 leader, 从而忽略了该任务指令.
但此后该任务却进入了死锁状态,无法 kill, 甚至 appid 无法 stop.
因为 marathon 请求该 task 状态或请求 杀死该任务都不会有任何 ack .
目前没有找到解决办法.
只能强制杀掉 deployment (或强制杀掉 task, 未经实验,但api中有, 不知道管不管用)
(1) 强制杀掉 deployment:
marathonAddr="http://abcd:1234";
deployment_id="14eed6d3-6f72-41f4-8329-ce6a7583eb32";
apiPath="/v2/deployments/${deployment_id}"
curl -X DELETE ${marathonAddr}${apiPath}?force=true
(2) 强制杀掉 task:
# 经测试, 该方法无用
marathonAddr="http://abcd:1234";
app_id="autodeploy"
task_id="autodeploy.8c873ce2-ad63-11e7-a70d-36d30528411f"
apiPath="/v2/apps/${app_id}/tasks/${task_id}"
curl -X DELETE ${marathonAddr}${apiPath}?force=true&scale=false&wipe=false
作者：坚持到底v2
链接：https://www.jianshu.com/p/eb6659cdeda8
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
