Я новичок в docker / contaners и т. Д. У меня есть сервер узла, работающий на металлической машине на порту 8080. У меня NginX работает как обратный прокси для него.
Приложение устанавливает веб-сокет для каждого подключенного клиента, чтобы облегчить чат в реальном времени. В настоящий момент карта веб-сокетов находится в процессе, а это означает, что я не могу масштабироваться для нескольких процессов (да, я знаю, хромает); однако мне нужно будет обновить архитектуру, чтобы пользователи могли общаться с другими пользователями, даже если они подключены к веб-сокетам в разных процессах.
База данных - Mongo.
Возникает вопрос: как бы это выглядело, если бы я перенес его на Kubernetes? Что бы он заменил и как? Мог бы я по-прежнему использовать NginX? Или Kubernetes предоставит возможность действовать как обратный прокси? Если бы я сделал это, означало бы это, что я смогу развернуть свое приложение везде, и просто посмотреть, как это работает? Будет ли контейнер приложения включать все CentOs / Node / и т. Д. стек?
Kubernetes позволит вам иметь парк металлических машин, которые он будет рассматривать как кластер. Помимо машин в кластере, он будет обрабатывать планирование автоматически масштабируемого количества серверов websocket узлов без сохранения состояния, используя объекты Kubernetes, называемые Pods и ReplicaSets.
Существует объект kubernetes под названием Ingress, который в большинстве случаев представляет собой nginx под капотом и может заменить ваш существующий nginx.
Вы также можете запустить монго в кубернетах. Монго хочет хранить данные на локальном диске. В кубернетах это сложнее, но возможно.
Для обработки карты состояний веб-сокета вы можете запустить redis в кубернетах, хотя кубернетес снова ожидает, что приложения, которые он запускает, не будут иметь состояния и будут перемещаться на любой узел в кластере. Или он ожидает, что приложение будет иметь собственную кластерную модель с выбором лидера и надежной синхронизацией данных.
Если вы выполнили всю эту архитектурную работу и подготовили всю эту конфигурацию кубернетов, то вы могли бы развернуть всю систему приложений в любом кластере кубернетов.
Инструмент под названием Helm https://helm.sh/ занимается сбором конфигураций объектов Kubernetes в пакеты, что обеспечивает такое удобство.
В каждом контейнере приложения обычно находится ОС, библиотеки времени выполнения, а затем само приложение. Многие люди используют контейнерные линии с минимальным количеством ОС, а не с полным дистрибутивом, например с множеством пользовательских инструментов командной строки, поскольку обычно ssh или оболочка не помещаются в контейнер.