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

Question

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

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

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

Answer 1

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

1. Бастионный маршрут в К2 для всех услуг К2:

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

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

   Добавьте расширенное правило маршрутизации, чтобы взять трафик, предназначенный для этого диапазона, и направить его на узел в 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 дополнительная работа, но это просто.

2. Установите kube-прокси на всех узлах в k1.

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

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

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

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

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

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

Answer 2

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

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