Наврно стоит описать кейс по подробней. Мы только начинаем использовать Kubernetes и хотим перенести первый сервис в него, на данный момент в качестве service discovery мы используем consul, и отказатся от него на данный момент будет очень дорого и сложно. По этому хочется что бы можно было регать или поды в консуле, или создать отдельный DC в kubernetes и приконнектить его к сущесвующему, а для этого нужно что бы ip подов были доступны для машин вне кластера

Поднимайте Consul агенты кластере, джойните их в существующий кластер, настраиваете регистрацию сервисов через аннотации, делаете роутинг в сеть k8s кластера, все. https://github.com/hashicorp/consul-helm/blob/master/values.yaml#L159 Захотите ходить в куб к сервисам по DNS именам - настроите форвардиг зону.

Наврно стоит описать кейс по подробней. Мы только начинаем использовать Kubernetes и хотим перенести первый сервис в него, на данный момент в качестве service discovery мы используем consul, и отказатся от него на данный момент будет очень дорого и сложно. По этому хочется что бы можно было регать или поды в консуле, или создать отдельный DC в kubernetes и приконнектить его к сущесвующему, а для этого нужно что бы ip подов были доступны для машин вне кластера

А чего не nomad?

Поднимайте Consul агенты кластере, джойните их в существующий кластер, настраиваете регистрацию сервисов через аннотации, делаете роутинг в сеть k8s кластера, все. https://github.com/hashicorp/consul-helm/blob/master/values.yaml#L159 Захотите ходить в куб к сервисам по DNS именам - настроите форвардиг зону.

Спасибо за ответ! Про helm chart для консул это все понятно, и уже сделано. Вопрос в том как сделать роутинг в сеть k8s кластера

А чего не nomad?

Я не очень знаком с nomad, как он может помочь в данной ситуацие ?)

Я не очень знаком с nomad, как он может помочь в данной ситуацие ?)

consul+nomad+traefik покрывает большую часть функций куба

traefik в роли ингресс*

На сколько я знаю, nomad это больше про aws, gcp, azure and etc, но у нас вся инфраструктура on-premise

На сколько я знаю, nomad это больше про aws, gcp, azure and etc, но у нас вся инфраструктура on-premise

Нет, nomad это один бинарник. Если консул готов, то развернуть номад дело часа максимум. Все тоже самое

Спасибо за ответ! Про helm chart для консул это все понятно, и уже сделано. Вопрос в том как сделать роутинг в сеть k8s кластера

Линуксы? Ядро какое?

Линуксы? Ядро какое?

Почти все на debian 9.7 - 4.9.0-8-amd64

Ребят, а обязательно деплойментам в кубере указывать жестко фиксированные ресурсы?

Тогда можно с ECMP. На нодах вне кластера k8s ip ro add 10.244.0.0/16 scope global proto static nexthop via $K8S_NODE1_IPADDR weight 1 nexthop $K8S_NODE2_IPADDR weight 1

Тогда можно с ECMP. На нодах вне кластера k8s ip ro add 10.244.0.0/16 scope global proto static nexthop via $K8S_NODE1_IPADDR weight 1 nexthop $K8S_NODE2_IPADDR weight 1

хм, интересно, попробую, спасибо!

Ребят, а обязательно деплойментам в кубере указывать жестко фиксированные ресурсы?

очень желательно, иначе ломается логика диспетчеризации

Ребят, а обязательно деплойментам в кубере указывать жестко фиксированные ресурсы?

Нет

Нет

Ответ полноценный, но, кмк, бесполезный

Ответ полноценный, но, кмк, бесполезный

Какой вопрос такой ответ, а в каком месте диспетчеризация сломается если не указать?

Какой вопрос такой ответ, а в каком месте диспетчеризация сломается если не указать?

Ну, предположим, что кубер знает, что есть Х нод с пулом ресурсов {cpu: n, mem: y}. Далее по ним надо раскидать NNN контейнеров. Если у контейнеров жестко заданы лимиты - все ок

задача рюкзака решена

Ну, предположим, что кубер знает, что есть Х нод с пулом ресурсов {cpu: n, mem: y}. Далее по ним надо раскидать NNN контейнеров. Если у контейнеров жестко заданы лимиты - все ок

Он и так раскидает на основании свободных ресурсов

как только появляется хотя бы один контейнер без жестко прописанных лимитов - есть шанс, что он начнет жрать ресурсы не в себя и мы приплыли. В принципе, если он (и только он, или какое-то подмножество деплойментов) жестко прибит гвоздями к определенной ноде - можно жить

но в остальном - зачем рисковать и провоцировать

но в остальном - зачем рисковать и провоцировать

Не всегда возможно лимитирование ресурсов, сильно зависит от ПО

я вообще с трудом представляю как можно капасити планирование, в случае если не определены лимиты

как только появляется хотя бы один контейнер без жестко прописанных лимитов - есть шанс, что он начнет жрать ресурсы не в себя и мы приплыли. В принципе, если он (и только он, или какое-то подмножество деплойментов) жестко прибит гвоздями к определенной ноде - можно жить

Не может. У него будет самый низкий приоритет.

Не всегда возможно лимитирование ресурсов, сильно зависит от ПО

соглашусь, но можно пойти по пессимистическому пути )

Не может. У него будет самый низкий приоритет.

ну, это еще хуже тогда =)

и в любом случае мы можем получить ситуацию, когда ему нужно, например, 4 ГиБ, а он на ноде с 2ГиБ максимум

как бы косяк

соглашусь, но можно пойти по пессимистическому пути )

Не везде очереди и лимиты в нутри приложения, если нету то твое лимитирование приведет к ещё большим проблемам

А ресурсы будут просто простаивать

если так, то повторюсь, никто не мешает прибить деплойменты гвоздями к определенным нодам (а по факту - это будут ВМки)

я склонен к тому, что "явное лучше неявного"

если так, то повторюсь, никто не мешает прибить деплойменты гвоздями к определенным нодам (а по факту - это будут ВМки)

Не надо ниче прибивать, само переедет

я склонен к тому, что "явное лучше неявного"

Планирование ресурсов хорошо когда возможно, но это редко так, в противном случае лимитирование приводит к проблемам

Не везде очереди и лимиты в нутри приложения, если нету то твое лимитирование приведет к ещё большим проблемам

Почему? Если сделать hpa то при выжирании цпу создастся ещё одна копия приложения

И не будет простоя ресурсов

Или не цпу а очереди/количества запросов и тп кастомноц метрики если приложение умеет их в прометеус формате отдавать

Почему? Если сделать hpa то при выжирании цпу создастся ещё одна копия приложения

Чем это отличается от нелимитированного?

Тем что это лимитировано и значит шедулер может нормально работать и значит реплика может подняться на другой ноде?

Тем что это лимитировано и значит шедулер может нормально работать и значит реплика может подняться на другой ноде?

Ну тоже верно

Без лимитов мы мало того что упремся в ресурсы текущей ноды так ещё и будем мешать другим приложениям на ноде вплоть до оом

Без лимитов мы мало того что упремся в ресурсы текущей ноды так ещё и будем мешать другим приложениям на ноде вплоть до оом

Один раз было подобное, но не до оом, просто ресурсы выбрало и тупило, обработка 4гб psd

Ну вот 🙂

о, наконец-то упал openebs

частично

о, наконец-то упал openebs

🙂 Долго ждали ?

🙂 Долго ждали ?

57 дней 🙂

правда, вроде почти всё разрулилось убийством pool подов, которые чувствовали себя плохо

о, наконец-то упал openebs

А что сломалось?

ну началось всё с того, что приатаченный volume стал RO

потом посмотрел в логи cstor-sparse-pool и увидел там много такого: 2019-04-21/17:23:31.861 ERROR zvol pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 ack sender already present 2019-04-21/17:23:31.861 Data connection closed on fd: 27 2019-04-21/17:23:31.862 ERROR connection closed for fd(23) 2019-04-21/17:23:31.863 [tgt 10.105.69.116:6060:23]: Closing the connection 2019-04-21/17:23:31.865 ERROR as status for pvc-ce3bc37e-4e54-11e9-af28-5404a6b4a4b0 is 1 or rebuild status is 3 2019-04-21/17:23:31.865 Data connection closed on fd: 28 2019-04-21/17:23:31.865 ERROR connection closed for fd(22) 2019-04-21/17:23:31.865 [tgt 10.108.71.65:6060:22]: Closing the connection 2019-04-21/17:23:31.899 Waiting for IO to send off on vol cstor-3241e023-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 2019-04-21/17:23:32.419 Waiting for conn_closed(1) and ack_sender (-1)for fd(25) to be false for cstor-3241e023-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 2019-04-21/17:23:32.899 Waiting for IO to send off on vol cstor-3241e023-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 2019-04-21/17:23:33.419 Waiting for conn_closed(1) and ack_sender (-1)for fd(25) to be false for cstor-3241e023-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 2019-04-21/17:23:33.899 Waiting for IO to send off on vol cstor-3241e023-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 2019-04-21/17:23:34.419 Waiting for conn_closed(1) and ack_sender (-1)for fd(25) to be false for cstor-3241e023-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0

ну и где-то в промежутках 2019-04-21/17:33:43.929 Rebuild scanner started on zvol pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 from sock(24) 2019-04-21/17:33:43.929 Checkpointed IO_seq: 2155383, Rebuild Req offset: 0, Rebuild Req length: 10737418240 for zvol(cstor-38ef4096-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0) 2019-04-21/17:33:44.538 zvol cstor-38ef4096-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0_rebuild_clone@.io_snap2155383.1555868023 status change: DEGRADED -> DEGRADED 2019-04-21/17:33:44.538 zvol cstor-38ef4096-37aa-11e9-943a-c8600054bedb/pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0_rebuild_clone@.io_snap2155383.1555868023 rebuild status change: INIT -> INIT

хотя не, убийство всё-таки не помогло, сейчас такая же штука повторяется

$ kubectl get cstorvolume -n openebs NAME STATUS AGE pvc-30c1a7d2-383b-11e9-af28-5404a6b4a4b0 Degraded 56d pvc-97a8a30c-469c-11e9-af28-5404a6b4a4b0 Healthy 37d pvc-a83437bb-383b-11e9-af28-5404a6b4a4b0 Degraded 56d pvc-afd08477-589a-11e9-a768-c86000bc3fdc Healthy 14d pvc-b14718cc-3879-11e9-af28-5404a6b4a4b0 Healthy 55d pvc-c5f24691-4e4e-11e9-af28-5404a6b4a4b0 Healthy 28d pvc-cc9437ef-58ad-11e9-9a52-c8600054bedb Healthy 14d pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 Offline 55d pvc-ce3bc37e-4e54-11e9-af28-5404a6b4a4b0 Degraded 28d pvc-dfa1ea02-589f-11e9-9a52-c8600054bedb Healthy 14d pvc-f5d7a648-383b-11e9-af28-5404a6b4a4b0 Healthy 56d

во, тут лучше видно, что что-то пошло не так

Degraded 28d

Выглядит как никто не смотрел логи вообще

есть такое...

но вообще вроде это age с момента создания

Выходит с момента создания работало плохо но никто даже не смотрел?

да не

вот на примере Offline: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Healthy 27m (x2 over 59m) pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0-target-758c9b79d5k57f5, k8s-2 Volume is in Healthy state Normal Init 6m52s (x2 over 24m) pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0-target-758c9b79d5k57f5, k8s-2 Volume is in Init state Normal Synced 4m55s (x59941 over 20d) pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0-target-758c9b79d5k57f5, k8s-2 Synced Normal Degraded 4m21s (x13 over 122m) pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0-target-758c9b79d5k57f5, k8s-2 Volume is in Degraded state Warning Offline 3m23s (x12 over 123m) pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0-target-758c9b79d5k57f5, k8s-2 Volume is in Offline state

то есть совсем недавно всё сломалось

root@k8s-1 ~ # kubectl get cstorvolume -n openebs -o wide NAME STATUS AGE pvc-30c1a7d2-383b-11e9-af28-5404a6b4a4b0 Degraded 56d pvc-97a8a30c-469c-11e9-af28-5404a6b4a4b0 Healthy 37d pvc-a83437bb-383b-11e9-af28-5404a6b4a4b0 Degraded 56d pvc-afd08477-589a-11e9-a768-c86000bc3fdc Healthy 14d pvc-b14718cc-3879-11e9-af28-5404a6b4a4b0 Healthy 55d pvc-c5f24691-4e4e-11e9-af28-5404a6b4a4b0 Healthy 28d pvc-cc9437ef-58ad-11e9-9a52-c8600054bedb Healthy 14d pvc-cccb1561-3863-11e9-af28-5404a6b4a4b0 Degraded 55d pvc-ce3bc37e-4e54-11e9-af28-5404a6b4a4b0 Degraded 28d pvc-dfa1ea02-589f-11e9-9a52-c8600054bedb Healthy 14d pvc-f5d7a648-383b-11e9-af28-5404a6b4a4b0 Healthy 56d Хм, один Offline стал уже Degraded

Нашел еще интересное в логах kubelet: Apr 21 19:45:21 k8s-2 kubelet[929]: E0421 19:45:21.491841 929 dns.go:132] Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: ...

хотя вроде там не страшно, судя по systemd-resolve --status там 6 DNS, 3 перечисленных в логах и 3 просто ipv6

Кажется, после убийства по лимитам ресурсов такая штука началась (alertmanager скинул как раз уведомление, что 2 из 3-х подов cstor-pool были убиты почти в одно время) Apr 21 19:24:12 k8s-2 kubelet[929]: E0421 19:24:12.864300 929 kuberuntime_manager.go:857] PodSandboxStatus of sandbox "4e13dc0ac94b8224ddf06037cfa09ee3668060f09f2914aa57cbc05a0a679e4e" for pod "cstor-sparse-pool-4sfq-869c9bdd55-wqlnb_openebs(442dea94-645a-11e9-9a52-c8600054bedb)" error: rpc error: code = Unknown desc = Error: No such container: 4e13dc0ac94b8224ddf06037cfa09ee3668060f09f2914aa57cbc05a0a679e4e Apr 21 19:24:12 k8s-2 kubelet[929]: E0421 19:24:12.864339 929 generic.go:247] PLEG: Ignoring events for pod cstor-sparse-pool-4sfq-869c9bdd55-wqlnb/openebs: rpc error: code = Unknown desc = Error: No such container: 4e13dc0ac94b8224ddf06037cfa09ee3668060f09f2914aa57cbc05a0a679e4e Apr 21 19:24:26 k8s-2 kubelet[929]: E0421 19:24:26.794677 929 kuberuntime_manager.go:871] getPodContainerStatuses for pod "cstor-sparse-pool-4sfq-869c9bdd55-wqlnb_openebs(442dea94-645a-11e9-9a52-c8600054bedb)" failed: rpc error: code = Unknown desc = Error: No such container: 77b95608fc818d56274236b24fe3c85a304b195652c6d6959eb12f5993413d4b

о, один Offline стал Healthy

zfs on linux вообще веселый цирк и шутки

ну пока есть шансы, что оно как-то само разрулит всё это )

Коллеги, поясните за Evicted поды, пожалуйста У меня с недавнего момента начали появляться Evicted поды в огромном количестве, раньше ничего такого не было Я так понял, что они помечаются как Evicted после ошибки, и висят ждут чего-то, вот только не потятно, чего именно. Раньше у меня такого не было, под просто падал и перезапускался, никаких Evicted

Или это из-за нехватки памяти?

имхо был выселен, и не может поселится, может квоты, может диск

Коллеги, поясните за Evicted поды, пожалуйста У меня с недавнего момента начали появляться Evicted поды в огромном количестве, раньше ничего такого не было Я так понял, что они помечаются как Evicted после ошибки, и висят ждут чего-то, вот только не потятно, чего именно. Раньше у меня такого не было, под просто падал и перезапускался, никаких Evicted

https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-signals

А через сам k8s как-то можно понять, чего ему конкретно не хватило, или нет? Describe pod недоступен на evicted, как и логи

А через сам k8s как-то можно понять, чего ему конкретно не хватило, или нет? Describe pod недоступен на evicted, как и логи

в ивентах ноды будет написано

А через сам k8s как-то можно понять, чего ему конкретно не хватило, или нет? Describe pod недоступен на evicted, как и логи

Еще в логах кублета обычно явно написано чем вызван eviction

Подскажите, а NodeHasInsufficientMemory это про RAM или диск?

Подскажите, а NodeHasInsufficientMemory это про RAM или диск?

по идее про оперативную память и с этим был баг мещающий скедулить поды: github com / kubernetes / kubernetes / issues / 45237