Kubernetes - маршрутизация статического IP-адреса к нескольким сервисам (Google Cloud Platform)
У меня есть небольшое приложение, состоящее из трех служб:
- Одностраничное приложение (SPA), обслуживаемое nginx
- Простой HTTP API nodejs, используемый SPA
- Брокер MQtt, открывающий порты 1883 и 9001
В идеале я бы хотел, чтобы все обслуживались с одного и того же субдомена и статического IP-адреса, и я пытался настроить это в Kubernetes на облачной платформе Google.
Я создал развертывания для каждой из служб, используя порт 80, предоставляющий SPA, API 3000 и брокер MQTT 1883/9001. Затем я выполнил инструкции здесь, чтобы настроить статический IP-адрес и службу для маршрутизации в SPA, а затем создал аналогичные службы для API и приложения MQTT. (Я изначально адаптировал их из развертываний и сервисов, созданных из файла docker-compose и Kompose).
Кажется, что SPA и API работают нормально, а служба MQTT - нет. Когда я запускаю kubetl get events, я вижу:
Error creating load balancer (will retry): failed to ensure load balancer for service default/mqtt-broker: failed to create forwarding rule for load balancer (a5529f2a9bdaf11e8b35d42010a84005(default/mqtt-broker)): googleapi: Error 400: Invalid value for field 'resource.IPAddress': '35.190.221.113'. Specified IP address is in-use and would result in a conflict., invalid
Поэтому мне интересно, следует ли мне создавать одну службу для маршрутизации к трем развертываниям, но я не могу найти никакой документации или примеров, объясняющих, как это сделать для службы, отличной от http.
Думаю, я мог бы разместить службу mqtt на отдельном IP-адресе, но это, похоже, взламывает проблему, а не решает ее.
Спасибо заранее за любые советы.
Ответы 1
В конце концов я нашел почти идентичный варианту использования моего собственного в этом репозитории github.
По сути, они находятся создают брокера MQTT на отдельном статическом IP-адресе и используют вызовы Kubernetes API для раскрытия деталей внешнему интерфейсу, что они объясняют в следующем комментарии в верхней части файла web.yaml:
This needs a bit of trickery as it needs to expose the LB ip address for the MQTT server. That requires kubernetes API calls to look it up, and the ability to store it somewhere (we put it in a secret). To be secure this is done with a dedicated service account and an init container.