Failover без Kubernetes: когда k8s — перебор

Честный вопрос: что вы переживёте и так

99.9% доступности — это 43 минуты простоя в месяц. Такой уровень достижим одним сервером с правильными перезапусками и быстрым восстановлением из кода. Kubernetes нужен, когда сервисов десятки, деплоев — десятки в день, а команда готова кормить сам кластер. Для 2–5 сервисов на одном VPS k8s добавляет больше отказов, чем убирает.

Уровень 1: контейнеры чинят себя сами

Большинство инцидентов — это не «сгорел сервер», а «процесс завис». Здесь хватает пары строк в compose: healthcheck ловит зависание, restart: always поднимает упавшее, autoheal перезапускает нездоровое.

services:
  app:
    image: registry.example.com/app:latest
    restart: always
    healthcheck:
      test: ['CMD', 'curl', '-sf', 'http://localhost:8000/health']
      interval: 15s
      retries: 3
      start_period: 30s
  autoheal:
    image: willfarrell/autoheal:latest
    restart: always
    environment: { AUTOHEAL_CONTAINER_LABEL: all }
    volumes: ['/var/run/docker.sock:/var/run/docker.sock']

Уровень 2: запасной сервер и переключение

От потери самого сервера спасает только второй сервер. Дешёвая схема без кластера: маленький standby-VPS, куда каждые несколько минут приезжают данные (restic или rsync), а стек описан тем же compose-файлом. Переключение — смена A-записи с низким TTL (60 сек) или floating IP провайдера, если он есть.

монитор (со стороны) ── ловит down ──▶ standby
  1. восстановить данные из последнего бэкапа
  2. docker compose up -d
  3. переключить floating IP / DNS (TTL 60)
итого: минуты простоя, копейки за standby

Всю цепочку можно автоматизировать скриптом — у нас в кейсах есть сайт, который так переезжает на новый VPS без участия человека примерно за минуту.

Чек-лист