Hasta ahora, hemos estado usando el clúster público de GKE para todas nuestras cargas de trabajo. Hemos creado un segundo clúster privado (todavía GKE) con seguridad y disponibilidad mejoradas (el anterior es de una sola zona, el nuevo es un clúster regional). Usamos Gitlab.com para nuestro código, pero usamos el ejecutor Gitlab CI autohospedado en los clústeres.
El corredor funciona bien en el clúster público, todas las cargas de trabajo se completan correctamente. Sin embargo, en el clúster privado, todos los comandos kubectl de thr CI fallan con Unable to connect to the server: dial tcp <IP>:443: i/o timeout error. La configuración de CI no ha cambiado: la misma imagen base, todavía usa el SDK de gcloud con una cuenta de servicio específica de CI para autenticarse en el clúster.
Ambos clústeres tienen redes maestras autorizadas habilitadas y solo tienen configuradas las direcciones IP de nuestra oficina. Se puede acceder al maestro desde una IP pública. La autenticación es exitosa, el certificado de cliente y la autenticación básica están deshabilitados en ambos. Cloud NAT está configurado, los nodos tienen acceso a Internet (pueden extraer imágenes de contenedores, Gitlab CI puede conectarse, etc.).
¿Me estoy perdiendo alguna configuración vital? ¿Qué más debería estar mirando?
Solución del problema
si es gitlab.com, puede incluir su rango de IP en la lista blanca en las redes autorizadas maestras en GKE,
https://docs.gitlab.com/ee/user/gitlab_com/#ip-range
No hay comentarios.:
Publicar un comentario