Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione di indirizzi IP pubblici utilizzati privatamente per GKE

Autopilot Standard

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 rete Virtual Private Cloud (VPC) di Google Cloud. 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).

Indirizzi PUPI per il blocco GKE Pod CIDR.

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 i propri 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	Esporta impostazioni	Note
Producer	Comportamento predefinito (disattivato): non vengono importate le route di subnet con indirizzi IP pubblici Per attivarlo: --import-subnet-routes-with-public-ip (tramite peering)	Comportamento predefinito (attivato): esporta route di subnet con indirizzi IP pubblici Per disattivare: --no-export-subnet-routes-with-public-ip (tramite peering)	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 di produzione alla rete vpc-consumer deve essere tradotto dietro gli indirizzi dei nodi nel cluster di produzione.

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 negli indirizzi IP dei nodi corrispondenti 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 utilizzerai 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.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

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 o 192.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 e consumer).

Nota: gli intervalli PUPI sono supportati solo come intervalli di indirizzi IP secondari per la rete del pod in GKE e non possono essere utilizzati per l'intervallo di indirizzi IP principale (utilizzato da nodi e servizi).
1. 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 VPC default 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, come 10.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 (2¹⁸ indirizzi). L'intervallo scelto automaticamente viene selezionato in modo casuale da 10.0.0.0/8 (un intervallo di 2²⁴ indirizzi).
    - SERVICES_IP_RANGE: un intervallo di indirizzi IP in notazione CIDR (ad esempio 10.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 nel SUBNET_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 secondari esistente nel valore specificato.
2. 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 VPC default 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, come 10.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 (2¹⁸ indirizzi). L'intervallo scelto automaticamente viene selezionato in modo casuale da 10.0.0.0/8 (un intervallo di 2²⁴ 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 esempio 10.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 nel SUBNET_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 helloapp.

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.
Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.