ну сначала docker ps -a, понятно, чтобы нужный труп найти

блин)

забыл --namespace указать для kubectl logs

?

бгггг

бывает

Касаемо твоей темы - nodeSelector умеет: In addition to labels you attach yourself, nodes come pre-populated with a standard set of labels. As of Kubernetes v1.2 these labels are: + kubernetes.io/hostname + failure-domain.beta.kubernetes.io/zone + failure-domain.beta.kubernetes.io/region + beta.kubernetes.io/instance-type см. http://kubernetes.io/docs/user-guide/node-selection/

дада

это я знаю

но как это поможет две реплики разнести на разные хосты?

я же не могу для каждой реплики отдельные nodeSelector'ы делать

https://github.com/kubernetes/kubernetes/issues/3945

? :)

Я вот решал такое на чистом CoreOS + Fleet - там есть настройки Conflicts: https://coreos.com/fleet/docs/latest/unit-files-and-scheduling.html

https://github.com/kubernetes/kubernetes/issues/3945

да, тот самый кейс чувак там в комментах сделал так же, как из статьи по ссылке от @Ai_boy

(может это вообще один и тот же человек)

короче, там предлагают в таких случаях заводить по отдельному RC на каждую реплику

как-то это... нууу....

ну вы поняли

да

но не всё сразу

или PR welcome :)

как я понял это все in development https://github.com/kubernetes/kubernetes/issues/25319 https://github.com/kubernetes/kubernetes/blob/master/docs/design/podaffinity.md

в этом смысле номад рулит

агада, конкретно это в номаде продумано

В этом смысле Mesos уделывает всех ибо там это 1 строчка конфига :) - "constraints": [["hostname", "UNIQUE"]]

А как как kubectl logs тогда работает? # kubectl get pods --namespace my-app-dev NAME READY STATUS RESTARTS AGE my-app-web-dispatcher-2847709974-348hp 0/1 Pending 0 1d my-app-web-dispatcher-2847709974-fqlkk 1/1 Running 0 1d my-app-web-dispatcher-2847709974-rhjnh 1/1 Running 0 1d my-app-web-dispatcher-3729888052-87k8e 1/1 Terminating 0 1d # kubectl logs --namespace my-app-web-dev my-app-web-dispatcher-2847709974-348hp Error from server: the server could not find the requested resource ( pods/log my-app-web-dispatcher-2847709974-348hp)

ну мезос-то понятно

какая мезость

@DenisIzmaylov оно еще пендинг

там пока нет логов, потому что контейнер еще не запустился

оно вот уже 10 минут пендинг, как раз хочу посмотреть почему

евенты смотри

логи не появятся до первого running

kubectl get events --namespace .. возвращает ничего

и даже в UI кнопки нет

просто deployment висит уже долго

точнее вкладку Events нашёл, но там пусто

ну тогда предыдущий совет в силе: иди на целевой хост, ищи контейнер в docker ps -a, инспектируй его доскером

т/е мы не можем посмотреть причины, почему deployments висит?

пока контейнер в состоянии "пендинг", логи не появятся

а вот тот факт, что у тебя нет евентов - это какой-то треш

так не должно быть

обычно там на кажный чих куча всего генерится

вот так даже

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22085 root 20 0 4795188 1.854g 10188 S 101.0 11.9 1603:02 dockerd

однако

эк его попячило

Нормально

Я вот не пойму, почему поды Pending и Terminating

ты в докер инспект-то потыкал?

и чего там в евентах?

А как понять на какой тачке под?)

kubectl describe pod тоже не помог

kubectl get po -o wide

последний столбец - хост

в describe должна быть инфа, на каком хосте под

О круто, спасибо

Pending и Terminating на одной машине

Сделал kubectl describe pod - но ничего полезного: Status: Pending IP:

тоже наблюдаю иногда такое. Помогает перезагрузка ноды. Возможно Docker глючит как-то

у тебя под поднимается чем?

я имею в виду - деплоймент там, или rc, или просто под в папке с манифестами?

Deployment

так

конфигурационный файл

которые отдаётся через kubectl apply -f

в одной консольке делай kubectl get ev -o wide -w --namespace=<чего-тут-у-тебя> в соседней консольке kubectl delete po <pod> --namespace=<чего-тут-у-тебя>

и смотри в ту консоль, где евенты тейлятся

начинаю

уоуоу

# kubectl get ev -o wide -w --namespace=my-app-dev FIRSTSEEN LASTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE FIRSTSEEN LASTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE 2016-08-22 11:48:30 -0400 EDT 2016-08-22 11:48:30 -0400 EDT 1 my-app-2847709974 ReplicaSet Normal SuccessfulCreate {replicaset-controller } Created pod: my-app-2847709974-ygngc 2016-08-22 11:48:30 -0400 EDT 2016-08-22 11:48:30 -0400 EDT 1 my-app-2847709974-ygngc Pod Normal Scheduled {default-scheduler } Successfully assigned my-app-2847709974-ygngc to 10.91.119.197

Забавно, что он зашедулилось

Но всё также повисло на том же сервере в режиме Pending

а у тебя там кьюблет-то вообще работает? :D

где в евентах сообщения про то, что он там имаж пытается скачать и вот это вот все

посмотри в логи кьюблета

на 10.91.119.197

чота с ним не так

делаю ребут

зблся)

надеюсь не отвалится ничего

Так а в логах кьюблета чего?

а это как глянуть?

Эээ

сейчас загрузится - могу проверить, но само по себе такое положение дел немного странное

Ну там лессом или тейлом

Как ты обычно логи смотришь

Если у тебя поттерингд, то journalctl -u kubelet

Ну или как он там у тебя называется

Странно, ещё загружается

ого: Update Strategy: No Reboots Failed Units: 1 user-cloudinit@var-lib-coreos\x2dinstall-user_data.service

Мне это ни о чем не говорит

Я флит только на картинках видел

Расшифруй, чего произошло-то

Сейчас разбираюсь)

Кажется что то пошло не так с CoreOS-кластером

Точнее с той его частью, на которой kube-api-server