15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
В PostgreSQL есть два способа репликации: физическая и логическая.
Обе крутые, но с разными компромиссами.
Физическая репликация передаёт на реплики весь WAL, создавая побайтовую копию основного узла. Это значит, что нагрузка на CPU у мастера минимальная, но при этом она работает только между одинаковыми версиями PostgreSQL (и даже некоторые версии расширений и glibc должны совпадать). Кросс-архитектурной репликации тоже нет.
Такой подход отлично подходит для схем "primary–replica" с высокой доступностью, но не годится для апгрейдов или миграции на другие платформы.
Логическая репликация работает на уровне строк. Она не делает поблочное зеркало данных, поэтому способна работать между всеми основными версиями PostgreSQL 10+, где она появилась.
Она гибче, но не волшебная таблетка для миграций. Логическая репликация не передаёт DDL и последовательности, так что часть работы придётся делать вручную. При больших объёмах данных (например, 1 ТБ и больше) она может быть медленной и просаживать производительность, поэтому процесс нужно тщательно планировать.
Что выбрать? Как обычно = зависит от ситуации. Иногда логичнее комбинировать их с инструментами вроде pg_dump.
👉 @BackendPortal
Узнайте все о протоколе HTTP : https://http.dev/
👉 @BackendPortal
Ты думаешь, что тебе это не нужно ‼️
🟣 Ты же не разработчик, твоя зона — это бизнес и пользователи.
Но правда в том, что технические скиллы дают продакту другой уровень силы:
⚫️быстрее проверять гипотезы
⚫️собирать прототипы без ожидания команды
⚫️понимать ограничения и возможности технологий
⚫️разговаривать с разработчиками на одном языке.
В итоге меньше зависимости, больше скорости и уверенности в продукте.
В канале Продукт и рост Яны Доценко мы разбираем инструменты, которые реально работают:
➡️от AI-билдеров до no-code и сетапов, с которыми можно запускать фичи и продукты самому.
Подписывайся, тут ты станешь настоящим фуллстек-боссом:
/channel/+J-Wtd0vQTXYxNjMy
Supabase теперь поддерживает очереди!
Помимо базы, аутентификации, хранилища и edge-функций, в Supabase появилась поддержка очередей, работающих на базе расширения pgmq.
Есть даже удобный интерфейс для их управления.
А если добавить cron и edge functions, получится мощная и масштабируемая система воркфлоу прямо внутри Supabase.
👉 @BackendPortal
TRUNCATE — это DDL.
У каждой таблицы и всех её индексов есть указатели на файлы на диске.
TRUNCATE просто сбрасывает эти указатели, создавая "пустые" файлы.
Чтобы операция была атомарной, TRUNCATE берёт эксклюзивную блокировку таблицы, блокируя все чтения и записи на время переназначения файлов.
Сами файлы потом удаляются отдельно — не обязательно синхронно.
DELETE FROM позволяет выполнять параллельные операции, но работает гораздо медленнее, и все изменения при этом логируются в WAL.
Оба подхода полезны — важно понимать, как они работают, чтобы грамотно проектировать приложение и не ловить тормоза.
Один из классных приёмов → разбивать таблицы по годам и просто truncate'ить нужный партишн, чтобы мгновенно удалить данные за целый год.
👉 @BackendPortal
Твой Kubernetes-DNS работает медленно, потому что поды обращаются к DNS-серверу, который находится на другом конце кластера.
Каждый запрос к имени хоста превращается в сетевой раунд-трип: приложение на ноде 1 пытается разрешить имя сервиса — и делает DNS-запрос к CoreDNS, запущенному на ноде 5.
Ответу приходится проходить весь путь обратно по сети.
NodeLocal DNSCache решает эту проблему, размещая DNS-кеш на каждой ноде.
Теперь поды обращаются за DNS-разрешением к localhost, не гоняя трафик по сети. Кешированные запросы возвращаются мгновенно.
Если записи в кеше нет — запрос всё ещё уходит в CoreDNS, но в продакшне большинство DNS-шаблонов повторяются, так что кеш срабатывает часто.
Настройка максимально простая: разворачивается DaemonSet, который запускает локальный DNS-кеш на каждой ноде. Поды продолжают использовать те же DNS-настройки, просто ответы приходят быстрее.
Разница в производительности особенно заметна в кластерах с высоким количеством DNS-запросов или при перегрузке DNS-серверов. В некоторых случаях задержка DNS падает со сотен миллисекунд до единичных.
Развернуть можно одной командой kubectl. Локальный кеш автоматически синхронизируется с основным DNS-сервисом.
Чем больше кластер, тем важнее это становится. В маленьких кластерах узкое место DNS может быть незаметно, но при масштабировании оно превращается в серьёзный фактор, влияющий на производительность.
Приложения, которые часто обращаются к сервис-дискавери, получают заметное снижение латентности.
Это один из тех апгрейдов, которые ничего не стоят, но могут значительно ускорить отклик приложений.
👉 @BackendPortal
Ваши Docker-контейнеры медленные, раздутые и уязвимые. И скорее всего, вы повторяете те же ошибки, что делают 90% инженеров в продакшне.
Вот мои советы:
Не используйте теги latest, вместо этого указывайте конкретные версии, например node:18.17-alpine.
Не собирайте толстые одностадийные образы, используйте многостадийную сборку, чтобы получать 50 МБ вместо 800 МБ.
Не запускайте контейнеры от root, создайте пользователя без прав root для безопасности.
Не копируйте всё с COPY . ., используйте .dockerignore и точные команды COPY.
Не позволяйте контейнерам использовать неограниченные ресурсы, задавайте лимиты памяти и CPU.
Не деплойте без проверок здоровья, добавляйте команды HEALTHCHECK, чтобы Kubernetes знал, что приложение работает.
Не создавайте 20 отдельных слоёв с RUN, объединяйте команды через &&, чтобы уменьшить количество слоёв.
Не пропускайте сканирование на уязвимости, используйте docker scan или Trivy в CI/CD.
Не берите полные образы ОС для простых приложений, используйте scratch или distroless как базу.
Не пишите логи в файлы внутри контейнера, логируйте в stdout/stderr и пусть оркестратор собирает их.
Библиотеки Java, которые должен знать каждый backend-разработчик
Lombok → уменьшает количество шаблонного кода в Java-классах
Guava → расширенные коллекции и утилиты
Jackson → мощная сериализация/десериализация JSON
Apache Commons → вспомогательные методы для стандартных Java-классов
JUnit 5 → современная платформа для модульного тестирования
Mockito → гибкое создание моков для тестов
SLF4J → абстракция для логирования
MapStruct → безопасное преобразование между Java-бинами
Logback → надёжная реализация логирования
OkHttp → эффективный HTTP-клиент для REST-запросов
👉 @BackendPortal
Опа, тут бывший сеньор одного из IT-отделов Яндекса Игорь Никитин выкатил целый канал про Python — и это лучшее, что есть в рунете по теме.
Качественные гайды. Советы от известных прогеров. Тематические мемасы. Короче, ничего лишнего.
Хватит душить питона, учись его кодить: /channel/+MHz6ewg03OVkZjcy 🐍
Твой кеш не сломан из-за LRU —> он сломан, потому что ты забыл про TTL.
LRU сам по себе не решает проблему, потому что горячие ключи никогда не устаревают, и в кеше может бесконечно храниться вчерашняя, давно неактуальная информация. Если память не заполняется полностью, ничего не вытесняется, и «мертвые» ключи продолжают занимать место. В итоге кеш может содержать некорректные данные, а это даже хуже, чем промах.
TTL тоже не панацея. Когда срок жизни данных истекает, все клиенты одновременно обращаются к источнику — начинается классический эффект «thundering herd». Если TTL выставлен слишком большим, в памяти остаются «холодные» ключи, которыми никто не пользуется, а если слишком коротким — данные постоянно сбрасываются, снижая эффективность кеша.
LRU и TTL решают разные задачи. Механизм вытеснения вроде LRU или LFU включается, когда память заполнена, и помогает оптимизировать использование пространства. TTL, наоборот, активируется, когда данные устаревают, обеспечивая их корректность.
Хороший кеш работает как холодильник: LRU выбрасывает продукты, когда они занимают всё место, а TTL следит за сроком годности, чтобы ты не выпил прокисшее молоко. Вместе они дают и свежие данные, и свободную память.
👉 @BackendPortal
SQLBolt - изучайте SQL с помощью простых интерактивных упражнений.
https://sqlbolt.com/
👉 @BackendPortal
Недавно Дима Александров (руководитель подразделения разработки в Яндекс Еде) писал про минимизацию ущерба при инцидентах в бэкенде. И очень зацепила мысль: «сначала откатывай, потом думай».
У меня не раз было так: сервис падает, а команда вместо отката лезет в логи, спорит, что сломалось, кто виноват. А время идёт, пользователи страдают. В итоге понимаешь, что самым быстрым решением был бы простой откат. Даже если нет уверенности, что откат поможет, лучше сразу его запустить и разбираться уже параллельно. В 95% случаев хуже не станет — виноват обычно крайний релиз.
Из опыта ещё очень больно, когда сам откат сделать легко, но сервис поднимается вечность. Один раз мы откатили релиз за минуту, а пользователи ждали ещё час, пока система стартанёт, потому что набирал полный кеш из БД. С тех пор я стараюсь обращать внимание не только на код, но и на то, как сервис «просыпается».
Ну и режим деградации, это вообще мастхэв. Лучше пусть сервис работает хоть как-то, чем лежит полностью. Даже «обрезанная» выдача или fallback-заглушка в критический момент спасает больше, чем кажется.
Поэтому такие мысли, как у Димы, я особенно ценю. Это вроде бы простые вещи: откат, быстрый рестарт, режим деградации. Но именно из таких «мелочей» складывается уверенность инженера и умение держать систему живой даже тогда, когда всё идёт не по плану.
📘 На Stepik вышел курс — «Golang - микросервисная архитектура, проектирование API»
Уже знакомы с Go и хотите перейти на следующий уровень? Этот курс — именно то, что нужно, чтобы прокачать свои навыки.
• Полный путь от сетевых протоколов до Kubernetes: HTTP/REST, gRPC, RabbitMQ и Kafka, PostgreSQL, Redis, Docker, Prometheus + Grafana
• Практика на реальных кейсах: проектируем API, пишем микросервисы, покрываем тестами, выкатываем CI/CD
• 180+ интерактивных заданий с автопроверкой — код прямо в браузере, в любое удобное время
• Итоговый pet-project: к финалу курса у вас будет рабочая мини-экосистема из нескольких сервисов
🎓 Сертификат по завершении — добавьте его в резюме или профиль LinkedIn
🚀 Прокачайте Golang с пользой и удовольствием. Начните уже сегодня и получите скидку 25%, которая действительна в течение 48 часов
👉 Пройти курс на Stepik
Как Netflix синхронизирует данные между 200 млн устройств
Чтобы пользователи могли без задержек продолжать просмотр на любом устройстве, Netflix обрабатывает свыше 150 000 событий в секунду.
Для этого используется отдельный микросервис, который собирает события, отправляет их в Amazon SQS, распределяет по приоритетам и через AWS-кластеры рассылает уведомления.
Данные хранятся в Cassandra, что позволяет сочетать push и pull обновления — онлайн-устройства получают события мгновенно, а офлайн-устройства при следующем подключении.
👉 @BackendPortal
Нагрузка на сервер такая высокая, что даже по SSH не подключиться?
Используй эту команду:
ssh -o ConnectTimeout=1 -o ConnectionAttempts=1 user@host "nice -n -20 bash"
⭐️ Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем
Инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми ежедневно пользуются больше 95 миллионов человек ежемесячно.
В этом видеопроекте разработчики на практических примерах рассказывают, как создают архитектуру систем, которые держат 1 000 000 RPS и хранят петабайты мета-данных.
В выпусках обсуждаем:
🎙 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения
🎙 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым
🎙 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит модель на примере Яндекс Календаря и как ребята применяют её для эффективной коммуникации с различными командами разработки
🎙Серия 4. Практика: Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной
🎙 Серия 5. Практика. Взаимодействие со смежными системами. Типичные сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать
Создаётся крупнейшая база реальных DevOps-проектов и ресурсов для тех, кто хочет перейти от теории к практике. 🥺
В ней собраны живые примеры AWS-проектов с Terraform и GitHub Actions, Docker-конфиги, мультиоблачные решения на GCP и Azure, а также полноценные деплои на Kubernetes.
Это то, чего многим не хватало в начале пути — практики, которую можно запустить, изучить и доработать под себя. База уже наполняется рабочими проектами, которые помогают понять, как DevOps устроен в реальном мире.
Кто хочет внести вклад: https://github.com/akhileshmishrabiz
👉 @BackendPortal
PostgreSQL использует ленивое «swizzling» указателей (lazy pointer swizzling), чтобы ускорить доступ к буферу и держать данные на диске и в памяти синхронизированными без лишних преобразований. Вот как это работает.
Когда PostgreSQL хранит структуры данных, например страницы B-tree индекса, на диске нельзя использовать обычные указатели из оперативки → адреса на диске и в памяти вообще из разных миров. Но как только данные попадают в память, хочется быстро ходить по структуре через указатели, а не через медленные косвенные ссылки.
На диске PostgreSQL хранит ссылки в виде номеров блоков и смещений. Когда страница читается в общий буферный пул, эти логические ссылки остаются как есть → и вот тут начинается интересное.
Буферные страницы
→ Каждая страница в памяти идентифицируется с помощью структуры BufferTag (в ней указаны база, таблица и номер блока).
→ В памяти PostgreSQL держит массив дескрипторов буферов.
→ Когда нужно получить доступ к странице, код идет через менеджер буферов, который по номеру блока находит реальное местоположение страницы в памяти.
→ Это и есть ленивое swizzling — преобразование адреса выполняется не заранее, а при каждом обращении.
Пример структуры BufferTag из исходников PostgreSQL:
typedef struct
{
Oid spcOid; /* tablespace */
Oid dbOid; /* database */
Oid relNumber; /* relation (table or index) */
ForkNumber forkNum;/* main, fsm, vm, init forks */
BlockNumber blockNum; /* block number within the relation */
} BufferTag;
Многим формат инструкций WASM напоминает LISP. И тут собственно ничего удивительного: под LISP и лиспоподобные языки очень удобно писать разные парсеры. Не случайно Брендон Айк - создатель JavaScript, изначально хотел создать язык для браузера на основе Лиспа, но его начальство настаивало на языке, похожем на Java (так как в то время Java была на хайпе) . Поэтому мы и получили то, что получили.
👉 @BackendPortal
Проблемы с блокировкой строк? Попробуй slotted counters
Это прикольный приём, который помогает распределить инкременты по нескольким строкам и тем самым снизить конфликт за ресурсы.
Представь сайт вроде YouTube, где нужно считать просмотры у каждого видео. Удобно хранить счётчик прямо в таблице video, но у популярных видео десятки тысяч запросов одновременно пытаются увеличить одно и то же поле.
Результат: конкуренция → блокировки → тормоза.
Решение — распределить счётчик по N строкам в отдельной таблице.
В примере N = 3, но можно сделать 100 или 1000 — зависит от нагрузки.
Каждое обновление выбирает одну из N строк случайным образом и увеличивает значение именно там.
Когда нужен общий счётчик для конкретного v_id, просто суммируем все строки с этим идентификатором. Это можно делать на лету или периодически и складывать результат обратно в основную таблицу video.
👉 @BackendPortal
Большинство сбоев происходят не из-за плохого кода.
Они происходят из-за предположений, которые никто не удосужился проверить.
Системы ломаются не потому, что люди невнимательны.
Они ломаются, потому что что-то «очевидное» так и не было озвучено.
Самые опасные вещи — это тихие моменты:
«Этот API никогда не вернёт пустой payload.»
«Кэш всегда будет warm»
«Этот cron никогда не выполнится дважды одновременно.»
«Очередь сообщений никогда не потеряет сообщение.»
«Место на диске никогда не закончится во время процесса.»
Невысказанные предположения превращаются в единые точки отказа.
🚀 Ты — разработчик, но не до конца понимаешь, как твой код оказывается в проде?
Пора разобраться с новым курсом по GitLab CI на Stepik!
От теории и концепций до рабочих пайплайнов со сборкой, тестами, линтингом, временными отчетами и деплоем нейросети DeepSeek!
📝 50+ уроков, реальные примеры, минимум теории.
👨💻 60+ учащихся уже записаны на курс.
🎁 Для подписчиков канала — промокод CICD15 (скидка 15%).
👉 Открыть курс на Stepik
malloc — не единственный способ выделения памяти.
Фактическое выделение и освобождение памяти происходит с помощью системных вызовов brk, sbrk и mmap, а malloc — это удобная оболочка над ними.
Стандартная реализация malloc на большинстве Linux-систем — это ptmalloc2 из glibc. Она подходит для общих задач, но имеет фундаментальные ограничения, которые становятся узкими местами в production-системах, особенно при:
- конкуренции за блокировки (lock contention)
- фрагментации памяти
- плохой локальности кэша
Некоторые популярные и широко используемые реализации malloc — это jemalloc и tcmalloc.
Используйте jemalloc, если у вас:
- долгоживущие процессы, где фрагментация накапливается (базы данных, кэши, игровые серверы)
- требуется стабильная производительность при разных паттернах выделения памяти
- важна не только скорость, но и эффективность использования памяти
- нужно подробное исследование и статистика работы памяти
Используйте tcmalloc, если у вас:
- много потоков с высокой активностью выделения памяти
- в основном маленькие и краткоживущие объекты
- приоритет — максимальная пропускная способность
- вы готовы пожертвовать немного большим потреблением памяти ради скорости
Популярные пакеты, такие как Redis и Varnish, перешли на jemalloc для повышения производительности, а Cloudflare использует tcmalloc, что привело к снижению потребления памяти в 2.5 раза.
Эти реализации открыты, и я потратил некоторое время на изучение их кода на GitHub и переписывал некоторые фрагменты.
Надеюсь, это будет полезно.
👉 @BackendPortal
Интересный факт про vector search: проверка меньшего объёма данных делает поиск быстрее и точнее.
Алгоритм HNSW это основа одних из самых быстрых векторных поисков. Если вы использовали Weaviate или другие векторные базы, вы уже сталкивались с HNSW, это стандартный тип индекса, и не случайно.
HNSW можно представить как многоуровневую транспортную систему для векторов: сверху —> редкие длинные связи для глобальной навигации, средний уровень —> средние связи для регионального поиска, низкий уровень —> плотные связи для всех векторов для точного результата. Поиск начинается сверху, постепенно уточняется на каждом слое и в конце достигает максимальной точности на нижнем уровне. Алгоритм «перепрыгивает» через множество неактуальных данных вместо проверки каждого вектора, что делает его быстрее brute-force методов.
Основные параметры, которые можно настраивать:
• maxConnections —> плотность графа; большее значение повышает точность, но замедляет поиск и требует больше памяти
• ef, efConstruction —> динамический размер списков для поиска и построения графа, влияющий на баланс между скоростью и точностью
HNSW это баланс между скоростью, точностью и расходом памяти; улучшение одного всегда требует компромисса с другими.
Подробнее о настройке HNSW и оптимизации: Weaviate docs
👉 @BackendPortal
Программисты из Telegram создали сильнейшие IT- каналы
🐍 Ghostly Python - автоматизируй всё, что можешь. Боты, скрипты, парсеры, утилиты - делаем Python простым и полезным. Уверенный старт для новичков и не только.
☕️ Easy Java - Java без боли. От основ до фреймворков. Просто, понятно и по делу. Если хочешь реально понять язык - тебе сюда.
😎 IT Syndicate - главный хаб для тех, кто живёт IT. GameDev, InfoSec, Frontend, DevOps, AI и многое другое. Готовь мозг, тут будет жарко.
🧡 Ghostly Frontend - фронтенд без лишнего шума. HTML, CSS, JavaScript, React, Vue — всё, что нужно, чтобы создавать быстрые и красивые интерфейсы.
Сети для самых маленьких
Это серия статей о сетях, их настройке и администрировании. Здесь собраны основные аспекты, которые необходимо знать и понимать. В этой серии рассматривается планирование сети, настройка маршрутизаторов, работа с коммутацией и маршрутизацией, протоколы и технологии: STP, NAT, VPN, BGP, MPLS и многое другое.
https://linkmeup.gitbook.io/sdsm
👉 @BackendPortal
Никогда не вызывай API внутри транзакции.
В реляционных базах данных — это плохая практика. Транзакции должны быть как можно более короткими.
Долгие транзакции приводят к росту конкуренции за ресурсы. Если каждая транзакция захватывает блокировки строк, то чем дольше она живёт, тем выше вероятность ожидания блокировок и задержек выполнения.
Плюс MVCC. В Postgres используется мультиверсионность (MVCC), и долго живущие транзакции мешают старым версиям строк становиться кандидатами для autovacuum. В MySQL это решается через undo log. Когда активных долгих транзакций становится много, журнал приходится держать дольше — это увеличивает его размер и снижает производительность.
Если ты используешь пул подключений, например PgBouncer в режиме transaction pooling, долгие транзакции легко могут привести к исчерпанию пула и сбоям на стороне клиентов.
База данных — самое критичное звено твоего стека. Минимизируй конкуренцию за её ресурсы.
👉 @BackendPortal
Ты на собеседовании на backend-разработчика.
Тебе задают вопрос:
«Как защитить API от replay-атак?»
Вот как стоит разложить ответ по пунктам:
1. Метки времени + окно актуальности
Каждый запрос содержит временную метку (timestamp).
Сервер отклоняет запросы, которые выходят за пределы короткого окна допустимой давности.
2. Nonce (уникальные идентификаторы)
К каждому запросу прикрепляется одноразовое случайное значение — nonce.
Сервер хранит уже использованные nonce и отклоняет повторные.
3. Подписи HMAC
Клиент подписывает запрос секретным ключом.
Сервер проверяет подпись и одновременно удостоверяется в "свежести" запроса (по timestamp и nonce).
4. TLS повсюду
Всегда использовать HTTPS, чтобы предотвратить перехват токенов или подписей.
5. Короткоживущие токены
Применять JWT или session tokens с малым временем жизни — это сокращает окно риска, если токен всё-таки утёк.
6. Idempotency key для критичных операций
Для операций вроде платежей или переводов использовать уникальные идентификаторы запросов.
Даже если replay произойдёт, сервер просто проигнорирует повтор.
КУРС "Python Backend собеседование | 101 вопрос + 101 тест"
Получите структурированные ответы на самые частые вопросы с технических интервью
ЧТО ВНУТРИ КУРСА ПРЯМО СЕЙЧАС:
📚 101 РАЗОБРАННЫЙ ВОПРОС
• Полные объяснения с примерами кода
• Ответы на вопросы всех ключевых тем:
• Python (GIL, функции , структуры данных)
• FastAPI
• Базы данных и SQL
• Асинхронное программирование
• Docker и контейнеризация
• Архитектура API
• Кеширование и Redis
•101 тестовое задание
🛠 ПРАКТИЧЕСКИЕ МАТЕРИАЛЫ:
• Тестовые задание к каждому вопросу
• Готовые шаблоны кода для проектов
• Примеры из реальных коммерческих проектов
🎓 ФОРМАТ ОБУЧЕНИЯ:
• Пожизненный доступ к материалам
• Постепенное усложнение - от Junior до Middle
• Структура "вопрос → ответ → практика"
Ссылка на курс: https://stepik.org/253465
Быстрая шпаргалка по kubectl
# 1) Просмотр ресурсов (быстрая отладка событий и полей)
kubectl describe pod my-pod -n apps
# 2) Просмотр логов Pod’а (используй -c для конкретного контейнера/sidecar)
kubectl logs my-pod -n apps -c sidecar
# 3) Применение YAML-манифестов (золотое правило идемпотентности)
kubectl apply -f resource.yaml
# 4) Перезапуск Deployment для обновления ConfigMap/Secret
kubectl rollout restart deployment api-server -n apps
# 5) Масштабирование Deployment (снизи до 0 перед изменениями или тестами)
kubectl scale deployment my-app --replicas=0
# 6) Публикация Deployment через NodePort (быстрый внешний доступ)
kubectl expose deployment web-app \
--name=web-svc --port=80 --target-port=80 --type=NodePort
# 7) Запуск временного debug Pod’а (интерактивная shell-сессия, автоочистка)
kubectl run tmp-shell --image=busybox --rm -it -- sh
# 8) Подключение внутрь Pod’а (проверка сетевых политик, доступности, тулов)
kubectl exec -n test-ns pod-a -it -- sh
# 9) Точечное обновление Deployment с помощью JSON Patch
kubectl patch deployment logger -n workloads \
-p '{"spec":{"template":{"spec":{"priorityClassName":"critical"}}}}'
# 10) Генерация ConfigMap YAML (не писать вручную — сгенерировать и подправить)
kubectl create configmap web-config --from-file=config.conf \
--dry-run=client -o yaml > cm.yaml
# 11) Генерация Deployment YAML (удобно для экзаменов и тестов)
kubectl create deployment web-app --image=nginx \
--replicas=2 --dry-run=client -o yaml > web-app.yaml
# Bonus: аналогично можно сгенерировать шаблон Pod’а
kubectl run test-pod --image=busybox --dry-run=client -o yaml > pod.yaml
# 12) Быстрое объяснение полей CRD (когда нет документации под рукой)
kubectl explain certificate.spec.subject