tutorial quickstart pricing google engine create cluster google-cloud-platform kubernetes google-kubernetes-engine

google-cloud-platform - quickstart - kubernetes engine google cloud



Cómo llamar a un servicio expuesto por un grupo de Kubernetes de otro grupo de Kubernetes en el mismo proyecto (2)

Tengo dos servicios, S1 en el clúster K1 y S2 en el clúster K2. Tienen diferentes requisitos de hardware. El servicio S1 necesita hablar con S2.

No quiero exponer Public IP para S2 por razones de seguridad. El uso de NodePorts en las instancias de cómputo del clúster K2 con el equilibrio de carga de la red elimina la flexibilidad, ya que tendría que agregar / eliminar las instancias de cómputo de K2 en el grupo objetivo cada vez que se agregue / elimine un nodo en K2.

¿Hay algo como "selector de servicio" para actualizar automáticamente el grupo objetivo? Si no es así, ¿hay algún otro enfoque mejor para este caso de uso?


Puedo pensar en un par de maneras de acceder a servicios a través de múltiples clústeres conectados a la misma red privada de GCP:

  1. Ruta de bastión en k2 para todos los servicios de k2:

    Busque el SERVICE_CLUSTER_IP_RANGE para el clúster k2. En GKE, será el campo servicesIpv4Cidr en la salida del clúster que describe:

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

    Agregue una regla de enrutamiento avanzada para tomar el tráfico destinado a ese rango y enrutarlo a un nodo en k2:

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

    Esto causará que k2-node-0 genere solicitudes desde la red privada para cualquiera de los servicios de k2. Esto tiene el inconveniente obvio de dar trabajo adicional a k2-node-0 , pero es simple.

  2. Instale el kube-proxy de k2 en todos los nodos en k1.

    Eche un vistazo al kube-proxy actualmente en ejecución en cualquier nodo en k2:

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

    Copie el archivo kubeconfig de k2 en cada nodo en k1 (digamos /var/lib/kube-proxy/kubeconfig-v2 ) e inicie un segundo proxy kube en cada nodo:

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

    Ahora, cada nodo en k1 maneja el proxy a k2 localmente. Un poco más difícil de configurar, pero tiene mejores propiedades de escala.

Como puede ver, ninguna de las soluciones es tan elegante. Están teniendo lugar discusiones sobre cómo debería funcionar idealmente este tipo de configuración en Kubernetes. Puede echar un vistazo al documento de propuestas de la Cluster Federation (específicamente la sección de Descubrimiento del Servicio de Cluster Server ) y unirse a la discusión abriendo temas / enviando RP.


GKE ahora es compatible con los equilibradores de carga internos: https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing

Su caso de uso principal es tener un equilibrador de carga que no esté expuesto a la Internet pública, por lo que se puede acceder a un servicio que se ejecuta en GKE desde otras máquinas virtuales GCE u otros clústeres GKE en la misma red.