по сути эта настройка нужна только тем, кто по недоразумению умудрился использовать частные адреса используемые кубером по дефолту для воркер нод... ну что тут сказать ¯_(ツ)_/¯
Во-первых, не только поэтому) Эти сети кастомизируются, так что можно их сдвинуть, даже если ты уже используешь такие сети, что и дефолтные.
Во-вторых, так не случится коллизии, что IP пода и IP сервиса совпадут.
Под понятием "pod network", вероятно, автор имел ввиду сеть, описанную в ClusterConfiguration.networking.podSubnet kubeadm конфига, а "service network" - сеть из ClusterConfiguration.networking.serviceSubnet.
Вы серьезно спрашиваете: "Почему их включение в список это допустимо, а российский сертификат - нет?". Я даже отвечать на этот вопрос не буду.
Альтернативы будут всегда. Хоть переезжай на другой домен, купленный НЕ в России и не российской компанией, и выписывай сертификат на него.
Трудности переезда на новый домен - ничто, по сравнению с рискам намеренной или непреднамеренной компрометации из-за этого славного корневого сертификата.
А зачем вообще кто-то готовится к собеседованию?
Покажу на своем примере:
Вот на скольки собеседованиях я ни был, ни к одному не готовился. Я такой, какой есть без подготовки — и это честно: если я понравился на собеседовании, то непременно и в работе понравлюсь, т.к. я такой и есть. Я не пытаюсь на собеседовании строить из себя того, кем не являюсь и не проявляю знания, коих ещё нет.
И думаю, что с той стороны, со стороны собеседующих, я выгляжу спокойно и честно. Мои реакции на вопросы — искренние, мои ответы на них — живые и не зазубренные.
Ну вот, к примеру, внезапно что-то в ваших p2p или клиент-северных взаимодействиях что-то пойдет не так: порт или указан не тот, что слушается на другой стороне, или же, например, в тестовых стендах фаерволлом закрыт — все? Как дебажить элементарные проблемы, не зная сети хотя бы на минимальном уровне? А уж если речь о p2p — то тут точно возможен миллион проблем по сети.
На счет того, что Вы знаете tcp/ip — это прекрасно, мой бомбеж был адресован не конкретно Вам, а в сторону сферического программиста в вакууме без знания сетей :)
Если Вы не знаете хотя бы на базовом уровне, как работает tcp/ip — грошь цена Вашим знаниям http, grpc, epoll, quic и уж тем более, я бы не стал верить вашим расчетам reqps. Жутко бесят разработчики и тестировщики, и, к сожалению в последнее время некоторые коллеги — админы и девопсы, не имеющие знания по сетям и вбивающие условный localhost/blablabla как dsn для доступа в базу тестового окружения у себя локально в датагриде. А объяснять что такое порт (эфемерный, конечно же) — это дико веселит (нет). А уж банально читать лог билда/деплоя, чтобы понять в чем проблема и уже нужному специалисту задать вопрос — это же не для бояр, надо просто кинуть ссылкой в девопса и написать — "не работает!!!"
Простите за бомбеж, но, к сожалению из-за хайпа вокруг IT мы видим тонну непрофессионалов, и, к сожалению, не только на junior позициях.
Как показывает практика, *далеко не всегда необходимо* разделять cluster_network и public_network, да и даже не всегда для этого есть возможности.
Да, трафик синка osd и доступа к rbd-образам от клиентов летит по одной сети, но, как правило, это не приводит к каким-либо глобальным проблемам.
Стоит отметить, что в данном случае речь не идет об инсталляциях ceph на сотни и тысячи машин, как оно бывает в действительно крупных кластерах чистого ceph. Именно поэтому разделение сетей тут не принесет особого эффекта, но, при этом, значительно усложнит настройку, обслуживание и диагностику.
Как выяснилось, у нас на каком-то из этапов подготовки публикации табы заменились на пробелы, отчего патч выходил нерабочим. В статье уже новый (рабочий) патч. Пользуйтесь на здоровье!
Не знал, что оно так)
Вот например с консоли подключиться к физической машине или к виртуалке при возникновении каких либо проблем со связью, я имел ввиду.
Привет, снежок! Тоже рад тебя видеть)
Во-первых, не только поэтому) Эти сети кастомизируются, так что можно их сдвинуть, даже если ты уже используешь такие сети, что и дефолтные.
Во-вторых, так не случится коллизии, что IP пода и IP сервиса совпадут.
Сеть сервисов - не настоящая. Под капотом iptables правила или ipvs
Короче, если ip сервиса попинговать, а под капотом iptables - ничего не выйдет)
Под понятием "pod network", вероятно, автор имел ввиду сеть, описанную в ClusterConfiguration.networking.podSubnet kubeadm конфига, а "service network" - сеть из ClusterConfiguration.networking.serviceSubnet.
Более того, мы даже можем догадаться, с какого Артема пошла эта практика постоянного нахождения в своем мите😉
Кстати, kubeval R.I.P.
вместо него можно использовать https://github.com/yannh/kubeconform
Вы серьезно спрашиваете: "Почему их включение в список это допустимо, а российский сертификат - нет?". Я даже отвечать на этот вопрос не буду.
Альтернативы будут всегда. Хоть переезжай на другой домен, купленный НЕ в России и не российской компанией, и выписывай сертификат на него.
Трудности переезда на новый домен - ничто, по сравнению с рискам намеренной или непреднамеренной компрометации из-за этого славного корневого сертификата.
Вы что, собираетесь использовать российский сертификат от госУЦ? Вы совсем о безопасности своих пользователей не думаете?
Серег, а как же PR в апстрим? https://github.com/enriclluelles/redis-sentinel-proxy/pulls
И, как обычно это бывает в России, сумма сделки не раскрывается?)
А так, моя поздравлять!
А зачем вообще кто-то готовится к собеседованию?
Покажу на своем примере:
Вот на скольки собеседованиях я ни был, ни к одному не готовился. Я такой, какой есть без подготовки — и это честно: если я понравился на собеседовании, то непременно и в работе понравлюсь, т.к. я такой и есть. Я не пытаюсь на собеседовании строить из себя того, кем не являюсь и не проявляю знания, коих ещё нет.
И думаю, что с той стороны, со стороны собеседующих, я выгляжу спокойно и честно. Мои реакции на вопросы — искренние, мои ответы на них — живые и не зазубренные.
Так зачем вообще кто-то готовится к встрече?
На счет того, что Вы знаете tcp/ip — это прекрасно, мой бомбеж был адресован не конкретно Вам, а в сторону сферического программиста в вакууме без знания сетей :)
Если Вы не знаете хотя бы на базовом уровне, как работает tcp/ip — грошь цена Вашим знаниям http, grpc, epoll, quic и уж тем более, я бы не стал верить вашим расчетам reqps. Жутко бесят разработчики и тестировщики, и, к сожалению в последнее время некоторые коллеги — админы и девопсы, не имеющие знания по сетям и вбивающие условный localhost/blablabla как dsn для доступа в базу тестового окружения у себя локально в датагриде. А объяснять что такое порт (эфемерный, конечно же) — это дико веселит (нет). А уж банально читать лог билда/деплоя, чтобы понять в чем проблема и уже нужному специалисту задать вопрос — это же не для бояр, надо просто кинуть ссылкой в девопса и написать — "не работает!!!"
Простите за бомбеж, но, к сожалению из-за хайпа вокруг IT мы видим тонну непрофессионалов, и, к сожалению, не только на junior позициях.
Добавление сделает вывод раздела
более удобочитаемым.
</зануда_мод_он>
А так, спасибо за статью, полезные штуки :)
Да, трафик синка osd и доступа к rbd-образам от клиентов летит по одной сети, но, как правило, это не приводит к каким-либо глобальным проблемам.
Стоит отметить, что в данном случае речь не идет об инсталляциях ceph на сотни и тысячи машин, как оно бывает в действительно крупных кластерах чистого ceph. Именно поэтому разделение сетей тут не принесет особого эффекта, но, при этом, значительно усложнит настройку, обслуживание и диагностику.
Не знал, что оно так)
Вот например с консоли подключиться к физической машине или к виртуалке при возникновении каких либо проблем со связью, я имел ввиду.