Я хотел бы спросить, какую стратегию использовать в Kubernetes для контроллеров Ingress, DNS-имен, сертификатов и приложений. Не спрашивая технических подробностей, но больше о моделировании. Я искал рекомендации по этому поводу и боролся.
Q1: Использовать один ИЛИ несколько балансировщиков нагрузки? Когда бы вы раскрутили новый LB — это основано на безопасности, трафике, чем-то еще?
Q2: Допустим, у меня есть 3 бизнес-подразделения, и в каждом из них есть 2 приложения. Как лучше всего использовать DNS-имена и сертификаты?
Любые советы приветствуются.
Джейк.
Q1: Использовать один ИЛИ несколько балансировщиков нагрузки? Когда бы вы раскрутили новый LB — это основано на безопасности, трафике, чем-то еще?
Это зависит от архитектуры вашего приложения, количества обслуживаемых вами местоположений и т. д. Доступно несколько типов балансировщиков нагрузки, таких как внутренние балансировщики нагрузки, внешние балансировщики нагрузки, глобальные балансировщики нагрузки, балансировщики нагрузки сети и приложений и т. д., если ваше приложение очень big, вместо того, чтобы иметь одну машину, обслуживающую все ваше приложение, вы можете разделить приложение на несколько групп в зависимости от их функциональности и настроить балансировщик нагрузки для каждой группы в зависимости от трафика или обращений, которые они получают.
Q2: Допустим, у меня есть 3 бизнес-подразделения, и в каждом из них есть 2 приложения. Как лучше всего использовать DNS-имена и сертификаты?
Опять же, это зависит от типа бизнеса, которым занимается каждое из ваших подразделений. Если все три подразделения занимаются одним и тем же бизнесом, но нацелены на разную аудиторию, у вас может быть один DNS и один сертификат. Если ваши три устройства работают по-разному, всегда рекомендуется использовать разные DNS-имена, чтобы охватить целевых потребителей.
Например: если у вас приложение для доставки еды, и у вас есть две единицы, одна из которых обслуживает всех клиентов, а другая обслуживает только клиентов b2b, здесь вы можете иметь одно доменное имя и один поддомен, а именно
fooddelivery.com и b2b.fooddelivery.com
Этот вопрос можно передать в Serverfault вместо того, чтобы закрывать или удалять, поскольку он связан с архитектурой приложения и требует обсуждения или дополнительных входных данных.