Wie Sie mit Cloud Build Private Pools auf Google Managed Services bereitstellen

Cloud Build ist ein serverloses Build-System. Es ermöglicht Ihnen die Ausführung von Builds in Ihrem privaten Netzwerk (VPC) unter Verwendung von Private Pools. Über die VPC-Verbindung können Sie auf die Ressourcen in Ihrer VPC zugreifen, aber nicht auf (gepeerte) verwaltete Dienste wie Google Kubernetes Engine (GKE) oder Cloud SQL. In diesem Blog zeige ich Ihnen, wie Sie diese Einschränkung überwinden und mit Cloud Build Private Pools auf GKE zugreifen können.

Umgang mit transitivem Peering

Für den Zugriff auf transitive Peer-Ressourcen empfiehlt die Cloud Build-Dokumentation eine VPN-basierte Lösung. Diese Lösung verwendet Cloud Router, um benutzerdefinierte Routen auszutauschen und den Datenverkehr an transitive Peers zu leiten. Der Nachteil dieser Lösung ist, dass Sie Ihren Datenverkehr nun über das Internet leiten und für ein VPN bezahlen, das Sie nur benötigen, wenn Sie einen Build ausführen.

Eine alternative Lösung ist der Einsatz eines IAP-Proxys. Dieser ermöglicht es Ihrer (öffentlichen) Cloud Build-Pipeline, sich sicher mit Ihrem Netzwerk zu verbinden. Diese Lösung löst den Preisaspekt der VPN-Lösung, indem sie winzige Instanz(en) verwendet. Bei dieser Lösung wird Ihr Datenverkehr jedoch nach wie vor über das Internet an den externen HTTP-Loadbalancer geleitet...

Eine weitere alternative Lösung ist der Austausch von Next-Hop-Routen mit Hilfe eines Internal Load Balancer. So können Sie Routen mit Peers austauschen und den Datenverkehr an eine benutzerdefinierte Netzwerk-Appliance weiterleiten. Diese Lösung löst den Preisaspekt der VPN-Lösung, indem sie winzige Netzwerk-Appliance(s) verwendet und Ihren Datenverkehr in der Cloud hält.

Lösung Design

Diese Lösung verwendet einen internen Load Balancer, um den Datenverkehr von Ihrem Cloud Build Private Pool zu Ihrer Google Kubernetes Engine Master-Instanz weiterzuleiten.

Der interne Load Balancer wird von einem NAT-Gateway unterstützt, das den Quellverkehr an die gepeerten Service-Netzwerke weiterleitet. Er fungiert sozusagen als Hub für Ihre gepeerten Ressourcen. So können Sie von Ihrem Cloud Build Private Pool aus auf Ihre internen Ressourcen zugreifen.

Finden Sie den Code auf GitHub.

Gateway-Konfiguration

Das Gateway ist eine VM, bei der das can-ip-forward-flag aktiviert ist. Dies ermöglicht es der VM, Pakete mit alternativen Zieladressen zu empfangen. Der Quellverkehr wird über iptables an das Ziel weitergeleitet.

# Allow forwarding packets to other destinations
echo 1 > /proc/sys/net/ipv4/ip_forward

# Forward all packages to other destinations
iptables -F
iptables -t nat -A POSTROUTING -j MASQUERADE

Routen Konfiguration

Damit der Cloud Build Private Pool das Gateway nutzen kann, müssen wir die Routen mit dem Peering des/der Google-Serviceproduzenten teilen: servicenetworking-googleapis-com-peer. Daher aktivieren wir die benutzerdefinierten Routenexporte und fügen eine statische Route zum gepeerten Dienst hinzu.

# Export custom routes with the Google service producer(s) peering.
resource "google_compute_network_peering_routes_config" "vpc_service_networking" {
  project = var.project_id
  network = google_compute_network.vpc.name
  peering = "servicenetworking-googleapis-com"

  import_custom_routes = false
  export_custom_routes = true

  depends_on = [google_service_networking_connection.vpc_service_networking]
}

# Add static route to the GKE master network
resource "google_compute_route" "gateway_routes" {
  project    = var.project_id
  name       = "vpc-tgw-gke"

  network      = "vpc"
  next_hop_ilb = google_compute_forwarding_rule.gateway.id
  priority     = 1000
  dest_range   = "10.20.0.0/24"
}

Stellen Sie sicher, dass Sie eine weniger spezifische Route austauschen, um Routing-Konflikte zu vermeiden.

Ergebnisse erstellen

Die Einrichtung wird validiert, indem ein Build ausgeführt und die Knoten des Kubernetes-Clusters abgefragt werden.

Das Gebäude ist definiert als:

steps:
  - name: gcr.io/cloud-builders/gcloud
    entrypoint: bash
    args:
      - '-c'
      - |
        gcloud container clusters get-credentials cluster1 --project <your-project> --zone europe-west1-d

        kubectl get nodes
options:
  workerPool: projects/<your-project>/locations/europe-west1/workerPools/pool-eu

Die Build-Protokolle berichten:

FETCHSOURCE
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
Initialized empty Git repository in /workspace/.git/
From https://source.developers.google.com/p/<your-project>/r/demo-b6e1
 * branch            4e453fdb377e075cadeba98d86bd1e4dd8b8a98d -> FETCH_HEAD
HEAD is now at 4e453fd Added cloudbuild.yaml
BUILD
Already have image (with digest): gcr.io/cloud-builders/gcloud
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster1.
NAME                                        STATUS   ROLES    AGE   VERSION
gke-cluster1-cluster1-node1-31add84f-tdjl   Ready    <none>   27m   v1.21.6-gke.1500
PUSH
DONE

Probieren Sie es selbst aus, indem Sie die Infrastruktur bereitstellen und einen Build mit den generierten Demo-Ressourcen anstoßen.

Diskussion

Es ist verwirrend, dass Cloud Build Private Pools nicht auf verwaltete Dienste wie Cloud SQL und GKE zugreifen können. Ich hätte wirklich gerne einen verwalteten Konnektivitätsdienst, um die Beschränkungen des transitiven Peerings zu überwinden und gleichzeitig den Datenverkehr kontrollieren zu können.

Die Kontrolle des Datenverkehrsflusses ist auch ein Thema in der vorgestellten Lösung. Das Gateway wird als Hub eingesetzt und ermöglicht es allen Google Service-Produzenten, GKE zu erreichen. Die gepeerten Google-Dienste sind erlaubt, weil sie ein einziges Service Networking Peering nutzen und daher die benutzerdefinierten Routen zu GKE erhalten. Gerne können wir Firewall-Regeln anwenden, um anderen Google-Diensten den Zugriff auf transitive Peers zu verwehren.

Eine alternative Lösung könnte einen Proxy verwenden, wie in der IAP-Proxy-Lösung gezeigt. Diese Lösung benötigt jedoch kein IAP, da Ihr Build bereits im Cloud-Netzwerk ausgeführt wird. Daher können Sie normale IAM-Berechtigungen verwenden, um Benutzern das Einreichen eines Builds oder den Zugriff auf die Kubernetes-Instanzen zu untersagen. Bei dieser Lösung ist außerdem keine Routing-Konfiguration erforderlich. Diese Konfiguration wird an den Endbenutzer delegiert, da er den Proxy-Endpunkt konfigurieren muss.

Fazit

Für die Bereitstellung von Google Managed Services aus Cloud Build Private Pools sind benutzerdefinierte Netzwerk-Appliances erforderlich. Sparen Sie Ihr Geld und halten Sie Ihren Datenverkehr in der Cloud, indem Sie eine benutzerdefinierte Routing-Appliance verwenden.

Foto von TimHill auf Pixabay