это же ограничение AWS CNI plugin насколько я знаю? можно его отключить и использовать любой другой плагин, тот же Calico я правда EKS не пользовал, это просто мысли вслух

Спасибо, попробуем на Calico потестировать

это же ограничение AWS CNI plugin насколько я знаю? можно его отключить и использовать любой другой плагин, тот же Calico я правда EKS не пользовал, это просто мысли вслух

fyi https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt

ага вот тут обсуждают это ограничение: https://github.com/aws/amazon-vpc-cni-k8s/issues/176 может видели

о, спасибо, конкретно этот тред не видел)

пишут "не хотите наш плагин — ставьте калико, неблагодарные" :)

и очень политкорректно, кстати)) Other CNI implementation like flannel or calico... Has other good capabilities

*стикер с калико* актуален всегда

*стикер с калико* актуален всегда

В пользу OSPF или RIP? Не уверен, что это хорошие альтернативы. Хотя если нагрузки маленькие, то можно обойтись и OSPF, конечно...

В пользу babel !

а давайте придумаем демон который будет слушать etcd и вписывать роуты на кубер-нодах!

oh wai~

oh wai~

кстати не помню, там только правила форвардинга в iptables так обновлялись или оно умело ip rule править

День

Господа, подскажите, есть один ingress controller, nginx

Нужно server из заголовков выпилить

describe не?

Изменения нужно в configmap nginx-config засунуть

Или как-то можно ему ещё конфигмапы скормить?

Поправь конфигмап, релоад в нигинкс сделай

Еще конфигмапы только с рестартом пода подъедут

Ребят, кто кроме kvaps'a использует pipework у себя в кубе?

Еще конфигмапы только с рестартом пода подъедут

Чо?

Чо?

Новые то

Кто?

Коефигмапы)

Поправь конфигмап, релоад в нигинкс сделай

Не, это понятно. А можно ему кроме стандартного ещё какие-то дать?

Не, это понятно. А можно ему кроме стандартного ещё какие-то дать?

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

можно

нжинксовому точно можно

нжинксовому точно можно

А через какой ключ? По дефолту там containers: - args: - /nginx-ingress-controller - —default-backend-service=$(POD_NAMESPACE)/default-http-backend - —configmap=$(POD_NAMESPACE)/nginx-configuration - —tcp-services-configmap=$(POD_NAMESPACE)/tcp-services - —udp-services-configmap=$(POD_NAMESPACE)/udp-services - —annotations-prefix=nginx.ingress.kubernetes.io - —default-ssl-certificate=ingress-nginx/ingress-default-cert

Почитал в доках, но то ли в шары долблюсь, то ли там этого нет

Там дальше нет конфигмапов и вольюмов?

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

https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/ где-то там должно быть описание

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

Посылать лучи уважения

Господа, подскажите, есть один ingress controller, nginx

"есть один ингресс" - это современная версия https://lurkmore.to/%D0%95%D0%9E%D0%A2 похоже

ubuntu. com/kubernetes кто-нибудь пробовал это?

"есть один ингресс" - это современная версия https://lurkmore.to/%D0%95%D0%9E%D0%A2 похоже

Ага

В пользу OSPF или RIP? Не уверен, что это хорошие альтернативы. Хотя если нагрузки маленькие, то можно обойтись и OSPF, конечно...

is-is

Но вообще сетевики не нужны даже не интересно троллить

ничего, скоро и до них дойдет, взять к примеру тот же cni

is-is

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

Не навязывают? У меня ощущение что мне этот резиновый член в глотку пихают.

Хорошо, когда есть с чем сравнить

is-is

проприаторное говно

запрещённое на территории рф

проприаторное говно

разве он проприетарный?

из калико можно выкинуть BGP в пользу любого протокола маршрутизации поддерживаемого bird

там bird патченный, может не получится.

там bird патченный, может не получится.

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

разве он проприетарный?

изначально активно разрабатывался сиськой, потом был вырыгнут в IETF

изначально активно разрабатывался сиськой, потом был вырыгнут в IETF

ну то есть вполне себе открытый?

ну то есть вполне себе открытый?

да, только реализация от сиськи, как всегда, немножко отличается)

наелись его в свое ремя

У packet.net какие-то хипстерские сетевые диски даже для меня. Кто нибудь пользовался для чего-нибудь большего чем бложик?

https://www.openwall.com/lists/oss-security/2019/02/11/2 runc настолько крутая штука, что позволяет саму себя переписывать :/

Мы юзаем TRILL, а он юзает IS-IS как раз. Просто. Работает. И да, у нас не сиска.

https://www.openwall.com/lists/oss-security/2019/02/11/2 runc настолько крутая штука, что позволяет саму себя переписывать :/

обязательно должна быть шутка про имя репортера

У packet.net какие-то хипстерские сетевые диски даже для меня. Кто нибудь пользовался для чего-нибудь большего чем бложик?

Обычные диски, ничего хипстерского, все как у всех остальных.

Обычные диски, ничего хипстерского, все как у всех остальных.

Сетевые? У всех цеф или сильно свое, у них от друзей

Ну ты же все равно не видишь что внутри, просто локальный блок сторейдж получаешь

https://www.openwall.com/lists/oss-security/2019/02/11/2 runc настолько крутая штука, что позволяет саму себя переписывать :/

SELINUX опять всех спас

Ну ты же все равно не видишь что внутри, просто локальный блок сторейдж получаешь

Это да, но без долгого гоняния непонятно как там со стабильностью, latency и прочим важным делам

Это да, но без долгого гоняния непонятно как там со стабильностью, latency и прочим важным делам

Не учитывая стабильность, все выясняется за 10 - 20 минут теста

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

В целом практика показала что в плане стабильности одного провайдера не стоит рассматривать, все так или иначе лагают и падают на долго

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

В итоге распределение по дц в до не сработало, хорошо был резерв в овх американском

А как наебываются цепх диски в хетзнер и все валяется, это основная причина почему я не перешёл в нем с локальных дисков, да есть шанс легко потерять все данные, но это лучше единично , чем массово у всех диски не доступны

а когда они падали? цеф диски в хецнере, прям что данные терялись?

по большому счету на ноды вообще насрать, если часть сдохнет. просто интересно, они ж там гарантии дают доступности :)

Данные нет, они просто либо недоступны либо тупят супер жестко

а, что тупили супер жестко - бывало, да

по большому счету на ноды вообще насрать, если часть сдохнет. просто интересно, они ж там гарантии дают доступности :)

Ну надо правильно уметь читать, сла 99 процентов говорит о том что из 100 запущенных виртуалок может быть одна всегда не доступна

сла на инстанс

а не на клиента)

а, что тупили супер жестко - бывало, да

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

сла на инстанс

Ну ты просто неправильно читаешь

Сла на всех, а не на инстанс

На инстанс никто давать сла наверно не будет с учётом того что у них диски локальные

подскажите, а что нельзя в кубере сделать ingress->service->deployment, чтоб приложения могли обращаться на вымышленное доменное имя или урлу, исключительно внутри кластера пытаюсь найти инфу по этому поводу, но не то всё, только с наружными ингрессами попадается пробовал сделать как хочу, но доменное имя будто не определяется внутри кластера: ping: bad address 'app.k8s.ml'