Налаштування локального Kubernetes для розробки (Minikube/Kind/k3d)

Розробляти Kubernetes-маніфести проти production-кластера — ризиковано. Навіть dev-namespace не дає повного контролю, а кожен push у CI — довгий цикл. Локальний кластер на ноутбуці розробника вирішує цю проблему: повний доступ, швидка ітерація, ізоляція. Ми допоможемо налаштувати локальний Kubernetes під ваш стек та процеси: оберемо інструмент, налаштуємо регістри та автоматизуємо деплой. Правильно налаштований локальний кластер скорочує час на відладку маніфестів на 30-40%. Розробник може тестувати helm-чарти, кастомні контролери та оператори без ризику зламати загальну інфраструктуру. Економія бюджету на інфраструктуру тестування становить до 30%. Налаштування кластера коштує менше, ніж одна година простою production.

У цій статті розберемо три популярних інструменти: Minikube, Kind та k3d. Кожен має свої особливості, і вибір залежить від ваших завдань: від простого тестування до CI-конвеєрів. Також розглянемо типові проблеми — нестача ресурсів, налаштування registry та інтеграція з локальними образами.

Які проблеми вирішує локальний Kubernetes?

Локальний кластер дає розробнику повний контроль над оточенням. Ви можете:

• Швидко тестувати маніфести, чарти та оператори без очікування CI.
• Експериментувати з налаштуваннями (наприклад, RBAC або поди з привілеями).
• Відладжувати проблеми в ізоляції, не впливаючи на команду.
• Використовувати ті самі інструменти (Helm, Kustomize, ArgoCD) що й на production.

Як обрати інструмент: Minikube, Kind або k3d?

Minikube — найстаріший інструмент, найбільш feature-complete. Підтримує декілька drivers: Docker, VirtualBox, Hyper-V, QEMU. Вбудовані аддони: ingress, metrics-server, dashboard, registry. Для розробника, який хоче «просто запустити Kubernetes» — оптимальний вибір.

minikube start --driver=docker --cpus=4 --memory=8g --kubernetes-version=v1.29.3
minikube addons enable ingress
minikube addons enable metrics-server

Kind (Kubernetes IN Docker) — кожна нода кластера — Docker-контейнер. Немає VM-overhead, швидкий старт (~30 секунд). Улюблений інструмент для CI-тестування Kubernetes-операторів та контролерів. Мульти-нодові кластери через конфіг:

---
# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    kubeadmConfigPatches:
      - |
        kind: InitConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            node-labels: "ingress-ready=true"
    extraPortMappings:
      - containerPort: 80
        hostPort: 80
      - containerPort: 443
        hostPort: 443
  - role: worker
  - role: worker

kind create cluster --config kind-config.yaml --name dev 

k3d — обгортка над k3s (полегшений Kubernetes від Rancher) у Docker. Швидший за Kind, підтримує вбудований load balancer (Traefik), вбудований registry. Чудовий вибір для розробки додатків під k3s edge-кластери.

k3d cluster create dev \
  --agents 2 \
  --k3s-arg "--disable=traefik@server:0" \
  --port "80:80@loadbalancer" \
  --port "443:443@loadbalancer"

Як налаштувати локальний регістр для Kind?

Основна біль при локальній розробці — деплой власних образів. docker push localhost:5000/myapp:dev працює, але вимагає налаштування registry.

Для Kind офіційний скрипт створює registry у Docker і підключає його до Kind-мережі:

# Запускаємо local registry
docker run -d --restart=always -p 5001:5000 --name kind-registry registry:2
# Підключаємо до Kind-мережі
docker network connect kind kind-registry
# Налаштовуємо Kind на доступ до registry без TLS
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: local-registry-hosting
  namespace: kube-public
data:
  localRegistryHosting.v1: |
    host: "localhost:5001"
    help: "https://kind.sigs.k8s.io/docs/user/local-registry/"
EOF

Після цього: docker build -t localhost:5001/myapp:dev . && docker push localhost:5001/myapp:dev, і образ доступний у кластері без додаткових налаштувань.

Для Minikube простіше: eval $(minikube docker-env) перемикає Docker CLI на Docker daemon всередині Minikube. docker build кладе образ одразу туди. У маніфесті imagePullPolicy: Never — кластер використовує локальний образ.

Покрокове налаштування Minikube для розробки

1. Встановіть Minikube через офіційний репозиторій: brew install minikube (macOS) або choco install minikube (Windows).
2. Запустіть кластер: minikube start --driver=docker --cpus=2 --memory=4g.
3. Увімкніть необхідні аддони: minikube addons enable ingress && minikube addons enable metrics-server && minikube addons enable dashboard.
4. Відкрийте дашборд: minikube dashboard.
5. Налаштуйте локальний регістр: eval $(minikube docker-env) та використовуйте docker build.

Спочатку отримайте доступ до кластера через kubectl get nodes. Якщо не налаштований локальний kubectl, завантажте його та виконайте kubectl config use-context minikube.

Типові проблеми та рішення

Локальний кластер з 3-4 сервісами + Redis + PostgreSQL легко з'їдає 6-8 ГБ RAM. Якщо працюєте на ноутбуці з 16 ГБ — це половина всієї пам'яті. Рішення:

• Запускати лише потрібні сервіси: kubectl scale deployment redis --replicas=0 коли не потрібен.
• Використовувати k3d замість Minikube — k3s споживає менше.
• Для баз даних використовувати port-forward до staging, а не піднімати локально: kubectl port-forward -n staging svc/postgres 5432:5432.

Ще одна проблема — невідповідність версій. Ми налаштовуємо кластер на версії Kubernetes, ідентичній production, що виключає сюрпризи при деплої.

kind create cluster --config kind-config.yaml --name multinode kubectl get nodes