Questo tutorial mostra come applicare indirizzi IP pubblici utilizzati privatamente (PUPI) ai blocchi degli indirizzi dei pod di Google Kubernetes Engine (GKE).
Gli indirizzi IP pubblici utilizzati privatamente (PUPI) sono indirizzi che puoi utilizzare privatamente all'interno della tua Google Cloud rete Virtual Private Cloud (VPC). Questi indirizzi IP non sono di proprietà di Google. Non è necessario essere proprietari di questi indirizzi IP pubblici per utilizzarli privatamente.
Panoramica
I cluster GKE richiedono intervalli di indirizzi IP dedicati per nodi, pod e servizi. Con la crescita dell'infrastruttura, potresti dover fare i conti con l'esaurimento dello spazio di indirizzi IP interno standard (RFC 1918). Un modo per ridurre l'esaurimento degli indirizzi RFC 1918 privati è utilizzare indirizzi IP pubblici utilizzati privatamente (PUPI) per il blocco CIDR dei pod GKE. I PUPI forniscono un'alternativa per la rete del pod GKE, riservando indirizzi IP privati per altri componenti del cluster.
Cluster singolo: se crei un solo cluster GKE, puoi attivare gli IP pubblici utilizzati privatamente attivando gli intervalli di indirizzi IP esterni utilizzati privatamente.
Più cluster: se utilizzi più cluster GKE collegati tramite il peering VPC (uno scenario comune per i fornitori di servizi), avrai bisogno di una configurazione più complessa. Il seguente diagramma mostra un esempio di come un'azienda (producer) offre un servizio gestito utilizzando PUPI con il peering VPC a un cliente (consumer).
Il diagramma precedente prevede le seguenti considerazioni:
- Blocco CIDR principale: un blocco CIDR non PUPI utilizzato per i nodi e il bilanciatore del carico interno (ILB) e che non deve sovrapporsi tra le VPC.
- Blocco CIDR secondario del produttore: un blocco CIDR PUPI utilizzato per i pod
(ad esempio
45.45.0.0/16
). - Blocco CIDR secondario del consumatore: qualsiasi altro blocco CIDR PUPI sul lato del cliente (ad esempio
5.5.0.0/16
).
Come vengono utilizzati i PUPI in uno scenario di fornitore di servizi
Il fornitore di servizi (produttore) esegue il proprio servizio gestito su un
cluster GKE (gke-2) all'interno della propria VPC (vpc-producer
). Questo
cluster utilizza l'intervallo PUPI 45.0.0.0/8
per gli indirizzi IP dei pod.
Il cliente (consumatore) ha anche un cluster GKE (gke-1) nella propria VPC (vpc-consumer
), che utilizza un intervallo PUPI diverso, 5.0.0.0/8
, per gli indirizzi IP dei pod.
Queste due VPC sono connesse tramite il peering VPC, ma ciascuna continua a utilizzare indirizzi IP privati standard (RFC 1918) per nodi, servizi e bilanciatori del carico interni.
Garantire la comunicazione tra i VPC
- Da consumatore a produttore: per impostazione predefinita, la VPC del consumatore condivide automaticamente le route RFC 1918 (ma non i PUPI) con il produttore. In questo modo, le risorse nel VPC del consumer possono accedere ai servizi nel VPC del producer (in genere tramite bilanciatori del carico interni).
- Da produttore a consumer: per consentire ai pod del produttore di raggiungere le risorse nel VPC del consumer, è necessaria una configurazione esplicita.
- Nessuna sovrapposizione: il producer e il consumer devono assicurarsi che l'intervallo PUPI del consumer non sia in conflitto con gli indirizzi IP utilizzati nel VPC del producer.
- Esportazione/Importazione: il produttore deve attivare l'esportazione delle sue route PUPI e il consumatore deve attivare l'importazione di queste route tramite la connessione in peering.
Attivare la comunicazione quando gli intervalli PUPI si sovrappongono
Se la VPC del consumer utilizza già la stessa gamma PUPI del producer, la comunicazione diretta dai pod del producer non è possibile. Il produttore può invece attivare l'IP masquerading, in cui gli indirizzi IP dei pod vengono nascosti dietro gli indirizzi IP dei nodi del produttore.
La tabella seguente mostra le impostazioni di importazione ed esportazione predefinite per ogni VPC. Puoi modificare le impostazioni predefinite del peering VPC utilizzando il comando gcloud compute networks peerings update
.
Rete VPC | Impostazioni di importazione | Impostazioni di esportazione | Note |
---|---|---|---|
Producer | Comportamento predefinito (disattivato): non vengono importate le route di subnet con indirizzi IP pubblici |
Comportamento predefinito (attivato): esporta route di subnet con indirizzi IP pubblici |
Indicatori controllati tramite il networking di servizi. |
Consumer | Disattivata (impostazione predefinita) | Attivata (impostazione predefinita) | In genere gestito dal cliente, non deve essere modificato tramite la rete di servizi |
Queste impostazioni comportano quanto segue:
- Il VPC producer vede tutte le route del cliente.
- Il VPC consumer non vede le route PUPI configurate sulla subnet del pod nel VPC producer.
- Il traffico proveniente dai pod del producer alla rete
vpc-consumer
deve essere tradotto dietro gli indirizzi dei nodi nel cluster del producer.
Prerequisiti
Per stabilire una comunicazione efficace tra i pod VPC e un'altra VPC, assicurati che siano soddisfatti i seguenti prerequisiti e configurazioni:
- Il cluster GKE deve soddisfare i seguenti requisiti minimi per le versioni:
- Cluster Autopilot: GKE versione 1.22 o successive
- Cluster standard: GKE versione 1.14 o successive
- Seleziona un intervallo PUPI che non sia pubblicamente instradabile o di proprietà di Google.
- Assicurati che gli indirizzi IP dei nodi e l'intervallo di indirizzi IP principale di entrambe le VPC non si sovrappongano.
- Se hai bisogno di una comunicazione diretta tra pod della VPC del cliente e del servizio gestito, segui questi passaggi:
- Cluster Autopilot: configura SNAT per PUPI per garantire la comunicazione tra pod. Non è richiesta alcuna configurazione aggiuntiva.
- Cluster standard: traduci gli indirizzi IP dei pod nei relativi indirizzi IP dei nodi utilizzando SNAT. Attiva SNAT per il traffico PUPI. Per ulteriori informazioni, consulta Abilitare intervalli di indirizzi IP esterni utilizzati privatamente.
Configurare indirizzi IP pubblici utilizzati privatamente per i cluster GKE
Per configurare gli indirizzi PUPI per i cluster GKE:
- Configura due reti Virtual Private Cloud.
- Configura una subnet all'interno di ogni rete Virtual Private Cloud.
- Configura un intervallo di indirizzi PUPI su un intervallo di indirizzi secondario in ogni subnet.
- Stabilisci una relazione di peering Virtual Private Cloud tra le due reti Virtual Private Cloud con le impostazioni di importazione ed esportazione appropriate.
- Controlla le route all'interno di ogni Virtual Private Cloud.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installa e poi
inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
Utilizza solo cluster nativi di VPC.
Configura le specifiche IPAM richieste per il peering VPC.
Configurare reti e cluster
Crea reti VPC:
Crea le seguenti due reti VPC con RFC-1918 come intervalli principali per i nodi e intervalli PUPI per i pod. Assegna intervalli di indirizzi IP primari dello spazio indirizzi privato RFC 1918 (ad esempio
10.x.x.x
,172.16.x.x
o192.168.x.x
) a entrambi i VPC. Questi intervalli vengono tipicamente utilizzati per i nodi worker all'interno dei cluster GKE. Oltre agli intervalli di indirizzi IP interni, designa intervalli distinti di indirizzi IP pubblici utilizzati privatamente (PUPI) per ogni VPC. Questi intervalli PUPI vengono utilizzati esclusivamente per gli indirizzi IP dei pod all'interno dei cluster GKE corrispondenti.Rete VPC consumer: questa VPC ospita il cluster GKE in cui vengono eseguite le applicazioni o i carichi di lavoro del consumer. Puoi utilizzare una configurazione simile alla seguente:
Network: consumer Subnetwork: consumer-subnet Primary range: 10.129.0.0/24 Service range name and cidr: consumer-services, 172.16.5.0/24 Pod range name and cidr: consumer-pods, 5.5.5.0/24 Cluster name: consumer-cluster
Rete VPC del producer: questa VPC ospita il cluster GKE responsabile della fornitura del servizio utilizzato dal consumer. Puoi utilizzare una configurazione simile alla seguente:
Network: producer Subnetwork: producer-subnet Primary range: 10.128.0.0/24 Service range name and cidr: producer-services, 172.16.45.0/24 Pod range name and cidr: producer-pods, 45.45.45.0/24 Cluster name: producer-cluster
Per ulteriori informazioni sulla creazione di reti VPC, consulta Creare reti VPC.
Con le reti e le subnet VPC create con gli intervalli PUPI nel passaggio precedente, puoi creare due cluster GKE (
producer
econsumer
).Crea cluster
producer
con la rete e la subnet del produttore come segue:gcloud container clusters create PRODUCER_CLUSTER_NAME \ --enable-ip-alias \ --network=NETWORK_NAME \ --subnetwork=SUBNETWORK_NAME \ --cluster-secondary-range-name=PRODUCER_PODS \ --services-secondary-range-name=PRODUCER_SERVICES \ --num-nodes=1 \ --zone=PRODUCER_ZONE_NAME \ --project=PRODUCER_PROJECT_NAME
Sostituisci quanto segue:
PRODUCER_CLUSTER_NAME
: il nome del cluster di produttori GKE.COMPUTE_LOCATION
: la posizione di Compute Engine per il cluster.PRODUCER_SUBNET_NAME
: il nome di una subnet esistente. L'intervallo di indirizzi IP principale della subnet viene utilizzato per i nodi. La subnet deve essere presente nella stessa regione utilizzata dal cluster. Se omesso, GKE tenta di utilizzare una subnet nella rete VPCdefault
nella regione del cluster.- Se il metodo di assegnazione dell'intervallo secondario è gestito da GKE:
POD_IP_RANGE
: un intervallo di indirizzi IP in notazione CIDR, come10.0.0.0/14
, o la dimensione della maschera di sottorete di un blocco CIDR, come/14
. Viene utilizzato per creare l'intervallo di indirizzi IP secondario della subnet per i pod. Se ometti l'opzione--cluster-ipv4-cidr
, GKE sceglie automaticamente un intervallo/14
(218 indirizzi). L'intervallo scelto automaticamente viene selezionato in modo casuale da10.0.0.0/8
(un intervallo di 224 indirizzi).SERVICES_IP_RANGE
: un intervallo di indirizzi IP in notazione CIDR (ad esempio10.4.0.0/19
) o la dimensione della subnet mask di un blocco CIDR (ad es./19
). Viene utilizzato per creare l'intervallo di indirizzi IP secondario della subnet per i servizi.
- Se il metodo di assegnazione dell'intervallo secondario è gestito dall'utente:
SECONDARY_RANGE_PODS
: il nome di un intervallo di indirizzi IP secondari esistente inSUBNET_NAME
specificato. GKE utilizza l'intero intervallo di indirizzi IP secondario della subnet per i pod del cluster.SECONDARY_RANGE_SERVICES
: il nome di un intervallo di indirizzi IP secondario esistente nel valore specificato.
Crea cluster
consumer
con la rete e la subnet del consumatore come segue:gcloud container clusters create CONSUMER_CLUSTER_NAME \ --enable-ip-alias \ --network=CONSUMER_NETWORK_NAME \ --subnetwork=CONSUMER_SUBNETWORK_NAME \ --cluster-secondary-range-name=CONSUMER_PODS \ --services-secondary-range-name=CONSUMER_SERVICES \ --num-nodes=1 \ --zone=CONSUMER_ZONE \ --project=CONSUMER_PROJECT
Sostituisci quanto segue:
CONSUMER_CLUSTER_NAME
: il nome del cluster consumer GKE.COMPUTE_LOCATION
: la posizione di Compute Engine per il cluster.CONSUMER_SUBNET_NAME
: il nome di una subnet esistente. L'intervallo di indirizzi IP principale della subnet viene utilizzato per i nodi. La subnet deve essere presente nella stessa regione utilizzata dal cluster. Se omesso, GKE tenta di utilizzare una subnet nella rete VPCdefault
nella regione del cluster.- Se il metodo di assegnazione dell'intervallo secondario è gestito da GKE:
POD_IP_RANGE
: un intervallo di indirizzi IP in notazione CIDR, come10.0.0.0/14
, o la dimensione della maschera di sottorete di un blocco CIDR, come/14
. Viene utilizzato per creare l'intervallo di indirizzi IP secondario della subnet per i pod. Se ometti l'opzione--cluster-ipv4-cidr
, GKE sceglie automaticamente un intervallo/14
(218 indirizzi). L'intervallo scelto automaticamente viene selezionato in modo casuale da10.0.0.0/8
(un intervallo di 224 indirizzi) e non include gli intervalli di indirizzi IP allocati alle VM, i percorsi esistenti o gli intervalli allocati ad altri cluster. L'intervallo scelto automaticamente potrebbe essere in conflitto con indirizzi IP riservati, route dinamici o route all'interno di VPC in peering con questo cluster. Se utilizzi uno di questi valori, devi specificare--cluster-ipv4-cidr
per evitare conflitti.SERVICES_IP_RANGE
: un intervallo di indirizzi IP in notazione CIDR (ad esempio10.4.0.0/19
) o la dimensione della subnet mask di un blocco CIDR (ad es./19
). Viene utilizzato per creare l'intervallo di indirizzi IP secondario della subnet per i servizi.
- Se il metodo di assegnazione dell'intervallo secondario è gestito dall'utente:
SECONDARY_RANGE_PODS
: il nome di un intervallo di indirizzi IP secondari esistente inSUBNET_NAME
specificato. GKE utilizza l'intero intervallo di indirizzi IP secondario della subnet per i pod del cluster.SECONDARY_RANGE_SERVICES
: il nome di un intervallo di indirizzi IP secondario esistente nel valore specificato.
Per ulteriori informazioni sulla creazione di cluster, vedi Creare cluster.
Stabilisci la relazione di peering VPC tra la rete VPC consumer e la rete VPC producer come segue:
Per collegare la rete
consumer
al produttore, esegui il seguente comando:gcloud compute networks peerings create PEERING_NAME \ --project=consumer_project \ --network=consumer \ --peer-network=producer
Per connettere la rete
producer
al consumatore, esegui il seguente comando:gcloud compute networks peerings create PEERING_NAME \ --project=producer_project \ --network=producer \ --peer-network=consumer \ --no-export-subnet-routes-with-public-ip \ --import-subnet-routes-with-public-ip
Sostituisci quanto segue:
PEERING_NAME
: il nome del cluster consumer GKE.CONSUMER_CLUSTER_NAME
: il nome del cluster consumer GKE.
Per impostazione predefinita, la VPC del consumatore esporta gli indirizzi PUPI. Quando crei il VPC del produttore, utilizza i seguenti argomenti per configurare il VPC in modo che importi gli indirizzi PUPI, ma non li esporti:
--no-export-subnet-routes-with-public-ip --import-subnet-routes-with-public-ip
Verifica le reti e le subnet
Verifica la rete del produttore:
gcloud compute networks describe producer \ --project=producer_project
L'output è simile al seguente:
... kind: compute#network name: producer peerings: - autoCreateRoutes: true exchangeSubnetRoutes: true exportCustomRoutes: false exportSubnetRoutesWithPublicIp: false importCustomRoutes: false importSubnetRoutesWithPublicIp: true name: producer-peer-consumer …
Verifica la sottorete del produttore:
gcloud compute networks subnets describe producer-subnet \ --project=producer_project\ --region=producer_region
L'output è simile al seguente:
... ipCidrRange: 10.128.0.0/24 kind: compute#subnetwork name: producer-subnet … secondaryIpRanges: - ipCidrRange: 172.16.45.0/24 rangeName: producer-services - ipCidrRange: 45.45.45.0/24 rangeName: producer-pods …
Verifica la rete del consumatore:
gcloud compute networks subnets describe consumer-subnet \ --project=consumer_project \ --region=consumer_region
L'output è simile al seguente:
... kind: compute#network name: consumer peerings: - autoCreateRoutes: true exchangeSubnetRoutes: true exportCustomRoutes: false exportSubnetRoutesWithPublicIp: true importCustomRoutes: false importSubnetRoutesWithPublicIp: false name: consumer-peer-producer ...
Verifica la sottorete del consumatore:
gcloud compute networks describe consumer \ --project=consumer_project
L'output è simile al seguente:
... ipCidrRange: 10.129.0.0/24 kind: compute#subnetwork name: consumer-subnet ... secondaryIpRanges: - ipCidrRange: 172.16.5.0/24 rangeName: consumer-services - ipCidrRange: 5.5.5.0/24 rangeName: consumer-pods ...
Verifica il cluster GKE e le relative risorse
Recupera le credenziali del cluster consumer:
gcloud container clusters get-credentials consumer-cluster \ --project=consumer_project \ --zone=consumer_zone
L'output è simile al seguente:
... Fetching cluster endpoint and auth data. kubeconfig entry generated for consumer-cluster. ...
Installa e verifica l'app hello.
In alternativa, puoi salvare il seguente manifest come
deployment.yaml
:kubectl apply -f - <<'EOF' apiVersion: apps/v1 kind: Deployment metadata: name: helloweb labels: app: hello spec: selector: matchLabels: app: hello tier: web template: metadata: labels: app: hello tier: web spec: containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 ports: - containerPort: 8080 resources: requests: cpu: 200m EOF
Applica il file deployment.yaml:
kubectl apply -f
Verifica il deployment di
helloweb
:kubectl get deployment helloweb
L'output è simile al seguente:
... NAME READY UP-TO-DATE AVAILABLE AGE helloweb 1/1 1 1 10s ...
Verifica della soluzione
Verifica di aver creato correttamente il peering VPC:
gcloud compute networks peerings list
L'output è simile al seguente, che mostra i peering denominati consumer e producer:
NAME NETWORK PEER_PROJECT PEER_NETWORK STACK_TYPE PEER_MTU IMPORT_CUSTOM_ROUTES EXPORT_CUSTOM_ROUTES STATE STATE_DETAILS consumer-peer-producer consumer <project_name> producer IPV4_ONLY 1460 False False ACTIVE [2023-08-07T13:14:57.178-07:00]: Connected. producer-peer-consumer producer <project_name> consumer IPV4_ONLY 1460 False False ACTIVE [2023-08-07T13:14:57.178-07:00]: Connected.
Verifica che il VPC consumer esegua l'esportazione delle route PUPI:
gcloud compute networks peerings list-routes consumer-peer-producer \ --direction=OUTGOING \ --network=consumer \ --region=<consumer_region>
L'output è simile al seguente, che mostra tutti e tre i blocchi CIDR consumer:
DEST_RANGE TYPE NEXT_HOP_REGION PRIORITY STATUS 10.129.0.0/24 SUBNET_PEERING_ROUTE us-central1 0 accepted by peer 172.16.5.0/24 SUBNET_PEERING_ROUTE us-central1 0 accepted by peer 5.5.5.0/24 SUBNET_PEERING_ROUTE us-central1 0 accepted by peer
Convalida le route PUPI importate dalla VPC del produttore:
gcloud compute networks peerings list-routes producer-peer-consumer \ --direction=INCOMING \ --network=producer \ --region=<producer_region>
L'output è simile al seguente, che mostra tutti e tre i blocchi CIDR consumer:
DEST_RANGE TYPE NEXT_HOP_REGION PRIORITY STATUS 10.129.0.0/24 SUBNET_PEERING_ROUTE us-central1 0 accepted 172.16.5.0/24 SUBNET_PEERING_ROUTE us-central1 0 accepted 5.5.5.0/24 SUBNET_PEERING_ROUTE us-central1 0 accepted
Verifica che i pod GKE abbiano un indirizzo PUPI:
kubectl get pod -o wide
L'output è simile al seguente, che mostra che gli indirizzi IP dei pod rientrano nell'intervallo 5.5.5/24.
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES helloweb-575d78464d-xfklj 1/1 Running 0 28m 5.5.5.16 gke-consumer-cluster-default-pool-e62b6542-dp5f <none> <none>
Passaggi successivi
- Leggi la guida Configurare l'accesso privato ai servizi.
- Leggi la guida Introduzione all'API Service Networking.
- Scopri architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.