Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

350
Vistas
No se puede acceder al servicio de Kubernetes de un clúster a otro (a través de intercambio de tráfico de VPC)

Me pregunto si alguien puede ayudar con mi problema, aquí está la configuración:

  • Tenemos 2 clústeres de kubernetes separados en GKE, que se ejecutan en v1.17, y cada uno de ellos se encuentra en un proyecto separado
  • Hemos configurado el emparejamiento de VPC entre los dos proyectos.
  • En el clúster 1, tenemos 'servicio 1' que está expuesto por un balanceador de carga HTTPS interno , no queremos que esto sea público
  • En el clúster 2, tenemos la intención de poder acceder al 'servicio 1' a través del balanceador de carga interno, y debería hacerlo a través de la interconexión de VPC entre los dos proyectos.

Aquí está el problema: cuando estoy conectado a través de SSH en un nodo de GKE en el clúster 2, puedo ejecutar correctamente una solicitud curl para acceder a https://service1.domain.com que se ejecuta en el clúster 1 y obtener la respuesta esperada, por lo que el tráfico definitivamente está enrutando desde el clúster 2 > clúster 1. Sin embargo, cuando ejecuto el mismo comando curl desde un POD, ejecutándolo en un nodo GKE, la misma solicitud curl se agota.

He ejecutado la mayor cantidad de solución de problemas que he podido, incluidos telnet, traceroute, etc. y estoy realmente atascado por qué podría ser esto. Si alguien puede arrojar luz sobre la diferencia aquí, sería genial.

Me preguntaba si la red de pods de alguna manera está reenviando el tráfico a través de la IP pública de los clústeres en lugar de a través de la conexión de interconexión de VPC.

over 4 years ago · Santiago Trujillo
3 Respuestas
Responde la pregunta

0

Como se mencionó en una de las respuestas , los alias de IP (nativos de VPC) deberían funcionar de forma inmediata. Si usa un clúster de GKE basado en rutas en lugar de nativo de VPC, necesitará usar rutas personalizadas.

Según este documento

De forma predeterminada, se admite el intercambio de tráfico entre redes de VPC con GKE cuando se usa con alias de IP. Si no usa alias de IP, puede exportar rutas personalizadas para que los contenedores de GKE sean accesibles desde redes emparejadas.

Esto también se explica en este documento.

Si tiene clústeres de GKE sin direccionamiento nativo de VPC, es posible que tenga varias rutas estáticas para dirigir el tráfico a las instancias de VM que alojan sus contenedores. Puede exportar estas rutas estáticas para que los contenedores sean accesibles desde redes emparejadas.

over 4 years ago · Santiago Trujillo Denunciar

0

Entonces parece que no está utilizando un clúster "nativo de VPC" y lo que necesita es "enmascaramiento de IP".

De este documento: "Un clúster de GKE usa enmascaramiento de IP para que los destinos fuera del clúster solo reciban paquetes de direcciones IP de nodos en lugar de direcciones IP de pods. Esto es útil en entornos que esperan recibir paquetes solo de direcciones IP de nodos".

Puede usar ip-masq-agent o k8s-custom-iptables . Después de esto, funcionará, ya que será como si estuviera haciendo una llamada desde el nodo, no dentro del módulo.

over 4 years ago · Santiago Trujillo Denunciar

0

El problema al que se enfrenta parece similar al mencionado en esta pregunta SO , ¿quizás sus pods están usando direcciones IP fuera del rango de VPC y, por ese motivo, no pueden acceder a la VPC interconectada?

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda