Что же всё-таки такое kubernetes

Kubernetes (он же K8s) — это ещё одна инструментина для управления контейнерами в кластере. Она решает, в какой части кластера контейнер будет запущен, следит, чтобы его запрошенная конфигурация («запущен», «пять реплик») выполнялась, чтобы у контейнера была сеть и айпишка, настроен доступ извне (если нужно), обновления приходили в нужном порядке, и т.п.

Изначально Kubernetes разрабатывался Гуглом, но те передали его в open source, так что теперь K8s свободен, как бесплатное пиво.

Да, K8s — не замена для Docker. Более того, Докер ему понадобится для, собственно, запуска контейнеров (правда, rkt — ещё один контейнерный движок — для этих целей тоже подойдёт). Чему Kubernetes альтернатива, так это Docker Swarm. Хотя они и используют похожие идеи и терминологию, вроде сервисов, реплик, запрошенной конфигурации и её выполнения, Kubernetes более гибкий, что ли. И, зная, что его папа — Гугл, глупо сомневаться, что K8s потянет кластер любого размера. С другой стороны, как и со всеми остальными детьми гугла (в основном, с API), с K8s сложновато иметь дело. Да и понимать его, местами, нелегко.

K8s может работать как на реальных машинах, так и на виртуалках, нативно в Google Compute Engine и с некоторыми оттенками серого в AWS и Azure. Он даже может работать с Windows Server контейнерами, блин!

Итак, какой будет план. Создадим-ка мы какой-нибудь локальный Kubernetes кластер и осмотримся. Установим в него что-нибудь, пооткрываем страниц в браузере. В общем, ничего сложного, просто посмотрим, на что же он похож, этот ваш Kubernetes.

Что очень сильно понадобится

Очень сильно понадобится VT-x или AMD-v виртуализация, включённая в BIOS. но обычно она включена и так. Всё остальное можно скачать.

Установка

Я обитаю на маке, поэтому все инструкции и скачиваемые пакеты будут для него. Но установка на Windows и особенно на Linux не должна фундаментально отличаться.

В общем, вот, что нам понадобится:

1. kubectl — для запуска команд в кластере.
2. minikube — дла создания кластера.
3. VirtualBox — для жилища кластера.

Установка kubectl и minikube очень простая: скачать, добавить право на запуск, скопировать. Всё выполняется методом копи-пасты команды в терминал.

Kubectl:

Minikube:

Установка VirtualBox тоже удивительно тривиальна.

После того, как всё установилось, можно, наконец, создать кластер при помощи команды minikube start:

Вот теперь можно играться.

Ноды и поды (это не считалка)

На самом верху кластерной иерархии Kubernetes живут две вещи: мастер-сервисы (masters) и работяги-ноды (nodes). Пока мастера управляют кластером и распределяют работу («возьми контейнер тут, запусти там»), работяги послушно кивают и делают то, что им сказали. Ноды — это хосты кластера, на которых в конечном итоге и будут запускаться контейнера.

Так как у нас уже есть какой-никакой кластер, можно, например, спросить Kubernetes, сколько у него нодов. Команда для этого гениальна: kubectl get nodes:

Всего один, но могло быть и хуже.

Если идти дальше по иерархии, то будет вот какой момент. Хотя я уже несколько раз использовал слово контейнер, минимальный юнит работы в Kubernetes кластере на самом деле называется под (pod). Это всего лишь абстракция над контейнером, у которой будет своё имя, айпишка, и внутри которой-таки будет сидеть контейнер. Или два. Или больше. Все контейнеры внутри пода будут делить общую айпишку и могут общаться друг с другом по, например, localhost.

Можно использовать ту же самую kubectl get команду, чтобы посмотреть, какие поды сейчас запущены:

У нас — никакие. Но если посмотреть по всех пространствах имён (--all-namespaces), то будут аж три, созданных самим Kubernetes для своих таинственных нужд. Один из них, kubernetes-dashboard, очень, кстати, интересный.

kubernetes-dashboard

Что здорово, в комплекте с K8s идёт собственный дашборд. Он не только может показать, что сейчас запущено и где, но сможет и поделиться, сколько ресурсов на это уходит, и даже запустить команду-другую. Самый простой способ посмотреть, как он выглядит, это запустить minikube dashboard:

Запускаем первый pod

В каком-то отношении запуск пода очень похож на запуск контейнера в Докер. Та же run команда, то же имя образа на вход и, опционально, номер порта. Но магия происходит совсем другая. kubectl run не разрешит вот просто взять и запустить под. Он создаст deployment, который сам разберётся с запуском. Разберётся и будет следить, чтобы потом с подом не произошло чего. Если тот упадёт, то деплоймент тут же создаст новый.

Создадим чего-нибудь и мы. Какой-нибудь контейнеризированный nginx сервер, например:

Как и в Докер, у K8s есть команды и для описания объектов (kubectl describe), и для запроса логов (kubectl logs nginx-158599303-hq212) и даже для того, чтобы залезть внутрь пода и запустить там что-нибудь (kubectl exec -ti nginx-158599303-hq212 bash):

Если вам показалось, что между предпоследними абзацами айдишка пода изменилась с nginx-158599303-hq212 на nginx-158599303-ffscb, то это не галлюцинация или не иной признак ментального нездоровья. Айдишка действительно поменялась. Просто, чтобы убедиться, что в случае чего деплоймент действительно воссоздаст pod, я вмешался в ход событий командой kubectl delete, и деплоймент действительно заметил потерю пода и завёл себе новый.

Открываем pod миру и сети

Тот pod, что мы создали, он ведь может общаться только внутри сети кластера. А кому это нужно? Но с подключением его к большой сети была бы проблема. Ведь даже если мы настроим проброс портов пода наружу, его деплоймент может же пересоздать под на другой машине. Там тоже, что ли, пробрасывать? А откуда я узнаю, где он теперь? А если он вообще клонирован, и их там десяток?

Чтобы связать точку входа с одной стороны, и непонятное количество  подов с другой, у Kubernetes есть ещё одна абстракция — сервисы (services). Сервис — это прокся. Что в ней интересно, так это способ, которым она находит целевые поды. Если посмотреть ещё раз на вывод команды  kubectl describe pod/nginx-158599303-ffscb, то у пода, оказывается, в описании было поле labels. Метки. Kubernetes добавил их автоматически, но мы могли бы добавить и своих.

И вот какая чёрная магия бывает: сервисы используют метки как фильтр «своих» подов. Те могут быть даже созданы из разных образов, nginx и httpd, например. Сервису плевать. Если мы создадим сервис через kubectl expose команду, то K8s скопирует начальный набор меток для фильтра прямо из deployment:

Мы использовали «NodePort» тип сервиса, чтобы тот привязывал внутренний порт пода к внешнему порту нода. Но можно было бы использовать «ClusterIP», чтобы сервис не высовывался из внутренней сети кластера, или «LoadBalancer», чтобы использовать балансировщик нагрузки облачного провайдера (если тот поддерживает), или даже «ExternalName», чтобы подключить к сервису магию DNS.

Описание сервиса содержало внешний номер порта (32543), так что заполучив к нему в пару айпишку самого нода, в теории можно, наконец, обратиться к поду с nginx извне:

Теория сработала, и теперь у нас есть под в кластере, к которому можно достучаться снаружи.

Убираем кластер назад

Есть ещё много вещей, с которыми можно поэксперементировать в Kubernetes кластере, но как только это всё надоест, кластер можно прибить одной-единственной командой:

Итого

Хочется верить, что эти нехитрые эксперименты хоть немного показали, на что же похож Kubernetes. Конечно, в продакшене мы бы не запускали поды по одному и точно не руками — есть YAML конфигурации для этого. Да и взаимодействие контейнеров и их обновление мы не тронули вообще никак. Но откуда-то же надо начинать, так что почему бы не с кластера из одной машины, и пода с бессмысленным сервером внутри.