Как развернуть локальный кластер Kubernetes с kind

05.11.2026

Как развернуть локальный кластер Kubernetes с kind для отработки базового администрирования

На чтение

7 мин

Дата обновления

05.11.2026

kind — это инструмент для запуска локальных кластеров Kubernetes, где узлы работают как контейнеры. Для учебной практики это удобно: стенд поднимается быстро, не требует облака и так же быстро удаляется, если нужно начать заново. Такой сценарий хорошо подходит для отработки базового администрирования: посмотреть ноды, применить манифест, прочитать статус Pod и разобраться, где искать проблему.

Ниже — практический маршрут: что нужно перед стартом, как создать многоузловой кластер, как проверить, что kubectl смотрит именно туда, куда нужно, и как развернуть маленькое учебное приложение с Deployment и Service.

Что нужно до запуска kind

В рамках этой задачи предполагается, что контейнерный движок и kubectl уже установлены. Для kind этого достаточно на старте: сам инструмент может работать с Docker, Podman или nerdctl, а для упражнений с ресурсами Kubernetes понадобится именно kubectl. Документация kind отдельно оговаривает, что kubectl не обязателен для самого создания кластера, но без него нельзя выполнять большую часть учебных действий.

Если вы используете Podman или nerdctl в rootless-режиме, для полностью рабочей среды может понадобиться дополнительная настройка. Поэтому для первого стенда обычно проще брать Docker или уже заранее подготовленную среду.

Установка kind и первый запуск

У kind есть несколько способов установки: готовый бинарник, пакетный менеджер или сборка через Go. Один из подтверждённых вариантов выглядит так:

go install sigs.k8s.io/kind@v0.33.0

После установки полезно проверить, что команда доступна в PATH:

kind version

Самый короткий запуск кластера — это:

kind create cluster

Но для тренировки администрирования лучше сразу сделать учебный многоузловой кластер: одна control-plane-нода и две worker-ноды. Это даёт более реалистичную картину и позволяет видеть, как workload распределяется по узлам.

Конфигурация кластера: control-plane, worker и доступ к сервису

Создайте файл kind-config.yaml:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30080
    hostPort: 8080
    listenAddress: "127.0.0.1"
    protocol: TCP
- role: worker
- role: worker

Что здесь важно:

control-plane — узел, где работают компоненты управления кластером;
worker — узлы, на которых будут размещаться обычные workload;
extraPortMappings — проброс порта с хоста в контейнер-ноду. Это удобно для локального доступа к учебному сервису;
127.0.0.1 как адрес прослушивания безопаснее, чем публикация на все интерфейсы.

Теперь создайте кластер по конфигурации:

kind create cluster --name admin-lab --config kind-config.yaml --wait 60s

Флаг --wait заставляет команду дождаться готовности control plane. Для учебной среды это полезно: вы сразу понимаете, что кластер поднялся, а не ушёл в фон с незавершённой инициализацией.

Если кластер создаётся слишком долго или часть нод не становится готовой, частая причина — нехватка ресурсов у локального контейнерного движка. Для Docker Desktop документация kind отдельно предупреждает, что базовым кластерам нужен запас памяти, а многоузловые конфигурации требуют ещё больше.

Как проверить ноды и контекст kubectl

После создания кластера важно убедиться в двух вещах: сам кластер существует и kubectl смотрит именно на него.

Сначала проверьте, какие кластеры kind вообще созданы:

kind get clusters

Для кластера с именем admin-lab контекст в kubectl будет называться kind-admin-lab. Это стоит запомнить: имя kind-кластера и имя kubeconfig-контекста не совпадают дословно.

Проверьте текущий контекст:

kubectl config current-context

Посмотреть все контексты тоже полезно:

kubectl config get-contexts

Найдите в списке контекст созданного учебного кластера. В нашем примере используется имя kind-admin-lab. Перед дальнейшими командами явно выберите этот контекст и проверьте результат:

kubectl config use-context kind-admin-lab
kubectl config current-context

Если в вашем списке имя отличается, подставьте именно его. Следующие команды без флага --context выполняются в выбранном контексте. Затем запросите сводку по учебному кластеру:

kubectl cluster-info --context kind-admin-lab

Теперь можно проверить узлы:

kubectl get nodes
kubectl get nodes -o wide

В исправной учебной среде вы ожидаете увидеть три ноды: одну control-plane и две worker, а в статусе — Ready.

Проверка	Команда	Что должно получиться
Список kind-кластеров	`kind get clusters`	Есть `admin-lab`
Текущий контекст	`kubectl config current-context`	Выбранный выше контекст учебного кластера, в примере `kind-admin-lab`
Информация о кластере	`kubectl cluster-info --context kind-admin-lab`	Control plane отвечает
Список узлов	`kubectl get nodes -o wide`	3 ноды, статус `Ready`

Типичная ошибка новичка — применять манифесты не в тот контекст. Поэтому перед каждым упражнением полезно быстро проверять kubectl config current-context.

Учебное приложение: Deployment и Service

Теперь развернём маленькое приложение. Создайте файл hello-app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 2
  selector:
    matchLabels:
      run: load-balancer-example
  template:
    metadata:
      labels:
        run: load-balancer-example
    spec:
      containers:
      - name: hello-world
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
        ports:
        - containerPort: 8080
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  type: NodePort
  selector:
    run: load-balancer-example
  ports:
  - name: http
    port: 8080
    targetPort: 8080
    nodePort: 30080

Примените манифест:

kubectl apply -f hello-app.yaml

Что происходит:

Deployment просит кластер поддерживать две реплики приложения;
Kubernetes создаёт Pod через ReplicaSet;
Service выбирает Pod по метке run: load-balancer-example и даёт им стабильную точку доступа;
тип NodePort публикует сервис на порту ноды, а наша конфигурация kind пробрасывает этот порт на 127.0.0.1:8080.

Проверьте результат:

kubectl get deployments
kubectl get pods -o wide
kubectl get services
kubectl describe service example-service

Если всё в порядке, сервис должен быть доступен локально на 127.0.0.1:8080. Для учебного стенда это удобно: не нужно искать IP ноды и думать о внешнем балансировщике.

Базовая диагностика: Pod, Deployment и Node

Главная привычка администратора Kubernetes — двигаться сверху вниз: от желаемого состояния к фактическому, а потом к деталям конкретного объекта.

Deployment

kubectl get deployment hello-world
kubectl describe deployment hello-world
kubectl rollout status -w deployment/hello-world

Эти команды помогают понять, создан ли Deployment, сколько реплик он хочет держать и завершился ли rollout.

Pod

kubectl get pods
kubectl get pods -o wide
kubectl describe pod <имя-pod>
kubectl logs <имя-pod>

describe нужен, когда Pod не стартует или перезапускается: там видно события, назначение на ноду и состояние контейнера. logs полезен, если контейнер стартовал, но приложение внутри работает не так, как ожидалось.

Node

kubectl get nodes
kubectl describe node <имя-ноды>

Здесь смотрят статус узла, роли, условия готовности и общую информацию о его состоянии.

События

kubectl get events --sort-by=.metadata.creationTimestamp

События особенно полезны, когда кажется, что «ничего не происходит». Часто именно там видно, что Pod ещё не назначен, образ не подтянулся или rollout ждёт готовности.

Учебный порядок диагностики обычно такой: контекст → ноды → deployment → pod → логи → события. Он быстро отсекает самые частые причины ошибок.

Как удалить кластер и быстро пересоздать среду

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

kind delete cluster --name admin-lab

Для kind это штатный сценарий. Если кластера с таким именем уже нет, команда удаления по замыслу остаётся безопасной и не должна мешать автоматизированной очистке среды.

Чтобы начать заново, используйте ту же команду создания:

kind create cluster --name admin-lab --config kind-config.yaml --wait 60s

В этом и состоит одно из главных преимуществ kind для практики: вместо долгой ручной уборки вы просто возвращаете стенд в чистое, воспроизводимое состояние. Для обучения это ценнее, чем пытаться бесконечно «долечивать» экспериментальный кластер.

Если хотите изучать тему глубже, в подтверждённой программе курса для действующих IT-специалистов есть отдельные блоки по основам Kubernetes, его применению и администрированию. Также в описании программы заявлена практика развёртывания кластера Kubernetes на собственных мощностях.

Программирование