Как сделать местное развитие с Kubernetes?
Кажется, что Kubernetes занимается развертыванием контейнеров в облаке кластеров. Кажется, что не трогает среда разработки и промежуточная среда (или такая).
Во время разработки вы хотите быть как можно ближе к производственной среде с некоторыми важными изменениями:
- Развертывается локально (или, по крайней мере, где-то, где вы и только вы можете получить доступ)
- Используйте последний исходный код при обновлении страницы (предположим, что это веб-сайт; в идеале - автоматическое обновление страницы при сохранении локального файла, что можно сделать, если вы смонтируете исходный код и используете что-то вроде Yeoman).
Точно так же можно хотеть, чтобы непубличная среда выполняла непрерывную интеграцию.
Поддерживает ли Kubernetes такую среду разработки или нужно что-то создавать, надеясь, что во время работы она все еще будет работать?
9 ответов
Обновление (2016-07-15)
С выпуском Kubernetes 1.3 Minikube теперь является рекомендуемым способом запуска Kubernetes на локальной машине для разработки.
Вы можете запустить Kubernetes локально через Docker. Когда у вас запущен узел, вы можете запустить модуль, который имеет простой веб-сервер и монтирует том с вашего хоста. Когда вы нажмете на веб-сервер, он будет читать с тома, и если вы изменили файл на локальном диске, он может служить последней версией.
Мы работаем над инструментом для этого. Основная идея заключается в том, что у вас есть удаленный кластер Kubernetes, фактически промежуточная среда, а затем вы запускаете код локально, и он передается через прокси на удаленный кластер. Вы получаете прозрачный доступ к сети, копируемые переменные среды, доступ к томам... как можно ближе к удаленной среде, но при этом ваш код работает локально и под вашим полным контролем.
Так что вы можете заниматься живым развитием, скажем. Документы на http://telepresence.io/
"Горячая перезагрузка" - это то, что мы планируем добавить, но это не так просто, как сегодня. Однако, если вы чувствуете себя предприимчивым, вы можете использовать rsync с docker exec, kubectl exec или osc exec (все примерно одинаково) для синхронизации локального каталога в контейнере при его изменении. Вы можете использовать rsync с kubectl или osc exec следующим образом:
# rsync using osc as netcat
$ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder
Еще одна отличная отправная точка - это установка Vagrant, особенно. если ваша операционная система Windows. Очевидные преимущества
- быстрая и безболезненная настройка
- легко уничтожить / воссоздать машину
- неявное ограничение на ресурсы
- возможность тестирования горизонтального масштабирования путем создания нескольких узлов
Недостатки - вам нужно много оперативной памяти, а VirtualBox - это VirtualBox... к лучшему или к худшему.
Смешанным преимуществом / недостатком является сопоставление файлов через NFS. В нашей настройке мы создали два набора определений RC - один, который просто загружает образ докера наших серверов приложений; другая с 7 дополнительными строками, которые устанавливают сопоставление файлов из HostOS -> Vagrant -> VirtualBox -> CoreOS -> Kubernetes pod; перезаписать исходный код из образа Docker.
Недостатком этого является файловый кеш NFS - с ним проблематично, без него проблематично медленно. Даже настройка mount_options: 'nolock,vers=3,udp,noac' не полностью избавляется от проблем с кэшированием, но работает большую часть времени. Некоторые задачи Gulp, выполняемые в контейнере, могут занимать 5 минут, если они занимают 8 секунд в хост-ОС. Кажется, хороший компромисс mount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15',
Что касается автоматической перезагрузки кода, это зависит от языка, но мы довольны разработчиком Django для Python и Nodemon для Node.js. Для фронтенд-проектов вы, конечно, многое можете сделать с помощью чего-то вроде gulp+browserSync+watch, но для многих разработчиков несложно обслужить Apache и просто сделать традиционное сложное обновление.
Мы сохраняем 4 набора файлов yaml для Kubernetes. Dev, "devstable", сцена, прод. Различия между этими
- Переменные env, явно устанавливающие среду (dev/stage/prod)
- количество реплик
- devstable, stage, prod использует изображения докера
- dev использует образы docker и сопоставляет папку NFS с исходным кодом над ними.
Очень полезно создавать много псевдонимов bash и автозаполнения - я могу просто напечатать rec users и это будет делать kubectl delete -f ... ; kubectl create -f ..., Если я хочу, чтобы все настройки начались, я печатаю recfoи воссоздает дюжину сервисов, извлекая последние образы докера, импортируя последний дамп базы данных из Staging env и очищая старые файлы Docker для экономии места.
Я только начал со Скаффолдом
Действительно полезно автоматически вносить изменения в код в локальный кластер.
Для развертывания локального кластера лучше всего использовать Minikube или просто Docker для Mac и Windows, оба из которых включают интерфейс Kubernetes.
Хорошая петля обратной связи по местному развитию - это тема быстрого развития экосистемы Кубернетес.
Если разбить этот вопрос, есть несколько инструментов, которые, я считаю, хорошо поддерживают эту цель.
Докер для Mac Kubernetes
Docker для Mac Kubernetes ( Docker Desktop - это общее название кроссплатформенности) предоставляет отличный вариант для локальной разработки. Для виртуализации он использует HyperKit, который построен на собственной платформе Hypervisor в macOS вместо VirtualBox.
Функция Kubernetes была впервые выпущена в качестве бета-версии на канале пограничного уровня в январе 2018 года и с тех пор прошла долгий путь, став сертифицированным Kubernetes в апреле 2018 года и перейдя на стабильный канал в июле 2018 года.
По моему опыту, с Minikube работать намного проще, особенно в macOS, особенно когда речь идет о таких проблемах, как RBAC, Helm, гипервизор, частный реестр и т. Д.
Шлем
Что касается распространения вашего кода и получения обновлений локально, Helm является одним из самых популярных вариантов. Вы можете публиковать свои приложения через CI/CD как диаграммы Хелма (а также базовые образы Docker, на которые они ссылаются). Затем вы можете извлечь эти диаграммы из реестра карт Helm локально и обновить их в своем локальном кластере.
Лазурный черновик
Вы также можете использовать такой инструмент, как черновик Azure, для выполнения простых локальных развертываний и создания базовых диаграмм Helm из общепринятых языковых шаблонов, наподобие buildpack-пакетов, для автоматизации этой части головоломки.
Skaffold
Skaffold похож на черновик Azure, но более зрелый, гораздо более широкий по объему и сделан Google. У него очень подключаемая архитектура. Я думаю, что в будущем все больше людей будут использовать его для разработки локальных приложений для Kubernetes.
Если вы использовали React, я думаю о Скаффолде как о " Создать приложение React для Kubernetes".
Композицию или Композицию на Кубернетес
Docker Compose, хотя и не связан с Kubernetes, является одной из альтернатив, которую некоторые компании используют для предоставления простой, легкой и переносимой среды локальной разработки, аналогичной среде Kubernetes, которую они используют в производстве. Однако идти по этому пути означает расхождение ваших производственных и локальных настроек развития.
Kompose является конвертером Docker Compose для Kubernetes. Это может быть полезным путем для тех, кто уже запускает свои приложения в виде коллекций контейнеров локально.
Compose в Kubernetes - это недавно открытое (от 2018 г.) предложение от Docker, которое позволяет развертывать файлы Docker Compose непосредственно в кластер Kubernetes через специальный контроллер.
См. https://github.com/kubernetes/kubernetes/issues/12278 чтобы узнать, как смонтировать том с хост-машины, что эквивалентно:
docker run -v hostPath:ContainerPath
Недостаток использования minkube в том, что он порождает другую виртуальную машину поверх вашей машины. Также с последними minikube Для этой версии требуется минимум 2 процессора и 2 ГБ оперативной памяти от вашей системы, что делает ее довольно тяжелой, если у вас недостаточно ресурсов системы.
Вот почему я перешел на microk8s для развития на kubernetes и я люблю это. microk8s поддерживает DNS, локальное хранилище, панель мониторинга, istio, вход и многое другое, все, что вам нужно для тестирования ваших микросервисов.
Он предназначен для быстрой и легкой установки восходящего потока Kubernetes, изолированной от вашей локальной среды. Эта изоляция достигается за счет упаковки всех двоичных файлов для Kubernetes, Docker.io, iptables и CNI в единый пакет с привязкой.
Один кластер kubernetes можно установить в течение одной минуты с помощью одной команды:
snap install microk8s --classic
Убедитесь, что в вашей системе не запущена ни одна служба докера или kubelet. Microk8s установит все необходимые сервисы автоматически.
Пожалуйста, посмотрите на следующую ссылку, чтобы включить другие дополнения в microk8s,
Вы можете проверить статус, используя:
velotio@velotio-ThinkPad-E470:~/PycharmProjects/k8sClient$ microk8s.status
microk8s is running
addons:
ingress: disabled
dns: disabled
metrics-server: disabled
istio: disabled
gpu: disabled
storage: disabled
dashboard: disabled
registry: disabled
Kubespary полезен при настройке локальных кластеров. В основном я использовал кластер на основе бродяги на локальной машине.
Конфигурация Kubespray Вы можете настроить эти переменные, чтобы получить желаемую версию kubernetes.
Взгляните на https://github.com/okteto/okteto и Okteto Cloud. Ценность предложения состоит в том, чтобы иметь опыт классической разработки, чем работать локально, до докера, где у вас могут быть горячие перезагрузки, инкрементные сборки, отладчики... но все ваши локальные изменения немедленно синхронизируются с удаленным контейнером. Удаленные контейнеры предоставляют вам доступ к скорости облака, обеспечивают новый уровень совместной работы и интегрируют разработку в производственную среду. Кроме того, это устраняет бремя локальных установок.
Как указывалось ранее Робертом, миникуб - это путь.
Вот краткое руководство, чтобы начать работу с Minikube. Основные шаги:
Установить миникуб
Создать кластер мини-кубов (на виртуальной машине, которая может быть VirtualBox или Docker для Mac или HyperV в случае Windows)
Создать Docker-образ файла вашего приложения (с помощью Dockerfile)
Запустите образ, создав развертывание
Создайте сервис, который предоставляет ваше приложение, чтобы вы могли получить к нему доступ.
Вот как я сделал локальную настройку Kubernetes в Windows 10:
Используйте Docker Desktop
Включите Kubernetes в настройках Docker Desktop
В Docker Desktop по умолчанию ресурс, выделяемый для памяти, составляет 2 ГБ, поэтому для использования Kubernetes с Docker Desktop увеличьте объем памяти.
Установите kubectl в качестве клиента, чтобы общаться с кластером Kubernetes
Запустите команду kubectl config get-context, чтобы получить доступный кластер.
Выполните команду kubectl config use-context docker-desktop, чтобы использовать рабочий стол докера.
Создайте Docker-образ вашего приложения
Напишите файл YAML (описательный метод для создания развертывания в Kubernetes), указывающий на образ, созданный в кластере вышеупомянутого шага.
Предоставьте службу типа порт узла для каждого развертывания, чтобы сделать ее доступной для внешнего мира.
Вы можете использовать удаленный кластер kubernetes и настроить свои локальные машины для подключения к этому кластеру. Используйте команды kubectl cp для копирования кода в запущенные модули для горячей перезагрузки кода во время разработки.
Вы можете использовать "Portainer" для разработки. Это легко и не требует запоминания команды или манифеста yaml.