Kubernetes просто лабы, часть 1: поднимаем кластер и знакомимся с его устройством

В первой теоретической статье мы разобрали, из чего состоит Kubernetes. Узнали, что такое Node и Pod, зачем нужны API Server, Scheduler и kubelet.

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

Kubernetes управляет контейнеризированными приложениями на нодах кластера. Для знакомства с его устройством нам хватит одного домашнего компьютера. После установки инструментов на лабораторную стоит заложить около 20-30 минут. Первая загрузка образов может занять дополнительное время.

Сегодня наша цель - связать понятия из статьи с тем, что можно увидеть в терминале. Все команды разберём по мере выполнения.

Материалы лабораторных собираю в GitHub-репозитории «Kubernetes просто лабы». Для первой лабы там есть краткая памятка с командами и задания для самостоятельной проверки. По мере выхода следующих частей буду добавлять их материалы. Клонировать репозиторий для этой лабы не обязательно: все необходимые команды есть ниже

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

Для работы установим три инструмента:

Вспомните! Node - машина, входящая в кластер

Для обучения kind позволяет использовать вместо отдельной машины контейнер. Внутри него будет работать наша нода Kubernetes.

Установите инструменты по инструкциям для своей операционной системы:

• Docker Desktop для Windows и macOS или Docker Engine для Linux.

• kind.

• kubectl.

На Windows Docker Desktop должен работать в режиме Linux containers. Если используете WSL2, включите интеграцию Docker Desktop с вашим дистрибутивом и выполняйте команды в его терминале. Если установка завершится ошибкой, сохраните её полный текст и проверьте раздел диагностики в документации соответствующего инструмента

Встроенный Kubernetes в Docker Desktop включать не нужно: наш кластер создаст kind.

После установки запустите Docker и откройте терминал. По очереди выполните:

docker version
kind version
kubectl version --client

Каждая команда должна показать сведения о версии своего инструмента. У Docker должны быть оба раздела: Client и Server. Если вместо Server появилась ошибка подключения, проверьте, запущен ли Docker или для Windows - Docker Desktop

К следующему шагу переходим, когда все три команды выполняются без ошибок.

Шаг 1. Создаём кластер

Выполните:

kind create cluster --name k8s-first-lab --wait 180s

Здесь:

• create cluster - создать кластер;

• --name k8s-first-lab - дать ему имя;

• --wait 180s - подождать готовности управляющих компонентов до трёх минут.

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

По умолчанию kind создаёт одну ноду. Да, кластер у нас получится скромный, но для первой лабы этого вполне достаточно.

В теории мы разделяли Control Plane и Worker Nodes по их задачам. В маленьком учебном кластере одна нода может совмещать обе роли: на ней работают и управляющие компоненты, и наше приложение. Это не меняет их назначения.

Теперь укажем kubectl, с каким кластером работать:

kubectl config use-context kind-k8s-first-lab

Пока эту команду достаточно понимать как «выбрать подключение к нашему учебному кластеру».

Если будете переключаться между кластерами, перед продолжением лабы снова выберите это подключение

Проверим связь:

kubectl cluster-info

Команда покажет адрес управляющей части кластера. Найдите строку Kubernetes control plane is running at ....

Это уже первое наблюдение из теории: kubectl обращается к API Server, через который мы взаимодействуем с Kubernetes

Шаг 2. Смотрим на ноду

Выполните:

kubectl get nodes

get nodes означает «показать ноды кластера».

Пример вывода:

NAME                          STATUS   ROLES           AGE   VERSION
k8s-first-lab-control-plane    Ready    control-plane   2m    v1.x.y

Это пример, а не результат запуска на вашем компьютере. Версия и время существования ноды будут отличаться.

Разберём колонки:

Если сразу после создания видите NotReady, немного подождите и повторите команду. Продолжайте, когда появится Ready

В колонке ROLES написано control-plane, но в нашем однонодовом kind на этой же ноде разрешён запуск обычных приложений. Скоро мы это проверим

Шаг 3. Находим компоненты из теории

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

Поды в Kubernetes распределены по пространствам имён - namespaces. Они позволяют разделять объекты внутри одного кластера. Сейчас нам встретятся два: kube-system, где находятся системные компоненты, и default, где мы создадим своё приложение

Посмотрим на системные поды:

kubectl get pods -n kube-system

get pods выводит список подов, а параметр -n kube-system ограничивает его пространством имён kube-system.

В выводе найдите имена, начинающиеся так:

В этом учебном кластере перечисленные компоненты сами работают в подах. Поэтому мы и видим их в таком списке

В выводе будут и другие строки. Разбирать их все сейчас не будем: найдите четыре знакомых компонента и вспомните задачу каждого

А где kubelet? В отличие от перечисленных компонентов, kubelet в нашем стенде запущен непосредственно в операционной системе ноды, вне Pod. Поэтому команда kubectl get pods его не показывает. Когда Scheduler выбирает ноду для нового Pod, kubelet на этой ноде обеспечивает запуск его контейнеров через контейнерный движок и следит за их состоянием.

Шаг 4. Запускаем первый Pod

В первой статье мы разобрали: Kubernetes запускает контейнеры внутри Pod. Посмотрим на это на примере nginx - веб-сервера.

Выполните:

kubectl run hello-k8s --image=nginx:stable-alpine

Команду можно прочитать так:

Создай Pod с именем hello-k8s и запусти в нём контейнер из образа nginx:stable-alpine.

Здесь --image указывает образ контейнера. Никаких файлов для этого первого запуска нам пока не понадобится.

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

kubectl get pods

Сразу после запуска вы можете увидеть Pending или ContainerCreating: Kubernetes ещё подготавливает Pod и его контейнер. При первой загрузке образа это нормально

Повторите команду через несколько секунд. Ожидаемый результат:

NAME        READY   STATUS    RESTARTS   AGE
hello-k8s   1/1     Running   0          30s

Running показывает, что Pod запущен. 1/1 означает, что единственный учитываемый здесь контейнер отмечен как готовый. Подробно проверки готовности разберём позже; сейчас это ожидаемый результат нашего упражнения.

Ранее мы выполняли kubectl get pods -n kube-system и видели системные поды. Теперь выполняем kubectl get pods - в нашем стенде эта команда показывает поды из namespace default, где создан hello-k8s. API Server и etcd продолжают работать, но находятся в другом namespace и в этот список не попадают

Теперь добавим к команде -o wide:

kubectl get pods -o wide

Это означает «показать больше подробностей». Найдите колонку NODE. У нашего Pod там должно быть:

k8s-first-lab-control-plane

Вот и обещанная проверка: наш Pod работает на той самой ноде с ролью control-plane. Нода у нас одна, так что интриги с выбором не было.

Шаг 5. Связываем результат с теорией

Команда была одна, а работы за ней оказалось немало. Давайте разберём, кто успел поучаствовать в запуске.

1. kubectl отправил запрос в API Server

2. API Server обработал создание объекта Pod, состояние которого сохранилось в etcd

3. Scheduler выбрал ноду для этого Pod

4. kubelet на выбранной ноде обеспечил запуск контейнера через контейнерный движок

Посмотрим, какие сведения о запуске доступны в самом кластере:

kubectl describe pod hello-k8s

describe означает «показать подробную информацию об объекте». Вывода будет много - сейчас найдите только два места:

• Node - назначенная нода;

• Events в конце - события, связанные с Pod.

В событиях обычно можно увидеть сообщения Scheduled, Pulled, Created и Started: нода назначена, образ получен, контейнер создан и запущен. Формулировки и порядок отдельных сообщений могут отличаться; старые события со временем удаляются.

Мы не указывали в команде имя ноды и не запускали на ней контейнер вручную. Компоненты Kubernetes выполнили свои задачи, и теперь результат виден в терминале

Если что-то не получилось

Для первой лабы достаточно нескольких ориентиров:

Если нода долго остаётся NotReady, посмотрите подробности командой kubectl describe node k8s-first-lab-control-plane. Сохраните текст ошибки, если будете обращаться за помощью: он полезнее, чем описание «ничего не работает».

Проверьте себя

Теперь попробуйте повторить несколько действий сами. Если команда забылась, можно подсмотреть - мы пока только знакомимся с kubectl:

1. Покажите ноды кластера и назовите состояние учебной ноды.

2. Найдите Pod с API Server среди системных компонентов.

3. Покажите наш hello-k8s и определите ноду, на которой он работает.

Затем объясните своими словами: кто принимает запрос от kubectl, кто выбирает ноду и кто обеспечивает запуск контейнера на ней?

Если эти роли понятны, цель первой лабы достигнута.

Хотите закрепить практику? В GitHub-репозитории есть дополнительные задания к первой лабе: сравнить пространства имён, разобрать события запуска и самостоятельно создать второй Pod. Попробуйте выполнить их без подсказок, а затем сверьтесь с решениями и пояснениями. Выполняйте задания до удаления учебного кластера.

Что делать с кластером после лабы

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

Если хотите полностью удалить именно этот учебный кластер, выполните:

kind delete cluster --name k8s-first-lab

Вместе с ним удалится и наш Pod. Для повторного прохождения можно снова начать с первого шага.

В следующей лабе перейдём к материалу второй теоретической статьи: опишем приложение в YAML-файле и посмотрим, как Kubernetes поддерживает заданное число его экземпляров.

Материалы лабы на GitHub

Для повторного прохождения удобно держать под рукой папку первой лабы в репозитории: там собраны команды этой лабы и ожидаемые результаты. Попробуйте пройти её ещё раз по короткой памятке, а затем выполнить задания без подсказок.

Если встретили ошибку в инструкции или получили другой результат, создайте Issue в репозитории. Укажите операционную систему, версии Docker, kind и kubectl, команду и полный текст ошибки - так будет проще разобраться и уточнить материал.

Если серия полезна, поставьте репозиторию звезду: так его будет проще найти, когда вернётесь к следующей лабораторной.

Документация

Эти ссылки пригодятся, если захотите подробнее разобраться с инструментами:

• kind - создание локального кластера

• Компоненты Kubernetes

• kubectl run