Как включить экземпляры сервера Kubernetes api для подключения к внешним сетям через прокси

Question

Цель состоит в том, чтобы позволить серверу Kubernetes api подключаться к ресурсам в Интернете, когда он находится в частной сети, доступ к Интернет-ресурсам которой возможен только через прокси.

Справочная информация:

Кластер kubernetes запускается с помощью kubespray, содержащего два экземпляра apiserver, которые работают на двух виртуальных машинах и управляются через файл манифеста.Azure AD используется в качестве поставщика удостоверений для проверки подлинности.Чтобы это работало, сервер API должен инициализировать свой компонент OIDC, подключившись к Microsoft и загрузив некоторые ключи, которые используются для проверки токенов, выпущенных Azure AD.

Поскольку кластер Kubernetes находится в частной сети и должен пройти через прокси-сервер, прежде чем выходить в Интернет, одним из подходов было установить https_proxy и no_proxy в среде контейнера сервера API kubernetes, добавив это в файл манифеста.Проблема этого подхода заключается в том, что при использовании Istio для управления доступом к API, no_proxy необходимо обновлять всякий раз, когда в кластер добавляется новая служба.Одним из решений могло быть добавление суффикса к каждому имени службы и установка * .suffix без прокси.Однако, похоже, что использование подстановочных знаков в конфигурации no_proxy не поддерживается.

Есть ли какой-либо альтернативный способ для сервера API Kubernetes связаться с Microsoft без вмешательства в другие функции?

Пожалуйста, дайте мне знатьесли требуется какая-либо дополнительная информация или разъяснения.

Answer 1

Мы испробовали несколько решений, чтобы избежать необходимости устанавливать переменные http (s) _proxy и no_proxy env в kube-apiserver и постоянно добавлять новые службы в белый список в кластере ...

1. Представьте прокси-сервер с самоуправлением, который определит, какой трафик направляется на прокси-сервер, подключенный к Интернету, а какой трафик не проксируется:

   • прокси-сервер squid, похоже, добился цели, определив некоторые ACL.Одна из проблем, с которой мы столкнулись, заключалась в том, что имена узлов не были решены с помощью kube-dns, поэтому нам пришлось добавлять записи вручную в файлы хостов контейнеров (не знаю, как они обрабатывались по умолчанию).
   • мы также попытались написатьиспользуя прокси-узел, но в некоторых сценариях возникли проблемы с https.

2. Внедрите самостоятельно управляемый провайдер идентификации между azure и нашим кластером k8s, который был настроен на использование прокси-сервера, подключенного к Интернету.избегая необходимости настраивать прокси-сервер в kube-apiserver

Мы получили доступ к варианту 2, поскольку он дал нам большую гибкость в долгосрочной перспективе.

Answer 2

Я не уверен, как вы заставите Istio управлять выходным трафиком для ваших мастеров Kubernetes, где работают ваши kube-apiservers, поэтому я бы не рекомендовал это.Насколько я понимаю, Istio обычно используется для управления (входной / выходной / lb / metrics / etc) фактическими рабочими нагрузками в вашем кластере, и эти рабочие нагрузки обычно выполняются на ваших узлах, а не на основных.Я имею в виду, что kube-apiserver фактически управляет CRD , которые использует Istio.

Большинство людей используют Docker на своих мастерах, вы можете использовать переменные окружения proxy для своих контейнеровкак вы упомянули.