Я работаю с Docker уже довольно давно, и у меня уже есть производственная среда, которая начиналась с малого, но теперь выросла до более чем 50 узлов Linux, на каждом из которых работает один контейнер Docker.
Я все координировал, используя собственные скрипты Python, и до сих пор он отлично работал, но, поскольку мы, вероятно, продолжим расширение, я думаю, что в какой-то момент мне понадобится надежный, гибкий инструмент оркестровки, так что можно начать планирую все сейчас.
Я начал читать о вариантах оркестрации докеров, и пока что сузил их до двух вариантов: Kubernetes или docker-swarm.
Глядя на Kubernetes, это кажется правильным выбором (как надежной, гибкой системой оркестровки), но я не уверен, подходит ли он для моей среды. Из того, что я читал, он не может обрабатывать уже существующие контейнеры докеров, его можно использовать только для создания нового кластера с нуля. В нашем случае мы используем выделенные серверы со специальными требованиями к оборудованию, поэтому у нас нет другого параллельного альтернативного кластера, где мы могли бы начать с Kubernetes.
С другой стороны, docker-swarm кажется более подходящим для оркестровки существующих контейнеров докеров, но, похоже, имеет проблемы с надежностью и масштабированием.
Может ли кто-нибудь с обширным опытом Kubernetes / docker-swarm дать мне совет о том, как мне подойти к миграции на оркестрованный кластер докеров, без необходимости создавать его с нуля (поскольку в моем случае это невозможно)?
Спасибо!
Я мало что знаю о Docker Swarm, но могу поделиться своими мыслями о стороне Kubernetes.
В любом случае вам понадобятся дополнительные машины, если вы хотите внести изменения в среду - ваши машины используются на 90%, поэтому я не понимаю, как вы могли бы мигрировать или начать использовать Kubernetes в текущем сценарии. Помимо отключения ваших узлов по одному и постепенного перехода на Kubernetes. Вы можете попробовать изменить два текущих узла на 1 мастер kubernetes и 1 узел (используя, например, kubespray), а затем присоединить свои контейнеры к кластеру как Deployments.
Вы уже упоминали, что вы не можете начать оркестровку запущенных контейнеров, так как вам нужно будет развернуть все с нуля, чтобы начать использовать Kubernetes, но здесь важно одно. Если вы сделаете это правильно с K8s, у вас больше никогда не будет этой проблемы. Декларативный способ Kubernetes и тот факт, что все является файлом yaml, облегчают будущее. Вам просто нужно будет сохранить резервные копии ваших сервисов, развертываний, конфигурационных карт и т. Д., И эта проблема исчезнет в будущем. Кроме того, оркестровка, самовосстановление, апгрейды и масштабирование больше не будут такими сложными.
Короче говоря. Я не утверждаю, что то, что я напишу, является единственно правильным способом, я просто расскажу, что я сделал бы в вашей ситуации.
Вы уже упомянули, что арендуете оборудование - почему бы тогда не перейти в облако? Не нужно сразу все перемещать. Я имею в виду - воссоздайте свою инфраструктуру в облаке - возможно, в одном из управляемых сервисов Kubernetes (GKE, EKS, AKS или многие другие), поскольку ими проще всего управлять, и вас будут поддерживать инженеры из Google / AWS / Azure и т. Д. чтобы помочь вам, если у вас возникнут проблемы с вашим кластером. После того, как вы закончите со средой в облаке и она работает должным образом, вы можете решить, что делать дальше.
Стоит ли оставаться со всей инфраструктурой или, может быть, лучше вернуться в локальную среду? В этом случае у вас уже будет опыт работы с Kubernetes, готовыми файлами YAML, резервными копиями и т. Д., И перенести это из Cloud Kubernetes в локальный Kubernetes будет намного проще - все, что вам нужно сделать, это миграция почти 1: 1 + немного возиться с сети.
Доступны бесплатные пробные версии, поэтому вы можете проверить, работает ли это для вас таким образом - в GCP вы получаете бесплатную пробную версию 300 долларов, а также они предоставляют скидки на постоянное использование. Таким образом, вы можете протестировать свое приложение в меньшем масштабе. В AWS есть уровень бесплатного пользования, которого должно хватить для тестирования некоторых основных функций. Не уверен в других облачных провайдерах, но у них наверняка есть соответствующие предложения.
Итак, вы либо пытаетесь частично перейти в облако и поиграетесь с разделением трафика между локальной средой и облаком, либо скопируете всю инфраструктуру в облако, а затем воспроизведете его локально, если вам это понравится.
Другой способ - отключить два узла, создать на них мастер Kubernetes и узел, а затем медленно присоединить узлы к кластеру один за другим. Это также зависит от того, какое приложение вы используете, можете ли вы позволить себе простои и т. Д., Но все это можно решить, например, с помощью канареечного развертывания.