Завтра проверю

Спасибо

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

https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

а зачем этот модуль, не лучше и проще ли чтобы SSL терминейтился на самом ингрессе?

а зачем этот модуль, не лучше и проще ли чтобы SSL терминейтился на самом ингрессе?

nginx умеет терминейтить только http

зачем этим должен заниматься сам микросервис?

хмм а этот модуль для TCP SSL и раскидывания по хосту (в тсп пакете) на разные апстримы?

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

что-то я ничего не понимаю если честно

хмм а этот модуль для TCP SSL и раскидывания по хосту (в тсп пакете) на разные апстримы?

да

ага, погуглил - оказывается они tcp ssl termination только в плюс версии сделали https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/

неужели это какая-то супер энтерпрайз фича (особенно учитывая что https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html модуль не в плюс версии)

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

Народ, а кто как из ci в ingress добавляет рулы? Можете накидать примеров?

Эээ, я хелм в пайплайне дергаю и все

В чем суть-то проблемы

берешь и создаёшь новый ингресс

нельзя просто так взять и создать новый ингресс

Я пока с ним не очень разобрался

ну да, тупо новый создавать проще

это не столько тупо, сколько правильно )

А что на счет пост контейнеров?

по аналогии с initContainers, только после того как они поднялись?

есть такой функционал?

или тут актуально что-то вроде? lifecycle: postStart:

решил тут с containerd поиграться, кто-нибудь заводил?

я

в чем вопрос

или тут актуально что-то вроде? lifecycle: postStart:

preStop: только по-моему

у меня он вроде images скачивает через crictl а куб по прежнему не может с ним взамиодействовать: Warning ContainerGCFailed 55m kubelet, m7c45 rpc error: code = Unavailable desc = grpc: the connection is unavailable

в логах containerd чет ниче интересного не нашел

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

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

critctl run не работает, говорит No help topic for 'run'

а ты его как деволтный CRI поставил кубелету?

схема такая:

ага, сам куб видит его как containerd://1.1.0

в конфиге демона кубелета ты указываешь CRI в конфиге демона CRI ты указываешь рантайм

но почему-то в NotReady

а на каком этапе затык

инит кластера?

классный гайд, ставил по нему: https://medium.com/@ramaswin121994/kubernetes-installation-with-containerd-721fe0c40b6e

сча покажу как я делал

а на каком этапе затык

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

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

нода добавилась, куб ее видит, корректно определяет container runtime, но запустить ничего не может

ты должен взять голую ноду

хм, а в чем разница?

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

https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md

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

просто kata-runtime не ставь а делай с дефолтным и в целом тебе самое оно по инструкции

вот такое я не пробовал

я знаю что кубер может

с разными CRI на разных дистрибутивах работать в одном кластере

то бишь убунта с докером за мастер и федора с containerd за ноду

обычно я строил кластера только в рамках одного Runtime

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

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

у тебя равномерно не выйдет

ну вот, тогда в чем проблема то? * опции для kubelet есть: KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"* containerd запущен * crictl pull ubuntu на ноде работает * kubectl get node <name> видит ноду и видит что она с containerd://1.1.0

а при kubeadm join ты можешь указывать свой CRI

попробуй кату повертеть, заодно разберешься со своей траблой я думаю

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

видна ничего не имзенилось)) либо люди не экспериментируют либо не рассматривают варианты лучше докера))

а при kubeadm join ты можешь указывать свой CRI

а вот за это спасибо, указал --cri-socket /var/run/containerd/containerd.sock и оно взлетело!

инит кластера?

я так и думал:)

а вот за это спасибо, указал --cri-socket /var/run/containerd/containerd.sock и оно взлетело!

не подскажешь, а в пределах какого кейса ты решил использовать containerd?

ну что бы docker выкинуть, в первую очередь :)

не подскажешь, а в пределах какого кейса ты решил использовать containerd?

Криктл подсы показывает нормально

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

А в целом просто ищу более легкую альтернативу docker, которая нативно работала бы с кубом. И не требовала бы конкретной версии docker, не ломало бы сеть и все такое

а CRIO никто не вертел?

правда сейчас и на докере с --iptables=false --ip-masq=false живется весьма неплохо

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

Недавно на хабре было про containerd 1.1

да я читал это

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

в моем случае я все ищу не серебрянную, а золотую пулю

это аналог докера с изоляцией по ядру