Кажется, что Kubernetes занимается развертыванием контейнеров в облаке кластеров. Чего он, похоже, не касается, так это среды разработки и постановки (или чего-то подобного).

Во время разработки вы хотите быть как можно ближе к производственной среде с некоторыми важными изменениями:

• Развернуты локально (или, по крайней мере, где-нибудь, где только вы можете получить доступ )
• Используйте последний исходный код при обновлении страницы (предположим, что это веб-сайт; в идеале автоматическое обновление страницы при сохранении локального файла, что можно сделать, если вы смонтируете исходный код и используете что-то вроде Yeoman ).

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

Поддерживает ли Kubernetes такую ​​среду разработки или это нужно создавать, надеясь, что во время производства она все еще будет работать?

Обновление (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", stage, prod. Различия между ними

• переменные env, явно устанавливающие среду (dev / stage / prod)
• количество реплик
• devstable, stage, prod использует образы докеров
• dev использует образы докеров и отображает папку NFS с исходным кодом поверх них.

Очень полезно создавать множество псевдонимов и автозаполнения bash - я могу просто набрать текст, rec usersи он подойдет kubectl delete -f ... ; kubectl create -f .... Если я хочу, чтобы вся настройка была запущена, я набираю текст recfo, и он воссоздает дюжину служб, извлекая последние образы докеров, импортируя последний дамп db из Staging env и очищая старые файлы Docker для экономии места.

Я только начал со скаффолд

Действительно полезно автоматически применять изменения в коде к локальному кластеру.

Для развертывания локального кластера лучше всего использовать Minikube или просто Docker для Mac и Windows, оба включают интерфейс Kubernetes.

См. Https://github.com/kubernetes/kubernetes/issues/12278, чтобы узнать, как смонтировать том с хост-машины, эквивалент:

docker run -v hostPath:ContainerPath

Наличие хорошей обратной связи на местном уровне - одна из основных тем в экосистеме Kubernetes.

Разбивая этот вопрос, я считаю, что есть несколько инструментов, которые хорошо поддерживают эту цель.

Докер для Mac Kubernetes

Docker для Mac Kubernetes ( Docker Desktop - это общее название кроссплатформенности) предоставляет отличный вариант для локальной разработки. Для виртуализации он использует HyperKit, который построен на собственной структуре гипервизора в macOS вместо VirtualBox.

Функция Kubernetes была впервые выпущена в виде бета-версии на пограничном канале в январе 2018 года и с тех пор прошла долгий путь, став сертифицированным Kubernetes в апреле 2018 года и перейдя на стабильный канал в июле 2018 года .

По моему опыту, работать с ним намного проще, чем с Minikube, особенно на macOS, и особенно когда дело касается таких проблем, как RBAC, Helm, гипервизор, частный реестр и т. Д.

Шлем

Что касается распространения вашего кода и получения обновлений локально, Helm - один из самых популярных вариантов. Вы можете публиковать свои приложения через CI / CD в виде диаграмм Helm (а также базовых образов Docker, на которые они ссылаются). Затем вы можете извлечь эти диаграммы из реестра диаграмм Helm локально и обновить их в локальном кластере.

Лазурный осадок

Вы также можете использовать такой инструмент, как Azure Draft, для простого локального развертывания и создания базовых диаграмм Helm из общеязыковых шаблонов, вроде пакетов сборки, чтобы автоматизировать эту часть головоломки.

Скаффолд

Skaffold похож на Azure Draft, но более зрелый, более широкий по своему охвату и создан Google. У него очень гибкая архитектура. Я думаю, что в будущем больше людей будут использовать его для разработки локальных приложений для Kubernetes.

Если вы использовали React, я думаю о Skaffold как о « Create React App for Kubernetes».

Сочинять или сочинять в Kubernetes

Docker Compose , хотя и не имеющий отношения к Kubernetes, является альтернативой, которую некоторые компании используют для предоставления простой, легкой и переносимой локальной среды разработки, аналогичной среде Kubernetes, которую они запускают в производственной среде. Однако идти по этому пути означает расходиться с настройками производства и локальной разработки.

Kompose - это конвертер Docker Compose в Kubernetes. Это может быть полезным путем для тех, кто уже запускает свои приложения в виде коллекций контейнеров локально.

Compose on Kubernetes - это недавно выпущенное (декабрь 2018 г.) предложение от Docker с открытым исходным кодом, которое позволяет развертывать файлы Docker Compose непосредственно в кластере Kubernetes через настраиваемый контроллер.

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

Конфигурация Kubespray Вы можете настроить эти переменные, чтобы получить желаемую версию Kubernetes.

Недостатком использования minkubeявляется то, что он создает другую виртуальную машину поверх вашей. Кроме того, для последней minikubeверсии требуется минимум 2 процессора и 2 ГБ оперативной памяти от вашей системы, что делает ее довольно тяжелой, если у вас нет системы с достаточным количеством ресурсов.

Это причина, по которой я перешел microk8sна разработку кубернетов, и мне это нравится. microk8sподдерживает DNS, локальное хранилище, панель мониторинга, istio, ingress и многое другое, все, что вам нужно для тестирования ваших микросервисов.

Он предназначен для быстрой и легкой установки Kubernetes вверх по течению, изолированной от вашей локальной среды. Эта изоляция достигается за счет упаковки всех двоичных файлов для Kubernetes, Docker.io, iptables и CNI в один пакет snap.

Кластер Kubernetes с одним узлом можно установить за минуту с помощью одной команды:

snap install microk8s --classic

Убедитесь, что в вашей системе не запущены докеры или службы kubelet. Microk8sавтоматически установит все необходимые службы.

Перейдите по следующей ссылке, чтобы включить другие надстройки microk8s.

https://github.com/ubuntu/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

Взгляните на https://github.com/okteto/okteto и Okteto Cloud . Ценностное предложение состоит в том, чтобы иметь классический опыт разработки, чем локальная работа до докера, где у вас могут быть горячие перезагрузки, инкрементные сборки, отладчики ... но все ваши локальные изменения немедленно синхронизируются с удаленным контейнером. Удаленные контейнеры дают вам доступ к скорости облака, обеспечивают новый уровень сотрудничества и интегрируют разработку в производственную среду. Кроме того, это устраняет нагрузку на местные установки.

Как ранее указывал Роберт, миникубе - это лучший способ.

Вот краткое руководство по началу работы с minikube. Общие шаги:

• Установить minikube

• Создайте кластер 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, чтобы использовать рабочий стол докера.

• Создайте образ докера вашего приложения

• Напишите файл YAML (описательный метод создания развертывания в Kubernetes), указывающий на образ, созданный в кластере вышеупомянутого шага.

• Предоставьте службу типа node port для каждого развертывания, чтобы сделать ее доступной для внешнего мира.