Сегодня мы поговорим о Kubernetes: в частности о теме microk8s vs minikube, kompose и helm. Обзорная экскурсия, так сказать.

Написать статью о kubernetes (он же k8s или просто куб) руки у меня чесались уже довольно давно. Я активно работаю с ним уже больше года. Делится конкретным опытом внедрений в рамках данной статьи цели у меня не стоит, однако я опишу некоторые моменты на обучающих примерах. Так будет более последовательно и понятно. Можно назвать данный материал обзорным, который рассчитан на читателя, не знакомого с k8s. Однако я убежден, что каждый здесь сможет что-то для себя интересное, особенно в знакомстве с microk8s. Начнем с оглавления:

• МикроКуб или МиниКуб? (microk8s vs minikube)
• Пощупайте самостоятельно
• Kompose, что еще за зверь такой
• Конфиги для deployment, service, pvc и запуск
• Конфиги для ingress, service и внешний доступ
  • NodePort
  • Ingress (поддиректория)
  • Ingress (поддомен)
• Helm
• Итоги

Вообще, знакомство с кубом стоит начинать из далека. С docker и плавным переходом на docker-compose. Посему, рекомендую ознакомится с моими предыдущими статьями на данные темы:

• Dockerfile, создаем свой контейнер
• Docker Compose или знакомство с родителями

Следущий этап, это теория. Следует начать с обзорной экскурсии (overview) на офф.сайте. Там доходчиво объясняют все базовые вещи по пунктам, с примерами. Поиграться с виртуальной консолью даже можно в katacoda. Однако, из всех многочисленных обзорных статей на Хабре, увы ни одного по настоящему доходчиво изложенного материала я порекомендовать не могу. Однако в блоге одного нашего коллеги есть весьма годная статья на Dots and Brackets, написанная понятным человеческим языком. С ней я рекомендую ознакомится сразу после обзорного курса по офф.докам.

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

МикроКуб или МиниКуб? (microk8s vs minikube)

Врятли у вас сразу в распоряжении окажется полноценный кластер K8s для экспериментов. И сразу возникнет вопрос что поставить у себя локально, или на отдельном одном сервере. Офф.доки рекомендуют для этого использовать minikube (Миникуб) и он часто многими используется в качестве примера. Я сам с ним тоже работал, однако minikube мне не понравился тем, что это все таки виртуальная машина. Для ее работы нужно “откусывать” часть ресурсов и использовать гипервизор (VirtualBox или KVM). Вы можете еще поспешить и возразить, что мол, есть же режим “–vm-driver=none”! Как видите, количество потенциальных косяков там внизу (перейдите по ссылке выше) просто зашкаливает, не говоря уже просто про root доступ контейнеров в хост системе. В общем, minikube в таком режиме мне не понравился. А гипервизоры я не особо жалую (хотя некоторые на KVM с драйверами virtio заслуживают уважения). Поэтому не minikube, а microk8s.

MicroK8s (он же МикроКуб) это продукт любимой нами Canonical, поэтому он уже по умолчанию является православным. Его мы и будем использовать!) Не, это шутка конечно, помимо религиозных предубеждений, здесь еще есть и целый ряд преимуществ (у microk8s):

• использует только необходимые ему ресурсы и не каплей больше
• полностью масштабируем в пределах одной wordstation или даже целого server (в описании новых версий значится даже “clustering” в статусе “beta”.. недавно вот еще документации появились заметки о кластеризации нескольких microk8s, но я этот функционал еще не успел протестировать)
• легкая и простая установка в Ubuntu через snap, хваленая изоляция snap пакетов, возможность легкого отката на предыдущую версию
• наличие аддонов, в этом плане он очень похож на minikube
• более нативный опыт работы с инструментарием K8s, ведь в minikube есть целый ряд specific-только-для-него команд

Далее, переходим в офф.доки microk8s, устанавливаем и настраиваем его. Дополнительно, есть еще и офф.tutorials, где подробно все расписано по пунктам.

У меня же свежая установка выглядит следующим образом (про аддоны сами почитайте, можно их и больше поставить):

sudo microk8s.enable dns storage ingress
sudo snap alias microk8s.kubectl kubectl
alias kubectl='microk8s.kubectl'
sudo microk8s.stop
sudo microk8s.start
sudo microk8s.status
sudo microk8s.inspect

Как видите, командой alias вы делаем линк с внутреннего приложения microk8s.kubectl в kubectl. Это конечно же актуально, если у вас отдельно не стоит kubectl. Если стоит,то можете подключить его следующим образом:

microk8s.kubectl config view --raw > $HOME/.kube/config

Актуальная версия microk8s на момент написания статьи: 1.16.3 (1079).

Еще тут в параметрах CoreDNS я прописываю локальные DNS адреса, для корректного resolve внутренних ресурсов в сети. Также обратите внимание на результат по командам “status” и “inspect”. MicroK8s там обычно требует еще прописать ему правило в iptables для доступности его сервисов за пределами нашего workstation/server.

Пощупайте самостоятельно

Это как с сиськами, картинки и видео, наблюдение издалека.. это одно дело. А вот щупать своими руками, это уже совсем другие ощущения.. Так вот, в k8s работать с объектами можно по разному:

• Императивные команды (Imperative commands) – последовательный ввод команд для создания объектов. По образу и подобию очень похоже на работу с docker.
• Императивные объекты (Imperative object configuration) – скармливание кубу .yaml конфигов с параметрами объектов. Похоже на docker-compose.
• Декларативные объекты (Declarative object configuration) – скармливание кубу целых директорий с .yaml конфигами различных объектов внутри. Это не похоже не на что другое, но это самый смак и true-way.

Подробнее об этом можно почитать в доках на офф.сайте. Поэксперементируйте самостоятельно с командами, попробуйте найти готовые .yaml конфиги на Github и скормите их k8s через kubectl. Это очень удобный и мощный инструмент, что позволяет применять конфиги различными способами, даже напрямую по ссылке (при наличии доступа в Инет).

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

Kompose, что еще за зверь такой

Как следует из названия, Kubernetes + Compose = Kompose. Эдакая ядреная утилита, которая позволяет запускать сервисы в k8s из конфигов docker-compose, или же конвертировать их в готовые конфиги k8s (а потом уже запускать их вручную, предварительно проверим и модифицировав). Конечно, стоит сразу сказать, что Kompose преследует скорее демонстративно-обучающие цели. Однако, он подойдет и для быстрого переноса существующих проектов на docker-compose. На офф.сайте смотрите варианты установки и базового использования. Актуальная версия kompose на момент написания статьи: 1.19.0 (f63a961c).

Итак, давайте рассмотрим все это на примерах. Возьмем docker-compose.yml из моей предыдущей статьи про docker-compose. У меня это лежит в $HOME/kompose/wordpress. Можно сразу создать такую же иерархию и напрямю скачать командой:

mkdir $HOME/kompose
mkdir $HOME/kompose/wordpress
cd $HOME/kompose/wordpress
curl -LO https://darkfess.ru/wp-content/uploads/2019/12/plus/docker-compose.yml

Далее, меняем версию манифеста у конфига docker-compose.yml:

sed -i 's/version: "3.7"/version: "3"/g' $HOME/kompose/wordpress/docker-compose.yml

Теперь сгенерируем на базе этого конфиги для k8s:

kompose convert

Увидим соответствующее сообщение вида:

INFO Kubernetes file "df-phpmyadmin-service.yaml" created
INFO Kubernetes file "df-wordpress-service.yaml" created
INFO Kubernetes file "df-maria-deployment.yaml" created
INFO Kubernetes file "df-mariadata-persistentvolumeclaim.yaml" created
INFO Kubernetes file "df-phpmyadmin-deployment.yaml" created
INFO Kubernetes file "df-wordpress-deployment.yaml" created
INFO Kubernetes file "wp-content-persistentvolumeclaim.yaml" created

Создадутся эти конфиги, вот они наглядно:

df-maria-deployment.yaml
df-mariadata-persistentvolumeclaim.yaml
df-phpmyadmin-deployment.yaml
df-phpmyadmin-service.yaml
df-wordpress-deployment.yaml
df-wordpress-service.yaml
wp-content-persistentvolumeclaim.yaml

Есть также одна волшебная команда в kompose (up), которая позволяет запустить все сервисы сразу без генерации конфигов:

kompose up

..но срабатывает в текущих версиях сходу она очень редко или для слишком уж тривиальных примеров. Вероятно проблема тут у него именно с новой версией k8s 1.16, с 1.15 и более ранними чаще отрабатывало корректно. Удалить все что насоздавал up, можно с помощью, соответственно, down:

kompose down

Конфиги для deployment, service, pvc и запуск

После convert, конфиги мы получили и теперь надо их отредактировать. В версии 1.16 k8s (а у нас в microk8s идет самая свежая стабильная), отключили старые “apiVersion: extensions/v1beta1” поэтому теперь нам надо все их заменить на актуальные “apiVersion: apps/v1”. Тут обойдемся sed`ом:

sed -i 's/apiVersion: extensions\/v1beta1/apiVersion: apps\/v1/g' $HOME/kompose/wordpress/*

После этого можно попробовать стартануть, но теперь будет ругатся на поле “selector” которое также необходимо добавить в новой версии. Мне лень писать мульти-строчное регулярное выражение, поэтому давайте просто сделаем это ручками. Необходимо в конфигах *-deployment между строк “strategy: {}” и “template:” аккуратно вставить параметр (не забывайте про форматирование .yaml файлов, уровни и никаких TAB-ов.. label используем уже прописанный kompose):

   selector:
     matchLabels:
       io.kompose.service: <имя>

Также я внес некоторые правки в *-services: поменял порты для красоты (теперь 80:80). А еще, чтобы уж наверняка, прописал полные имена сервисов в переменных (это вида df-maria.default.svc.cluster.local). Создал дополнительный конфиг и сервис для доступа к базе (df-maria-service.yaml) по ее дефолтному порту 3306.

Все. После этого выполняем команду на запуск “всего”:

kubectl apply -f $HOME/kompose/wordpress

Если вам влом было проходить все эти шаги, можете сразу скачать и запустить готовый конфиг для всего* (df-wordpress-all.yaml):

kubectl apply -f https://darkfess.ru/wp-content/uploads/2019/12/plus/df-wordpress-all.yaml

*если интересно как собрать один большой конфиг из нескольких, то тут можно воспользоватся ‘kubectl kustomize’ и подложить ему соответствующий конфиг: kustomization.yaml

А вот и каждый конфиг по отдельности:

• df-maria-deployment.yaml
• df-maria-service.yaml
• df-mariadata-persistentvolumeclaim.yaml
• df-phpmyadmin-deployment.yaml
• df-phpmyadmin-service.yaml
• df-wordpress-deployment.yaml
• df-wordpress-service.yaml
• wp-content-persistentvolumeclaim.yaml

Проверить статус можно, допустим, так:

kubectl get deploy,svc,pods

После чего, если microk8s запущен локально, мы уже можем получить доступ к сервисам по их внутреннему IP (тип ClusterIP). Выглядит нам нужная строка так:

service/df-wordpress ClusterIP 10.152.183.138 <none> 80/TCP 10m

Таким образом, вбив в браузере адрес сервиса для wordpress, вы увидите что он доступен для первичной настройки (по 80 порту, соответственно).

А перейдя по адресу сервиса для phpmyadmin, авторизовавшись (по параметрам env из переменных в конфигах), мы сразу получаем доступ к нашей БД:

Конфиги для ingress, service и внешний доступ

Хм, теперь нам нужен внешний доступ к wordpress или phpmyadmin. Тут есть несколько вариантов, но мы рассмотрим три основных:

• порт (правка service на NodePort)
• поддиректория (через ingress)
• поддомен (через ingress)

Важный момент, дальше я буду в качестве примера для внешнего доступа показывать phpmyadmin вместо wordpress. Т.к. wordpress держит параметр своего адреса в БД, и постоянно редиректит на него. По сути как бы держит его захардкоженым, что неудобно в нашем случае, т.к. мы будем переключать его туда-сюда. Мне лень с этим бодатся и каждый раз менять адрес (это пункт в настройках и параметр в БД), и лень искать способ обхода этого на стороне WP. Кто хоть когда-нить мигрировал wordpress знает о чем я говорю. Короче говоря, поэтому показываем на phpmyadmin, он не такой капризный.

NodePort

Самый простой способ. Но и достаточно кривой, подойдет когда надо быстро что-то пробросить, особенно для тестовых целей. В нашем распоряжении только диапазон портов 30000:32767. Можно отредактировать оригинальный конфиг в -service, но мы для наглядности и удобства сравнения, просто создадим еще один -service-nodeport. Это не добавит еще один сервис, просто отредактирует настройки текущего. Но у нас останется оба конфига на руках, старый и новый (можно все вернуть назад в любой момент, просто применив старый конфиг). Применяем:

kubectl apply -f $HOME/kompose/wordpress/df-phpmyadmin-service-nodeport.yaml

Либо (df-phpmyadmin-service-nodeport.yaml):

kubectl apply -f https://darkfess.ru/wp-content/uploads/2019/12/plus/df-phpmyadmin-service-nodeport.yaml

При просмотре статуса через kubectl get svc, увидим проброс:

service/df-phpmyadmin NodePort 10.152.183.211 <none> 80:30090/TCP 15m

Теперь phpmyadmin доступен из вне по порту (как по localhost, так и по IP нашего wordstation/server):

Итак, по порту пробрасывать мы научились.

Ingress (поддиректория)

Вообще, если крутить яйца ingress, то можно получить много чего интересного. Мы же рассмотрим в данном примере, чтобы можно было размещать разные сервисы в поддиректориях главного домена. Это будет выглядеть, например, как то так: darkfess.ru/service1,  darkfess.ru/service 2 и т.д. Не очень красивое решение, но зато можно быстро что-то прикрутить без дополнительных настроек DNS, ожидания его синхронизации и т.д (однако один раз вам, все же, придется DNS настроить на основном домене). Минусы тоже есть, некоторые сервисы могут держать в себе какой то захаркоженный путь и попросто не будут работать в поддиректории или будут работать криво.

Ну да ладно, поехали (для справки, я тестирую локально, поэтому сделал соответтвующую запись в /etc/hosts про FQDN darkfessus.ru)

kubectl apply -f $HOME/kompose/wordpress/df-ingress-path.yaml

Либо (df-ingress-path.yaml):

kubectl apply -f https://darkfess.ru/wp-content/uploads/2019/12/plus/df-ingress-path.yaml

Ага, здесь видим что то не так. Ошибка 404:

Запрос к phpmyadmin уходит и мы можем проверить это через логи (но phpmyadmin не понимает что это за адрес такой /phpmyadmin, потому что сам он работает в корне /):

kubectl logs deployment.apps/df-phpmyadmin -f

Нужно “помочь Даше найти дорогу, давайте все вметсе позовем Карту!” (с) Как мы и делали раньше, применяем другой конфиг ingress с тем же name и модифицируем его настройки (здесь появляется режим rewrite, и это функционал nginx, как вы уже наверное догадались):

kubectl apply -f $HOME/kompose/wordpress/df-ingress-path-rewrite.yaml

Либо (df-ingress-path-rewrite.yaml):

kubectl apply -f https://darkfess.ru/wp-content/uploads/2019/12/plus/df-ingress-path-rewrite.yaml

Теперь все. Вуаля! Заработало на поддиректории:

Подробнее об режиме rewrite можно почитать в офф.доках

Ingress (поддомен)

Это, пожалуй, мой самый любимый способ. Он самый красивый, через поддомены сервисы выглядят очень окультуренными, по типа такого: service1.darkfess.ru, service2.darkfess.ru. Прописываем DNS записи на нужные сервисы, прописываем конфиг ingress – и пли! Все красиво, никаких портов, никаких лишних хвостов в виде поддиректорий и прочего.

Ну да ладно, поехали (для справки, я тестирую локально, поэтому сделал соответтвующую запись в /etc/hosts про FQDN svc1.darkfessus.ru):

kubectl apply -f $HOME/kompose/wordpress/df-ingress-fqdn.yaml

Либо (df-ingress-fqdn.yaml):

kubectl apply -f https://darkfess.ru/wp-content/uploads/2019/12/plus/df-ingress-fqdn.yaml

Вот теперь все. Заработало на поддомене:

На этой ноте пожалуй наш экскурс по ingress закончим. Я показал лишь часть его возможностей, есть еще и множество его различных контроллеров. Кроме NodePort, Ingress есть еще и тип сервиса LoadBalancer (Network Load Balancer). Мы его здесь не рассматривали, и его обзор не входит в рамки данной статьи.

Подводя итоги по Ingress хочется сказать, что это очень мощный и очень гибкий инструмент, в который по настоящему влюбляешься. Он просто значительно упрощает жизнь. Чтобы вывести WordPress через ingress, придумайте ему и пропишите DNS запись в виде поддомена. Потом зайдите через phpmyadmin и поменяйте эти параметры в базе на свой FQDN соответственно:

Helm

Пройдя весь этот путь до конца, вы наверное нехило так подзаебались… и возникает вполне логичный вопрос, а нельзя ли попроще? Можно! Дело в том, что здесь я взял wordpress+phpmyadmin+mariadb как хороший пример из уже написанной мной ранее статьи. По сути все это те компоненты, на которых работает мой блог. Мы его взяли, прежде всего, в обучающих целях, чтобы во всем хорошенько разобратся. Но, конечно же, можно сделать проще. Особенно когда дело касается каких то известных продуктов или сервисов.

У k8s есть свой package manager. Да-да, вы не ослышались. У “куба” есть свой менеджер пакетов, который позволяет с легкостью пера ставить огромные тяжеловестные продукты. И там, конечно же, есть и WordPress и многое другое.

На офф.сайте вы можете почитать описательную часть документации. А также, изучить местный Hub. Текущая версия Helm состоит из 2-х частей, клиентская часть (собственно, сам helm) и tiller (компонент, который устанавливается в k8s). Устанавливается все как обычно, через snap:

sudo snap install helm --channel=2.16/stable --classic

Вот и все. Дальше собственно устанавливаем компонент tiller в k8s:

helm init

Обновить его можно такой же командой с флагом –upgrade. Маленькая шпаргалка по использованию:

helm version
helm list
helm del <имя> --purge

Обратите внимание также и на совместимость версии k8s с каждой актуальной версией Helm. Я столкнулся с этим совсем недавно, когда вышла версия k8s 1.16, helm тогда без шаманств не работал. Ну а что дальше? Дальше идите на HelmHub, ищите нужный софт и ставьте его по инструкции внутри. Помимо официальных, очень много готовых собранных образов идет от bitnami, например. Идите в Hub, там есть что посмотреть.

Собственно, на этом пожалуй, этот краткий обзор по Helm я закончу. А все потому, что скоро выйдет новая мажорная версия Helm 3.0, и она принесет в себе множество новых изменений. Одной из основных будет отказ по Tiller. но это уже совсем другая история, может быть я лучше на нее отдельный обзор напишу.

Итоги

Не люблю я писать эпилоги. Будут ли еще статьи про k8s? Очевидно, что да.  А так, данный материал получился довольно большого объема, да и писал я его достаточно долго. Бесят бессконечные редактирования! Но в целом.. хочется верить, что данный материал окажется вам полезен в понимании k8s и работе с ним. В частности с microk8s, если вы с ним еще не знакомы. Ведь это чрезвычайно удобная и крутая штука, на которой спокойно можно построить все, пожалуй, кроме серьезных больших production сред. Но зато можно сделать переезд на этот самый “бАльшой” prod максимально безшовным.