Что произойдёт, если удалить один из трёх Pod? Kubernetes создаст замену. Во второй части «Kubernetes просто лабы» проверим это на практике.

Продолжим работу в учебном кластере: опишем Deployment в YAML, запустим три реплики nginx и разберёмся, как связаны Deployment, ReplicaSet и Pod. Затем удалим один Pod, понаблюдаем за появлением нового, изменим количество реплик и научимся выбирать Pod по меткам.

За 20–30 минут увидим, как Kubernetes приводит фактическое состояние приложения к желаемому. Всё пошагово: команды, пояснения и пиксельные иллюстрации.

В этой части разберём, зачем Kubernetes понадобился Gateway API, если уже существует Ingress. На простом примере посмотрим, как Gateway и HTTPRoute разделяют точку входа и маршрутизацию, зачем нужен GatewayClass и почему такая модель удобна, когда кластер и приложения обслуживают разные команды.

Практика к первой части серии «Kubernetes просто». Поднимем локальный кластер с помощью kind, найдём компоненты Control Plane и запустим первый Pod. Разберём команды и их вывод, а затем закрепим материал самостоятельными заданиями.

Разбираемся, зачем Kubernetes нужен Ingress. Чем он отличается от Service и Ingress Controller, как маршрутизировать HTTP-трафик по по доменам и путям к разным приложениям внутри кластера.

Разбираемся, как предоставить доступ к приложению снаружи Kubernetes-кластера. На простых схемах рассмотрим ClusterIP, NodePort и LoadBalancer, разберём разницу между port, targetPort и nodePort и проследим путь запроса от клиента до Pod

Pod'ы в Kubernetes появляются, исчезают и меняют IP. Разбираемся, как Service даёт приложению стабильную точку доступа, как работает ClusterIP, DNS, selectors, EndpointSlice и readiness - и как запрос в итоге попадает на конкретный Pod.

От YAML-манифеста до работающих контейнеров: разбираемся, что Kubernetes делает после kubectl apply.

Kubernetes без магии и заучивания команд. Разберёмся, зачем он вообще нужен, как устроен кластер, чем Control Plane отличается от Worker Nodes и какую роль играют Pod, Scheduler, kubelet, etcd и другие основные компоненты.

В этой статье цикла мы решим главную проблему сервиса DeadDrop: пользователь создаёт секрет, но не может его забрать.

Здесь мы:

1) Научим net/http понимать динамические маршруты без фреймворков
2) Научимся подписывать куки через HMAC и узнаем, как оно работает изнутри
3) Настроим безопасное скачивание файлов

Никаких готовых решений - лишь стандартная библиотека, которая никуда не пропадёт и не развалится за месяц!

Сегодня сервис DeadDrop станет полноценным веб-приложением - покрываем все функции, заявленные в первой статье

Продолжаем писать сервис DeadDrop: сегодня идём от монолита к чистой архитектуре

В предыдущей части мы реализовали готовый прототип, но его код был спорным: от смешанной логики до хранения секретов пользователей в открытом виде - пора вносить правки!

Сегодня мы:

1) Превращаем "толстый" хэндлер в хорошее архитектурное решение с разделением слоёв

2) Хэшируем с bcrypt

3) Внедряем зависимости (DI) через интерфейсы

4) Готовим код к дальнейшему масштабированию

Рефакторинг, который не ломает проект, а делает его удобным для дальнейшей разработки!

Предыдущая статья

Продолжаем создавать сервис анонимных «мертвых ящиков» DeadDrop на чистом Go.

Во второй части (первый подвыпуск) закладываем фундамент: учимся принимать POST-запросы, загружать файлы с проверкой MIME-типа и размера, создаём in-memory хранилище с потокобезопасным доступом через RWMutex. Пишем утилиты для генерации криптостойких ID и паролей. Разбираемся с интерфейсами и готовим архитектуру к дальнейшему развитию.

Без фреймворков, только net/http и стандартная библиотека.

Первая часть цикла «Разбираем net/http на практике»: создаём с нуля сервис DeadDrop — аналог Privnote для безопасной передачи самоуничтожающихся сообщений и файлов.

На чистой стандартной библиотеке net/http разбираем основы:

• запуск HTTP-сервера

• маршрутизация в ServeMux

• написание middleware (логирование и recovery от panic)

• работа с HTML-шаблонами и layout’ами

• подключение статики через http.FileServer и embed.FS

В итоге получаем работающий сервер с красивой главной страницей, формой создания «ячейки» и базовой архитектурой проекта — всё без внешних зависимостей.

Идеально для начинающих и тех, кто хочет глубоко понять внутренности популярных фреймворков вроде Gin и Echo. Пишем код вместе!