СЕТЬ В KUBERNETES transcript

Всем привет. Вы на канале Просто [музыка] DevOps. И сегодня мы продолжаем тему сетей, но поговорим про сеть в Кубере. Как вы могли догадаться из названия ролика, сеть в Kubernetis - это тема важная, но одновременно сложная за счёт хитрой организации этой самой сети. Вот с обычными сетями всё более-менее понятно. Есть айпишники, порты, какая-то маршрутизация. А в Кубере всё по-другому. с какими-то своими айпишниками, сервисы с виртуальными адресами CNI, плагины и оверлеи. Вот обо всём этом мы сегодня и поговорим. Если вы смотрели наше видео про сети, это продолжение ложится ровно поверх. А если нет, посмотрите сначала его. Подсказка в правом углу, там самая база. Ну а если вы не подписаны на канал, обязательно подписывайтесь, ставьте лайк, переходите в нашу телегу, а мы начинаем. Сначала давайте коротко пробежимся по самому куберу, о котором, кстати, тоже были ролики. Поэтому сегодня без глубоких подробностей чисто основа, которая нам нужна для сегодняшней темы и без которой не понять, откуда берутся сетевые сложности. Вот представьте, у нас есть несколько десятков сервисов, каждый из которых запущен в нескольких копиях, и всё это крутится на куче серверов. Следить за этим всем самостоятельно невозможно. И Kubernetis берёт на себя оркестрацию. Он запускает контейнеры, сидит, чтобы их было нужное количество, перезапускает упавшие и раскидывает всё это дело по серверам. В Кубере есть базовая единица. Это под. В поде, как правило, один, но иногда несколько контейнеров, которые работают вместе и делят сетевое пространство пода. Сами поды запускаются на нодах, то есть серверах, из которых состоит кластер. И тут начинается сетевая проблема, которой в обычной инфре нет. Поды сами по себе эфемерные, они постоянно то создаются, то удаляются. Если под падает, кубер поднимает новый, и у этого нового пода новый IP-адрес. Если мы делом обновление, то старые коды заменяются новыми и получают новые другие IP-адреса. Также коды могут переезжать между нодами, а ещё их количество может меняться в зависимости от нагрузки. Давайте вернёмся к обычной инфре. Там у сервера фиксированный IP-адрес, и вы просто ссылаетесь на него. А в Кубере IP пода штука временная, а при этом поды должны как-то находить друг друга и общаться. Вот это и есть главная сетевая задача Кубернетиса. Обеспечить связь между эфемерными сущностями, которые постоянно меняются, так ещё и прыгают между серверами. Чтобы понять, откуда берутся сетевые сложности, нужно посмотреть настроение кластера и его сердце, а также мозг - это control plane. Там живёт асервер, через который идёт всё управление, планировщик, который решает, на какую ноду поставить под, база с состоянием кластера ATCD и различные контроллеры. Также в кубере есть воркерноды. Это те самые рабочие серверы, на которых запускаются наши с вами поды. И на каждой воркерноде работают специальные компоненты. Это кублет, агент, который общается с [музыка] контролплейном и запускает коды. Контейнер Runime, обычно контейнер D, который реально запускает контейнеры, и купси, который отвечает за сервисы. И к нему мы ещё вернёмся. А теперь смотрите, какие сетевые проблемы вырастают из этой архитектуры. Проблема первая: ноды должны общаться между собой и с котролплейном. Это обычная серверная сеть. Здесь ничего особенного нет. Проблема вторая. Поды на одной ноде должны видеть на другой ноде, а удовдреса, которые обычная сеть между серверами не знает.

[музыка] Под на первой ноде имеет адрес, как вы сейчас видите на экране. под на второй. Вот этот. Сеть между нодами знает только адреса самих нот. Вот они тоже на экране. И как в таком случае пакету от первого подасть ко второму, непонятно. И третья проблема. Подырождаются с новыми IP-адресами, поэтому нам нужна стабильная точка входа, виртуальный адрес, который не меняется даже когда поды за ним перетасовываются. [музыка] И как раз-таки из этих проблем складываются три сети кубера: сеть нот, сеть подов сервисов. Кубернетис задаёт правила для этих сетей. Каждый подлучает уникальный IP. Все поды общаются напрямую без над. Поды на одной ноде общаются без внешней маршрутизации. Но главный прикол в том, что сам кубер сеть не строит, [музыка] он просто задаёт требования, а реализация ложится на CNI плагин.

[музыка] Что это и как работает? Разберём после того, как пройдём по каждой сети отдельно. Самый простой уровень - это сеть между нодами. Тут всё как в обычной инфре. Но подключены к обычной сети: физические [музыка] коммутаторы в каком-нибудь дата-центре или виртуальная сеть в облаке. У каждой ноды есть свой айпишник. И если они находятся внутри одной подсети, то им достаточно уровня L2 для того, чтобы общаться. Если в разных подсетях, то на помощь приходит обычная или тримаршрутизация. И эта сеть настраивается до Кубернетиса и существует независимо от него. По ней ноды видят друг друга. Кублет может встучаться в IP-сервер, а Control Plane рассылать команды. Обычная серверная связанность. И вот тут мы подбираемся к самому главному. Сеть notт ничего не знает проды. Для неё весь мир - это ноды с их адресами. Пот со своим айпишником для сети нот просто не [музыка] существует. Маршрутизатор между нодами не знает, куда слать пакет на адрес какого-то пода. И это создаёт главную проблему сети Кубера. Как доставить пакет от одного пода, если они находятся на разных нодах, а сеть между нодами про эти поды вообще не в курсе? И мы подходим, по сути, к главному вопросу всего видео. Как под на одной ноде общается с подом на другой? И пойдём мы от простого к сложному. Сначала разберём, что происходит внутри одной ноды, а уже потом, что происходит между подами. Когда на ноде запускается под, [музыка] для него создаётся виртуальный сетевой интерфейс. Витая пара. Проще всего это представить как обычный кабель. Один конец внутри пода. Под думает, что у него своя сетевая карта, а другой на ноде, воткнутый в виртуальный мост. И все поды, которые находятся на ноде, подключены к этому мосту, который, по сути, является коммутатором только программным, а не физическим. И когда под А хочет поговорить с подом B, пакет идёт через этот бридж, не выходя за пределы ноды. Это самая обыкновенная L2 коммутация, просто виртуальная. И каждой ноде выделяется своя подсеть для подов. Первая нода раздаёт адреса из такого диапазона. Вторая- из такого, третья из следующего и так далее. И, кстати говоря, поэтому по первым байтам адреса пода можно понять, на какой ноде он находится. А теперь более сложный момент. Поды находятся на разных нодах, и это уже начинает быть проблематично. Вот смотрите, под А отправляет пакет на такой-то адрес. Пакет доходит до бриджа на первой ноде и оттуда попадает на нулевой интерфейс. А вот дальше тупик, потому что сеть между нодами знает адреса нот, а про адрес пода она не знает. И в этот момент, по сути, можно просто поймать ошибку, что Destination Unreachable и пакет умрёт. Но при этом нам же нужно как-то перенаправить этот пакет через сеть нот до нужной ноды, а уже там доставить нужному поду. И для этого существует на самом деле две реализации. Первое - это овер, то есть пакет в пакете. Идея достаточно простая. Мы заворачиваем пакет пода внутрь пакета ноды. Снаружи получаем адрес ноды, которые сеть знает, а внутри адрес пода, который сама сеть не знает, но [музыка] ей это и не требуется. И в такой реализации происходит следующее. Под шлёт пакет на нужный ему адрес. Ада перехватывает это и заворачивает в новый пакет. И дальше по сети notт летит уже этот пакет с нормальным адресом. Он без каких-либо проблем доставляется. А дальше нужная нода его распаковывает, достаёт внутренний пакет и доставляет нужному поду. И эта реализация называется VXLAN. И именно так работает фланель. Но есть и вторая реализация, которая не делает переупаковку, а реализует маршрутизацию. И здесь принцип такой, что вместо того, чтобы прятать адреса подовнутри, мы должны научить сеть нот, их маршрутизировать. И для этого на каждой ноде прописываются маршруты. условно говоря, если адрес получателя находится в таком-то диапазоне подсетей, слать его на такую ноду, если в другом диапазоне на вторую, в другом на третью и так далее. И в таком случае, когда пот отправляет пакет на нужный ему адрес, Нода смотрит в таблицу маршрутизации, понимает, на какую ноду надо это перенаправить, и отправляет пакет. Вторая нода получает, видит адрес кода и доставляет. И пакет летит как есть, без упаковки. Это быстрее, но сеть NТ должна уметь маршрутизировать эти адреса. И для автоматического распространения маршрутов используется BGP. Итак, [музыка] работает Калика. А теперь перейдём к одному ещё очень важному моменту, про который, кстати, часто спрашивают на собеседованиях. Почему не используется над вспомним тот же докер. В обычном докере контейнер находится за натом. Он выходит наружу под IP, а его адрес скрыт. Но вот в Кубере так нельзя, потому что если подлучит запрос, но вместо адреса пода отправителя увидит просто адрес ноды, то очень многие вещи просто не будут работать. Возьмём ту же сетевую политику. Допустим, она хочет разрешать трафик от подов фронтенда, но будет видеть только адрес [музыка] ноды, а не конкретного пода, который на ней находится. И как в таком случае она сможет отличить фронтендерский под от, допустим, бэкндерского? Никак. И поэтому в Кубере отсутствие НАТО - это, по сути, фундаментальное правило. Поды должны общаться напрямую по реальным адресам и без подмены. А теперь мы переходим к очень важной части, а именно CNI.

CNI расшифровывается как контейнер Network интерфейс, то есть стандарт, по которому Kuber общается с сетевым плагином. При этом сам Kuber, как мы выяснили, сеть не строит и просто задаёт правила, которые должны быть. У каждого подашник, и все общаются без над. И вот реализация этого целиком лежит на CNI плагине. И чтобы было понятнее, рассмотрим это на примере на жизненном цикле пода. Вот наш пользователь DevOPS, кто угодно хочет запустить под, прописывает нужную команду, а дальше происходит следующее.

IP сервер принимает, а планировщик выбирает ноду, после чего кублет на ноде получает задание. И для выполнения этого задания вызывает CNI Plugin, чтобы он настроил сеть для этого пода. И CNI плагин выполняет всю свою работу, создаёт витую пару, подключает один конец к поду, а другой к бриджу ноды, выдаёт поду IP из нужного диапазона, прописывает маршруты и настраивает правила фаервола. После чего кублет запускает контейнер, пот работает, и у него есть сеть. Пот дальше живёт, обрабатывает запросы и так далее. А если пот удаляется, то Кубле тоже вызывает синайпла плагин, который должен за собой убраться. Соответственно, он удаляет втую пару, возвращает IP в пул и чистит маршруты и правила. Поэтому CNI - это просто интерфейс, можно сказать, контракт. Он должен уметь делать две вещи: настроить сеть для нового пода и удалить сеть для удалённого пода. А как именно он это делает? Это уже его собственная забота. Может делать через оверлей, может делать через маршрутизацию, да хоть голубями. Реализации на самом деле очень много. Каликов ланель, про который мы сказали. А ещё есть, например, Sлиum VI или облачные решения для менеджed куберов. Каждый из них строит сеть по-своему. Но есть два главных ключевых момента. Первый - это то, что без CNI плагина кластер просто не работает. То есть, если вы поставили кубер, но не поставили CNI, коды будут висеть в пендинге или контейнеркйтинге. просто потому, что им некому выдать сеть. А второй момент - это то, что менять CI на живом кластере очень больно. И, в принципе, на практике никто так не делает, потому что для этого нужно будет пересоздавать абсолютно все поды, перенастраивать [музыка] все маршруты, и всё равно сохраняется риск потерять связанность. Поэтому выбор синая - это одно из первых решений при создании кластера, и его делать стоит очень осознанно, с насколько это возможно, глубокой первичной аналитикой. И вот мы разобрали то, как поды общаются друг с другом по IP. Но тут есть одна практическая проблема. Допустим, у нас Кэнд состоит из трёх подов, а фронтEN должен слать им запросы. И на какой IP в таком случае слать? Мы с вами помним, что поды эфимерны, то есть они рождаются, отключаются и IP у них меняются. Сегодня эээнд на одном адресе, завтра на другом, послезавтра на третьем. Поэтому фнтendнд не может держать список IP-подов и обновлять его каждую секунду. Ему нужна стабильная точка входа. И для этого есть сервис. Это специальный объект Кубернетиса, который получает фиксированный виртуальный IP, который не меняется, пока сервис существует. Мы сейчас говорим про кластер IP, и Front шлёт запрос на этот кластер IP, а Kuber дальше уже сам разберётся, какому конкретно поду его доставить. Если у вас сразу не получилось представить, как это работает, то не переживайте, потому что сейчас мы рассмотрим весь процесс. Вот вы создаёте сервис, и Кубе выдаёт ему адрес, допустим, вот такой. За этим адресом стоят три бэкэнда. Фронend направляет запрос на вот этот адрес, и купкси на ноде перехватывает этот пакет и подменяет адрес назначения на IP одного из реальных кодов. То есть, по сути, это денат, да, виртуальный адрес сервиса подменяется на реальный адрес пода. А если под упадёт или будет удалён, то купкси просто обновит свои правила, а фронт об этом не узнает, потому что он это изначально не знает, и это никак не отразится на общем аптайме и доступности. Ну и давайте быстро пробежимся по типам сервисов, которые можно встретить. Первый, мы его уже упомянули, - это кластер IP, то есть виртуальный адрес, доступный только внутри кластера. Это самый дефолтный тип. и сервисы общаются между собой через него. Следующий тип - это notтпорт. Он открывает порт на каждой ноде кластера. То есть запрос на любую ноду на этот порт попадает в нужный пот. Это самый грубый способ пустить внешний трафик внутрь. Следующий тип сервиса - это Load Balanнсер. Он создаёт внешний балансировщик, и запрос из интернета приходит на балансировщик, а оттуда попадает к подам. Это самый классический и, в принципе, стандартный способ выступить сервис наружу в облаке. Ещё естьс, но это уже не тип сервиса, а отдельный контроллер, который маршрутизирует HTTP трафик по доменам и путям. Но это отдельная тема, о ней чуть позже. Короче говоря, сервисы решают проблему, которая не решается на уровне CNI, то есть дают стабильный адрес группе постоянно меняющихся подов. Поэтому CNI обеспечивает связанность, а сервисы обнаружения и балансировку. А теперь рассмотрим два самых популярных Cная, которые используют разные подходы. И начнём из фланеля. Он работает достаточно просто. По умолчанию использует overlay через VXL, о чём мы говорили ранее. И повторимся, под на первой ноде шлёт пакет поду на второй. Фланел для этого заворачивает пакет в UDP, отправляет на нужную ноду, там разворачивает и доставляет уже к поду. Теперь более предметно. Вот у нас есть три ноды. Мы поставили flunel. И что в этот момент произошло? Фланел на каждой ноде поднял свой интерфейс. Это Vixland туннель. Каждой ноди он выделил подсеть. Нода первая получила такую-то сеть, вторая такую-то, третья такую-то. Информация о том, какая подсеть на каждой ноде, хранится у фланела в его ETCD. И когда под, допустим, с первой ноды пошлёт пакет на вот такой адрес, flunл просто посмотрит, что эта подсеть относится к ноде, допустим, третьей, которая имеет следующий адрес, после чего завернёт пакет VXL и отправит куда надо, а на третьей ноде уже развернёт и доставит поду. Всё понятно, и никаких настроек сети не нужно. Работать это будет где угодно. Это не требует от сети знания проды, не нужен BGP, не нужна поддержка инфраструктуры. Но есть и обратная сторона. Накладные расходы на упаковку и распаковку каждого пакета - это, во-первых, процессор, а во-вторых, небольшая потеря производительности. Плюс из-за заголовка Vixlan [музыка] уменьшается полезный размер пакета, и это даже может приводить к проблемам. Есть такая вещь, как МТУ. Это максимальный размер полезного блока данных одного пакета. И вот он в случае с фланелом снижается примерно на 50 байт. И если приложение это не знает, то могут быть странные проблемы с большими пакетами. Но главный минус даже не в этом, а в том, что funelл не умеет в сетевые политики. А это значит, что все поды видят всех. Ограничить это средствами flanel нельзя. И какой-нибудь фронт может ходить напрямую в базу, минуя эээнд. Любой под может сканировать всю сеть кластера. И поэтому для обучения и простых задач фланлов вполне достаточно и будет хватать. Но вот для продакшена, где есть требования к безопасности, он не годится. А в продакшене самый популярный CNA - это Кака. У него другой подход- маршрутизация, а не оверка пакеты не заворачивает, он использует BGP, с помощью которого раздаёт по кластеру информации, какая подсеть подов живёт на какой ноде. И по сути каждая нода становится таким маленьким маршрутизатором, и пакеты летят напрямую без какой-либо упаковки. В результате получаем производительность, потому что нет накладных расходов Оверлея, пакеты летят как обычный трафик, нет проблем с МТУ и нет двойной обработки пакетов. Второй плюс, ради которого Калика часто и выбирают - это Network полиcy. Вот конкретный пример. У вас в Фластере три группы подовн, бэкэнд и база. Без сетевых политик все они будут видеть друг друга, и фронт сможет ходить напрямую в базу, как мы упомянули ранее. А это большая дыра в безопасности. А скалика можно описать правила: фронт может общаться только с бэкэндом, бэкэнд с базой и фронтэндом, а база, соответственно, только с бэкэндом. И если фронт попробует достучаться до базы напрямую, пакет просто будет дропнут. По сути, это фаервол на уровне подов, что для продакшена является обязательной вещью. Но у Калика есть и минус.

BGP маршрутизация работает не во всех средах. Чтобы маршруты подовых подсетей дошли до всех нот, нужно, чтобы сеть между нодами их пропускала. А в некоторых облаках, например, провайдер фильтрует незнакомые маршруты и чистый BGP не взлетает. Но в этом случае Калика переключается в режим оверлея IP или уже знакомый нам VXL. По сути, начинает работать как флаг, то есть заворачивать пакеты, теряет часть производительности, но при этом сохраняет сетевые политики. Поэтому даже если в нашей среде роутинг будет не работать, калика всё равно имеет большой смысл, как раз-таки ради политик безопасности сети. А ещё есть третий вариант, самый сложный, но за эту сложность дающий наибольшие возможности и гибкость. Это Silлиum. Строится он на EBPF. Это возможность запускать программы прямо в ядре Линукса. Он обрабатывает трафик на уровне ядра, что даёт и скорость, и глубокую видимость трафика. Это самый современный из массовых синаев, и крупные компании сейчас постепенно переходят на него. И да, он сложнее, он требует свежих ядер и команды, которые готова в это вникнуть, но при этом даёт наибольшую гибкость и возможности. И тут мы с вами подходим к логическому вопросу. Какой CNI лучше выбрать под конкретную ситуацию? Если вы сейчас изучаете Uber, хотите поднять тестовый кластер и просто в него потыкаться, посмотреть, поломать, починить, что-то написать и развернуть, то, конечно, самый логичный выбор - это фланель. Там минимум настроек, он будет работать везде и не нужно будет вникать в BGP. Если мы говорим про какой-то продакшн, где нужны network полиcy, где нужна нормальная производительность, то, конечно, классическим выбором был, есть и остаётся калика. по сути дефолт для серьёзных пластеров с огромным коммьюнити, объёмной документацией. И поэтому такой выбор будет логичным в любом более-менее нормальном проекте. Если же продакшн высоконагруженный и нужна какая-то максимальная производительность, то, конечно, стоит смотреть в сторону силиума. Но здесь, как мы и говорили ранее, очень важна экспертиза. Если мы говорим про managed, да, управляемый в облаке, то обычно облако навязывает свой собственный CNI, заточенный под их сеть. И тут выбор сделан за вас. Ну а если сложно сделать конкретный выбор, то лучше всего остановиться на Калика. Это безопасный дефолт, который покрывает большинство потребностей. И сейчас мы затронем последнюю тему, которую часто путают с CN. Это сервис MH.

CNI решает базовую задачу связать поды, чтобы пакет от пода А дошёл до по Б. И это и есть вся работа сияная. Но если микросервисов слишком много и они постоянно общаются, то возникают, конечно, вопросы, на которые CNI не отвечает. Условно говоря, как зашифровать трафик между сервисами или как автоматически повторить запрос при сбоя? Или как увидеть, какой сервис с каким общается и где тормозит? или как пустить 5% трафика на новую версию для каноречного деплоя. Вот для этого есть сервис МШ и самые известные представители жанра - это ISO и Linker D. Сервис МШ работает следующим образом. Рядом с каждым подом запускается проксиконтейнер, так называемый сайтка, и весь трафик пода. При этом приложение об этом не знает. Оно шлёт обычный HTTP запрос, а Proxy перехватывает его [музыка] и добавляет шифрование. тайм-ауты, сбор метрик и многое другое. Опять же рассмотрим на примере. Сервис заказы шлёт запрос сервису оплата. И, допустим, в нашем кластере сервисмш нету, тогда может произойти следующее: запрос ушёл, а сервис оплата в этот момент перезапускается, и тогда запрос упадёт, произойдёт ошибка, и пользователь увидит, что что-то пошло не так, и ему придётся нажимать кнопки заново. А если сервис МШ есть, то запрос уйдёт. Прокси увидит, что оплата не ответила, подождёт 100 мсекунд, пошлёт повторно уже на другой под оплаты, и пользователь ничего не заметят. Ретрай произойдёт автоматически на уровне прокси, [музыка] а приложение об этом не знает и в коде ничего менять не придётся. И есть ещё одна вещь, которую даёт сервис МШ - это МТЛС, [музыка] то есть когда трафик между подами шифруется автоматически без настройки на стороне приложения, без Мэш. Трафик между подами внутри кластера обычно ходит открытым текстом, и если кто-то вдруг получит доступ к одной ноде, он увидит весь трафик. А если сервис MH есть, то каждый сайфрует исходящий трафик и расшифровывает входящий. Приложение по-прежнему шлёт обычный HTTP, а прокси заворачивает его в ТЛS. Но сервис МШ - это слой поверх сети, а не замена синаю.

Cий даёт связанность, а сервис МШ добавляет контроля. Но нужен сервисм Mмш далеко не всегда. Если кластер маленький, то это только лишняя сложность и лишние ресурсы. Сервис МШ имеет смысл только при десятках, а то и сотнях микросервисов, когда без автоматических ретрав, шифрования и видимости трафика уже просто невозможно нормально работать. А теперь давайте подведём итоги. Так как поды эфимерны, главная сетевая задача - это связать их между собой, невзирая на то, что адреса меняются, а поды могут перемещаться между нодами. В Кубере есть три сети: сеть нот, обычная сеть подов своём [музыка] адресном пространстве. Следующий вывод: Ber не строит сеть сам, а только задаёт правила. Задача построения остаётся заенай плагином. Сами плагины бывают разными, со своими плюсами и минусами. А сервис МШ - это дополнение, которое даёт дополнительные возможности. Если было полезно и интересно, то обязательно [музыка] ставьте лайк, подписывайтесь на канал и заходите в наш Telegram, в котором мы делимся кейсами с реальной работой, новостями, в котором вы сможете найти Roadmap для Devopпса и первыми узнавать о новых продуктах и анонсах. Всем спасибо за просмотр. Всем пока-пока.