Кто хочет — ищет способ, кто не хочет — ищет причину.

В четвёртом сезоне Linux Factory мы собираем нормальный отказоустойчивый кубер: три control-ноды, три worker-ноды, HAProxy, Keepalived, VIP, отдельный DNS и хранилище. Это правильно для обучения инфраструктуре, но даже в минимальной конфигурации получается шесть виртуалок по 2 CPU и 2 ГБ RAM. Не у каждого ноутбук способен переварить такой зоопарк.

Роман Шубин
Роман Шубин
CEO & CTO, Главред в «Цифровой улей»
Задать вопрос
Если железа или денег на облако нет, это не повод забить хуй на кубер и ждать, пока сервер сам вырастет в шкафу. Для знакомства с API, Pod, Deployment, Service, ConfigMap, Secret, Ingress, Helm и остальными объектами можно развернуть одиночный K3s-кластер на одной локальной виртуалке.

Давай. Сразу договоримся — K3s не заменит лабораторию с kubeadm один в один. Ты не потрогаешь кворум etcd, HA control plane, VIP, kubeadm init/join/reset и отказ нод.

Но это настоящий Kubernetes API, а не симулятор. Манифесты, kubectl, namespaces, контроллеры, scheduler, kubelet, container runtime и большая часть повседневной работы останутся теми же.

Что понадобится

Абсолютный минимум для одной виртуалки:

  • 2 vCPU
  • 2 ГБ RAM
  • 20 ГБ SSD
  • Ubuntu 24.04 LTS
  • доступ в интернет
  • один обычный пользователь с sudo

Я бы рекомендовал выдать 2 vCPU, 3–4 ГБ RAM и 30 ГБ диска. На 2 ГБ сам кластер запустится, но после установки пары операторов, мониторинга или жирного приложения память закончится быстрее, чем твоё терпение.

Для лаборатории не нужен белый айпишник, домен, внешний балансировщик или отдельный NFS. Виртуалка может жить в VirtualBox, VMware, Proxmox, libvirt или Hyper-V. Главное, чтобы с твоего компьютера был доступ к её айпи-адресу.

Официальные требования K3s лежат в документации. Там же отдельно предупреждают, что производительность хранилища важна, поэтому виртуалку лучше держать на SSD.

Подготавливаем виртуалку

Обновляем систему и ставим базовые пакеты:

sudo apt update
sudo apt install -y curl ca-certificates
sudo apt upgrade -y

Проверяем имя машины и адрес:

hostnamectl
ip -br address

Если хочешь, задай нормальное имя:

sudo hostnamectl set-hostname k3s-lab

Для учебной виртуалки лучше сразу отключить swap, чтобы поведение kubelet было ближе к обычному кластеру из интенсива:

sudo swapoff -a
sudo sed -ri '/\sswap\s/s/^#?/#/' /etc/fstab
sudo swapon --show

Последняя команда ничего выводить не должна.

Проверь, не включён ли на виртуалке UFW:

sudo ufw status

Для полностью локальной учебной виртуалки проще всего отключить его. На сервере с публичным айпишником сначала разберись с правилами и не отключай файрвол вслепую.

sudo ufw disable

Устанавливаем K3s

Официальная установка выглядит банально:

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

Если ссышь отправлять скачанный скрипт прямо в shell, сначала сохрани и просмотри его:

curl -sfL https://get.k3s.io -o install-k3s.sh
less install-k3s.sh
sudo sh install-k3s.sh

Скрипт установит K3s, создаст systemd-сервис и запустит кластер. Проверяем:

sudo systemctl status k3s --no-pager
sudo k3s --version
sudo k3s kubectl get nodes -o wide
sudo k3s kubectl get pods -A

Без дополнительных переменных установщик берёт актуальную версию из канала stable. Для одноразовой лаборатории это нормально. Если хочешь получить одинаковую версию на нескольких машинах или повторить стенд позже, зафиксируй её через переменную INSTALL_K3S_VERSION, взяв точное значение из релизов K3s.

Через минуту единственная нода должна перейти в состояние Ready, а системные Pod — в Running или Completed.

По умолчанию K3s приносит с собой containerd, Flannel, CoreDNS, metrics-server, Traefik, ServiceLB и local-path-provisioner. То есть после одной команды у тебя уже есть сеть Pod, DNS, Ingress и простое локальное хранилище. Для слабого ноутбука это куда гуманнее шести полноценных виртуалок.

Настраиваем обычный kubectl внутри виртуалки

Администраторский kubeconfig лежит здесь:

/etc/rancher/k3s/k3s.yaml

Не работай постоянно через sudo k3s kubectl. Скопируй конфиг своему пользователю:

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

Проверяем уже обычным клиентом:

kubectl cluster-info
kubectl get nodes
kubectl get pods -A
kubectl get storageclass

Если хочешь запускать kubectl со своего компьютера

Предыдущие команды настраивают kubectl внутри виртуалки. Если удобнее управлять кластером с основного компьютера, скопируй конфиг в отдельный файл, чтобы не затереть уже существующий ~/.kube/config:

mkdir -p "$HOME/.kube"
scp user@192.168.1.50:~/.kube/config "$HOME/.kube/k3s-lab.yaml"

Здесь user — пользователь виртуалки, а 192.168.1.50 — её реальный IP. Затем открой k3s-lab.yaml и в поле server замени 127.0.0.1 на IP виртуалки:

server: https://192.168.1.50:6443

Проверяем, явно указав нужный конфиг:

KUBECONFIG="$HOME/.kube/k3s-lab.yaml" kubectl get nodes

Для этого компьютер должен видеть айпи виртуалки, а TCP-порт 6443 должен быть доступен из твоей локальной сети. Не открывай API-сервер всему интернету. K3s обновляет сертификаты в исходном /etc/rancher/k3s/k3s.yaml при запуске сервиса, но внешняя копия сама не обновится, если спустя длительное время она перестанет работать из-за сертификата, скопируй файл заново.

Запускаем первое приложение

Чтобы не радоваться одному зелёному статусу ноды, проверим кластер настоящим Deployment и Service.

Создаём файл web.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 25m
              memory: 32Mi
            limits:
              cpu: 200m
              memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: 80

Применяем и ждём запуска:

kubectl apply -f web.yaml
kubectl rollout status deployment/web
kubectl get pods -o wide
kubectl get service web

Пробрасываем сервис на локальный порт:

kubectl port-forward service/web 8080:80

В другом терминале:

curl http://127.0.0.1:8080

Если получил HTML от nginx — всё, кубер у тебя крутится. Денег не потратил, облако не арендовал, оправдания закончились.

Почистить лабораторное приложение можно так:

kubectl delete -f web.yaml

Как не убить кластер на двух гигабайтах

На слабой машине придётся соблюдать диету:

  1. Не запускай Prometheus, Grafana, Loki, Elasticsearch и ещё десять операторов одновременно.
  2. Для каждого учебного приложения задавай небольшие requests и limits.
  3. Держи одну реплику, если задание не посвящено масштабированию.
  4. После лаборатории удаляй ненужные namespaces и Helm-релизы.
  5. Периодически проверяй память и диск:
free -h
df -h
kubectl top nodes
kubectl top pods -A --sort-by=memory

Сразу после установки metrics-server может ещё не успеть собрать данные. Если kubectl top отвечает Metrics API not available, подожди минуту, проверь Pod metrics-server и повтори команду:

kubectl -n kube-system get pods -l k8s-app=metrics-server
  1. Перед опасными экспериментами делай snapshot виртуалки.

Можно отключить встроенные Traefik и ServiceLB, но я бы на первом запуске этого не делал. Они пригодятся в уроках про Ingress и сервисы. Сначала получи рабочий кластер, а оптимизацией на три копейки занимайся, когда действительно упрёшься в ресурсы.

Что здесь совпадает с обычным Kubernetes

На K3s ты нормально отработаешь:

  • Pod, ReplicaSet, Deployment, DaemonSet, StatefulSet и Job
  • Service, CoreDNS и Ingress
  • ConfigMap и Secret
  • namespaces, ServiceAccount, Role и RoleBinding
  • requests, limits, probes и rollout
  • Helm
  • PersistentVolumeClaim через встроенный local-path-provisioner
  • логи, события, describe, exec, port-forward и остальную работу через kubectl

Те же манифесты после этого можно применять в кластере на kubeadm, если они не завязаны на особенности конкретного Ingress-контроллера или StorageClass.

Что не совпадает с kubeadm

K3s упакован иначе:

  • компоненты собраны в один дистрибутив и управляются сервисом k3s
  • для одиночного сервера по умолчанию используется SQLite, а не отдельный кластер etcd
  • нет команд kubeadm init, kubeadm join, kubeadm reset и kubeadm upgrade
  • пути к конфигам и журналам отличаются
  • часть компонентов уже установлена и настроена за тебя
  • одна нода не даёт никакой отказоустойчивости

Именно поэтому K3s подходит для знакомства с кубер апихой и прикладных лабораторных, но не заменяет изучение внутренней сборки кластера.

Если захочется добавить worker-ноду

Когда появится ещё 1 ГБ RAM, можешь создать вторую виртуалку и превратить лабораторию в маленький многонодовый кластер.

Сначала задай второй машине уникальное имя: две ноды с одинаковыми hostname в один кластер добавлять нельзя.

sudo hostnamectl set-hostname k3s-worker-1

Между нодами должны проходить TCP 6443 от worker к серверу, UDP 8472 в обе стороны для Flannel VXLAN и TCP 10250 в обе стороны для kubelet и metrics-server. Если виртуалки находятся в одной закрытой виртуальной сети и файрвол отключён, дополнительно настраивать правила обычно не требуется.

На серверной ноде получаем токен:

sudo cat /var/lib/rancher/k3s/server/node-token

Этот токен даёт возможность присоединить ноду к кластеру. Не публикуй его в git, домашке, чатах и скриншотах.

На новой виртуалке запускаем установку агента, подставив айпишник первой ноды и токен:

curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.50:6443 K3S_TOKEN='ВСТАВЬ_ТОКЕН' sudo -E sh -

После этого на первой машине:

kubectl get nodes -o wide

Для worker-ноды достаточно начать с 1 vCPU и 1 ГБ RAM. Это всё ещё не HA, зато уже можно смотреть распределение Pod между узлами, cordon, drain, labels, taints и падение worker-ноды.

Как удалить K3s

Если решил начать заново:

sudo /usr/local/bin/k3s-uninstall.sh

На worker-ноде используется другой скрипт:

sudo /usr/local/bin/k3s-agent-uninstall.sh

Сначала попробуй прочитать ошибку и посмотреть журналы, а не сносить кластер после первого красного статуса:

sudo journalctl -u k3s -n 200 --no-pager
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl describe node

Итог

Роман Шубин
Роман Шубин
CEO & CTO, Главред в «Цифровой улей»
Задать вопрос
Полноценная лаборатория на kubeadm всё равно нужна, если хочешь понять устройство control plane, HA и жизненный цикл нод. Но для большей части практики достаточно одной виртуалки с K3s.

Минимальный план простой: выделил 2 CPU, 2–3 ГБ RAM и 20–30 ГБ SSD, установил K3s, проверил ноду, запустил nginx и пошёл изучать манифесты. Никакого хайлоада на этом железе не будет, зато Pod будет Pod, Deployment — Deployment, а kubectl перестанет выглядеть неведомой хуйнёй.

Короче, если нет денег на шесть серверов — не ной. Подними один K3s локально и начни работать. Когда доберёшься до HA и kubeadm, уже будешь понимать, ради чего вся эта инфраструктурная ебатория вообще нужна, либо не нужна.