До основного вмісту

Kubernetes на VPS: легкий кластер із k3s

Хмара та DevOps · 19.04.2026 · 4 хв читання
Ілюстрація до статті «Kubernetes на VPS: легкий кластер із k3s»

Kubernetes на VPS: мінімальний кластер із k3s

k3s — легкий дистрибутив Kubernetes від Rancher Labs, що потребує всього 512 МБ RAM. Ідеальний для вивчення K8s і запуску невеликих production-кластерів на VPS від 4 ГБ RAM.

Встановлення k3s (Master-нода)

curl -sfL https://get.k3s.io | sh -
systemctl status k3s

# Перевірити кластер
kubectl get nodes
kubectl get pods -A

Додавання Worker-ноди

# Отримати токен на Master
cat /var/lib/rancher/k3s/server/node-token

# На Worker-ноді
curl -sfL https://get.k3s.io | K3S_URL=https://MASTER_IP:6443   K3S_TOKEN=TOKEN sh -

Деплой застосунку

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: nginx:alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer
kubectl apply -f deployment.yaml
kubectl get pods
kubectl get services

Helm: пакетний менеджер K8s

# Встановити Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Встановити застосунок із Helm Chart (наприклад, cert-manager)
helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager   --namespace cert-manager   --create-namespace   --set installCRDs=true

Ingress + авто-SSL

# Traefik (входить у k3s за замовчуванням)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - app.yourdomain.com
    secretName: webapp-tls
  rules:
  - host: app.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80
Рекомендації: Для одного VPS із 4-8 ГБ RAM k3s — відмінний вибір. Для production-кластера з високою доступністю використовуйте щонайменше 3 Master-ноди (непарну кількість для etcd quorum).

Розбір реальних помилок і статусів подів

Три статуси пода закривають майже всі питання новачків у Kubernetes. Розберемо, що означає кожен і як знайти причину через kubectl describe.

Pod завис у стані Pending

kubectl describe pod webapp-7d9f8c-abcde

Events:
  Warning  FailedScheduling  12s   default-scheduler  0/1 nodes are available: 1 Insufficient memory.

Планувальник не може знайти ноду, де вистачає запитаних ресурсів із resources.requests. Рішення: зменшити requests.memory у маніфесті, додати worker-ноду або перевірити, чи не зайняті ресурси іншими подами через kubectl describe node.

CrashLoopBackOff

kubectl get pods

NAME                      READY   STATUS             RESTARTS   AGE
webapp-7d9f8c-abcde        0/1    CrashLoopBackOff   6          4m

Контейнер стартує і одразу падає, Kubernetes перезапускає його з експоненційною затримкою. Причина майже завжди в самому застосунку: дивіться kubectl logs webapp-7d9f8c-abcde --previous — прапорець --previous обов'язковий, інакше побачите логи вже нового процесу, що впав, а не попереднього.

ImagePullBackOff

Events:
  Warning  Failed     8s   kubelet  Failed to pull image "myrepo/app:v2": rpc error: code = Unknown desc = Error response from daemon: pull access denied for myrepo/app, repository does not exist or may require 'docker login'

Або одруківка в назві образу/тезі, або образ приватний і на ноді не налаштовано imagePullSecrets. Створіть секрет командою kubectl create secret docker-registry regcred --docker-server=... --docker-username=... --docker-password=... і вкажіть його в spec.imagePullSecrets.

k3s проти інших легких дистрибутивів

Критерійk3sMicroK8sПовний kubeadm
Мінімум RAM512 MB540 MB2 GB на control-plane
База даних стануSQLite (або etcd для HA)dqliteetcd
Встановлення однією командоюЄЄ (snap)Немає, кілька кроків

Коли k3s не підходить

  • Проєкт вміщується в Docker Compose або Docker Swarm — оверхед Kubernetes не окупається на масштабі 1-2 сервісів.
  • Команда не знайома з поняттями Kubernetes і немає часу на навчання — краще почати з Docker Swarm.
  • Потрібна строго сертифікована upstream-збірка Kubernetes для комплаєнсу — k3s замінює частину компонентів (Traefik, servicelb, local-path-provisioner) на свої полегшені версії, для деяких аудитів це доведеться вимикати.
  • VPS менш ніж з 1 ГБ RAM — навіть мінімальний k3s з'їдає суттєву частину пам'яті, для сайту вистачить звичайного стека без оркестрації.
  • Потрібне планування задач на GPU зі специфічними device plugins виробника — їх доведеться налаштовувати вручну, готової інтеграції в k3s немає.

Перевірка результату

# Усі ноди у стані Ready
kubectl get nodes -o wide

# Усі системні поди запущені
kubectl get pods -A | grep -v Running

# HTTP-відповідь через Ingress
curl -I https://app.yourdomain.com

# Статус випуску сертифіката cert-manager
kubectl get certificate -A
kubectl describe certificate webapp-tls

Якщо команда grep -v Running повернула хоч один рядок (крім заголовка) — якийсь системний под не піднявся, розбирайтеся через kubectl describe pod у відповідному неймспейсі. Перед продакшн-використанням кластера налаштуйте зовнішній моніторинг — він покаже падіння сервісу, навіть якщо сам Kubernetes вважає под живим.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці