fluentd или filebeat и собирать с диска в эластик.

есть еще fluent-bit. Но это все работает только на малых обьемах логов в секунду. (либо требует больших ресурсов от еластика) Логи из еластика к томуже довольно паскудно читаются.

Почему только на малых работает? Вполне видел большие инсталляции, у меня правда всего ~12-15 гигабайт в день.

У меня в сворме правда - graylog на коленке за 5 минут поднятый 15к рпс кушает и вроде жив пока, хотя поскрипывает иногда, вполне себе решение

У меня в сворме правда - graylog на коленке за 5 минут поднятый 15к рпс кушает и вроде жив пока, хотя поскрипывает иногда, вполне себе решение

Сколько под грейлогом реплик эластика?

Точнее из скольких нод кластер эластика)

И сколько ресурсов под это дело?

Почему только на малых работает? Вполне видел большие инсталляции, у меня правда всего ~12-15 гигабайт в день.

так или иначе все зависит от капасити еластик сервера(кластера). Чтобы увидеть как все умирает на дефолтных инсталяциях - можно врубить nginx ingress json logs, и даже просто logs, и натравить лоадтест хотябы 500-1000rps.

У меня в сворме правда - graylog на коленке за 5 минут поднятый 15к рпс кушает и вроде жив пока, хотя поскрипывает иногда, вполне себе решение

у грейлога под капатом тоже еластик же. Проблемы теже.

отдельно стоит упомянуть, что когда еластик (или прослойка перед ним) начинают захлебываться, то коллекторы пытаются отбуферизировать этот поток, и тоже начинают захлебываться. Ничего приятного короче. Мина замедленного действия.

>то коллекторы пытаются отбуферизировать этот поток, и тоже начинают захлебываться Ни разу с таким не сталкивался, т.к. все логи пишутся в файл и потом файлбитом отсылаются. Если эластик/логстеш втупили, файлбит просто притормаживает отправку и все.

все зависит от того, с какой скоростью ваш энвайромент позволяет писать логи в файлы. Но для к8с уже офтоп.

по Java - оракл же выкатил фикс https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits ну и флаги же есть для более старых версий. Мопед не мой, сам яву сейчас в проде не запускаю. С монгой точно такая же проблема у меня но только с памятью - надо ей в конфиг прописать сколько памяти она может юзать, иначе она попытается как обычно выжрать всю оперативу и упадет.

Это как раз sched_getaffinity , работает только если контейнер прибит к конкретным CPU. В кубе оно включается через CPUManager альфа фичу и работает только для qos guaranteed и только для целого значения ядер в cpu limits/requests.

>то коллекторы пытаются отбуферизировать этот поток, и тоже начинают захлебываться Ни разу с таким не сталкивался, т.к. все логи пишутся в файл и потом файлбитом отсылаются. Если эластик/логстеш втупили, файлбит просто притормаживает отправку и все.

Вот, человек пороху нюхал. В докере можно пользоваться только дефолтным json-file логером, все остальное ковбойство

Если не эластик, то что?

кликхаус

кликхаус

так вроде же они для разных вещей предназначены, нет?

хотя не, это немного другое, я с прометеусом перепутал

У нас есть Proof of Concept. Пока глубокая альфа, но гораздо легче, чем ElasticSearch. В плане ресурсов, конечно. Юзабилити ещё тянуть и тянуть. https://github.com/flant/loghouse

велосипед?

там же масса решений

разных

поясните

не масса

совсем

elk онли

для аггрегации логов

я имею в виду

Увидели потенциал Clickhouse в качестве бэкэнда - сделали интеграцию.

Увидели потенциал Clickhouse в качестве бэкэнда - сделали интеграцию.

а что уже есть и чего в ближайших планах?

В issue на GitHub можно посмотреть. Я непосредственно не задействован в разработке, лишь использую в некоторых проектах. Очень хорошо ставится в бюджетные конфигурации серверов.

travis там собирает только чарт => тестов нет?

Пока да, это альфа. К лету будет бета

а на сервисы не смотрели? Мы пробовали Loggly но не очень зашло и казалось дорого, сейчас сидим на AWS ES с которым свои грабли и не сказать что сильно дешево, другие команды у нас сейчас на logz.io - планируем попробовать скоро

Всем привет, у меня проблема с натом у Hetzner. Кто то сталкивался с таким? Мастер kubernetes на vServer'ах. Каждый vServer имеет серый адрес 172.31.1.100. У хостера подход 1:1 nat etcd, apiserver слушают externalIP создавал через kubeadm init --config config.yml apiVersion: kubeadm.k8s.io/v1alpha1 kind: MasterConfiguration api: advertiseAddress: hetzner-ip1 etcd: endpoints: - "http://hetzner-ip1:2379" - "http://hetzner-ip2:2379" networking: podSubnet: 10.244.0.0/16 nodeName: kub1 apiServerCertSANs: - "hetzner-ip1" - "hetzner-ip2" - "127.0.0.1" token: "7596f9fa1cc70" tokenTTL: "0" И вот проблема когда открываешь логи api то там он обращается на какой то левый ip Хетзнера I0215 18:36:40.816104 1 logs.go:41] http: TLS handshake error from 195.201.1.82:48292: remote error: tls: bad certificate

Дорого :) поэтому сделали свое - дешовое

Вот, человек пороху нюхал. В докере можно пользоваться только дефолтным json-file логером, все остальное ковбойство

аналогичные ощущения, сначала пытались в journald но была куча проблем, сейчас с json файликами и в целом получше. Но в моем случае стоит лимит в 50МБ на файлик в анстройках драйвера и можно потерять какие-то строки легко, что не очень критично для наших логов, но для многих может быть важно

Дорого :) поэтому сделали свое - дешовое

свое это на железе в смысле?

У каждого клиента в том же кубе разворачиваем эту систему

а не стремно логи в самом же кластере хранить? если поломался flannel ну или еще там что глобальное - как потом до них долезть и посмотреть логи? не лазить же на каждую ноду смотреть journald или что у вас там для логов системы

и вопрос в догонку, etcd тоже внутри кластера?

они живут в pvc. да и etcd там же

из нашего полтинника инсталяций кубов мы не сталкивались с такими проблемами. еще раз- - это альфа. там не все моменты предусмотрены

хорошо если все работает, мы когда начинали был 1.3 он EBS volume 1 из 20 раз в среднем аттачил, здорово что все сильно улучшилось с тех пор

Большая часть на Ceph RBD. С ним с 1.5, наверное, проблем не было почти. EBS инсталляция стабильно в 1.7 работает в AWS.

Всем кто тут за CRI-O топит, они до сих пор тупо копируют код из моби, когда у них самих что-то отваливается, до тех пор так и живут с протухшим кодом: https://github.com/containers/storage/pull/149 всяких вкусных штук вроде github.com/moby/moby/pull/34670 там еще хз сколько не будет

Увидели потенциал Clickhouse в качестве бэкэнда - сделали интеграцию.

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

Всем кто тут за CRI-O топит, они до сих пор тупо копируют код из моби, когда у них самих что-то отваливается, до тех пор так и живут с протухшим кодом: https://github.com/containers/storage/pull/149 всяких вкусных штук вроде github.com/moby/moby/pull/34670 там еще хз сколько не будет

оно копирует теперь хардлинками?

если это весь чендж, то это здорово, наконец-то догнали ostree, который только там и делает тащемта

оно копирует теперь хардлинками?

Нет, оно copy_file_range юзает, которое включает COW на последних xfs

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

а почему НЕ в кубере?

Нет, оно copy_file_range юзает, которое включает COW на последних xfs

интересно, посмотрим что отпишут в том же issue

а почему НЕ в кубере?

есть мнение что мониторить и логировать систему нужно извне этой системы. Это раз. Хранить стейт в кубере тяжело и геморойно - это два.

есть мнение что мониторить и логировать систему нужно извне этой системы. Это раз. Хранить стейт в кубере тяжело и геморойно - это два.

кто сказал?)

здравый смысл (с)

здравый смысл (с)

Достаточно базово мониторить мониторинг, что он жив :)

я всеже предпочитаю телеметрию федерейтить на внешний прометеус. Вообщем, как обычно it depends.

клаудовый prometheus кто нить сервисом предоставляет?

Мониторить в смысле глазами поглядывать?

Периодически

Ребят, скажите, а из контейнера внутри кубера есть доступ "наружу"? В интернет или к серверам вне кубера. Периодически натыкаюсь на туториалы когда люди предоставляют такой доступ через сервис

есть

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

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

Спасибо за ответ. Мысль пошла дальше)) А сервисом можно балансировку делать? Ну чтоб туда сунуть больше 1 ip. P.S. понимаю что наверное уже брежу)

ip route никто не отменял, так что не бредишь. если я правильно понял твою мысль

Egress Rules ?

вроде того получается) Ну т.е. есть некий внешний сервис у которого есть 1+ входных ip. И для того чтобы балансировать/failover'ить я прописываю в Service несколько внешних IP этого сервиса. Честно говоря, кажется что проще будет в самой приложеньке их прописать. Спрашиваю просто про возможность так сделать и уровень костыльности относительно канонов

у меня странная проблема, деплой через helm работает, если сменился image.tag, а если обновился image с тем же тегом, то ничгео не происходит. Рапортует об удачном апгрейде, а на деле поды теже. pullPolicy: Always стоит и tag не latest. helm 2.8.1

у меня странная проблема, деплой через helm работает, если сменился image.tag, а если обновился image с тем же тегом, то ничгео не происходит. Рапортует об удачном апгрейде, а на деле поды теже. pullPolicy: Always стоит и tag не latest. helm 2.8.1

Все правильно, в куб отправился yaml ничем не отличный от того, что там уже есть, почему он поды перезапускать должен? Надо чтобы ямл менялся, например номер релиза запихните в аннотацию к подам

а что тогда делает pullPolicy Always?

image sha отличается же

Оно скачиввает образ перед запуском пода, даже если он на хосте уже есть. Ваша проблема в том, что никто новые поды запускать и не пытается

хм, спасибо

короч нужно всегда двигать тэг имейджа

вроде того получается) Ну т.е. есть некий внешний сервис у которого есть 1+ входных ip. И для того чтобы балансировать/failover'ить я прописываю в Service несколько внешних IP этого сервиса. Честно говоря, кажется что проще будет в самой приложеньке их прописать. Спрашиваю просто про возможность так сделать и уровень костыльности относительно канонов

кажется я понял юзкейс, для этого в кубе есть сервис для внешних сервисов, по сути мы делаем статический внутрикластерный днс а сам сервис может ссылаться на что-то вне и это уже его ответственность как он это делает - вот тут в документации описано https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors

у меня странная проблема, деплой через helm работает, если сменился image.tag, а если обновился image с тем же тегом, то ничгео не происходит. Рапортует об удачном апгрейде, а на деле поды теже. pullPolicy: Always стоит и tag не latest. helm 2.8.1

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

ребят а подскажите про kube-proxy он возвращает какое то значение по пути /healthz

а откуда он его берет?

кажется я понял юзкейс, для этого в кубе есть сервис для внешних сервисов, по сути мы делаем статический внутрикластерный днс а сам сервис может ссылаться на что-то вне и это уже его ответственность как он это делает - вот тут в документации описано https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors

Спасибо большое. Почитаю.

а что тогда делает pullPolicy Always?

это для кубернетеса а не хелма, например если запустить новый под (или если удалить старый и заново стартануть) то в случае always он проверит реджистри, иначе если на этой ноде уже есть такой образ (с IfNotPresent) то он в реджистри не полезет

ключевое слово, "если удалить" ))

ребята не подскажите откуда берет значение kube-proxy я образаюшь к нему а он мне возвращает вот такое значение "1 Service Endpoints found"

Подскажите пожалуйста, можно ли настроить доступ в ~/.kube/config от имени ServiceAccount-а с использованием только токена?

Упорно пишет Unauthorized

что такое "доступ в ~/.kube/config"?

Ну, в смысле настроить kubectl на работу с k8s правя таким образом ~/.kube/config

а, в смысле в конфиг только токен положить. По идее должно работать, я подключаюсь к апи курлом, иcпользуя только токен (и ca.pem, но это для ssl, я так понял у вас не с ним проблема).

возможно этот сервис аккаунт не может быть авторизован на то действие, которое вы запрашиваете

у меня говорит Unauthorized на всё, возможно как-то не так токен интерпретирую

base64/jwt, вот это всё

про jwt не могу ничего сказать. Чтобы получить токен, я обычно делаю describe serviceaccount <accountname>, там я вижу секреты, потом я делаю describe secret <secretname>, и там уже есть токен. Ну или можно вручную с пода забрать файл.

вот с секрета то и скопировал

и напрямую пробовал и в base64 кодировать