☸️ Локальные Kubernetes для Linux – MiniKube или MicroK8s
В этой статье мы сосредоточимся на Linux.
MiniKube все еще остается здесь конкурирующим соперником.
Но еще мы рассмотрим MicroK8s, единственное решение для Linux для легкого локального кластера Kubernetes.
Мы оценим эти решения и предоставим краткое сравнение, основанное на простоте установки, развертывании и управлении.
Minikube
Установка
Чтобы установить Minikube на Linux, вы можете выполнить шаги, описанные в официальной документации.
В нашей статье мы использовали Ubuntu 18.04 LTS с поддержкой VirtualBox, используя следующие команды:
Управление и развертывание
Управление кластером Minukube в Linux – это то же самое, что управление им в Windows.
Microk8s
Microk8s – это новое решение для запуска легкого локального кластера Kubernetes.
Он был разработан командой Kubernetes в Canonical.
Он предназначен для быстрой и легкой установки потока Kubernetes, изолированной от вашей локальной среды.
Эта изоляция достигается за счет упаковки всех двоичных файлов для Kubernetes, Docker.io, iptables и CNI в единый пакет Snap (доступен только в Ubuntu и совместимых дистрибутивах).
Установив Microk8 с использованием snap, вы можете создать «чистое» развертывание последних версий Kubernetes на локальном компьютере без каких-либо дополнительных затрат.
Инструмент Snap выполняет все необходимые операции и может обновить все связанные двоичные файлы до последних версий.
По умолчанию Microk8s устанавливает и запускает следующие службы:
Установка
Microk8s можно установить одной командой snap, прямо из хранилища Snap.
Разворачиваем Kubernetes на десктопе за несколько минут с MicroK8s
Начать работать с Kubernetes не всегда бывает просто. Не у всех есть необходимая для разворачивания полноценного кластера Kubernetes инфраструктура. Для локальной работы Kubernetes предлагет утилиту Minikube. Minikube — достаточно простое и удобное средство, и есть несколько обучающих курсов по работете с Minikube. Но, все же, о Minikube нельзя сказать, что с помощью этой утилиты можно за несколько минут развернуть среду Kubernetes.
Сегодня я хочу рассказать о пакете MicroK8s, который без преувеличения позволяет развернуть Kubernetes локально за несколько минут, и начать разработку. Не требуется даже предустановленных Docker и Kubernetes, т.к. все включено. В предлагаемом Вам уроке будет рассмотрен деплой приложения Django в локальной среде Kubernetes.
В качестве источника я шел вслед за серией статей Mark Gituma, в которых описана аналогичная работа, но только с Minikube, а не с MicroK8s.
Все же есть одно требование, которое необходимо удовлетворить до начала работы. У Вас должен быть установлен Snap, что в свою очередь означает, что у Вас должен быть установлен Linux.
Установка MicroK8s описана в руководстве на сайте. Впрочем, это всего одна строчка:
Далее, возможно, будет необходимо стартовать среду:
Как Вы уже сейчас можете заключить по списку расширений, у Вас будет доступ ко многим сервисам, в том числе к dashboard и метрикам.
Создадим Dockerfile для создания образа:
и файл с необходимыми зависимостями requirements.txt:
Соберем образ. Для этого не нужен предустановленный Docker, т.к. он поставляется c MicroK8s:
Если Вы собираете образ раннее установенным докером, возможно Вам будет недостаточно просто собрать образ, а еще дополнительно отправить в локальный реестр, который также поставляется с MicroK8s, и работет на порту 32000:
Скорее всего этот шаг будет не нужен, но для полноты я указал на него, и заодно обратил Ваше внимание, что у Вас есть локальный реестр докера.
Базовым строительным блоком Kubernetes является Pod (Под), в котором работает контенйер (чаще всего один но может быть и несколько). Поды могут создаваться разными средствами. Но нас сегодня интересует Deployment (Деплоймент). Деплоймент описывает шаблон по которому создаются Поды. Деплоймент определяется при помощи файлов конфигрураций в формате yml. В конфигурации Деплоймента Вы указываете количество реплик Пода и образ, из которого этот Под и его реплики будут собираться, а также порт (порт 8000 на котором работет Django из Dockerfile — никакой магии):
Депоймент загружается в среду командой:
Параллельно Вы можете запустить команду, которая будет мониторить происходящие при деплойменте действия:
Теперь у Вас есть несколько Подов с приложениями Django, к которым нет доступа. Для того, чтобы Поды могли общаться между собой и с внешним миром, существует еще одна абстракция — это Сервис. Сервис, как и Деплоймент, определяется файлом конфигурации:
Селектор pod: django-container определяет, какой именно Деплоймент будет обслуживаться Сервисом (имя селектора «pod» не является предопределенным — это всего лишь метка котороая должна совпасть). Загружается сервис аналогично Деплойменту:
Выполнив команду curl (или открыв браузер) мы получим приветсвенную страничку Django:
В конфигурации Сервиса есть две закомментированные строчки. Если их раскомментировать, то сервис дополнительно будет доступен из внешней сети по случайному порту в диапазоне от 32000 и выше.
Для того чтобы получить постоянный адрес для Сервиса, по котрому можно будет обращаться из вешней сети, в MicroK8s предлагается на выбор два варианта 1) ingress и 2) istio. Проще всего реализовать при помощи ingress. Если еще не активизирован, то нужно активизировать компнент ingress:
Имя default-http-backend — предопределенное имя в MicroK8s. Именно по этому имени необходимо ссылаться на этот сервис в конфигурациях ingress.
Конфигруации ingress напоимнают конфигруации веб-сервера или прокси-сервера, и где-то там внутри системы, ими и являются. Поэтому в них присутсвуют хосты, пути и порты — все атрибуты, которые хорошо знакомы:
Загружается конфигруация ingress командой:
После чего, приветственная страница Django будет доступна по адресу localhost/django
Kubernetes в миниатюре для локального запуска: k0s, MicroK8s, kind, k3s и Minikube
Тех, кто работал с Kubernetes, вряд ли удивит ситуация, когда внезапно пришла идея по автоматизации, унификации, преобразованию чего-либо в кластере, но так, чтобы не волноваться за конечный результат. Когда возникает потребность в какой-то песочнице, чтобы провести тестирование, проверить гипотезу «на коленке», не используя рабочий Kubernetes-кластер.
В таких случаях приходят на помощь «мини-кластеры». Их можно запустить на рабочем ПК, «поиграться» с примитивами, построить новую структуру, а после завершения эксперимента — безвозвратно удалить (ведь это уже отработанный материал).
Отвечая на эту потребность, разработчики со всего мира пришли со своими решениями для быстрого запуска облегчённого варианта Kubernetes. Все они по-разному организованы и, конечно, обладают разными возможностями. Чем пользоваться, зависит от нужд и предпочтений. Чтобы получше разобраться в них или вообще понять, с чего стоит начать, предлагаем результаты нашего беглого знакомства с некоторыми популярными решениями. Благо, все они достаточно хорошо документированы (как на сайтах, так и в CLI), что существенно ускоряет первое погружение и взаимодействие с ними. В конце статьи будет сводная таблица с основными особенностями решений.
Обзор
1. k0s
Первый коммит: июнь 2020
Основной разработчик: Mirantis
Поддерживаемые версии K8s: 1.20 и 1.21
Название проекта (произносится как «kziros») говорит само за себя: тяжело придумать систему меньше, т.к. настройку и дальнейшую работу с кластером обеспечивает самодостаточный (собранный статически) бинарный файл, а его установка состоит в получении актуальной версии из репозитория проекта. Файл скомпилирован под Linux — соответственно, работа кластера возможна только в этой системе (подробнее о поддерживаемых хост-системах см. в конце обзора). Для полноценного запуска необходимо обладать правами суперпользователя.
После незатейливой установки файла (он помещается в /usr/local/bin ) вспомогательным скриптом нужно запустить службу, которая позволит нашей системе выполнять функцию узла кластера (по умолчанию это master):
Взаимодействие с Kubenetes API осуществляется с помощью встроенного kubectl :
За работу контейнеров в Pod’ах отвечает containerd. К Pod’ам можно подключить тома типа HostPath. В качестве CNI по умолчанию используется Calico, на выбор из коробки также предлагается и kube-router, но можно настроить любой другой: ограничений на настройку собственно Kubernetes нет.
Для удобства работы в консоли предусмотрены готовые наборы для автодополнения в разных оболочках: Bash, zsh, fish, PowerShell (через WSL).
k0s максимально аскетичен: это ванильный Kubernetes без каких-либо готовых модулей и плагинов. По умолчанию в нём нет поддержки облачных провайдеров, но её можно добавить при запуске. Устанавливать ПО нужно по аналогии с обычным кластером Kubernetes — через объявление необходимых примитивов (возможно, с применением Helm и подобных инструментов).
2. MicroK8s
Основной репозиторий на GitHub: ubuntu/microk8s
Первый коммит: май 2018
Основной разработчик: Canonical
Поддерживаемые версии K8s: 1.19—1.21
В качестве CNI по умолчанию также используется Calico. Для запуска потребуются права суперпользователя. Но поставляется продукт в виде пакета snap и официально поддерживает работу в 42 разновидностях Linux:
После установки остаётся только запустить кластер:
Весьма полезным может оказаться набор дополнений, который позволяет с помощью одной команды установить, например, Kubernetes dashboard:
По аналогии включается внутренний container registry, который может использоваться как библиотека образов для контейнеров.
3. kind
Первый коммит: сентябрь 2018
Основной разработчик: Kubernetes SIG
Поддерживаемые версии K8s: 1.21
Название этого дистрибутива представляет собой аббревиатуру: Kubernetes in Docker. Установка совершенно бесхитростна: нужно просто скачать выполняемый файл.
Для создания кластера достаточно обладать правами на создание контейнеров и сетей Docker. После установки и создания кластера ( kind create cluster )* появляется узел, представляющий собой контейнер Docker, внутри которого находятся другие контейнеры:
* При установке создаётся сеть Docker. В случае, если установка не удалась из-за ошибки:
. следует проверить наличие в системе процесса OpenVPN и остановить его на время установки. После завершения установки можно запустить вновь.
Также во время создания кластера производится настройка конфига kubectl для доступа к API. Настройка кластера более сложной конфигурации может быть осуществлена только в момент создания с помощью конфига. Например, для создания кластера, состоящего из трёх узлов:
Поскольку узел представляет собой Docker-контейнер, объявление томов HostPath в Pod’ах приведёт к использованию файловой системы контейнера, каталог на которой, в свою очередь, можно пробросить на ФС родительской ОС. Есть возможность загружать Docker-образы с управляющего хоста на узлы кластера. Плагинов, дополнений нет.
В качестве CNI по умолчанию — собственное решение kindnetd, — но возможно и использование других плагинов. Хотя поддержка этой фичи называется ограниченной, «многие популярные CNI-манифесты работают, например, Calico».
4. k3s (и k3d)
Контрибьюторов: 1750+ (50+)
Первый коммит: январь 2019 (апрель 2019)
Основной разработчик: CNCF (Rancher)
Поддерживаемые версии K8s: 1.17—1.21
k3s — дистрибутив от Rancher, название которое сделали «меньше», чем K8s, чтобы подчеркнуть его легковесность и простоту (пусть и с меньшим функционалом). Общая идея схожа с k0s и MicroK8s. После запуска в системе k3s он становится узлом кластера с одной из двух возможных ролей:
сервер, выполняющий функции master’а: API server, scheduler и controller manager, — с БД в виде SQLite;
агент, выполняющий функции рядового узла Kubernetes: kubelet и containerd, управляющий запуском контейнеров CRI-O.
С целью уменьшения размера исполняемого файла при сборке исключены большинство драйверов для работы с дисками и драйверы облачных провайдеров. За счёт того, что он содержит в себе сразу несколько составляющих классического Kubernetes, более экономно расходуется оперативная память.
В «вырожденном» случае для запуска кластера в составе единственного узла можно использовать Docker Desktop без систем полноценной виртуализации.
Помимо собственно дистрибутива существует также k3d — утилита, управляющая узлами k3s, каждый из которых помещён в контейнер Docker. Она устанавливается на систему с Linux с помощью Bash-скрипта.
Для запуска кластера достаточно обладать правами на создание контейнеров и сетей Docker.
Кластер создаётся одной командой**:
** См. выше примечание про создание сети Docker при установке и возможную ошибку из-за процесса OpenVPN. Только текст ошибки в данном случае будет другим:
Failed Cluster Preparation: Failed Network Preparation: Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network
Под каждый узел кластера выделяется свой контейнер плюс ещё один — служебный с nginx, который выполняет роль балансировщика нагрузки. В качестве CNI используется Flannel, а ingress — Traefik. Предусмотрена возможность выбора других CNI — например, в документации есть особые инструкции для Calico и Canal. Поддерживается автодополнение для Bash, zsh, fish, PowerShell.
Предусмотрена возможность управления репозиториями образов: создавать свои репозитории в кластере, импортировать образы из основной системы. Это может сослужить хорошую службу при локальной разработке образов Docker, т.к. они будут доступны в кластере сразу после сборки.
5. Minikube
Первый коммит: апрель 2016
Основной разработчик: Kubernetes SIG
Поддерживаемые версии K8s: 1.11—1.22
Инсталляция Minikube в Linux-дистрибутивах, базирующихся на Debian и Red Hat, сводится к установке соответствующего пакета. Пользователь, который не обязан быть root (но должен обладать правами, достаточными для настройки выбранной системы виртуализации), может создать кластер одной командой:
В рамках локальной ОС Minikube создаёт систему smth1-in-smth2, где:
smth1 — одно из значений: docker, cri-o, containerd;
smth2 — одно из: virtualbox, vmwarefusion, kvm2, vmware, none, docker, podman, ssh.
Также можно выбрать CNI:
Можно добавить необходимое количество узлов на той же физической машине:
А посмотреть текущее состояние кластера — командой minikube status :
При необходимости подключения внешних каталогов с большим количеством файлов 9P может работать нестабильно. Выйти из этого положения помогут возможности подключения ФС, предоставляемые системами виртуализации (VirtualBox, KVM, VMware).
В minikube есть дополнения, которые легко активировать в кластере:
Аналогично можно включить registry, ingress, Istio и многие другие компоненты.
Поддерживается параллельная работа с несколькими кластерами, использующими разные профили:
6. Альтернативные решения
Существуют также и некоторые другие проекты, не попавшие в этот обзор из-за их меньшей популярности или по другим причинам. Например, есть проект Red Hat CRC (CodeReady Containers;
750 звёзд на GitHuB), пришедший на смену Minishift для запуска минимального кластера OpenShift 4.x на лаптопе/десктопе.
По-своему интересен Firekube от Weaveworks — Kubernetes-кластер, работающий в виртуальной машине Firecracker. Однако его разработка больше не выглядит активной.
Где всё это запускать
Все упомянутые дистрибутивы работают в Linux. Но если в распоряжении находится другая ОС, можно обойтись виртуализацией:
В частных случаях — другие средства виртуализации, такие как, например, WSL на Windows.
Для kind, k3d, Minikube в минимальном варианте будет достаточно создания одной ВМ с Linux, а для k0s, Microk8s, k3s — по числу узлов кластера.
DarkFess
Персональный сайт
Знакомство с MicroK8s (+ kompose, helm)
Сегодня мы поговорим о Kubernetes: в частности о теме microk8s vs minikube, kompose и helm. Обзорная экскурсия, так сказать.
Написать статью о kubernetes (он же k8s или просто куб) руки у меня чесались уже довольно давно. Я активно работаю с ним уже больше года. Делится конкретным опытом внедрений в рамках данной статьи цели у меня не стоит, однако я опишу некоторые моменты на обучающих примерах. Так будет более последовательно и понятно. Можно назвать данный материал обзорным, который рассчитан на читателя, не знакомого с k8s. Однако я убежден, что каждый здесь сможет что-то для себя интересное, особенно в знакомстве с microk8s. Начнем с оглавления:
Вообще, знакомство с кубом стоит начинать из далека. С docker и плавным переходом на 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):
Далее, переходим в офф.доки microk8s, устанавливаем и настраиваем его. Дополнительно, есть еще и офф.tutorials, где подробно все расписано по пунктам.
У меня же свежая установка выглядит следующим образом (про аддоны сами почитайте, можно их и больше поставить):
Как видите, командой alias вы делаем линк с внутреннего приложения microk8s.kubectl в kubectl. Это конечно же актуально, если у вас отдельно не стоит kubectl. Если стоит,то можете подключить его следующим образом:
Актуальная версия microk8s на момент написания статьи: 1.16.3 (1079).
Еще тут в параметрах CoreDNS я прописываю локальные DNS адреса, для корректного resolve внутренних ресурсов в сети. Также обратите внимание на результат по командам “status” и “inspect”. MicroK8s там обычно требует еще прописать ему правило в iptables для доступности его сервисов за пределами нашего workstation/server.
Если у вас нет возможности или желания настраивать кластер Kubernetes самостоятельно на своем железе, можете купить его в готовом виде как сервис в облаке Mail.ru Cloud Solutions: https://mcs.mail.ru/easy-k8s/
Пощупайте самостоятельно
Это как с сиськами, картинки и видео, наблюдение издалека.. это одно дело. А вот щупать своими руками, это уже совсем другие ощущения.. Так вот, в k8s работать с объектами можно по разному:
Ну и дальше мы сразу перейдем к использованию третьего способа.
Kompose, что еще за зверь такой
Как следует из названия, Kubernetes + Compose = Kompose. Эдакая ядреная утилита, которая позволяет запускать сервисы в k8s из конфигов docker-compose, или же конвертировать их в готовые конфиги k8s (а потом уже запускать их вручную, предварительно проверим и модифицировав). Конечно, стоит сразу сказать, что Kompose преследует скорее демонстративно-обучающие цели. Однако, он подойдет и для быстрого переноса существующих проектов на docker-compose. На офф.сайте смотрите варианты установки и базового использования. Актуальная версия kompose на момент написания статьи: 1.19.0 (f63a961c).
Далее, меняем версию манифеста у конфига docker-compose.yml:
Теперь сгенерируем на базе этого конфиги для k8s:
Увидим соответствующее сообщение вида:
Создадутся эти конфиги, вот они наглядно:
Есть также одна волшебная команда в kompose (up), которая позволяет запустить все сервисы сразу без генерации конфигов:
..но срабатывает в текущих версиях сходу она очень редко или для слишком уж тривиальных примеров. Вероятно проблема тут у него именно с новой версией k8s 1.16, с 1.15 и более ранними чаще отрабатывало корректно. Удалить все что насоздавал up, можно с помощью, соответственно, down:
Конфиги для deployment, service, pvc и запуск
После convert, конфиги мы получили и теперь надо их отредактировать. В версии 1.16 k8s (а у нас в microk8s идет самая свежая стабильная), отключили старые “apiVersion: extensions/v1beta1” поэтому теперь нам надо все их заменить на актуальные “apiVersion: apps/v1”. Тут обойдемся sed`ом:
Также я внес некоторые правки в *-services: поменял порты для красоты (теперь 80:80). А еще, чтобы уж наверняка, прописал полные имена сервисов в переменных (это вида df-maria.default.svc.cluster.local). Создал дополнительный конфиг и сервис для доступа к базе (df-maria-service.yaml) по ее дефолтному порту 3306.
Все. После этого выполняем команду на запуск “всего”:
Если вам влом было проходить все эти шаги, можете сразу скачать и запустить готовый конфиг для всего* (df-wordpress-all.yaml):
*если интересно как собрать один большой конфиг из нескольких, то тут можно воспользоватся ‘kubectl kustomize’ и подложить ему соответствующий конфиг: kustomization.yaml
А вот и каждый конфиг по отдельности:
Проверить статус можно, допустим, так:
После чего, если microk8s запущен локально, мы уже можем получить доступ к сервисам по их внутреннему IP (тип ClusterIP). Выглядит нам нужная строка так:
Таким образом, вбив в браузере адрес сервиса для wordpress, вы увидите что он доступен для первичной настройки (по 80 порту, соответственно).
А перейдя по адресу сервиса для phpmyadmin, авторизовавшись (по параметрам env из переменных в конфигах), мы сразу получаем доступ к нашей БД:
Конфиги для ingress, service и внешний доступ
Хм, теперь нам нужен внешний доступ к wordpress или phpmyadmin. Тут есть несколько вариантов, но мы рассмотрим три основных:
Важный момент, дальше я буду в качестве примера для внешнего доступа показывать phpmyadmin вместо wordpress. Т.к. wordpress держит параметр своего адреса в БД, и постоянно редиректит на него. По сути как бы держит его захардкоженым, что неудобно в нашем случае, т.к. мы будем переключать его туда-сюда. Мне лень с этим бодатся и каждый раз менять адрес (это пункт в настройках и параметр в БД), и лень искать способ обхода этого на стороне WP. Кто хоть когда-нить мигрировал wordpress знает о чем я говорю. Короче говоря, поэтому показываем на phpmyadmin, он не такой капризный.
NodePort
При просмотре статуса через kubectl get svc, увидим проброс:
Теперь phpmyadmin доступен из вне по порту (как по localhost, так и по IP нашего wordstation/server):
Итак, по порту пробрасывать мы научились.
Ingress (поддиректория)
Вообще, если крутить яйца ingress, то можно получить много чего интересного. Мы же рассмотрим в данном примере, чтобы можно было размещать разные сервисы в поддиректориях главного домена. Это будет выглядеть, например, как то так: darkfess.ru/service1, darkfess.ru/service 2 и т.д. Не очень красивое решение, но зато можно быстро что-то прикрутить без дополнительных настроек DNS, ожидания его синхронизации и т.д (однако один раз вам, все же, придется DNS настроить на основном домене). Минусы тоже есть, некоторые сервисы могут держать в себе какой то захаркоженный путь и попросто не будут работать в поддиректории или будут работать криво.
Ну да ладно, поехали (для справки, я тестирую локально, поэтому сделал соответтвующую запись в /etc/hosts про FQDN darkfessus.ru )
Ага, здесь видим что то не так. Ошибка 404:
Запрос к phpmyadmin уходит и мы можем проверить это через логи (но phpmyadmin не понимает что это за адрес такой /phpmyadmin, потому что сам он работает в корне /):
Нужно “помочь Даше найти дорогу, давайте все вметсе позовем Карту!” (с) Как мы и делали раньше, применяем другой конфиг ingress с тем же name и модифицируем его настройки (здесь появляется режим rewrite, и это функционал nginx, как вы уже наверное догадались):
Теперь все. Вуаля! Заработало на поддиректории:
Подробнее об режиме rewrite можно почитать в офф.доках.
Ingress (поддомен)
Это, пожалуй, мой самый любимый способ. Он самый красивый, через поддомены сервисы выглядят очень окультуренными, по типа такого: service1.darkfess.ru, service2.darkfess.ru. Прописываем DNS записи на нужные сервисы, прописываем конфиг ingress – и пли! Все красиво, никаких портов, никаких лишних хвостов в виде поддиректорий и прочего.
Ну да ладно, поехали (для справки, я тестирую локально, поэтому сделал соответтвующую запись в /etc/hosts про FQDN svc1.darkfessus.ru ):
Вот теперь все. Заработало на поддомене:
На этой ноте пожалуй наш экскурс по 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:
Вот и все. Дальше собственно устанавливаем компонент tiller в k8s:
Обновить его можно такой же командой с флагом –upgrade. Маленькая шпаргалка по использованию:
Обратите внимание также и на совместимость версии k8s с каждой актуальной версией Helm. Я столкнулся с этим совсем недавно, когда вышла версия k8s 1.16, helm тогда без шаманств не работал. Ну а что дальше? Дальше идите на HelmHub, ищите нужный софт и ставьте его по инструкции внутри. Помимо официальных, очень много готовых собранных образов идет от bitnami, например. Идите в Hub, там есть что посмотреть.
Собственно, на этом пожалуй, этот краткий обзор по Helm я закончу. А все потому, что скоро выйдет новая мажорная версия Helm 3.0, и она принесет в себе множество новых изменений. Одной из основных будет отказ по Tiller. но это уже совсем другая история, может быть я лучше на нее отдельный обзор напишу.
Итоги
Не люблю я писать эпилоги. Будут ли еще статьи про k8s? Очевидно, что да. А так, данный материал получился довольно большого объема, да и писал я его достаточно долго. Бесят бессконечные редактирования! Но в целом.. хочется верить, что данный материал окажется вам полезен в понимании k8s и работе с ним. В частности с microk8s, если вы с ним еще не знакомы. Ведь это чрезвычайно удобная и крутая штука, на которой спокойно можно построить все, пожалуй, кроме серьезных больших production сред. Но зато можно сделать переезд на этот самый “бАльшой” prod максимально безшовным.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
