Это на пустой, без подов

по факту у меня с t2.small подобные проблемы были, перешел на medium - все норм

пездес))) я бы проверил это, только вот удалить даже не могу ниче как хотя бы заставить Kubectl работать?

хоят бы снес прометея с графаной и поглядел нормализуется-ли всё

с форсом дестрой всё лишнее )

пездес))) я бы проверил это, только вот удалить даже не могу ниче как хотя бы заставить Kubectl работать?

выполнить команду kubectl)

на данный момент проц грузит дико apiserver

вообще у меня на 2Гб ОЗУ с парой подов очень нестабильно тоже всё работает

выполнить команду kubectl)

unable to recognize "prom/prometheus_volume-claim.yml": Get http://localhost:8080/api?timeout=32s: dial tcp 127.0.0.1:8080: connect: connection refused

Так ты их по очереди положи да сделай мощнее

дайте прав в цытатник репостить

ахах

unable to recognize "prom/prometheus_volume-claim.yml": Get http://localhost:8080/api?timeout=32s: dial tcp 127.0.0.1:8080: connect: connection refused

так при чем тут kubectl, у тебя api плохо

проверь, там контейнер не упал с ним вообще?

unable to recognize "prom/prometheus_volume-claim.yml": Get http://localhost:8080/api?timeout=32s: dial tcp 127.0.0.1:8080: connect: connection refused

Зайди на ноду и посмотри статус etcd и логи api-server

ребят сталкиваюсь с проблемой когда пишу логи кубера в еластик через filebeat “object mapping for [kubernetes.labels.app] tried to parse field [app] as object, but found a concrete value” может ктото знает простое решение?

у меня подозрение, что api-server вообще прилег у него

ребят сталкиваюсь с проблемой когда пишу логи кубера в еластик через filebeat “object mapping for [kubernetes.labels.app] tried to parse field [app] as object, but found a concrete value” может ктото знает простое решение?

https://github.com/elastic/beats/issues/9860

unable to recognize "prom/prometheus_volume-claim.yml": Get http://localhost:8080/api?timeout=32s: dial tcp 127.0.0.1:8080: connect: connection refused

Если ничего не работает, то смотри логи kubelet

ну по контейнерам гляжу, все в апе 10 часов, и апи и днс и кубелет и тд ща попробую поглядеть логи...

дайте прав в цытатник репостить

сделай свой

ребят сталкиваюсь с проблемой когда пишу логи кубера в еластик через filebeat “object mapping for [kubernetes.labels.app] tried to parse field [app] as object, but found a concrete value” может ктото знает простое решение?

точки есть в app?

сделай свой

я же не программист на голанге

точки есть в app?

кажется что нет вроде нет ни одного лейбла такого

я же не программист на голанге

тогда записывай в молескин

но не исключаю что всякие там helm или еще чтото могли создавать

ну по контейнерам гляжу, все в апе 10 часов, и апи и днс и кубелет и тд ща попробую поглядеть логи...

Хотя сейчас смысла особо нет, пока не добавишь ресурсов

тогда записывай в молескин

и опять я не хипстор :)

кажется что нет вроде нет ни одного лейбла такого

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

Хотя сейчас смысла особо нет, пока не добавишь ресурсов

etcdserver: read-only range request "key:\"/registry/daemonsets\" range_end:\"/registry/daemonsett\" count_only:true " with result "range_response_count:0 size:8" took too long (165.860927ms) to execute ну я могу хотя бы логи поглядеть из докер контейнеров

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

так и как тут быть?

туда нельзя точки совать, _ тоже вроде

так и как тут быть?

Поправить лейблы)

etcdserver: read-only range request "key:\"/registry/daemonsets\" range_end:\"/registry/daemonsett\" count_only:true " with result "range_response_count:0 size:8" took too long (165.860927ms) to execute ну я могу хотя бы логи поглядеть из докер контейнеров

165.860927ms это оченьььь много))

165.860927ms это оченьььь много))

W0207 09:57:58.509284 1 genericapiserver.go:319] Skipping API batch/v2alpha1 because it has no resources. о-па

а это с контейнера апи

туда нельзя точки совать, _ тоже вроде

Можно, если поставить альфу седьмой версии с фиксацией по дайджесту имаджа

W0207 09:57:58.509284 1 genericapiserver.go:319] Skipping API batch/v2alpha1 because it has no resources. о-па

Попробуй etcd посадить на более быстрые диски. И мне кажется все норм будет.

Попробуй etcd посадить на более быстрые диски. И мне кажется все норм будет.

W0207 09:57:58.509284 1 genericapiserver.go:319] Skipping API batch/v2alpha1 because it has no resources. W0207 09:58:10.071874 1 genericapiserver.go:319] Skipping API rbac.authorization.k8s.io/v1alpha1 because it has no resources. W0207 09:58:10.277336 1 genericapiserver.go:319] Skipping API scheduling.k8s.io/v1alpha1 because it has no resources. W0207 09:58:10.636646 1 genericapiserver.go:319] Skipping API storage.k8s.io/v1alpha1 because it has no resources. на каждые сервисы в общем кубера ругается апи сервер

Поправить лейблы)

да точки есть от helm chart: api-1.0.0

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

когда вообще без рук останусь:D

дауж и лейблы то особо не поменяешь

дауж и лейблы то особо не поменяешь

Религия запрещает?

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

Еще посмотри, пишет ли etcd следующий лог: failed to send out heartbeat on time и его значени Вот тут собственно коротко и ясно написано про оптимальные показатели: https://coreos.com/etcd/docs/latest/tuning.html

Религия запрещает?

они многие автоматически генерировались и я так понимаю вернутся даже не знаю есть ли у helm не добавлять эти его служебные labels

Еще посмотри, пишет ли etcd следующий лог: failed to send out heartbeat on time и его значени Вот тут собственно коротко и ясно написано про оптимальные показатели: https://coreos.com/etcd/docs/latest/tuning.html

спасибо))

Еще посмотри, пишет ли etcd следующий лог: failed to send out heartbeat on time и его значени Вот тут собственно коротко и ясно написано про оптимальные показатели: https://coreos.com/etcd/docs/latest/tuning.html

та не заметил такого, там столько мусора было

Религия запрещает?

ты уверен что проблема в точках то?

единственное что более менее информативное увидел, про задержки

Комрады, я тут запилил replicated block device. Идея в том есть драйвер говорящий с ядром через nbd и транслирующий nbd протокол в вызовы FoundationDB. А FoundationDB уже занимается репликацией и отказоустойчивостью. Если интересно, то вот гитхабчик https://github.com/meln1k/foundationdb-block-device

Выглядит интересно, где-то видел реализацию nbd-server с s3-бэкендом

единственное что более менее информативное увидел, про задержки

Ну вот у меня была таже проблема как у тебя. Помог вынос etcd на более быстрые диски. Попробуй протестировать как будет вести себя кластер.

они многие автоматически генерировались и я так понимаю вернутся даже не знаю есть ли у helm не добавлять эти его служебные labels

Он добавляет то, что ты в шаблоне напишешь

Вообще NBD достаточно плохо работает, если клиент не локальный, он плохо переживает падения сервера и потерю связи

ты уверен что проблема в точках то?

Скорее всего да, го же

Вообще NBD достаточно плохо работает, если клиент не локальный, он плохо переживает падения сервера и потерю связи

nbd клиент и сервер работают локально через юникс сокет, и сервер формирует запросы в базу, так что ничего страшного тут не случится

Выглядит интересно, где-то видел реализацию nbd-server с s3-бэкендом

в отличие от s3 бекенда данное решение выдает 10К random iops :)

@meln1k А что за FoundationDB?

Ну вот у меня была таже проблема как у тебя. Помог вынос etcd на более быстрые диски. Попробуй протестировать как будет вести себя кластер.

та я не хочу попасть на большие деньги из-за амазона) у меня на работе есть дев среда в кубере, так там m3.medium на мастере и t2.medium для двух нод и норм работает, хватает, но вот когда будет таска по прометею, чтоб я его туда впендюрил, то погляжу в итоге, как будет себя вести

в отличие от s3 бекенда данное решение выдает 10К random iops :)

А реплицироваться умеет?

@meln1k А что за FoundationDB?

это key-value база с транзакциями и синхронной репликацией

Ну вот у меня была таже проблема как у тебя. Помог вынос etcd на более быстрые диски. Попробуй протестировать как будет вести себя кластер.

диски кстати такие же

А реплицироваться умеет?

да, еще как :)

в отличие от s3 бекенда данное решение выдает 10К random iops :)

Sheepdog тоже выдает)

по 100 iops

по 100 iops

Да норм он выдает, только не безопасно нифига. Если резко отрубить есть большой шанс получить неконсистентность.

Sheepdog тоже выдает)

а что с автоматический фейловером? foundationdb спокойно перживает отстрел любой ноды прозрачно для клиента

а что с автоматический фейловером? foundationdb спокойно перживает отстрел любой ноды прозрачно для клиента

Sheepdog, вроде как тоже должен, но он ооочень странный!

по 100 iops

Почитай тут доку от etcd. Etcd очень чувствитель к IO. 100 это вообще практически ничего) Даже для поигратся

а что с автоматический фейловером? foundationdb спокойно перживает отстрел любой ноды прозрачно для клиента

Вообще очень интересно что там под капотом у OpenEBS, там вроде тоже репликация есть, но само устройство они через istgt отдают. Имхо ISCSI - намного стабильнее чем NBD работает

Да и istgt сам по себе очень быстрый

по 100 iops

Тем более тебе сам etcd об это кричит 165.860927ms

Вообще очень интересно что там под капотом у OpenEBS, там вроде тоже репликация есть, но само устройство они через istgt отдают. Имхо ISCSI - намного стабильнее чем NBD работает

у меня nbd не выдается клиенту как интерфейс. клиент сразу полуает block device, а nbd протокол используется для локального общения с ядром и формирования запросов в кластер foundationdb.

Тем более тебе сам etcd об это кричит 165.860927ms

да что-то мне кажется что это не из-за дисков, а из-за la я на нашем деве погляжу кстати логи, пишет-ли

осталось написать CSI интерфейс, и можно будет подключать к k8s плагином

да что-то мне кажется что это не из-за дисков, а из-за la я на нашем деве погляжу кстати логи, пишет-ли

Да я же писал выше что в следвтсвии этого LA высокое

интересная презенташка, как хранить секреты в Кубере с интеграцией через Терраформ https://speakerdeck.com/jelmersnoeck/from-terraform-to-kubernetes-creating-and-sharing-secrets

да что-то мне кажется что это не из-за дисков, а из-за la я на нашем деве погляжу кстати логи, пишет-ли

Disk An etcd cluster is very sensitive to disk latencies. Since etcd must persist proposals to its log, disk activity from other processes may cause long fsync latencies. The upshot is etcd may miss heartbeats, causing request timeouts and temporary leader loss. An etcd server can sometimes stably run alongside these processes when given a high disk priority.

да что-то мне кажется что это не из-за дисков, а из-за la я на нашем деве погляжу кстати логи, пишет-ли

У меня по этой причине LA стоял лютый, что на инстансах не реально было сделать что-то. Все к чертям висело, не говоря уже о работе компонентов control plane

etcd много делает дисковых операции. Когда диск медленный, то эти операции становтся во много раз дольше. В итоге получается пробка большая, которая и создает LA большой