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

Народ, а кто как из 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

да я читал это

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

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

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

тогда вообще пушка

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

Тоже интересует

Тоже интересует

сейчас попробую в две ноды кластер с ней построить

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

надеюсь это оно

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

кто CRIO или kata-containers?

крч такая история

сижу я читаю новости хоба релиз катаконтейнеров я такой думаю НУ ДИРЖИСЬ я нашел что искал оказалось что ката это просто рантайм разработанный Openstack+Intel, который в поды добавляет гостевое ядро, без возможности взаимодействия с ним и крч вся идея "сломалася" фигня

сижу я читаю новости хоба релиз катаконтейнеров я такой думаю НУ ДИРЖИСЬ я нашел что искал оказалось что ката это просто рантайм разработанный Openstack+Intel, который в поды добавляет гостевое ядро, без возможности взаимодействия с ним и крч вся идея "сломалася" фигня

даа, они еще полгода назад делали прессрелиз что будет убер-фича

ну неделю убил зато с containerd и кастомными рантаймами ознакомился)

неделю сидел с интеловскими разрабами в слаке)))

https://superuser.openstack.org/articles/project-update-whats-next-for-kata-containers/

сижу я читаю новости хоба релиз катаконтейнеров я такой думаю НУ ДИРЖИСЬ я нашел что искал оказалось что ката это просто рантайм разработанный Openstack+Intel, который в поды добавляет гостевое ядро, без возможности взаимодействия с ним и крч вся идея "сломалася" фигня

расскажи что значит "без возможности взаимодействия с ним" ?

https://superuser.openstack.org/articles/project-update-whats-next-for-kata-containers/

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

тоже эта тема интересна

расскажи что значит "без возможности взаимодействия с ним" ?

крч это типа еще одного уровня изоляции, но на уровне пода а не контейнера

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

вот лучше это почетайте http://www.vitanuova.com/inferno/papers/bltj.html

крч это типа еще одного уровня изоляции, но на уровне пода а не контейнера

ну а ты чего искал то? Хотешь стопку контейнеров и каждый со своим ядром запускать?

ну а ты чего искал то? Хотешь стопку контейнеров и каждый со своим ядром запускать?

типа да мне нужна нормальная изоляция, но не городить из контейнера целую вм, нужен легкий сплав докера и вм

и шобы кубером ими вертеть

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

аа, теперь понял, то есть krita-container не оперирует контейнерами как таковыми, она просто тупо в виртуалку все засовывает

аа, теперь понял, то есть krita-container не оперирует контейнерами как таковыми, она просто тупо в виртуалку все засовывает

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

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

ну как вариант можно собирать виртуалку в chroot через Dockerfile, и запускать ее с помощью qemu-kvm в контейнере :)

хахахаах