Как развернуть сайт в Kubernetes: от контейнера до домена с HTTPS
6 ноября 2026 г.
Развернуть сайт в Kubernetes можно за вечер, потому что каждый шаг закрыт готовой инструкцией, даже если это первое знакомство с кластером. Понадобятся кластер Kubernetes, образ контейнера с сайтом и четыре манифеста: Deployment, Service, Ingress и ClusterIssuer для сертификата HTTPS. На управляемом кластере VK Cloud (сервис Managed Containers, где мастер-узлы обслуживает облако) создание кластера и установка аддонов Docker Registry, Ingress NGINX и cert-manager сводятся к нажатию кнопок в личном кабинете, руками остаются манифесты и команды kubectl, а в конце появляется домен с защищённым соединением, который можно показывать посетителям.
Образ упаковывает приложение со всеми зависимостями и служит шаблоном. Контейнер это запущенный из образа экземпляр приложения, изолированный от соседей. Кластер Kubernetes объединяет группу серверов, узлов, на которых контейнеры работают под общим управлением. Мастер-узлы управляют кластером, worker-узлы запускают контейнеры. Манифест это текстовое описание объекта кластера в файле YAML. Deployment следит, чтобы работало нужное число копий сайта, каждая копия живёт в поде, единице запуска из одного или нескольких контейнеров. Service выдаёт копиям общий внутренний адрес. Ingress описывает правила, по которым запросы из интернета доходят до сайта. Сертификат для HTTPS выпускает cert-manager по настройкам из объекта ClusterIssuer. cert-manager это программа для выпуска и продления сертификатов в кластере.
Зачем сайту Kubernetes, если есть shared hosting, виртуальный хостинг, где сайт делит один сервер, процессор и память с чужими сайтами. Я называю три причины: сайт переживает недоступность сервера без ночного подъёма администратора, обновляется без остановки, а при наплыве посетителей получает дополнительные копии. Для сайта-визитки, который обновляется раз в год и не ждёт наплыва посетителей, виртуального хостинга достаточно. Kubernetes берут, когда простои и ручные перезапуски начали стоить денег.
Шесть шагов до работающего сайта
1. Создайте кластер.
В VK Cloud он собирается в личном кабинете: выбираете версию Kubernetes, тип кластера и число мастер-узлов, сеть, группу из двух worker-узлов и нажимаете «Создать». Файл kubeconfig с реквизитами доступа скачивается из личного кабинета через меню кластера, пункт «Получить Kubeconfig для доступа к кластеру». Пошаговый порядок со скриншотами лежит в инструкции создание кластера в личном кабинете.
2. Подключитесь к кластеру.
Установите kubectl, консольную утилиту для команд кластеру, вместе с плагином аутентификации client-keystone-auth, укажите путь к kubeconfig в переменной KUBECONFIG и проверьте связь командой kubectl cluster-info. Команды для Linux, Windows и macOS собраны в инструкции подключение через kubectl.
3. Положите образ сайта в реестр, хранилище образов, откуда кластер их скачивает.
Реестр в кластер по умолчанию не входит, сначала установите аддон Docker Registry из вкладки «Аддоны». Аддон это дополнительный компонент кластера, который ставится из личного кабинета. Бакет это именованное хранилище файлов в объектном хранилище, облачном хранилище по протоколу S3. Этому аддону нужны бакет, пара ключей доступа к нему, логин с паролем для входа в реестр и внешний IP-адрес. Порядок расписан в инструкции установка Docker Registry. Затем соберите образ: для статики подойдёт веб-сервер с файлами внутри, для приложения свой код. Добавьте адрес реестра в настройки Docker на своей машине, войдите в реестр командой docker login и отправьте образ туда. Чтобы кластер мог забирать образы, создайте секрет командой kubectl create secret docker-registry и укажите его в поле imagePullSecrets манифеста. Секрет это объект Kubernetes для паролей и ключей. Примеры манифестов под каждый тип объекта есть в инструкции подключение к реестру Docker.
4. Опишите Deployment и Service.
Deployment поддерживает нужное число копий пода и пересоздаёт их после сбоя, а образ из реестра на узел скачивает среда выполнения контейнеров по команде агента kubelet. Service выдаёт копиям общий внутренний адрес. Оба объекта входят в базовый набор Kubernetes, их формат разобран в официальной документации Deployment.
5. Откройте сайт в интернет.
Установите аддон Ingress NGINX. Он поднимет Ingress-контроллер, программу, которая исполняет правила Ingress, а также создаст облачный балансировщик нагрузки, точку входа трафика с внешним IP-адресом. На этот адрес направьте A-запись вашего домена у регистратора. Как ставить аддон и где смотреть выданный IP, расписано в инструкции установка Ingress NGINX.
6. Включите HTTPS.
Аддон cert-manager ставится из той же вкладки «Аддоны» (установка cert-manager), но сам по себе публичный сертификат не выпускает. Дальше три действия по документации cert-manager: описать объект Issuer или ClusterIssuer с удостоверяющим центром, например Let’s Encrypt. Issuer действует в своём пространстве имён, ClusterIssuer на весь кластер. Пространство имён это именованный раздел кластера для группы объектов. В манифесте Ingress добавить аннотацию cert-manager.io/cluster-issuer с именем этого объекта и секцию tls с именем домена в hosts и именем секрета. Аннотация это служебная пометка в метаданных объекта, для Issuer она называется cert-manager.io/issuer. Дождаться проверки владения доменом. При проверке HTTP-01 удостоверяющий центр запрашивает файл по вашему домену, поэтому A-запись из шага 5 к этому моменту уже должна указывать на балансировщик. После выпуска сертификат лежит в секрете, Ingress на него ссылается, а продление cert-manager делает сам до истечения срока (продление сертификатов).
На схеме ниже путь запроса к сайту: браузер посетителя, DNS с A-записью домена, балансировщик с внешним IP, Ingress-контроллер, Service, копии сайта в подах. Реестр образов стоит сбоку, из него кластер забирает образ при запуске.
Пять ошибок первого развёртывания
-
Забытый imagePullSecrets. Кластер не может скачать образ из закрытого реестра, под висит в ожидании образа. Лечится секретом из шага 3 и ссылкой на него в манифесте, примеры для каждого типа объекта собраны в той же инструкции по реестру.
-
A-запись не туда. Домен направляют на адрес узла, а у балансировщика свой внешний IP. Правильный адрес смотрится у сервиса ingress-nginx-controller в поле EXTERNAL-IP, где его искать, показано в инструкции по Ingress NGINX.
-
Сертификат застрял в ожидании. cert-manager установлен, а HTTPS не появляется. Первым делом проверьте, что объект Issuer или ClusterIssuer создан и что A-запись уже указывает на балансировщик, иначе удостоверяющий центр не находит домен. Затем смотрите состояние запроса командой kubectl describe certificate, причину застревания ищите дальше командой kubectl describe challenge. Challenge это объект с записью о проверке владения доменом.
-
Один worker-узел на всё. Любое обновление узла останавливает сайт целиком. Два узла из первого шага и минимум две копии сайта, разнесённые по узлам правилом podAntiAffinity, снимают проблему, нагрузка на время работ переезжает на соседа.
-
Пароли внутри образа. Образ уходит в реестр, и всё зашитое в него уходит вместе с ним. Реквизиты передаются через секреты Kubernetes и переменные окружения, а образ собирается чистым.
Частые вопросы
1. Можно ли обойтись без Ingress?
Можно, Service типа LoadBalancer тоже выдаст внешний адрес. Ingress удобнее, когда сайтов или путей больше одного, потому что один балансировщик обслуживает все.
2. Сколько копий сайта ставить?
Минимум две, на разных узлах. Обновление идёт поочерёдной заменой копий. Сайт остаётся доступным, пока одна копия перезапускается, при условии, что в манифесте задана проверка готовности readinessProbe, иначе трафик попадёт на копию, которая ещё стартует.
3. Что с базой данных для сайта?
Управляемая база в сервисе Cloud Databases снимает с вас настройку постоянных томов, резервных копий и обновлений, сайт ходит в неё по внутренней сети. Базам в Kubernetes посвящена отдельная статья цикла.
4. Сколько ресурсов закладывать?
Для визитки или блога хватит одной группы из двух worker-узлов младшей конфигурации из списка в личном кабинете. Дальше группа масштабируется без пересоздания кластера.
Короче говоря для заметки:
- Путь такой: кластер, образ в реестре, Deployment плюс Service, Ingress, cert-manager с объектом ClusterIssuer.
- Внешний IP выдаёт балансировщик аддона Ingress NGINX, домен направляем на него A-записью до запроса сертификата.
- Копий сайта минимум две, на разных узлах и с проверкой готовности, тогда обновления и сбои проходят незаметно для посетителей.
- Каждый шаг закрыт инструкцией в документации VK Cloud, писать команды с нуля почти не придётся.
Оставьте заявку, чтобы получить консультацию
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
Узнавайте о выходе новых статей в блоге первыми!
Будем держать в курсе новостей и облачных трендов
Почитать по теме
10 сентября
Как работает git reset: разница между soft, mixed и hard
10 сентября
Git rebase vs merge: в чём разница и когда что использовать
6 ноября
