KUBERNETES ЗА 13 МИНУТ transcript

Я думаю, всем известно, что Kubernetisс - это оркестратор контейнеров, что его создал Google, что он управляет контейнерами в проде у половины планеты и бла-бла-бла. В этом видео разберёмся, как он работает. И да, на первый взгляд кубе может показаться сложным, но на самом деле всё очень логично. Подпишитесь на канал, чтобы первыми смотреть наши новые видео. А мы начинаем. А начнём мы с архитектуры. Представьте Kuber как компанию с начальством и работягами. Есть Control Plane или же Мастерно. Это менеджмент, который принимает решение. Там сидят апи-сервер, через который все общаются с кубером, скидулер, который решает, на какой ноде запустить под контроллер-менеджер, который следит, чтобы всё работало как надо, и ETCD - это база данных, где хранится вся инфа о кластере. И есть воркерноды. Это работяги, которые крутят ваши контейнеры. На каждой ноде есть кублет - это агент, который общается с контролплейном, куб прокси, который настраивает сеть, и контейнер Runime, который, собственно, и запускает контейнеры. Простыми словами, control говорит, что делать.

Worкеerрноды делают. Переходим к основным сущностям Кубера. По - это самая маленькая штука, базовая единица развёртывания, которую может запустить. И в поде крутится какой-то контейнер с нашим приложением. И ещё стоит сказать, что всё в Кубере описывается через яam манифесты. Это такие файлы с описанием того, что вы хотите создать. И вот простейший манифест для пода. А создать под можно несколькими способами. Самый популярный сейчас вы видите на экране. И ещё можно создать под вот так. Но Apply умнее, так как умеет обновлять конфигурации. Ещё можно создавать коды там через UI, типа Kubernetis Dashboard или Lens. Это для тех, кто любит кликать мышкой. И коды могут создаваться прямо из CICD пайплайна, но это уже другая история. А всё управление происходит через се. Можем посмотреть, что получилось или, например, удалить и много чего ещё. И стоит сказать, что в одном поде может быть несколько контейнеров. Помимо основного контейнера с приложением могут быть и другие чудики, например, инит-контейнеры. Они запускаются перед основным, что-то настраивают и умирают. Например, могут скачать конфиги или проверить, что база данных доступна. И есть сайтка контейнеры, которые работают параллельно основному. Например, собирают логи, проксируют трафик или обновляют рты. Вообще, если быть до конца откровенным, ещё в поде всегда крутится паузконтейнер, который настраивает сеть. Но сами по себе поды штука ненадёжная. упал под, всё, гг. И поэтому реплика сет следит, чтобы нужное количество подовла. Упал один, и реплика set поднимет новый. Вот, собственно, пример. Тут из нового добавляется параметр replicas, то есть сколько подов нужно развернуть. И параметры Selector, и much labels. О них позже, но если просто, то это метки, чтобы другие сущности могли находить эти поды. Реплика set - это низкоуровневая штука. На практике же все используютмен - это главный способ запуска приложений в Кубере. Если под - это один контейнер, а реплика сет много одинаковых подов, то deploлоймент - это полноценное управление жизненным циклом вашего приложения. Он не просто держит нужное количество подов, но он умеет их грамотно обновлять, откатывать и масштабировать. На практике вы почти никогда не создаёте поды или реплика сет напрямую. Обычно всё через деплоймент. Ну а, собственно, я мол деплойменты у вас сейчас на экране. А главная фича деплоймента - это роллинт. Представьте, у вас три кода с версией V1, и вы меняете образ на V2 и выполняете обновление с помощью роллинг-апдейта. Что происходит в этот момент?

Uber создаёт новый по с версией 2, ждёт, пока он запустится, убивает старый под с версией 1 и повторяет, пока не обновятся все нужные поды. Стратегию роллинг-апдейта можно настроить, а именно прописать пару новых параметров, которые вы видите на экране. Но тут есть подвох. Как кубер узнает, что новый под готов принимать трафик? По умолчанию никак. И поэтому нужны пробы. Их всего три:nness проба, дис проба и стартап проба.

Livвнес проба проверяет, жив ли контейнер. Если нет, перезапускает. Redin Proba проверяет, готов ли контейнер принимать трафик. Пока не готов, трафик контейнер не получит. И ещё есть стартап проба. Она проверяет, запустился ли контейнер в принципе. А ещё деплоймент позволяет очень легко откатываться. Можно откатиться на предыдущую версию, можно посмотреть историю с помощью вот этой команды и можно откатиться на конкретную версию, указав параметр to revision. А ещё можно масштабироваться, это тоже изи. Если нужно больше подов, вот, пожалуйста, команда. Если нужно меньше подов, пишем вот так. Теперь, когда мы разобрались с подами и деплойментами, давайте посмотрим, как вся эта темка работает на практике. Вы пишете вот эту команду с тем самым деплойментом, что мы показывали выше. И что происходит под капотом?

CUCTL отправляет ваш Яam в AP, асервер проверяет валидность и сохраняет это всё в ETCD. Потом deployment controller - это часть контроллер-менеджера, видит всё это и создаёт реплика set. Реплика сет контроллер считает, сколько ему нужно кодов и создаёт их. Потом скидулер для каждого подара ноду. Кублит на выбранной ноде получает задание и дёргает контейнер Runтайм. Контейнер Runтайм тянет образ, создаёт и запускает контейнер. После чего кублет репортит: "Всё работает, всё хорошо, всё здорово". А если пот умрёт, реплика сет-контроллер это заметит, потому что было условно три, стало два. И запустит весь процесс заново для нового пода. И это только начало и прямо база-база. В Кубере развёрнуты приложения тысячи тысяч компаний. Когда речь заходит о девопсе, по сути, первое, что приходит в голову знающим людям - это Кубер. Работа - это кубер. А чтобы в нём разобраться, рекомендуем вам наш курс по куберу. Как и раньше, только необходимая теория и упор на практику. Переходите по ссылке в описании и забирайте скидку 15%. Едем дальше. А что, если у нас база данных или какая-нибудь кавка? Тут обычный деплоймент не подойдёт. Нужен state fullset. Есть два понятия. stateless приложения и stateful приложения. И у них есть разница.

Stateless приложение - это когда не имеет значения, какой instance обработает запрос. Вебсервиers, там с PHP, APGO, frontend Jinx, один под умер, запрос обрабатывает другой. Пользователь этого не заметят. А stateful приложения - это когда у каждого инстанца есть состояние и личность. Паastгress, мастер и реплика разная. Нельзя писать в реплику. Кавка, брокеры. У каждого свои партиции, Elastic search ноды. У каждой есть своя часть индекса. И Stateful Set решает эти проблемы. Он даёт стабильные имена. Поды называются условно MySQL0, MySQL 1, MySQL 2. Всегда в одном порядке, не рандомном. У них стабильный сетевой идентификатор. Каждый подлучает ДНС. Также устанавливается порядок запуска и остановки. Сначала запускается под нулевой, потом первый, потом второй, а при удалении всё происходит в обратном порядке. И четвёртое- это персистентное хранилище. То есть каждый подлучает свой persistant volume clime. Об этом мы поговорим чуть позже. А при перезапуске подлучит тот же самый диск. И это критично для баз данных. Мастер должен запуститься первым. Реплики должны знать адрес мастера, а данные не должны перемешиваться. Поды постоянно умирают и воскресают с новыми IP. Сервис - это постоянный адрес для доступа к вашим подом. Проблема в том, что каждый подлучает свой IP внутри кластера, а когда он умер, новый подлучит уже другое IP. И как другим подом общаться с вашим приложением, если адрес постоянно меняется? И вот чтобы такого не было, существует сервис. Он как постоянный ДНС и балансировщик в одном флаконе. Посмотрите вот на этот ямол сервиса. Теперь любой под в кластере может достучаться до вашего приложения по адресу MySвиice восьмидесятый порт или полному ДНСу.

Uber сам будет распределять трафик между всеми живыми подами. И есть разные типы сервисов. Кластер IP, который по умолчанию доступен только внутри кластера и нужен для внутренних сервисов типа база данных, кэш, внутренние апи. Notпор открывает порт на каждой ноде, и теперь можно достучаться снаружи. Но это косты для тестов. На проводе так никто не делает, а пользуются все лоad балансером, который создаёт внешний балансировщик, который работает, например, в облаке. А выглядит это вот так. Но load balanнer для каждого сервиса - это дорого. Например, у нас 10 микросервисов, тогда это 10 лотбалансеров, тогда это 10 внешних айпишников, тогда мы тратим деньги на аренду этих самых айпишников. Но что, если нужен нормальный HTTP-роутинг с доменами и путями? Тогда на помощь приходит Ингреressс. И, собственно, как это делается? Устанавливается контроллер, например, всем знакомый Engins. Этот контроллер следит за ингреressс-ресурсами и настраивает роутинг согласно правилам. Получается один load балансер на весь кластер. Ну, понятное дело, что в кластере у нас используется несколько ингрессов, но сам факт, что мы объединяем нужные нам сервисы под единый ингресс. Хардкодить конфиги в образе - это плохая идея. Один образ должен работать и в Деве, и в проде. Для этого существуют конфигмапы и секреты. Конфигмапы нужны для обычных конфигов. И в поде это будет выглядеть вот так. А секреты нужны для паролей, токенов, короче, каких-то чувствительных данных. А в поде это выглядит в целом так же, как и для конфиг мапы. Проще всего создать секрет из командной строки. Команду вы видите на экране. Вообще секрет в Кубере - это не суперзащита, а просто отделение секретов от конфигов. Пароль там в Base 64, а это вообще не шифрование, а просто кодировка. В реальности секрет защищает от случайного показа паролей в логах, юайке, но не от злоумышленника с доступом к кластеру. Так что любой, кто может сделать купсие secret, увидит ваши пароли. Для нормальной же защиты используются внешние системы типа Hшиorp World или Seal Secrets, который шифрует секреты. Расшифровать их может только сам кластер. Плюс ограничивается доступ через баг, но об этом как-нибудь в другой раз. Контейнеры по своей природе эфемерны. Умер контейнер, умерли и все данные внутри. Для логов или временных файлов это о'кей, но что делать с базой данных или с загруженными пользователями файлами? Тут на сцену выходят волю. Самые базовые волюмы временные. Вот пример на экране. И здесь мы видим MTDIR. По сути, самый простой вольум создаётся вместе с подом, умирает вместе с ним. Это полезно для обмена данными между контейнерами в поде или для временного кэша. Но нам же нужно настоящее постоянное хранилище. Есть два понятия. Это Persistant Volume, реальный диск в кластере. Админ создаёт Persistem Volume и говорит: "Вот, пожалуйста, 100 ГБ на SSDшке". И ещё есть Persistent Volume claim. Это, по сути, запрос. Дайте мне столько-то гигабайт для моей базы. И к волюмам существуют разные режимы доступа.

Readwright ones - это значит, что диск можно примонтировать к одному поду для чтения и записи. Read only many, то есть много подов могут читать, и ready, много подов могут писать. А то, как это выглядит в поде, вы видите на экране. А в целом про волю можно сказать так. Persistant Volume - это реальное физическое место на диске. Persistent Volume Clim - это заявка. Мне нужно место. В таком случае сам найдёт подходящий Persistant Volume и выдаст его вашему поду. Вот и всё. Теперь вы знаете основные сущности кубера: коды, реплика сеты, деплойменты, сервисы, конфигмапы, секреты, PV, PVC, stateфулсеты, ингрессы. Это всё база, без которой в Кубере делать нечего. Но это далеко не всё. Есть баг, политики сети, джабы, хпа и куча-куча всего. Если вы хотите это изучить и устроиться в DevOPS, welcome на наш курс по ссылке в описании. А ещё подписывайтесь на наш Telegram-канал Просто Devops. В нём вы найдёте информацию о реалиях рынка, разборы вопросов и тестовых с реальных сабесов и кучу полезной инфы на основе реальной работы. А если вы ещё тут, порадуйте автора комментариям, нам будет приятно. Всем спасибо за просмотр. Пока-пока.

M.