Как вызвать службу, открытую кластером Kubernetes из другого кластера Kubernetes в том же проекте

У меня есть две службы, S1 в кластере K1 и S2 в кластере K2. У них разные требования к оборудованию. Службе S1 необходимо поговорить с S2.

Я не хочу публиковать публичный IP-адрес для S2 из-за соображений безопасности. Использование NodePorts в экземплярах вычислений кластера K2 с балансировкой нагрузки сети требует гибкости, так как мне придется добавлять/удалять экземпляры K2 в целевом пуле каждый раз при добавлении/удалении node в K2.

Есть ли что-то вроде "service-selector" для автоматического обновления целевого пула? Если нет, есть ли другой лучший подход для этого случая использования?

Ответ 1

Я могу представить несколько способов доступа к службам через несколько кластеров, подключенных к одной и той же частной сети GCP:

  • Бастионный маршрут в k2 для всех услуг k2:

    Найдите SERVICE_CLUSTER_IP_RANGE для кластера k2. В GKE это будет поле servicesIpv4Cidr на выходе кластера:

    $ gcloud beta container clusters describe k2
    ...
    servicesIpv4Cidr: 10.143.240.0/20
    ...
    

    Добавьте расширенное правило маршрутизации, чтобы взять трафик, предназначенный для этого диапазона, и перенаправить его на node в k2:

    $ gcloud compute routes create --destination-range 10.143.240.0/20 --next-hop-instance k2-node-0
    

    Это вызовет запросы k2-node-0 к прокси-серверам из частной сети для любой из служб k2. Это имеет очевидный недостаток в предоставлении дополнительной работы k2-node-0, но это просто.

  • Установите k2-kxy-прокси на всех узлах в k1.

    Взгляните на текущий запущенный kube-прокси на любом node в k2:

    $ ps aux | grep kube-proxy
    ... /usr/local/bin/kube-proxy --master=https://k2-master-ip --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
    

    Скопируйте файл k2 kubeconfig в каждый node в k1 (скажем /var/lib/kube-proxy/kubeconfig-v2) и запустите второй kube-прокси на каждом node:

    $ /usr/local/bin/kube-proxy --master=https://k2-master-ip --kubeconfig=/var/lib/kube-proxy/kubeconfig-k2 --healthz-port=10247
    

    Теперь каждый node в k1 обрабатывает проксирование на k2 локально. Немного сложнее настроить, но имеет лучшие масштабирующие свойства.

Как вы можете видеть, ни одно решение не является элегантным. Происходят дискуссии о том, как этот тип установки должен идеально работать в Кубернете. Вы можете ознакомиться с предложением > "Кластерная федерация" (в частности, > Обнаружение нескольких кластеров) и присоединяйтесь к обсуждению, открыв проблемы/отправьте PR.

Ответ 2

GKE теперь поддерживает внутренние балансировки нагрузки: https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing

В основном случае используется балансировщик нагрузки, который не подвергается общедоступному Интернету, поэтому доступ к сервису, запущенному на GKE, можно получить из других виртуальных машин GCE или других кластеров GKE в той же сети.