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 IP gli indirizzi non sono di proprietà di Google. Non è necessario possedere questo IP pubblico per usarli 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 la presenza di una RFC privata L'esaurimento degli indirizzi nel 1918 prevede l'uso di indirizzi IP pubblici (PUPI) utilizzati privatamente per il CIDR del 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. Le seguenti mostra un esempio di come un'azienda (produttore) offre un servizio gestito utilizzando PUPI con peering VPC con un cliente (consumer).

Indirizzi PUPI per il CIDR del pod GKE
bloccare.

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 consumer: qualsiasi altro blocco CIDR PUPI sul cliente (ad esempio, 5.5.0.0/16).

Come vengono utilizzati i PUPI in uno scenario relativo a un fornitore di servizi

Il provider di servizi (producer) esegue il proprio servizio gestito su una Cluster GKE (gke-2) all'interno del relativo VPC (vpc-producer). Questo 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.

Questi due VPC sono connessi tramite peering VPC, ma ognuno continua a utilizzare indirizzi IP privati standard (RFC 1918) per i nodi, 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. Ciò consente alle risorse nel VPC del consumer di accedere nel VPC del producer (generalmente attraverso bilanciatori del carico).
dal produttore al consumatore: per consentire ai pod del producer di raggiungere risorse nella per il VPC del consumer, è necessaria una configurazione esplicita.
Nessuna sovrapposizione: il produttore e il consumatore devono assicurarsi che l'intervallo di PUPI del consumatore non sia in conflitto con qualsiasi 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.

Abilita la comunicazione quando gli intervalli PUPI si sovrappongono

Se il VPC del consumer utilizza già lo stesso intervallo PUPI del la comunicazione diretta dai pod del producer. 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 in un VPC. Puoi modificare le impostazioni di peering VPC predefinite usando il comando gcloud compute networks peerings update.

Rete VPC	Impostazioni di importazione	Esporta impostazioni	Note
Producer	Comportamento predefinito (disattivato): non importa route di subnet con indirizzi pubblici Indirizzi IP Per attivare: --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)	Flag controllati attraverso il networking di servizi.
Consumer	Disattivata (impostazione predefinita)	Attivato (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 verso la rete vpc-consumer deve tradotte dietro gli indirizzi dei nodi nel cluster 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 la seguente versione minima requisiti:
- Cluster Autopilot: GKE versione 1.22 o successive
- Cluster standard: GKE versione 1.14 o successive
Seleziona un intervallo PUPI che non sia instradabile pubblicamente 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 Comunicazione tra pod. Non è richiesta alcuna configurazione aggiuntiva.
- Cluster standard: traduci gli indirizzi IP dei pod nei rispettivi gli indirizzi IP dei nodi corrispondenti usando SNAT. Attiva SNAT per PUPI per via del traffico. Per ulteriori informazioni, consulta Abilitare 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:

Configurare 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 secondari in ogni subnet.
Stabilisci una relazione di peering del Virtual Private Cloud tra i due Virtual Private Cloud reti con impostazioni di importazione ed esportazione appropriate.
Controlla le route all'interno di ogni Virtual Private Cloud.

Costi

In questo documento vengono utilizzati 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 attività:

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 VPC e il peering.

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 principali 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 sono di solito utilizzato per i nodi worker all'interno di GKE cluster. 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: questo VPC ospita la Cluster GKE in cui vengono utilizzate le applicazioni o i carichi di lavoro vengono eseguiti tutti i test delle unità. 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 la il cluster GKE responsabile della fornitura del servizio per gli utilizzi del consumatore. 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 creati 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 il pod rete in GKE e non può essere utilizzato come indirizzo 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: il cluster Compute Engine località del 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, ad esempio 10.0.0.0/14, oppure le dimensioni di una subnet mask a blocchi CIDR, ad esempio /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 le dimensioni di una subnet mask a blocchi CIDR (ad esempio, /19). Viene utilizzato per creare l'indirizzo 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 elemento esistente intervallo di indirizzi IP secondari nel valore 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 di 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 principali 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 nel 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 secondari della subnet per i pod. Se ometti l'opzione --cluster-ipv4-cidr, GKE sceglie /14 (2¹⁸ indirizzi) automaticamente. L'intervallo scelto automaticamente viene selezionato in modo casuale da 10.0.0.0/8 (un intervallo di 2²⁴ indirizzi) e non includerà gli intervalli di indirizzi IP allocati alle VM, le route esistenti, o intervalli allocati ad altri cluster. L'intervallo scelto automaticamente potrebbe essere in conflitto con indirizzi IP riservati, route dinamiche 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 maschera di sottorete 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 elemento esistente intervallo di indirizzi IP secondari nel valore 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 elemento esistente nell'intervallo di indirizzi IP secondari specificato.
Per ulteriori informazioni sulla creazione di cluster, vedi Creare cluster.
Stabilisci il VPC relazione di peering tra consumer-vpc e producer-vpc network come segue:
- Per connettere la rete consumer al producer, esegui questo 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 producer, utilizzerai i seguenti argomenti configura il VPC per importare 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 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 consumer:

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 subnet consumer:

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 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 CIDR consumer blocchi:

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 l'articolo sulla configurazione di un servizio privato all'accesso.
Leggi la guida Introduzione all'API Service Networking.
Esplora le architetture di riferimento, i diagrammi e le best practice su in Google Cloud. Dai un'occhiata alla nostra architettura cloud assistenza.