да, я вот уже в серьез задумался :) в данный момент kubernetes используется для stateless сервисов, хочется так-же и statefull базы данных в нем запускать

бинго!

Я тут немного пораскинул мозгами - это ведь реально просто реализовать. Kubernetes и сущность StatefulSet отлично для этого подходит. Понадобится всего лишь простенький скрипт на мастере. Скрипт будет раз в короткий промежуток времени запускать kubectl get nodes и в случае обнаружения дефектной ноды выполнять fencing для нее, после этого удалять statefull pod'ы, что бы Kubernetes перезапустил их на других нодах.

Keep it short and simple

Поделюсь болью: В hyperkube 1.8 изменили базовый образ. Из-за этого в kubelet-wrapper, который используется в CoreOS сломался port-forward: socat просто зависает. Фикса в coreos stable пока нет: https://github.com/coreos/coreos-overlay/pull/2839 Будьте бдительны! Не убивайте почти 2 дня на дебаг, как я:)

А статус етцд что говорит?

А статус етцд что говорит?

etcd говорит что все впорядке, а api-server сыпет ошибками вроде: E1106 18:25:48.000712 1 status.go:62] apiserver received an error that is not an metav1.Status: rpc error: code = Internal desc = transport is closing I1106 18:25:48.000903 1 trace.go:76] Trace[2097119868]: "Create /api/v1/namespaces" (started: 2017-11-06 18:25:43.915292783 +0000 UTC) (total time: 4.085589052s): Trace[2097119868]: [4.007451233s] [4.002336898s] About to store object in database E1106 18:25:48.005714 1 client_ca_hook.go:78] rpc error: code = Internal desc = transport is closing E1106 18:25:50.467650 1 status.go:62] apiserver received an error that is not an metav1.Status: rpc error: code = Internal desc = transport is closing I1106 18:25:50.468250 1 trace.go:76] Trace[271110128]: "Create /api/v1/nodes" (started: 2017-11-06 18:25:49.810669425 +0000 UTC) (total time: 657.561839ms): Trace[271110128]: [657.561839ms] [657.364054ms] END

кто пользует kube-lego?

Я хочу попробовать. Но пока не понял, как скрестить его с трафиком

Поделюсь болью: В hyperkube 1.8 изменили базовый образ. Из-за этого в kubelet-wrapper, который используется в CoreOS сломался port-forward: socat просто зависает. Фикса в coreos stable пока нет: https://github.com/coreos/coreos-overlay/pull/2839 Будьте бдительны! Не убивайте почти 2 дня на дебаг, как я:)

Линуса на них нехватает

Линуса на них нехватает

Насчёт Линуса:) node_exporter начал падать с panic из nfs collector после обновления ядра до 4.13. Я пока не смотрел, что не так, но явно формат вывода из /proc поменялся

https://docs.google.com/document/d/1ti1Qjt7DKoRThdXWQxHmeRVqjeseOJgNIPBX_H0Sf0Q/edit#

Есть желание в игровом кластере развернуть nfs прямо в докере для pv. Например на этом https://hub.docker.com/r/fuzzle/docker-nfs-server/. Норм или есть вариант получше?

https://docs.google.com/presentation/d/1xeagoDn-6kQ6FPdfX9IlD5MjWalW2o8PeCt20DEfFpg/mobilepresent?slide=id.g272b78446f_0_221

Насчёт Линуса:) node_exporter начал падать с panic из nfs collector после обновления ядра до 4.13. Я пока не смотрел, что не так, но явно формат вывода из /proc поменялся

Кажется ioctl и /proc не подпадали под гарантии совместимости

так, а какой модный способ смотреть логи мертвых подов? нужно менять backend для логов в k8s? типа fluentd, или каковы тренды?

я чет ссыкую какой то docker logging driver использовать, который по сети отправляет логи. припоминаю что с gelf были ситуации когда контейнер не запускался изза недоступности logstash

я чет ссыкую какой то docker logging driver использовать, который по сети отправляет логи. припоминаю что с gelf были ситуации когда контейнер не запускался изза недоступности logstash

и чем закончились эти ситуации?

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

я тоже не стал заморачиваться, собираю логи filebeat'ом

для fluentd нагугливается https://github.com/moby/moby/issues/15757 где вроде пофиксили поведение, если fluentd недоступен - контейнер запустится всеравно

в общем, k8s складывает json журналы в /var/log/containers и единственная проблемма - это длинные имена. было бы круто иметь в json поле с именем контейнера, чтобы не думать как с этими именами потом разбираться

вроде как есть log tag options, чтобы в json больше сыпалось и этого будет достаточно наверное, еще даже не проверял

а если logstash на той же машине?

на каждой поднимать будешь вручную (вне k8s)?

почему в ручную, например в ECS, еще одним контейнером

в общем, k8s складывает json журналы в /var/log/containers и единственная проблемма - это длинные имена. было бы круто иметь в json поле с именем контейнера, чтобы не думать как с этими именами потом разбираться

зачем имя в логе? оно есть в названии файла лога

насчет json-log, достаточно к запуску докер демона добавить --log-opt=labels=io.kubernetes.container.name,io.kubernetes.pod.name,io.kubernetes.pod.namespace и можно будет видеть в json что за нэймспейс\под\контейнер. я лично предпочел бы ни от чего не зависеть, а уж json логи сливать можно куда захочешь

ну прост по json то удобнее будет запрос строить

выглядит потом как то так: { "log":"I1107 12:12:36.135370 7 controller.go:313] ingress backend successfully reloaded...\n", "stream":"stderr", "attrs":{ "io.kubernetes.container.name":"nginx-ingress-controller", "io.kubernetes.pod.name":"nginx-ingress-controller-kphcg", "io.kubernetes.pod.namespace":"default" }, "time":"2017-11-07T12:12:36.135491879Z" }

у меня так: 1. filebeat слушает логи, передаёт их в logstash + путь до файла лога 2. logstash гроком парсит имя лога, накидывает поля каждой записи лога + превращает лог из json в поля 3. закатывает в эластик

в названии лога есть и имя, и id, и namespace

ага

тут только с мультилайном беда в этой схеме

откуда тут мультилайн? это ж json

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

всё, что не закодировано в json — не json

вот я и говорю, что мультилайновые стэктрейсы придется писать куда то мимо stdout\stderr

ну это уже у каждого своя магия, мы вроде используем go-zap для логгирования. Если мне не изменяет память, то там стектрейс энкодится

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

тоесть его не прочесть глазами? =)

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

тоесть его не прочесть глазами? =)

ну в файле лога — нет)

ну это уже у каждого своя магия, мы вроде используем go-zap для логгирования. Если мне не изменяет память, то там стектрейс энкодится

а кто распарсивает это все? grok?

grok и json

Кто нибудь про RozoFS что-нибудь слышал/пробовал? https://github.com/rozofs/rozofs

насчет json-log, достаточно к запуску докер демона добавить --log-opt=labels=io.kubernetes.container.name,io.kubernetes.pod.name,io.kubernetes.pod.namespace и можно будет видеть в json что за нэймспейс\под\контейнер. я лично предпочел бы ни от чего не зависеть, а уж json логи сливать можно куда захочешь

О, удобно. Откуда докер знает про поды и неймспейсы?.

Я регуляркой в grsylog расковыриваю нэймспэйс, имя пода и контейнера из полного имени контейнера, которые создаёт kubelet

мы логи пока храним и смотрим с помощью https://github.com/flant/loghouse

О, удобно. Откуда докер знает про поды и неймспейсы?.

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

Да, в inspect на уровне докера видно кое что с уровня k8s)

Думаю, что /spam

/spam

/report

Нот воркинг

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

да лан

планета хоть вздохнет с облегчением

при условии что от нее что-то останется

останется

/spam

@DenisIzmaylov

https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/

https://github.com/prometheus/prometheus/releases/tag/v2.0.0

Решили с amazon s3 переехать на google cloud storage. По докам, Google Cloud Storage XML API совместим с s3. был ли у кого-то опыт переезда? нужно ли менять клиентов на сервисах?

Всем привет! Кто нибудь смотрел на etcd operator? https://github.com/coreos/etcd-operator/blob/master/README.md У меня возник вопрос)) Вот тут по мануалу предполагается поднимать кластер етцд в кубернете... Но для старта кубернета требуется кластер етцд))) А как поднять кубер на кластере етцд, управляемом этим оператором?

static pods наверное используются. kubelet когда стартует, поднимает их

я не смотрел, прост наугад =)

ну я поднимаю на железе CoreOS и при старте кубера использую етцд, вшитые в CoreOS. там в последней версии корки уже етцд версии 3 идёт

ну что, есть у кого какие мысли?

ну что, есть у кого какие мысли?

ответ очевиден, никак если хочешь использовать кореосовский фланнел

ответ очевиден, никак если хочешь использовать кореосовский фланнел

а если не использовать коросовский фланел?

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

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

так я попробую)) если мне подкинуть идею)) как именно это можно сделать и чем тут мешает фланел?

кто-нибудь ставил prometheus operator? там 3 реплики прометеуса если создать они автоматом сумеют в кластер определиться, или рандомно каждый будет пулить метрики отдельно себе?

Всем привет! Кто нибудь смотрел на etcd operator? https://github.com/coreos/etcd-operator/blob/master/README.md У меня возник вопрос)) Вот тут по мануалу предполагается поднимать кластер етцд в кубернете... Но для старта кубернета требуется кластер етцд))) А как поднять кубер на кластере етцд, управляемом этим оператором?

Смотрите bootkube (и typhoon как пример использования) оно умеет, но не рекоммендуют и вообще на эту фичу подзабили.

ответ очевиден, никак если хочешь использовать кореосовский фланнел

Фланнел может без etcd работать

Фланнел может без etcd работать

Это писать в apiserver ?

Да