K3s на VDS: минималистичный Kubernetes для малого проекта

Когда нужен Kubernetes, но нет смысла поднимать тяжёлый кластер из нескольких узлов, K3s — отличный вариант. Это минималистичная сборка Kubernetes, оптимизированная по размеру и потреблению ресурсов. Она включает контейнерный runtime, стандартный CNI (по умолчанию flannel), локальный провиженер томов и набор аддонов, запускается в один бинарник и не требует сложной подготовки. На небольшом VDS можно развернуть рабочую среду для тестов, staging или аккуратно спроектированного продакшен-сервиса с одной репликой при понимании ограничений.

Когда K3s уместен

K3s выбирают там, где важны простота и экономичность: небольшое веб‑приложение, API, бэк‑офисная служба, cron‑задачи в контейнерах, демо‑стенд, CI‑агенты.

• Меньше RAM и CPU, чем у «полного» Kubernetes.
• Быстрая установка и обновления.
• Встроенные компоненты: containerd, flannel, local-path-provisioner, metrics‑server.
• Подходит для одиночного узла и небольшого кластера.

Ограничение очевидно: один узел — одна точка отказа. Для высокой доступности потребуется несколько узлов, внешний балансировщик и реплики приложений.

Минимальные требования к VDS и ОС

Для одиночного узла с 1–3 микросервисами и тестовыми нагрузками обычно хватает 2 CPU и 4 ГБ RAM. Для продакшен‑нагрузки на одном узле ориентируйтесь на 4 CPU и 8 ГБ RAM. Диск — SSD от 20–40 ГБ минимум; если нужны PVC с данными — берите с запасом. Подробнее о выборе ресурсов — в материале как выбрать план VDS по CPU и RAM.

ОС: Ubuntu 22.04/24.04 LTS или Debian 12 — безопасный выбор. Нужны включённый ip_forward, отключённый swap и загруженные модули overlay, br_netfilter. Cgroups v2 поддерживаются.

Базовая подготовка узла

sudo apt update && sudo apt -y upgrade
sudo apt -y install curl vim ca-certificates gnupg lsb-release

# Загрузка модулей ядра
printf "overlay\nbr_netfilter\n" | sudo tee /etc/modules-load.d/k8s.conf
sudo modprobe overlay
sudo modprobe br_netfilter

# Сетевые параметры для Kubernetes
cat | sudo tee /etc/sysctl.d/99-kubernetes.conf > /dev/null << 'EOF'
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system

# Отключить swap (и убрать из fstab)
sudo swapoff -a
sudo sed -i.bak '/ swap / s/^/# /' /etc/fstab

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Установка K3s (одиночный узел)

K3s поставляется одним инсталлером и запускает сервисы через systemd. По умолчанию включены Traefik (Ingress), flannel (CNI) и local-path-provisioner (хранилище). Ниже два варианта: с Traefik и без него.

Вариант A: оставить Traefik (проще стартовать)

# Установить K3s с правами kubeconfig для чтения
curl -sfL get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode 0644" sh -

# Проверка статуса
sudo systemctl status k3s
kubectl get nodes -o wide
kubectl get pods -A

Плюсы: сразу есть ingress и TLS. Минусы: если нужен NGINX Ingress — придётся отключать Traefik и ставить другой контроллер.

Вариант B: без встроенного Traefik (под NGINX Ingress)

# Установить K3s без traefik
curl -sfL get.k3s.io | INSTALL_K3S_EXEC="--disable=traefik --write-kubeconfig-mode 0644" sh -

kubectl get pods -A

В этой статье дальше используем вариант A (Traefik), чтобы не утяжелять установку сторонними манифестами.

kubectl и kubeconfig

На узле с K3s kubectl уже доступен (симлинк). Kubeconfig лежит в /etc/rancher/k3s/k3s.yaml; сделайте рабочую копию в домашнем каталоге:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config

Для удалённой работы замените в ~/.kube/config адрес API‑сервера (часто 127.0.0.1) на внешний IP вашего VDS и ограничьте доступ к порту 6443/tcp по источникам. Для локальной работы ничего менять не нужно.

Сетевые порты и базовый firewall

Для одиночного узла с ingress откройте 80/443 для мира и 22 для SSH. Порт API 6443 держите закрытым или ограничьте по IP. Пример с UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Для многонодового кластера потребуется больше внутренних портов (etcd, kubelet, flannel VXLAN). Для одиночного узла это не нужно. Полезно свериться с чек‑листом безопасности VDS (SSH и firewall).

CNI: что выбрать для малого проекта

По умолчанию K3s использует flannel с backend VXLAN — идеальный старт: минимум настроек, работает «из коробки». Если нужны NetworkPolicy или eBPF‑возможности, рассмотрите Cilium или Calico — но это усложнит установку и увеличит расходы. Для одиночного узла с Traefik flannel достаточно.

Хранилище: local-path-provisioner

local-path-provisioner создаёт тома на локовом диске узла. Это быстро и просто, но без отказоустойчивости: при потере узла теряются данные. Используйте для кэшей, временных артефактов, мини‑БД с внешним бэкапом. Пример PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: local-path

Ingress и TLS на Traefik

Traefik понимает стандартные Ingress. Для теста можно создать самоподписанный сертификат и Secret. В продакшене используйте автоматическое обновление или загрузите актуальные SSL-сертификаты в Secret.

# Пример самоподписанного сертификата для app.example.com
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -subj "/CN=app.example.com" -keyout tls.key -out tls.crt
kubectl create secret tls demo-tls --key tls.key --cert tls.crt -n default

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Деплой первого приложения

Развернём минимальный nginx как пример: Deployment, Service и Ingress. Укажем requests и limits, чтобы планировщик не «съел» все ресурсы узла.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-nginx
  labels:
    app: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.25-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 300m
            memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: demo-svc
spec:
  selector:
    app: demo
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: demo-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-svc
            port:
              number: 80

Применяем манифесты и проверяем:

kubectl apply -f demo.yaml
kubectl get deploy,svc,ingress
kubectl describe ingress demo-ingress

Далее создайте A‑запись домена на публичный IP вашего VDS (при необходимости воспользуйтесь услугой регистрация доменов). Как только DNS обновится, проверьте доступность сайта по HTTPS. Для самоподписанного сертификата браузер предупредит — это нормально на тесте.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Ресурсы узла: сколько просить и ограничивать

Для одного небольшого приложения на 2 CPU и 4 ГБ RAM разумно задать суммарные requests в районе 400–600m CPU и 1–1.5 ГБ памяти, оставив запас системе и демонам K3s. Для «пиков» допускайте суммарные limits в 1–1.5 CPU и 2–2.5 ГБ RAM. Если видите OOMKill — снижайте limits или увеличивайте план VDS.

Журналы и диагностика

Основные точки входа:

• Логи k3s: journalctl -u k3s -f.
• Состояние: kubectl get pods -A, kubectl describe pod <name> -n <ns>.
• Логи контейнеров: kubectl logs -f <pod> -n <ns>.
• Ресурсы: kubectl top nodes, kubectl top pods -A (metrics-server предустановлен).
• Runtime: crictl ps, crictl logs <id>.

Типичные проблемы: Pending‑поды (не хватает ресурсов или ошибочные селекторы), CrashLoopBackOff (ошибка конфигурации/зависимости), сеть не поднимается (проверьте sysctl, модули и что flannel‑под жив в kube-system).

Бэкап кластера (одиночный узел)

По умолчанию K3s на одиночном узле использует SQLite в /var/lib/rancher/k3s/server/db/. Для консистентной копии остановите сервис, сохраните БД и манифесты, затем запустите обратно:

sudo systemctl stop k3s
sudo tar -C / -czf /root/k3s-backup-$(date +%F).tar.gz etc/rancher/k3s/k3s.yaml var/lib/rancher/k3s/server/db var/lib/rancher/k3s/server/manifests
sudo systemctl start k3s

Храните несколько последних архивов вне узла (облачное хранилище или другой сервер). Восстановление на «чистый» узел: установить K3s той же версии, остановить сервис, распаковать архив в корень с перезаписью, запустить сервис.

Обновления K3s

Ручное обновление

# Обновиться до последней стабильной версии
curl -sfL get.k3s.io | sh -

# Обновиться до конкретной версии
curl -sfL get.k3s.io | INSTALL_K3S_VERSION="v1.30.4+k3s1" sh -

# Проверка
k3s -v
kubectl version --short

Перед обновлением делайте бэкап. На продакшене тестируйте обновление на стенде.

Автоматизация

Существует контроллер обновлений, но на одиночном узле надёжнее обновлять вручную в обслуживаемое окно, чтобы избежать неожиданных рестартов.

Безопасность и изоляция

• Отключайте лишние аддоны и API. Не публикуйте 6443 наружу без ACL.
• Используйте NetworkPolicy, если ваш CNI их применяет (flannel — нет).
• Задавайте requests/limits и securityContext (drop ALL capabilities, readOnlyRootFilesystem, non-root пользователь).
• Храните секреты в Secret, доступ — через RBAC.
• Включайте полезные заголовки безопасности на уровне ingress и приложения.

Масштабирование: от одного узла к нескольким

Добавить ноды просто: на новых узлах подготовьте систему, возьмите токен с сервера (/var/lib/rancher/k3s/server/node-token) и запустите агент с адресом API‑сервера. Но как только выходите за рамки одного узла, продумайте схему: внешний балансировщик для ingress, отказоустойчивое хранилище или вынос данных в объектное хранилище, миграции БД, мониторинг и алертинг.

Тонкая настройка Traefik

Traefik поддерживает стандартный Ingress и свои CRD (IngressRoute). Для типового веб‑сервиса достаточно стандартного ресурса. Для канареек, sticky‑сессий и матчей по заголовкам изучите CRD и middleware.

Практический чек‑лист перед выходом в прод

• Ресурсы: заданы requests/limits для всех подов.
• Надёжность: используются liveness/readiness пробы.
• Ingress: корректный HTTPS, HSTS и полезные заголовки на уровне приложения.
• Хранилище: резервные копии вне узла.
• Логи и метрики: сбор и алерты на ключевые показатели.
• Обновления: отработана процедура бэкапа и отката.
• Сеть: firewall открыт только нужным портам, API защищён.

Итоги

K3s позволяет быстро поднять рабочий Kubernetes на одном VDS и запустить контейнеры с ingress и TLS без лишней инфраструктуры. Для малых проектов это отличный компромисс между декларативностью Kubernetes и скромным бюджетом. Начните со встроенных компонентов (flannel, Traefik, local-path), аккуратно задавайте ресурсы, держите под рукой план бэкапов и обновлений. Когда станет тесно — масштабируйтесь и добавляйте продвинутые компоненты.