ребята а кто как логи собирает в кубере в elastic fluentd , filebeat или еще как то?

демонсет filebeat на каждой ноде, который читает логи докера, добавляет к ним kubernetes metadata и отправляет в elasticsearch, при этом каждый namespace в отдельный index

--- Всем привет. Есть задача запрофайлить jvisualvm'ом микросервис который бежит внутри К8с кластера. Что уже попробовал? 1) Добавил проперти для jmx и rmi (а-ля "com.sun.management.jmxremote" и иже с ними), вместе с "jmxremote" и "jmxremote.rmi" портами в Dockerfile, пробросил их через EXPOSE 2) В K8s yaml добавил этот порт в описание деплоймента 3) Через "kubectl port-forward" пробрасываю локальный порт на jmx порт с деплоймента 4) Пытаюсь подключится jvisualvm через Connecton -> Add JMX Connecton и получаю ошибку "Cannot connect to localhost:9010 using service:jmx:rmi:///jndi/rmi://localhost:9010/jmxrmi" Грешу что пропертя "java.rmi.server.hostname=localhost" не подходит для кластера. Кто-то решал подобную задачу? Что можете посоветовать? Спасибо ---

демонсет filebeat на каждой ноде, который читает логи докера, добавляет к ним kubernetes metadata и отправляет в elasticsearch, при этом каждый namespace в отдельный index

у тебя напрямую в elastic или через logstash ( у меня такое стоит через redis->logstash->redis) но приложения пишут в json и хочется их распарсить

напрямую без логсташа

докер и так в json все пишет

докер и так в json все пишет

да в json но filebeat берет это как строку и передает logstash строку в случае kubernetes

ну смотри, вот мой конфиг https://gist.github.com/kvaps/aeab50b5654752a8c1444a6c5503a120

а, или ты про json в логах самого приложения?

а, или ты про json в логах самого приложения?

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

вот у тебя type docker а у меня стоит type: log

если так, то можно sidecar контейнер с logstash который будет логи приложения парсить и передавить в эластик.

для приложений который просто в stdout пишу, этого вполне достаточно

ну я и поставил logstash но там фильтр получается ругается так как не все ведь контейнеры пишут в json , например есть тот же redis он не пишет в json и парсинг logstahs ругается

Господа, а пробовал ли кто-нибудь oklog?

вопрос. А можно ли configmap использовать в spec для deployment?

как часть спека

ну я и поставил logstash но там фильтр получается ругается так как не все ведь контейнеры пишут в json , например есть тот же redis он не пишет в json и парсинг logstahs ругается

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

Почему Persistent Volume может не удаляться?

Почему Persistent Volume может не удаляться?

потому что pvc не удален?

удалён

а что за сторадж?

там цеф поцеплен

не удаляется потому что finalizers в манифесте не дает, по идее провижионер должен снести волум в цефе затем удалить pv

ага, понял.

смотри логи провижионера, или попробуй удалить вручную, удалив волум в цефе, затем поле finalizers в манифесте

а, всё, снеслось.

Возможно у кого-то было что-то подобное. Поставил калико, у сервиса есть два endpoints скажем 10.0.1.234 и 10.0.11.32, но в правилах iptables только одна запись для DNAT добавляется tcp to:10.0.1.234:80

https://banzaicloud.com/blog/mysql-on-kubernetes/

Привет. скажите, может кто сталкивался: появляется на 2-3 минуты Node kube-test-03 status is now: NodeHasDiskPressure failed to garbage collect required amount of images. Wanted to free 4925275340 bytes, but freed 0 bytes Но на сервере при этом ~70g на разделе (всего 100, раздел один, корневой). Что может давать такую ошибку, кроме отсутствия места?

иноды ?

df -i посмотри

смотрела, нормально

ну всмысле около 95% свободно

и буквально через 2-3 минуты он находит внезапно место, и перезапускает под.

и буквально через 2-3 минуты он находит внезапно место, и перезапускает под.

Скнь параметры командной строки kubelet.

--eviction-minimum-reclaim опция влияет явно на то, что ты видишь в логах. Подкрутить надо.

Или её друзья из eviction* опций.

/usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cadvisor-port=0 --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki --feature-gates=ReadOnlyAPIDataVolumes=false

такой опции нету

щас почитаю

щас почитаю

https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/ Вот это читать очень внимательно.

thanks

подскажите кто-нибудь как можно организовать pv+pvc для работы с хранилищем подам с двух нод (один из них мастер) не используя при этом внешние API (e.g. aws, azure) ?

ткните носом в доку, если такая есть)

куб развёрнут на виртуалках kvm

подскажите кто-нибудь как можно организовать pv+pvc для работы с хранилищем подам с двух нод (один из них мастер) не используя при этом внешние API (e.g. aws, azure) ?

ceph?

подскажите кто-нибудь как можно организовать pv+pvc для работы с хранилищем подам с двух нод (один из них мастер) не используя при этом внешние API (e.g. aws, azure) ?

https://akomljen.com/using-existing-ceph-cluster-for-kubernetes-persistent-storage/

да, то что нужно

спасибо!

Ох, в какую яму ты сейчас спустишься...

верю)

Мы активно его используем, но дышать глубже можно, когда AWS EBS под рукой.

принято

посоветуйте способ делать инициализацию приложения в deployment. init containers не совсем вписываются, по многим причинам 1) они выполняются при создании пода, а мне надо при создании/обновлении deployment 2) они выполняются при создании каждого пода, а мне надо только один раз 3) они могут начать выполняться в параллель 4) инит контейнер из одного пода может работать тогда, когда началось выполнение приложения в другом поде если 1 и 2 ещё терпимо, то 3 и 4 могут привести к неприятным последствиям

посоветуйте способ делать инициализацию приложения в deployment. init containers не совсем вписываются, по многим причинам 1) они выполняются при создании пода, а мне надо при создании/обновлении deployment 2) они выполняются при создании каждого пода, а мне надо только один раз 3) они могут начать выполняться в параллель 4) инит контейнер из одного пода может работать тогда, когда началось выполнение приложения в другом поде если 1 и 2 ещё терпимо, то 3 и 4 могут привести к неприятным последствиям

миграция?

типа того

Это cd делает обычно

$ run migrations $ kubectl apply

К разрабам требование - миграции не должны ломать работающие инстансы. типа не делать drop column

инструмент миграций не поддерживает локи?

то есть обратная совместимость в пределах апгрейда

Причем тут локи?

zero downtime deployment же. Никаких локов в принципе не может быть

инструмент миграций не поддерживает локи?

это плохо, если база будет локаться на миграции при масштабировании (добавлении нового пода)

если используете helm то там есть пост пре и прочие хуки

она в любом случае у вас так или иначе залочена на время миграций

Причем тут локи?

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

с чего она лочится? Простые операции вроде alter column без default или сознание новой таблицы не лочит базу.

она в любом случае у вас так или иначе залочена на время миграций

так вот я и не хочу миграции при масштабировании. только один раз при смене версии в деплоймемнте

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

ненене, даже не уговаривайте. миграции это не часть нормального функционирования приложения, это часть апгрейда

кк

rails/django всегда делали миграции и потом меняли воркеры. Тут также, только сменой воркеров занимается k8n. Годами проверенная практика.

(остальные фреймворки тоже скорее всего, я для примера)

$ run migrations $ kubectl apply

а как быть если миграция должна новый столбец сделать, на базе уже существующих? ты накатишь миграцию, сделается столбец с содержимым, а код еще старый работает, изменит старый столбец и данные разъедутся

да хоть триггерами

Это договорённость с программистами. Все должны понимать, как миграции приедут на прод. Есть куча статей на эту тему.

да хоть триггерами

Я всеми руками за критическию бизнес логику в триггерах (особенно операции с баблом, количество товара и тп). Только этот подход куча людей критикуют, типа бизнесухе не место в базе.

Не место. Просто один из вариантов решения проблемы.