He estado creando nuevos microservicios cada aproximadamente 2 meses durante el año pasado, siempre con el mismo proceso.
Reserva de IP privada
gcloud compute addresses create my-internal-lb \ --region europe-west3 \ --addresses 10.223.0.192 \ --subnet <subnet_name>y ponerlo en el servicio de kubernetes
apiVersion: v1 kind: Service metadata: name: <app_name_lb> annotations: cloud.google.com/load-balancer-type: "Internal" networking.gke.io/internal-load-balancer-allow-global-access: "true" labels: app: <app_name> env: <env> spec: type: LoadBalancer selector: app: <app_name> env: <env> ports: - port: 80 targetPort: 8080 protocol: TCP loadBalancerIP: 10.223.0.192 externalTrafficPolicy: Localpero en este momento veo mi nuevo servicio atascado en estado Pendiente
$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE <app_name_lb> LoadBalancer 10.190.93.199 <pending> 80:32767/TCP 22m y GCP ve la IP como RESERVED , no IN_USE , por lo que no debería haber ningún problema con eso, ¿alguien tiene idea de por qué sucede eso?
$ gcloud compute addresses list | grep "<app_name_lb>" <app_name_lb> 10.223.0.192 INTERNAL GCE_ENDPOINT europe-west3 <subnet_name> RESERVEDAgregaré que lo he hecho así varias veces, y otras aplicaciones funcionan bien
<other_app_lb> LoadBalancer 10.190.86.56 10.223.0.209 80:<32k port>/TCP 37dAgregaré que tuve este problema durante algunos días, y viniendo y dejándolo todo el tiempo, probado en múltiples subredes/zonas, diferentes IP siguen en el mismo estado Pendiente, cualquier ayuda será apreciada
Creo que podría haber alcanzado el límite de direcciones IN_USE, comprobando eso
¿Qué ves para kubectl describe svc <app_name_lb>? Debería haber un error.
Tenga en cuenta que si está utilizando la versión 1.17+, ahora es networking.gke.io/load-balancer-type: "Internal" en lugar de cloud.google.com/load-balancer-type: "Internal"
Tenga en cuenta también lo siguiente: según Restricciones para balanceadores de carga TCP/UDP internos :
Para los clústeres que ejecutan Kubernetes 1.7.X o posterior, mientras la IP del clúster permanece sin cambios, los balanceadores de carga TCP/UDP internos no pueden usar direcciones IP reservadas. El campo spec.loadBalancerIP todavía se puede definir usando una dirección IP no utilizada para asignar una IP interna específica.
Tenía cuotas límite en las direcciones EN USO, en los servicios de back-end y en las reglas de firewall que alcanzaban los límites (donde solo los servicios de back-end estaban en su límite); le pedí a Google que los aumentara y esperé un día para solucionar el problema.
Espero que esto siga siendo útil.
Veo que creaste la IP interna a través de Gcloud con estos comandos
gcloud compute addresses create my-internal-lb \ --region europe-west3 \ --addresses 10.223.0.192 \ --subnet <subnet_name>Sin embargo, te falta una bandera.
--propósito COMPARTIDO_LOADBALANCER_VIP
Esto es necesario para que el equilibrador de carga interno obtenga la IP interna estática que se le asigna. Además, si su clúster está en un proyecto de servicio de VPC compartida pero usa una red de VPC compartida en un proyecto host: entonces usaríamos
gcloud compute addresses create IP_ADDR_NAME \ --project SERVICE_PROJECT_ID \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --address= IP_ADDRESS \ --region REGION \ --purpose SHARED_LOADBALANCER_VIP