Ну они в связке с fluentd работают

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

и собирают логи с кластера

ааа, это было ELK vs graylog2

http://kubernetes.io/docs/getting-started-guides/logging-elasticsearch/

ааа, это было ELK vs graylog2

Ну типа да)

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

o_O

ну и в логах пусто, я даже через strace уже процесс смотрел

никаких ошибок

отключили это - все перестало пропадать

по поводу мониторинга деплоев и кастомных метрик

программисты у меня тут ленивые, поэтому мне пришлось написать им обертку вокруг kubectl

такой недохельм

страсти какие

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

в итоге получается так:

кстати какую ACL используешь для программистов?

скрипт (да и деплой вообще) сейчас работает так: 1. обновление версии в манифесте 2. git commit; git tag -a; git push; git push —tags 3. kubectl apply -f <манифест> дальше скрипт умирает, а все остальное разделяется на два потока 1. квай получает хук от гитхаба и начинает билдить образ 2. кубернетес получает обновленный манифест и начинает готовить его к запуску 2.1 подготавливается новый под в состоянии pending 2.2 качается образ с квая (до усера, пока квай его не опубликует) после того, как квай собрал и опубликовал новый образ 2.3 образ скачивается на ту ноду, где под в состоянии pending 2.4 гасится один из старых подов 2.5 под, бывший в состоянии pending, получает образ и стартует 2.6 гасится второй старый под 2.7 поднимается второй новый под ... профит

кстати какую ACL используешь для программистов?

ABAC или ты о чем?

об этом

токены для аутентификации, ABAC для авторизации

"версия в манифесте" ты имеешь в виду tag?

да

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

пока что в голову пришла только такая схема:

шаг 1: в скрипте куда-то высираем номер версии, которую деплоим шаг 2: в постСтарт хуке контейнера высираем туда же номер версии, которая задеплоилась цифирьки сошлись - улюлю, все хорошо цифирьки не сошлись - какое-то говно второй цифирьки нет больше н-минут - что-то с вероятностью пошло не так

но куда срать и чем ловить пока не придумал

нужен совет знатоков ;)

а почему не запустить какой-нибудь CI сервер прямо в кубике? тогда все может происходить в одном pipeline

заеб компании

все что можно вынести наружу, надо вынести наружу

поэтому никакого гитлаба, никаких CI внутре, etc

У вас не 12factors app? В stdout же проще + ES +kibana

грейлог - это тот же ES, но в более интересной обертке, чем кибана

ничего не могу с этим сделать

кстати, по поводу 12 факторов: а вот есть stdout/stderr, условно говоря это log.info и log.error... а если я хочу log.warn иметь и log.debug то как поступать?

log.warn+ -> stderr, log.info- -> stdout

чуток по поводу elk: лично мне нравится kibana, по крайней мере лучше всех коммерческих решений которые я перепробовал по CI: я прям в докер который тестирует приложение вмонтировал kubectl с креденшиалсами, и он после тестов делает "patch" деплоймента с новым имаджем :)

угу, у меня есть примерно такое на тревисе

в другом проекте

там докер есть, а кубернетеса пока нет

скрипт (да и деплой вообще) сейчас работает так: 1. обновление версии в манифесте 2. git commit; git tag -a; git push; git push —tags 3. kubectl apply -f <манифест> дальше скрипт умирает, а все остальное разделяется на два потока 1. квай получает хук от гитхаба и начинает билдить образ 2. кубернетес получает обновленный манифест и начинает готовить его к запуску 2.1 подготавливается новый под в состоянии pending 2.2 качается образ с квая (до усера, пока квай его не опубликует) после того, как квай собрал и опубликовал новый образ 2.3 образ скачивается на ту ноду, где под в состоянии pending 2.4 гасится один из старых подов 2.5 под, бывший в состоянии pending, получает образ и стартует 2.6 гасится второй старый под 2.7 поднимается второй новый под ... профит

Ты получается deployments вообще не используешь? или я не так понял? а как же rolling update, HA и прочее?

так наоборот же

deployment реализует rolling update

все в деплойментах

просто ты про поды писал

deployment запиливает pod'ы

ну деплоймент же подами оперирует

тупой вопрос и отсутствие времени на копание доков: можно в двух словах основные отличия patch от apply?

apply вроде сразу применяет изменения + создает если нету ресурса

patch может поставить их в очередь?

ну как я понимаю - при следующем запуске пода или еще чего будет применен пропатченный ресурс

но может я ошибаюсь

вот кстати

мне нужно обновить deployment

но перезапустить pod пока не нужно. как сказать k8ы чтобы он не рестартил поды

ну как вариант сразу на паузу поставить апдейт)

http://kubernetes.io/docs/user-guide/kubectl/kubectl_rollout_pause/

а кто какой стораж-драйвер использует?

сейчас Devicemapper(loop), в новых инсталяциях со свежим докером делаем уже direct-lvm. ибо The preferred configuration for production deployments is direct-lvm https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#/configure-direct-lvm-mode-for-production

а что такое Paas-type work?

он там красненький для директ-лвм

https://docs.docker.com/engine/userguide/storagedriver/images/driver-pros-cons.png

о. и кстати

teamur а посмотри на любой машине с direct-lvm и кубернетесом в папку /var/log/containers

чего там в ней?

Чет бьюсь с установкой на ubuntu, то ntpd удаляет интерфейсы, то вот застрял на ошибке The connection to the server 10.3.0.4:8080 was refused - did you specify the right host or port? (kubectl failed, will retry 2 times)

на 8080 ничего не поднялось

teamur а посмотри на любой машине с direct-lvm и кубернетесом в папку /var/log/containers

нет такой папки :)

ERROR: S client not available

Чет бьюсь с установкой на ubuntu, то ntpd удаляет интерфейсы, то вот застрял на ошибке The connection to the server 10.3.0.4:8080 was refused - did you specify the right host or port? (kubectl failed, will retry 2 times)

$ curl -I 10.3.0.4:8080

нет такой папки :)

этого я и боялся как тогда fluentd какой-нить вкручивать?

$ curl -I 10.3.0.4:8080

я в netstat смотри и вижу фигу :)

на curl Connection refused

ну так потому и не кусают

у тебя apiserver слушает insecure_port только на холокосте

надо либо --insecure-address=0.0.0.0

либо уже https делать по-человечьи

советую второй вариант

этого я и боялся как тогда fluentd какой-нить вкручивать?

ну дык всегда можно направить в сислог, а в качестве коллектора логов использовать уже какой-нить flume-ng и пихать уже с него в эластику

логи докера в локальный сислог

видимо все таки --insecure-bind-address=0.0.0.0 и конфиге это можно включить, но дело в другом Unknown admission plugin: DefaultStorageClass

а что у тебя в --admission-control?

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,DefaultStorageClass,ResourceQuota

все по умолчанию из коробки

эээ

1.3.7

SecurityContextDeny по-умолчанию?

да

http://kubernetes.io/docs/admin/admission-controllers/

ну и DefaultStorageClass в доке нету

хз, где ты его взял ;)

у меня вот так: --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota

с релизов скачал и запустил

короче, почитай http://kubernetes.io/docs/admin/admission-controllers/

и выбери только те, что реально нужны

мне вот нужны только те четыре, что я привел

ага, я уже удалил неизвестные и запустил

но реально просто так не запустишь

особено убил ntpd который удалял интерфейс docker0

агрессивный какой ntpd...

Максим, спасибо за подсказки