Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione di indirizzi IP pubblici utilizzati privatamente per GKE

Autopilot Standard

Questa pagina mostra come applicare gli indirizzi IP pubblici utilizzati privatamente (PUPI) ai blocchi degli indirizzi dei pod di Google Kubernetes Engine (GKE).

Gli indirizzi IP pubblico utilizzato privatamente (PUPI) sono indirizzi che puoi utilizzare privatamente all'interno della tua rete Virtual Private Cloud (VPC) 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. Man mano che la tua infrastruttura cresce, potresti riscontrare l'esaurimento dello spazio di indirizzi IP interni standard (RFC 1918). Un modo per mitigare l'esaurimento degli indirizzi RFC 1918 privati è utilizzare indirizzi IP pubblici utilizzati privatamente (PUPI) per il blocco CIDR pod GKE. Gli indirizzi IP privati utilizzati dai pod forniscono un'alternativa per la rete di pod GKE, riservando indirizzi IP privati per altri componenti del cluster.

Singolo cluster: se crei un solo cluster GKE, puoi attivare gli IP pubblici utilizzati privatamente abilitando gli intervalli di indirizzi IP esterni utilizzati privatamente.

Più cluster: se lavori con più cluster GKE connessi tramite 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 CIDR dei pod GKE.

Il diagramma precedente comporta le seguenti considerazioni:

Blocco CIDR principale: un blocco CIDR non PUPI utilizzato per i nodi e il bilanciatore del carico interno (ILB) e non deve sovrapporsi alle 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 consumer: qualsiasi altro blocco CIDR PUPI sul lato cliente (ad esempio, 5.5.0.0/16).

Come vengono utilizzati i PUPI in uno scenario di fornitore di servizi

Il fornitore di servizi (producer) esegue il proprio servizio gestito su un cluster GKE (gke-2) all'interno del proprio VPC (vpc-producer). Questo cluster utilizza l'intervallo PUPI 45.0.0.0/8 per i suoi indirizzi IP pod.

Il cliente (consumatore) ha anche un cluster GKE (gke-1) nel proprio VPC (vpc-consumer), utilizzando un intervallo PUPI diverso, 5.0.0.0/8, per i suoi indirizzi IP dei pod.

Questi due VPC sono connessi tramite il peering VPC, ma ciascuno continua a utilizzare indirizzi IP privati standard (RFC 1918) per nodi, servizi e bilanciatori del carico interni.

Garantire la comunicazione tra i VPC

Consumer to Producer: per impostazione predefinita, il VPC consumer condivide automaticamente le proprie route RFC 1918 (ma non i PUPI) con il producer. Ciò consente alle risorse nel VPC del consumer di accedere ai servizi nel VPC del producer (in genere tramite bilanciatori del carico interni).
Dal produttore al consumer: affinché i pod del produttore raggiungano 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 alcun indirizzo IP utilizzato nel VPC del producer.
Esportazione/Importazione: il produttore deve abilitare l'esportazione delle proprie route PUPI e il consumer deve abilitare l'importazione di queste route tramite la connessione in peering.

Attivare la comunicazione quando gli intervalli PUPI si sovrappongono

Se il VPC consumer utilizza già lo stesso intervallo PUPI del producer, la comunicazione diretta dai pod producer non è possibile. Il produttore può invece attivare l'IP masquerading, in cui gli indirizzi IP dei pod sono nascosti dietro gli indirizzi IP dei nodi del produttore.

La tabella seguente mostra le impostazioni di importazione ed esportazione predefinite per ciascun VPC. Puoi modificare le impostazioni di peering VPC predefinite utilizzando il comando gcloud compute networks peerings update.

Rete VPC	Impostazioni di importazione	Esporta impostazioni	Note
Producer	Comportamento predefinito (disattivato): non importa le route di subnet con indirizzi IP pubblici Per attivare: --import-subnet-routes-with-public-ip (tramite peering)	Comportamento predefinito (attivato): esporta le route di subnet con indirizzi IP pubblici Per disattivare: --no-export-subnet-routes-with-public-ip (tramite peering)	Flag controllati tramite il networking di servizi.
Consumer	Disattivato (impostazione predefinita)	Attivato (impostazione predefinita)	In genere gestito dal cliente, non è necessario modificarlo tramite il servizio di networking

Queste impostazioni comportano quanto segue:

Il VPC producer vede tutte le route del cliente.
Il VPC consumer non vede le route PUPI configurate nella subnet del pod nel VPC producer.
Il traffico proveniente dai pod producer alla rete vpc-consumer deve essere tradotto dietro gli indirizzi dei nodi nel cluster producer.

Prerequisiti

Per stabilire una comunicazione corretta tra i pod VPC e un altro VPC, assicurati che siano soddisfatti i seguenti prerequisiti e configurazioni:

Il cluster GKE deve soddisfare i seguenti requisiti di versione minima:
- Cluster Autopilot: GKE versione 1.22 o successive
- Cluster Standard: GKE versione 1.14 o successive
Seleziona un intervallo PUPI non instradabile pubblicamente o di proprietà di Google.
Assicurati che gli indirizzi IP dei nodi e l'intervallo di indirizzi IP principali di entrambi i VPC non si sovrappongano.
Se hai bisogno di una comunicazione diretta tra pod e pod tra il VPC del cliente e il servizio gestito, segui questi passaggi:
- Cluster Autopilot: configura SNAT per PUPI per garantire la comunicazione pod-to-pod. Non è necessaria alcuna configurazione aggiuntiva.
- Cluster standard: traducono gli indirizzi IP dei pod nei rispettivi indirizzi IP dei nodi utilizzando SNAT. Attiva SNAT per il traffico PUPI. Per saperne di più, consulta Abilitare gli intervalli di indirizzi IP esterni utilizzati privatamente.

Configura 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 in un intervallo di indirizzi secondario in ogni subnet.
Stabilisci una relazione di peering Virtual Private Cloud tra le due reti Virtual Private Cloud con impostazioni di importazione ed esportazione appropriate.
Esamina 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à, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
Nota:per le installazioni esistenti di gcloud CLI, assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Utilizza solo cluster nativi di VPC.
Configura le specifiche IPAM richieste per il peering VPC.

Configura reti e cluster

Crea reti VPC:

Crea le due reti VPC seguenti con RFC-1918 come intervalli primari per i nodi e intervalli PUPI per i pod. Assegna intervalli di indirizzi IP primari dallo spazio di indirizzi privati RFC 1918 (ad esempio 10.x.x.x, 172.16.x.x o 192.168.x.x) a entrambi i VPC. Questi intervalli vengono in genere utilizzati per i nodi worker all'interno dei cluster GKE. Oltre agli intervalli di indirizzi IP interni, designa intervalli separati 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 rispettivi cluster GKE.
- Rete VPC consumer: questo 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: questo 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 Crea reti VPC.
Con le reti VPC e le subnet 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 Pod in GKE e non possono essere utilizzati per l'intervallo di indirizzi IP primari (utilizzato da nodi e servizi).
1. Crea producer cluster con la rete e la subnet del produttore nel seguente modo:
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --location=PRODUCER_CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --network=PRODUCER_NETWORK_NAME \
    --subnetwork=PRODUCER_SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --project=PRODUCER_PROJECT_ID
```
  Sostituisci quanto segue:
  - PRODUCER_CLUSTER_NAME: il nome del cluster di produzione GKE.
  - PRODUCER_CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del cluster di produzione. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
  - PRODUCER_NETWORK_NAME: il nome di una rete VPC del produttore esistente.
  - PRODUCER_SUBNETWORK_NAME: il nome di una subnet esistente. L'intervallo di indirizzi IP principale della subnet viene utilizzato per i nodi. La subnet deve esistere 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 nella notazione CIDR, ad esempio 10.0.0.0/14, o la dimensione di una maschera di subnet del blocco CIDR, ad esempio /14. Viene utilizzato per creare l'intervallo di indirizzi IP secondari 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 nella notazione CIDR (ad esempio, 10.4.0.0/19) o la dimensione di una subnet mask del blocco CIDR (ad esempio, /19). Questo valore viene utilizzato per creare l'intervallo di indirizzi IP secondari 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 secondari della subnet per i pod del cluster.
    - SECONDARY_RANGE_SERVICES: il nome di un intervallo di indirizzi IP secondari esistente nella subnet specificata.
  - PRODUCER_PROJECT_ID: l'ID del progetto del produttore.
2. Crea consumer cluster con la rete e la subnet consumer nel seguente modo:
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --location=CONSUMER_CONTROL_PLANE_LOCATION \
    --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 \
    --project=CONSUMER_PROJECT_ID
```
  Sostituisci quanto segue:
  - CONSUMER_CLUSTER_NAME: il nome del cluster consumer GKE.
  - CONSUMER_CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del cluster consumer. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
  - PRODUCER_NETWORK_NAME: il nome di una rete VPC consumer esistente.
  - CONSUMER_SUBNETWORK_NAME: il nome di una subnet esistente. L'intervallo di indirizzi IP principale della subnet viene utilizzato per i nodi. La subnet deve esistere 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 nella notazione CIDR, ad esempio 10.0.0.0/14, o la dimensione di una maschera di subnet del blocco CIDR, ad esempio /14. Viene utilizzato per creare l'intervallo di indirizzi IP secondari 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 includerà intervalli di indirizzi IP allocati a VM, route esistenti o intervalli allocati ad altri cluster. L'intervallo scelto automaticamente potrebbe entrare in conflitto con indirizzi IP riservati, route dinamiche o route all'interno dei VPC in peering con questo cluster. Se utilizzi uno di questi, devi specificare --cluster-ipv4-cidr per evitare conflitti.
    - SERVICES_IP_RANGE: un intervallo di indirizzi IP nella notazione CIDR (ad esempio, 10.4.0.0/19) o la dimensione di una subnet mask del blocco CIDR (ad esempio, /19). Questo valore viene utilizzato per creare l'intervallo di indirizzi IP secondari 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 secondari della subnet per i pod del cluster.
    - SECONDARY_RANGE_SERVICES: il nome di un intervallo di indirizzi IP secondari esistente nella subnet specificata.
  - CONSUMER_PROJECT_ID: l'ID del progetto consumer.
Per ulteriori informazioni sulla creazione di cluster, vedi Creazione di cluster.
Stabilisci la relazione di peering VPC tra la rete consumer-vpc e la rete producer-vpc nel seguente modo:
- Per connettere la rete consumer al produttore, esegui questo comando:
```
gcloud compute networks peerings create CONSUMER_PEERING_NAME \
    --project=CONSUMER_PROJECT_ID \
    --network=CONSUMER_NETWORK_NAME \
    --peer-network=PRODUCER_NETWORK_NAME
```
  Sostituisci CONSUMER_PEERING_NAME con il nome del peering da aggiungere alla rete consumer.
- Per connettere la rete producer al consumer, esegui questo comando:
```
gcloud compute networks peerings create PRODUCER_PEERING_NAME \
    --project=PRODUCER_PROJECT_ID \
    --network=PRODUCER_NETWORK_NAME \
    --peer-network=CONSUMER_NETWORK_NAME \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
  Sostituisci PRODUCER_PEERING_NAME con il nome del peering da aggiungere alla rete producer.
Per impostazione predefinita, il VPC consumer esporta gli indirizzi PUPI. Quando crei il VPC producer, utilizzi i seguenti argomenti per configurare il VPC in modo da importare gli indirizzi PUPI ma non esportarli:
```
--no-export-subnet-routes-with-public-ip
--import-subnet-routes-with-public-ip
```

Verifica le reti e le subnet

Verifica la rete producer:

gcloud compute networks describe PRODUCER_NETWORK_NAME \
    --project=PRODUCER_PROJECT_ID

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 subnet del produttore:

gcloud compute networks subnets describe PRODUCER_SUBNETWORK_NAME \
    --project=PRODUCER_PROJECT_ID\
    --region=PRODUCER_CONTROL_PLANE_LOCATION

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 di consumo:

gcloud compute networks describe CONSUMER_NETWORK_NAME \
    --project=CONSUMER_PROJECT_ID

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 subnet di consumo:

gcloud compute networks subnets describe CONSUMER_SUBNETWORK_NAME \
    --project=CONSUMER_PROJECT_ID\
    --region=CONSUMER_CONTROL_PLANE_LOCATION

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_NAME \
    --project=CONSUMER_PROJECT_ID \
    --location=CONSUMER_CONTROL_PLANE_LOCATION

L'output è simile al seguente:

...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for consumer-cluster.
...

Installa e verifica l'app 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 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 esporti le route PUPI:

gcloud compute networks peerings list-routes CONSUMER_PEERING_NAME \
    --direction=OUTGOING \
    --network=CONSUMER_NETWORK_NAME \
    --region=CONSUMER_CONTROL_PLANE_LOCATION

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 rete VPC producer:

gcloud compute networks peerings list-routes PRODUCER_PEERING_NAME \
    --direction=INCOMING \
    --network=PRODUCER_NETWORK_NAME \
    --region=PRODUCER_CONTROL_PLANE_LOCATION

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 Configurazione dell'accesso privato ai servizi.
Leggi la guida Introduzione all'API Service Networking.
Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.

Configurazione di indirizzi IP pubblici utilizzati privatamente per GKE Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica

Prerequisiti

Configura indirizzi IP pubblici utilizzati privatamente per i cluster GKE

Costi

Prima di iniziare

Configura reti e cluster

Verifica le reti e le subnet

Verifica il cluster GKE e le relative risorse

Verifica della soluzione

Passaggi successivi

Configurazione di indirizzi IP pubblici utilizzati privatamente per GKE