Получение внешнего трафика в Kubernetes - ClusterIp, NodePort, LoadBalancer и Ingress
За последние несколько месяцев, я действовал в качестве Защитника Developer для OVH Managed Kubernetes беты , следуя наши бета - тестеры, получать обратную связь, писать документы и учебники, и в целом помогаю убедиться , продукт соответствует потребностям наших пользователей настолько близко , насколько это возможно.
В следующих нескольких постах я расскажу вам несколько историй об этой стадии бета-тестирования . Мы рассмотрим отзывы некоторых из наших бета-тестеров, технические идеи и некоторые забавные анекдоты о разработке этой новой службы.
Сегодня мы начнем с одного из самых частых вопросов, которые я задавал в первые дни бета-тестирования: как направить внешний трафик в мою службу Kubernetes? Этот вопрос возник часто, когда наши клиенты начали изучать Kubernetes, и когда я попытался ответить на него, я понял, что часть проблемы заключается в огромном количестве возможных ответов и концепциях, необходимых для их понимания.
С этим вопросом был связан запрос функции : большинству пользователей нужен инструмент балансировки нагрузки . Поскольку бета-версия предназначена для подтверждения стабильности продукта и проверки приоритетов набора функций, мы смогли быстро подтвердить
Чтобы попытаться лучше ответить на вопрос о внешнем трафике и упростить внедрение
Это сообщение в блоге представляет собой расширенную версию этого руководства. Надеемся, оно вам пригодится!
Когда вы начинаете использовать Kubernetes для реальных приложений, один из первых вопросов, который нужно задать, — как получить внешний трафик в вашем кластере. В официальной документации предлагает полное (но довольно сухое) объяснение этой темы, но здесь мы будем объяснять его в более практических, служебной необходимости знать пути.
Есть несколько способов перенаправить внешний трафик в ваш кластер:
1. Использование Kubernetes прокси и ClusterIP: По умолчанию значения Kubernetes ServiceType является ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ к ClusterIp из внешнего источника, вы можете открыть прокси Kubernetes между внешним источником и кластером. Обычно это используется только для разработки.
2. Предоставление сервисов как NodePort: объявление Service as открывает NodePortего на IP-адресе каждого узла на статическом порте (называемом NodePort). Затем вы можете получить доступ к Service извне кластера, запросив :. Это также можно использовать для производства, хотя и с некоторыми ограничениями.
3. Предоставление услуг как LoadBalancer: объявление Service as LoadBalancer предоставляет его внешнему виду с помощью решения балансировки нагрузки поставщика облачных услуг. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Это наиболее широко используемый метод в производственной среде.
По умолчанию Kubernetes ServiceType это ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ ClusterIp с внешнего компьютера, вы можете открыть прокси Kubernetes между внешним компьютером и кластером.
Вы можете использовать kubectl для создания такого прокси. Когда прокси включен, вы напрямую подключены к кластеру и можете использовать для этого внутренний IP-адрес (ClusterIp) Service.
Этот метод не подходит для производственной среды, но он полезен для разработки, отладки и других быстрых и грязных операций.
Объявление службы как NodePort раскрывает Service IP-адрес каждого узла в NodePort (фиксированный порт для этого Serviceв диапазоне по умолчанию 30000-32767). Затем вы можете получить доступ к Service извне кластера, запросив :. Каждая служба, которую вы развертываете, NodePort будет отображаться в своем собственном порту на каждом узле.
Это довольно громоздким, чтобы использовать NodePortдля, Servicesкоторые находятся в производстве. Поскольку вы используете нестандартные порты, вам часто нужно настроить внешний балансировщик нагрузки, который прослушивает стандартные порты и перенаправляет трафик на :.
Объявление службы типа LoadBalancer предоставляет ее внешнему виду с помощью балансировщика нагрузки облачного провайдера. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Как трафик от этого внешнего балансировщика нагрузки направляется в Service модули, зависит от поставщика кластера.
Это LoadBalancer лучший вариант для производственной среды, но с двумя оговорками:
Согласно официальной документации, Ingress это объект API, который управляет внешним доступом к службам в кластере (обычно HTTP). Так в чем разница между этим и LoadBalancer или NodePort?
Ingress это не тип Service, а объект, который действует как обратный прокси-сервер и единственная точка входа в ваш кластер, который направляет запрос различным службам. Самый простой из них Ingress — это NGINX Ingress Controller, где NGINX берет на себя роль обратного прокси, а также работает как SSL.
Ingress ClusterIP доступен за пределами кластера через прокси Kubernetes NodePort, или LoadBalancer, и направляет входящий трафик в соответствии с настроенными правилами.
Основное преимущество использования Ingress за одним LoadBalancer — это стоимость: вы можете иметь множество услуг за одним LoadBalancer.
Что ж, это вопрос на миллион долларов, и он, вероятно, вызовет разный ответ в зависимости от того, кого вы спросите!
Вы можете пойти на все 100% LoadBalancer, получив индивидуальную LoadBalancer услугу. Концептуально это просто: каждая служба независима и не требует дополнительной настройки. Обратной стороной является цена (вы будете платить за одну LoadBalancer услугу), а также сложность управления множеством разных IP-адресов.
Вы также можете использовать только один LoadBalancer и Ingress позади него. Все ваши службы будут находиться под одним и тем же IP-адресом, каждая по своему пути. Это более дешевый подход, поскольку вы платите только за одну LoadBalancer, но если ваши услуги не имеют логической взаимосвязи, это может быстро стать хаотичным.
Если вы хотите узнать мое личное мнение, я бы попытался использовать комбинацию из двух…
Подход мне нравится, имеющий LoadBalancer для каждого соответствующего набора услуг, а затем маршрутизации этих услуг используя Ingressпозади LoadBalancer. Например, предположим, что у вас есть два разных API на основе микросервисов, каждый из которых содержит около 10 сервисов. Я бы поставил один LoadBalancerперед другим Ingressдля каждого API, LoadBalancerпоскольку это единственная общедоступная точка входа и Ingressмаршрутизация трафика к различным службам API.
Но если ваша архитектура достаточно сложна (особенно если вы используете микросервисы), вы скоро обнаружите, что управлять всем вручную с помощью LoadBalancer и Ingress довольно громоздко. Если это так, ответом может быть делегирование этих задач сервисной сети…
Возможно, вы слышали об Istio или Linkerd и о том, как они упрощают создание микросервисных архитектур на Kubernetes, добавляя изящные льготы, такие как A / B-тестирование, канареечные выпуски, ограничение скорости, контроль доступа и сквозную аутентификацию.
Istio, Linkerd и аналогичные инструменты представляют собой сети служб, которые позволяют создавать сети микросервисов и определять их взаимодействия, одновременно добавляя некоторые важные функции, которые упрощают настройку и работу архитектур на основе микросервисов.
Когда дело доходит до использования сервисных мешей в Kubernetes, есть о чем поговорить, но, как говорится, это уже история для другого раза…
В следующих нескольких постах я расскажу вам несколько историй об этой стадии бета-тестирования . Мы рассмотрим отзывы некоторых из наших бета-тестеров, технические идеи и некоторые забавные анекдоты о разработке этой новой службы.
Сегодня мы начнем с одного из самых частых вопросов, которые я задавал в первые дни бета-тестирования: как направить внешний трафик в мою службу Kubernetes? Этот вопрос возник часто, когда наши клиенты начали изучать Kubernetes, и когда я попытался ответить на него, я понял, что часть проблемы заключается в огромном количестве возможных ответов и концепциях, необходимых для их понимания.
С этим вопросом был связан запрос функции : большинству пользователей нужен инструмент балансировки нагрузки . Поскольку бета-версия предназначена для подтверждения стабильности продукта и проверки приоритетов набора функций, мы смогли быстро подтвердить
LoadBalancerЧтобы попытаться лучше ответить на вопрос о внешнем трафике и упростить внедрение
LoadBalancerЭто сообщение в блоге представляет собой расширенную версию этого руководства. Надеемся, оно вам пригодится!
Некоторые понятия: ClusterIP, NodePort, Ingress и LoadBalancer
Когда вы начинаете использовать Kubernetes для реальных приложений, один из первых вопросов, который нужно задать, — как получить внешний трафик в вашем кластере. В официальной документации предлагает полное (но довольно сухое) объяснение этой темы, но здесь мы будем объяснять его в более практических, служебной необходимости знать пути.
Есть несколько способов перенаправить внешний трафик в ваш кластер:
1. Использование Kubernetes прокси и ClusterIP: По умолчанию значения Kubernetes ServiceType является ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ к ClusterIp из внешнего источника, вы можете открыть прокси Kubernetes между внешним источником и кластером. Обычно это используется только для разработки.
2. Предоставление сервисов как NodePort: объявление Service as открывает NodePortего на IP-адресе каждого узла на статическом порте (называемом NodePort). Затем вы можете получить доступ к Service извне кластера, запросив :. Это также можно использовать для производства, хотя и с некоторыми ограничениями.
3. Предоставление услуг как LoadBalancer: объявление Service as LoadBalancer предоставляет его внешнему виду с помощью решения балансировки нагрузки поставщика облачных услуг. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Это наиболее широко используемый метод в производственной среде.
Использование прокси Kubernetes и ClusterIP
По умолчанию Kubernetes ServiceType это ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ ClusterIp с внешнего компьютера, вы можете открыть прокси Kubernetes между внешним компьютером и кластером.
Вы можете использовать kubectl для создания такого прокси. Когда прокси включен, вы напрямую подключены к кластеру и можете использовать для этого внутренний IP-адрес (ClusterIp) Service.
Этот метод не подходит для производственной среды, но он полезен для разработки, отладки и других быстрых и грязных операций.
Предоставление услуг как NodePort
Объявление службы как NodePort раскрывает Service IP-адрес каждого узла в NodePort (фиксированный порт для этого Serviceв диапазоне по умолчанию 30000-32767). Затем вы можете получить доступ к Service извне кластера, запросив :. Каждая служба, которую вы развертываете, NodePort будет отображаться в своем собственном порту на каждом узле.
Это довольно громоздким, чтобы использовать NodePortдля, Servicesкоторые находятся в производстве. Поскольку вы используете нестандартные порты, вам часто нужно настроить внешний балансировщик нагрузки, который прослушивает стандартные порты и перенаправляет трафик на :.
Предоставление услуг как LoadBalancer
Объявление службы типа LoadBalancer предоставляет ее внешнему виду с помощью балансировщика нагрузки облачного провайдера. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Как трафик от этого внешнего балансировщика нагрузки направляется в Service модули, зависит от поставщика кластера.
Это LoadBalancer лучший вариант для производственной среды, но с двумя оговорками:
- Все, Service что вы развернете LoadBalancer, получит собственный IP.
- LoadBalancer Обычно выставлен счет на основании количества выставляемых услуг, которые могут быть дорогими.
В настоящее время мы предлагаем услугу OVH Managed Kubernetes LoadBalancer в качестве бесплатной предварительной версии до конца лета 2019 года.
О чем Ingress?
Согласно официальной документации, Ingress это объект API, который управляет внешним доступом к службам в кластере (обычно HTTP). Так в чем разница между этим и LoadBalancer или NodePort?
Ingress это не тип Service, а объект, который действует как обратный прокси-сервер и единственная точка входа в ваш кластер, который направляет запрос различным службам. Самый простой из них Ingress — это NGINX Ingress Controller, где NGINX берет на себя роль обратного прокси, а также работает как SSL.
Ingress ClusterIP доступен за пределами кластера через прокси Kubernetes NodePort, или LoadBalancer, и направляет входящий трафик в соответствии с настроенными правилами.
Основное преимущество использования Ingress за одним LoadBalancer — это стоимость: вы можете иметь множество услуг за одним LoadBalancer.
Какой мне использовать?
Что ж, это вопрос на миллион долларов, и он, вероятно, вызовет разный ответ в зависимости от того, кого вы спросите!
Вы можете пойти на все 100% LoadBalancer, получив индивидуальную LoadBalancer услугу. Концептуально это просто: каждая служба независима и не требует дополнительной настройки. Обратной стороной является цена (вы будете платить за одну LoadBalancer услугу), а также сложность управления множеством разных IP-адресов.
Вы также можете использовать только один LoadBalancer и Ingress позади него. Все ваши службы будут находиться под одним и тем же IP-адресом, каждая по своему пути. Это более дешевый подход, поскольку вы платите только за одну LoadBalancer, но если ваши услуги не имеют логической взаимосвязи, это может быстро стать хаотичным.
Если вы хотите узнать мое личное мнение, я бы попытался использовать комбинацию из двух…
Подход мне нравится, имеющий LoadBalancer для каждого соответствующего набора услуг, а затем маршрутизации этих услуг используя Ingressпозади LoadBalancer. Например, предположим, что у вас есть два разных API на основе микросервисов, каждый из которых содержит около 10 сервисов. Я бы поставил один LoadBalancerперед другим Ingressдля каждого API, LoadBalancerпоскольку это единственная общедоступная точка входа и Ingressмаршрутизация трафика к различным службам API.
Но если ваша архитектура достаточно сложна (особенно если вы используете микросервисы), вы скоро обнаружите, что управлять всем вручную с помощью LoadBalancer и Ingress довольно громоздко. Если это так, ответом может быть делегирование этих задач сервисной сети…
Что такое сервисная сетка?
Возможно, вы слышали об Istio или Linkerd и о том, как они упрощают создание микросервисных архитектур на Kubernetes, добавляя изящные льготы, такие как A / B-тестирование, канареечные выпуски, ограничение скорости, контроль доступа и сквозную аутентификацию.
Istio, Linkerd и аналогичные инструменты представляют собой сети служб, которые позволяют создавать сети микросервисов и определять их взаимодействия, одновременно добавляя некоторые важные функции, которые упрощают настройку и работу архитектур на основе микросервисов.
Когда дело доходит до использования сервисных мешей в Kubernetes, есть о чем поговорить, но, как говорится, это уже история для другого раза…
0 комментариев