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

еще бы дали возможность крутить размер буфера под log line, было бы вообще отлично.

>Some problems here may be with users who are directly accessing container log files, expecting a particular format, place on disk, etc... this sucks... but ultimately on-disk state is not part of our API and people should not be messing around in there аахахахахха

"some problems", да

писать логи локально в протобаф это прям космос идея

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

куб забирает через dockershim путь до лог-файлов у докера. потому фича все еще полезна, если надо писать логи удаленно.

т.к. теперь не надо выбирать

кстати а кто-нибудь юзает убунтовский docker.io с --log-driver=journald?

чтение из журнала не работает

и соответственно ломается kubectl logs

а какая убунта?

куб забирает через dockershim путь до лог-файлов у докера. потому фича все еще полезна, если надо писать логи удаленно.

Ну там приписочка, что формат на диске поменялся, а значит kubelet офигеет пока что

18.04

Что такое докершим? Я немного отстал от веяний

Что такое докершим? Я немного отстал от веяний

часть докера, реализующая CRI. По ссылке есть диаграмка https://katacontainers.io/posts/why-kata-containers-doesnt-replace-kubernetes/

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

Какой ингресс контроллер и какая схема подключения? По cluster-ip работает?

Кто нибудь решал задачу с публикацией UDP сервисов наружу. Как это сделать правильно в кубе?

возможно тебе поможет ингресс нжинкс

Возможно нет :)

Там либо прокси пилить либо прям сервис жопой вытаскивать, но есть проблемы с маппингом портов

Ну, не проблемы а неудобства

нжинкс же вроде умеет быть udp прокси

Умеет

коллеги, а кто-нибудь ловил на 1.7.1 при большой нагрузке на сервис, connection reset by peer? если спрашивать не через сервис, ошибок нет kube-proxy запущена с --proxymode=iptables

коллеги, а кто-нибудь ловил на 1.7.1 при большой нагрузке на сервис, connection reset by peer? если спрашивать не через сервис, ошибок нет kube-proxy запущена с --proxymode=iptables

ловили, переходи на ipvs

правда на 1.9 и на 1.10 ловили

но суть та же

да, только 1.7.x не умеет в ipvs

это же фича кубе-прокси

нельзя только его подобновить?

сложновато

штопаделать

если у тебя получится побороть без ipvs - сообщи пожалуйста

ок

перешел на 1.10.1 и врубил ipvs - не помогло. дело происходит на ажуре (но не AKS)

коннтрек для ipvs включил?

точнее, значения задрать надо

оно дефолтное 131072

подробнее можно у @rgersh узнать, если он не спит

я вот думаю, svc нужно пересоздавать после этих телодвижений?

ну ты проверь остались ли iptables nat правила

с ipvs натолкнулся на такой баг https://github.com/kubernetes/kubernetes/issues/59976

с ipvs тоже не вышло, коннективити между подами есть, но вылазит тот же connection reset by peer под нагрузкой (10 параллельных tcp сессий)

https://www.reddit.com/r/kubernetes/comments/954ybm/horrors_of_using_azure_kubernetes_service_in/

А кто тут использует cilium?

А кто тут использует cilium?

+1

с ipvs тоже не вышло, коннективити между подами есть, но вылазит тот же connection reset by peer под нагрузкой (10 параллельных tcp сессий)

В dmesg на клиенте и сервере нет ничего?

А кто тут использует cilium?

Зачем?

В dmesg на клиенте и сервере нет ничего?

ничего страшного, проверял

у меня меня, есть один воркек и один мастер на воркере запущена два пода если делать seq 1 100000 | xargs -P5 curl <second-pod> все работает сносно если сделать в десять потоков seq 1 10000 | xargs -P10 ... ловлю connection reset by peer, на некоторое количество запросов

сам k8s, 1.7.1, kube-proxy пробовал в разных вариациях, от userspace, до ipvs.

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

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

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

net.core.somaxconn какой у вас выставлен?

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

8096

у меня складывается впечатление, что эти линуксы никак не тюнились вообще

Всем привет! КТо нибуть снимает логи контейнеров в k8s через fluentd и GELF?

у меня складывается впечатление, что эти линуксы никак не тюнились вообще

Если 8096 - значит тюнились, по дефолту там 128

Всем привет! КТо нибуть снимает логи контейнеров в k8s через fluentd и GELF?

кто-нибудь наверняка

у меня складывается впечатление, что эти линуксы никак не тюнились вообще

Но там ещё приложение может само выставлять backlog, как вариант

kube-proxy выставляет, да

стоит в его опции глянуть ещё

кто-нибудь наверняка

Есть какой то имейдж докеровский готовый под эти цели? Видел только для системных компонентов.

в россии выходной сегодня?

ERROR: S client not available

в августе вроде нет праздников

Но там ещё приложение может само выставлять backlog, как вариант

я проверял изнутри second pod теже curl на localhost проблема отсутствует

Есть какой то имейдж докеровский готовый под эти цели? Видел только для системных компонентов.

разве не демонсетом принято запускать?

Всем привет! КТо нибуть снимает логи контейнеров в k8s через fluentd и GELF?

Вот это посмотрите https://github.com/roffe/kube-gelf

у меня меня, есть один воркек и один мастер на воркере запущена два пода если делать seq 1 100000 | xargs -P5 curl <second-pod> все работает сносно если сделать в десять потоков seq 1 10000 | xargs -P10 ... ловлю connection reset by peer, на некоторое количество запросов

Так вы в под или в сервис ходите? Говорили что в под нормально работает

хожу из одного pod'а в другой, проблема есть если во втором поде запустить тест и натравить его на localhost - проблема отстутсвует поды на одной машине запущены

Вот это посмотрите https://github.com/roffe/kube-gelf

Смотрел, но немного не подходит решение.

В 10 потоков сразу умирает или держится сначала?

Всем привет. Вчера уже задавал вопрос по запуску cadvisor'а и сбору метрик, продолжаю с этим разбираться. Сейчас команда kubectl top node возвращает ошибку error: metrics not available yet При этом, логе heapster'a вижу записи подобного вида: error while getting containers from Kubelet: failed to get all container stats from Kubelet URL "http://10.90.8.15:10255/stats/container/": Post http://10.90.8.15:10255/stats/container/: dial tcp 10.90.8.15:10255: getsockopt: connection refused Порт 10255 действительно не слушается ни на одной из нод(все версии 1.11). Как я понял по релиз нотсам, с 11 версии этот порт по умолчанию закрыт, а открыт защищенный 10250. Вижу два возможных варианта решения: 1. Открыть порт 10255 2. Настроить heapster'а на работу по порту 10250. Прав ли я? Подскажите, что нужно выполнить, чтобы реализовать второй вариант?

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

Всем привет. Вчера уже задавал вопрос по запуску cadvisor'а и сбору метрик, продолжаю с этим разбираться. Сейчас команда kubectl top node возвращает ошибку error: metrics not available yet При этом, логе heapster'a вижу записи подобного вида: error while getting containers from Kubelet: failed to get all container stats from Kubelet URL "http://10.90.8.15:10255/stats/container/": Post http://10.90.8.15:10255/stats/container/: dial tcp 10.90.8.15:10255: getsockopt: connection refused Порт 10255 действительно не слушается ни на одной из нод(все версии 1.11). Как я понял по релиз нотсам, с 11 версии этот порт по умолчанию закрыт, а открыт защищенный 10250. Вижу два возможных варианта решения: 1. Открыть порт 10255 2. Настроить heapster'а на работу по порту 10250. Прав ли я? Подскажите, что нужно выполнить, чтобы реализовать второй вариант?

Убить хипстер и жить с metrics-server

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

А в 'ss -nl' на сервере какой backlog ?

я к сожалению в этом контейнере не могу его поставить, из-за отсутствия прав. я бы тоже грешил на backlog, если бы не работающий тест через localhost. backend'ом там служит java фреймвор jetty

хотя точно можо утверджать, что connectio reset by peer я ловлю на моменте connect(2)

я вот думаю, не поднять ли мне рядом nginx и не сделать ли тест против него

Есть какой то имейдж докеровский готовый под эти цели? Видел только для системных компонентов.

При старте контейнера с fluentd вот такая ошибка unexpected error error_class=Errno::EACCES error=#<Errno::EACCES: Permission denied @ rb_sysopen - /var/log/fluentd-containers.log.pos>

да, если натравить на nginx, то проблема отсусттвует

я давно смотрел в то как устроена сеть в линуксе, у меня есть какое-то странное ощущение, что когда пакет идет на localhost, он может попадать в "берзарменый" backlog, хитро "проходить по цепочкам" внутри ядра

потому что, если этот тест запускть внутри "проблемного пода", против localhost, то connection reset by peer отсутствует

может дело в SELINUX?

ну-ну

ммм. не думаю... но если тест фейлится на java backend'e и не валится на nginx backend'е - это хорошая отправная точка

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

При старте контейнера с fluentd вот такая ошибка unexpected error error_class=Errno::EACCES error=#<Errno::EACCES: Permission denied @ rb_sysopen - /var/log/fluentd-containers.log.pos>

Permission denied @ rb_sysope

chown -r rb_sysope:rb_sysope /var/log/

srsly

спасибо коллеги, а то у меня уже глаз замылился

Кто нибудь читал где нибудь, возможно ли чтобы сеть для подов была маршрутизируемой, чтобы поды получали IP в сети которая доступна напрямю, а не через НАТ ?

Кто нибудь читал где нибудь, возможно ли чтобы сеть для подов была маршрутизируемой, чтобы поды получали IP в сети которая доступна напрямю, а не через НАТ ?

сделать под с DHCP

Кто нибудь читал где нибудь, возможно ли чтобы сеть для подов была маршрутизируемой, чтобы поды получали IP в сети которая доступна напрямю, а не через НАТ ?

bgp?

Кто нибудь читал где нибудь, возможно ли чтобы сеть для подов была маршрутизируемой, чтобы поды получали IP в сети которая доступна напрямю, а не через НАТ ?

https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp

calico поддерживает