Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Networking a doppio stack IPv4/IPv6

Il networking dual-stack in Google Distributed Cloud consente ai tuoi cluster di accettare il traffico da dispositivi esterni che utilizzano IPv4 o IPv6. I pod e i nodi ricevono indirizzi IPv4 e IPv6 e un servizio Kubernetes può avere un indirizzo IPv4, un indirizzo IPv6 o entrambi.

I cluster a doppio stack utilizzano sempre la modalità flat per IPv6. Per IPv4, i cluster dual-stack utilizzano la modalità isola per impostazione predefinita, ma puoi configurare la modalità flat. Per creare un cluster a doppio stack, la rete sottostante deve essere abilitata per il doppio stack. Non puoi avviare un cluster a doppio stack su una rete IPv4 o IPv6 a stack singolo.

Prima di iniziare

Se i nodi del cluster eseguono RedHat Enterprise Linux e hanno SELinux abilitato, su ogni nodo:

In /etc/firewalld/firewalld.conf, imposta IPv6_rpfilter=no.
Esegui systemctl restart firewalld.

Panoramica della creazione di un cluster a doppio stack

Puoi attivare il networking dual-stack quando crei un nuovo cluster, ma non puoi attivarlo per un cluster esistente.

Segui le istruzioni riportate in uno dei documenti per la creazione dei cluster.

Nel file di configurazione, includi i manifest per:

Una risorsa Namespace
Una risorsa Cluster
Una o più risorse NodePool
Una o più risorse ClusterCIDRConfig

Compila i manifest Namespace e NodePool come faresti per un cluster single-stack.

Nel manifest del cluster, in clusterNetwork.services.cidrBlocks, specifica sia un intervallo CIDR IPv4 sia un intervallo CIDR IPv6. Questo è il criterio di attivazione per un cluster dual-stack. In altre parole, se fornisci intervalli CIDR dei servizi sia per IPv4 sia per IPv6, il tuo cluster avrà una rete a doppio stack.

Nel manifest del cluster, in clusterNetwork.pods.cidrBlocks, specifica un intervallo CIDR IPv4, ma non un intervallo CIDR IPv6. Gli intervalli CIDR IPv6 per i pod sono specificati nei manifest ClusterCIDRConfig.

Se utilizzi il bilanciamento del carico integrato, fornisci sia indirizzi IPv4 sia indirizzi IPv6 nella sezione loadBalancer.addressPools del manifest del cluster.

Le risorse ClusterCIDRConfig servono per specificare gli intervalli CIDR IPv4 e IPv6 per i pod. Puoi utilizzare una singola risorsa ClusterCIDRConfig per specificare intervalli CIDR a livello di cluster. In altre parole, gli indirizzi IPv4 dei pod per tutti i nodi vengono presi da un singolo intervallo CIDR e gli indirizzi IPv6 dei pod per tutti i nodi vengono presi da un singolo intervallo CIDR. In alternativa, puoi utilizzare diverse risorse ClusterCIDRConfig per specificare intervalli CIDR che si applicano a un determinato pool di nodi o a un determinato nodo.

Raggiungibilità degli indirizzi IP dei pod

Un cluster a doppio stack utilizza la modalità flat per il networking IPv6. L'esempio fornito in questo documento riguarda un cluster che utilizza il networking in modalità flat statica per IPv6. In altre parole, il cluster non è configurato per l'utilizzo del Border Gateway Protocol (BGP).

Per un cluster che utilizza il networking in modalità flat statica, devi specificare indirizzi IP dei nodi e dei pod che fanno tutti parte della stessa subnet. Questa configurazione consente ai client esterni al cluster, ma nello stesso dominio di livello 2 dei nodi del cluster, di inviare pacchetti direttamente agli indirizzi IP dei pod.

Ad esempio, supponiamo che i nodi del cluster e alcune altre macchine si trovino tutti nello stesso dominio di livello 2. Ecco un modo per specificare gli intervalli di indirizzi:

Finalità	Intervallo	Numero di indirizzi
Intero dominio di livello 2	`fd12::/108`	2²⁰
Pod	`fd12::1:0/112`	2¹⁶
Nodi	`fd12::2:0/112`	2¹⁶
Altre macchine	`fd12::3:0/112`	2¹⁶
VIP	`fd12::4:0/112`	2¹⁶

Nell'esempio precedente, questi sono i punti chiave da comprendere:

Tutti gli indirizzi di nodi, pod e macchine si trovano nell'intervallo di grandi dimensioni: fd12::/108.
Gli indirizzi IP dei pod si trovano in un sottoinsieme dell'intervallo di grandi dimensioni.
Gli indirizzi IP dei nodi si trovano in un sottoinsieme diverso dell'intervallo più ampio.
Gli indirizzi IP delle altre macchine si trovano in un sottoinsieme diverso dell'intervallo più ampio.
Tutti gli intervalli di sottoinsiemi sono distinti l'uno dall'altro.

Nell'esempio precedente, ogni macchina nel dominio di livello 2, inclusi i nodi del cluster, deve avere una regola di forwarding per l'intervallo di grandi dimensioni. Ad esempio:

inet fd12::/108 scope global eth0

Esempio: crea un cluster a doppio stack

Quando crei un cluster dual-stack, hai diverse opzioni. Ad esempio, potresti avere intervalli CIDR a livello di cluster o intervalli CIDR che si applicano a pool di nodi specifici. Puoi combinare una rete flat IPv6 con una rete in modalità isola IPv4. In alternativa, sia le reti IPv4 che quelle IPv6 potrebbero essere piatte. Puoi utilizzare il bilanciamento del carico in bundle o il bilanciamento manuale del carico.

Questa sezione fornisce un esempio di come creare un cluster a doppio stack. Il cluster in questo esempio ha le seguenti caratteristiche:

Una rete IPv4 in modalità isola
Una rete IPv6 in modalità flat
Un intervallo CIDR IPv4 a livello di cluster per i pod
Un intervallo CIDR IPv6 a livello di cluster per i pod
Un intervallo CIDR IPv4 a livello di cluster per i servizi
Un intervallo CIDR IPv6 a livello di cluster per i servizi
Un pool di indirizzi IPv4 da utilizzare per i servizi di tipo LoadBalancer
Un pool di indirizzi IPv6 da utilizzare per i servizi di tipo LoadBalancer
Bilanciamento del carico in bundle

Per ulteriori esempi di configurazione, consulta Varianti sull'utilizzo di ClusterCIDRConfig.

Compila un file di configurazione

Segui le istruzioni riportate in uno dei documenti per la creazione dei cluster.

Nel file di configurazione, nel manifest Cluster:

Per clusterNetwork.pods.cidrBlocks, fornisci un singolo intervallo CIDR IPv4.
Per clusterNetwork.services.cidrBlocks, fornisci due intervalli CIDR: uno per IPv4 e uno per IPv6.
Per loadBalancer.addressPools, fornisci due intervalli di indirizzi: uno per IPv4 e uno per IPv6. Quando crei un servizio di tipo LoadBalancer, gli indirizzi IP esterni per il servizio vengono scelti da questi intervalli.

Ecco un esempio che mostra le parti pertinenti di un manifest Cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: "dual-stack"
  namespace: "cluster-dual-stack"

spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - "192.168.0.0/16"
    services
      cidrBlocks:
       - "172.16.0.0/20"
       - "fd12::5:0/116"
...
  loadBalancer:
    mode: "bundled"
    ...
    addressPools:
    - name: "pool-1"
      addresses:
       - "10.2.0.212-10.2.0.221"
       - "fd12::4:101-fd12::4:110"

Nello stesso file di configurazione, includi un manifest per un ClusterCIDRConfig.

Imposta ipv4.cidr sullo stesso intervallo CIDR fornito nel manifest Cluster. Questo è un requisito se IPv4 è in modalità isola.
Imposta namespace sullo stesso valore fornito nel manifest Cluster.
Imposta ipv6.cidr su un intervallo CIDR IPv6 per i pod.
Per ogni intervallo CIDR, fornisci un valore per perNodeMaskSize per specificare quanti indirizzi di pod verranno assegnati a ciascun nodo. Il numero di indirizzi IPv4 assegnati a ciascun nodo deve essere uguale al numero di indirizzi IPv6 assegnati a ciascun nodo. Devi impostare i valori per perNodeMaskSize di conseguenza. Ad esempio, se vuoi 2⁸ indirizzi per nodo, imposta i valori perNodeMaskSize come segue:
- ipv4.perNodeMaskSize: 24 # (32 - 8 = 24)
- ipv6.perNodeMaskSize: 120 # (128 - 8 = 120)

Ecco un esempio di manifest ClusterCIDRConfig:

apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: "cluster-wide-ranges"
  namespace: "cluster-dual-stack"  # Must be the same as the Cluster namespace.
spec:
  ipv4:
    cidr: "192.168.0.0/16"  #  For island mode, must be the same as the Cluster CIDR.
    perNodeMaskSize: 24
  ipv6:
    cidr: "fd12::1:0/112"
    perNodeMaskSize: 120

Nell'esempio precedente:

L'intervallo CIDR dei pod IPv4 ha 2^(32-16) = 2¹⁶ indirizzi. La dimensione della maschera per nodo è 24, quindi il numero di indirizzi assegnati a ogni nodo è 2^(32-24) = 2⁸.
L'intervallo CIDR dei pod IPv6 ha 2^(128-112) = 2¹⁶ indirizzi. La dimensione della maschera per nodo è 120, quindi il numero di indirizzi assegnati a ogni nodo è 2^(128-120) = 2⁸.

File di configurazione di esempio

Fai clic per visualizzare un esempio di file di configurazione completato.

Attenzione: non utilizzare questo esempio così com'è. Sostituisci gli intervalli di indirizzi e i percorsi delle chiavi con valori appropriati per la tua rete.

gcrKeyPath: "bmctl-workspace/.sa-keys/gcr.json"
sshPrivateKeyPath: "/home/me/.ssh/id_rsa"
gkeConnectAgentServiceAccountKeyPath: "bmctl-workspace/.sa-keys/bm-connect.json"
gkeConnectRegisterServiceAccountKeyPath: "bmctl-workspace/.sa-keys/bm-register.json"
cloudOperationsServiceAccountKeyPath: "bmctl-workspace/.sa-keys/bm-cloud-ops.json"
---
apiVersion: v1
kind: Namespace
metadata:
  name: "cluster-dual-stack"
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: "dual-stack"
  namespace: "cluster-dual-stack"
spec:
  type: "user"
  anthosBareMetalVersion: "1.14.0"
  gkeConnect:
    projectID: "my-project"
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: "10.2.0.4"
  clusterNetwork:
    pods:
      cidrBlocks:
      - "192.168.0.0/16"
    services:
      cidrBlocks:
       - "172.16.0.0/20"
       - "fd12::5:0/116"
  loadBalancer:
    mode: "bundled"
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: "10.2.0.211
      ingressVIP: "10.2.0.212"
    addressPools:
    - name: "pool-1"
      addresses:
      - "10.2.0.212-10.2.0.221"
      - "fd12::4:101-fd12::4:110
  clusterOperations:
    projectID: "my-project"
    location: "us-central1"
  storage:
    lvpNodeMounts:
      path: "/mnt/localpv-disk"
      storageClassName: "node-disk"
    lvpShare:
      numPVUnderSharedPath: 5
      path: "/mnt/localpv-share"
      storageClassName: "local-shared"
  nodeConfig:
    podDensity:
      maxPodsPerNode: 110
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: "pool-1"
  namespace: "cluster-dual-stack"
spec:
  clusterName: "dual-stack"
  nodes:
  - address: "10.2.0.5"
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: "cluster-wide-ranges"
  namespace: "cluster-dual-stack"
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "fd12::1:0/112"
    perNodeMaskSize: 120

Completa la creazione del cluster

Completa la creazione del cluster come descritto nel documento di creazione del cluster.

Visualizza i nodi e i pod del cluster

Elenca i nodi del cluster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes --output yaml

Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster.

Nell'output puoi vedere gli indirizzi IPv4 e IPv6 di ogni nodo. Puoi anche visualizzare gli intervalli di indirizzi IPv4 e IPv6 per i pod sul nodo. Ad esempio:

- apiVersion: v1
  kind: Node
  ...
  spec:
    podCIDR: 192.168.1.0/24
    podCIDRs:
    - 192.168.1.0/24
    - fd12::1:100/120
    providerID: baremetal://10.2.0.5
  status:
    addresses:
    - address: 10.2.0.5
      type: InternalIP
    - address: fd12::2:5
      type: InternalIP

Elenca i pod presenti nel cluster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get pods --all-namespaces

Scegli un pod ed elencane i dettagli. Ad esempio:

kubectl --kubeconfig CLUSTER_KUBECONFIG get pod gke-metrics-agent-b9qrv \
  --namespace kube-system \
  -- output yaml

Nell'output puoi visualizzare gli indirizzi IPv4 e IPv6 del pod. Ad esempio:

apiVersion: v1
kind: Pod
metadata:
  ...
  name: gke-metrics-agent-b9qrv
  namespace: kube-system
...
status:
  ...
  podIPs:
  - ip: 192.168.1.146
  - ip: fd12::1:11a

Varianti sull'utilizzo di ClusterCIDRConfig

L'esempio precedente utilizzava un oggetto ClusterCIDRConfig per specificare gli intervalli CIDR dei pod a livello di cluster. In altre parole, viene utilizzato un singolo intervallo CIDR IPv4 per tutti i pod nel cluster. Inoltre, per tutti i pod del cluster viene utilizzato un unico intervallo CIDR IPv6.

In determinate situazioni, potresti non voler utilizzare un singolo intervallo CIDR per tutti i pod di un cluster. Ad esempio, potresti voler specificare un intervallo CIDR separato per ogni pool di nodi o per ogni nodo. Per ulteriori informazioni su ClusterCIDRConfig ed esempi di utilizzo, consulta Informazioni sulla risorsa personalizzata ClusterCIDRConfig.

Ad esempio, il seguente ClusterCIDRConfig specifica un intervallo CIDR per un node pool denominato "workers".

apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: "worker-pool-ccc"
  namespace: "cluster-dual-stack"
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "fd12::1:0/112"
    perNodeMaskSize: 120
  nodeSelector:
    matchLabels:
      baremetal.cluster.gke.io/node-pool: "workers"

Il seguente ClusterCIDRConfig specifica un intervallo CIDR per un singolo nodo con indirizzo IP 10.2.0.5:

apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: "range-node1"
  namespace: "cluster-dual-stack"
spec:
  ipv4:
    cidr: "192.168.1.0/24"
    perNodeMaskSize: 24
  ipv6:
    cidr: "fd12::1:0/120"
    perNodeMaskSize: 120
  nodeSelector:
    matchLabels:
      baremetal.cluster.gke.io/k8s-ip: "10.2.0.5"

Crea un servizio dual-stack di tipo `ClusterIP`

Ecco un manifest per un deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "my-deployment"
spec:
  selector:
    matchLabels:
      app: "try-dual-stack"
  replicas: 3
  template:
    metadata:
      labels:
        app: "try-dual-stack"
    spec:
      containers:
      - name: "hello"
        image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"

Salva il manifest in un file denominato my-deployment.yaml e crea il deployment:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-deployment.yaml

Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster.

Ecco un manifest per un servizio di tipo ClusterIP:

apiVersion: v1
kind: Service
metadata:
  name: "my-service"
spec:
  selector:
    app: "try-dual-stack"
  type: "ClusterIP"
  ipFamilyPolicy: "RequireDualStack"
  ipFamilies:
  - "IPv6"
  - "IPv4"
  ports:
  - port: 80
    targetPort: 8080

Nel contesto di questo esercizio, ecco i punti chiave da comprendere sul manifest del servizio precedente:

Il campo ipFamilyPolicy è impostato su RequireDualStack. Ciò significa che per il servizio vengono allocati sia indirizzi IPv6 sia indirizzi IPv4 ClusterIP.
Il campo ipFamilies specifica prima la famiglia IPv6 e poi la famiglia IPv4. Ciò significa che spec.ClusterIP per il servizio sarà un indirizzo IPv6 scelto da clusterNetwork.services.cidrBlocks nel manifest del cluster.

Salva il manifest in un file denominato my-cip-service.yaml e crea il servizio:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-cip-service.yaml

Elenca i dettagli del servizio:

kubectl --kubeconfig CLUSTER_KUBECONFIG get service my-service --output yaml

Nell'output puoi visualizzare gli indirizzi IP del cluster per il servizio. Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  …
spec:
  clusterIP: fd12::5:9af
  clusterIPs:
  - fd12::5:9af
  - 172.16.12.197

Su un nodo del cluster, chiama il servizio:

curl IPV4_CLUSTER_IP
curl IPV6_CLUSTER_IP

L'output mostra un messaggio "Hello world":

Hello, world!
Version: 2.0.0
Hostname: my-deployment-xxx

Crea un servizio dual-stack di tipo `LoadBalancer`

Ecco un manifest per un servizio di tipo LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: "my-lb-service"
spec:
  selector:
    app: "try-dual-stack"
  type: "LoadBalancer"
  ipFamilyPolicy: "RequireDualStack"
  ipFamilies:
  - "IPv6"
  - "IPv4"
  ports:
  - port: 80
    targetPort: 8080

Salva il manifest in un file denominato my-lb-service.yaml e crea il servizio:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-lb-service.yaml

Ricorda che nel manifest del cluster hai specificato un intervallo di indirizzi IPv6 e un intervallo di indirizzi IPv4 da utilizzare per i servizi di tipo LoadBalancer:

  loadBalancer:
    mode: "bundled"
    ...
    addressPools:
    - name: "pool-1"
      addresses:
      - "10.2.0.112-10.2.0.221"
      - "fd12::4:101-fd12::4:110"

Al servizio verrà assegnato un indirizzo IPv4 esterno scelto dall'intervallo IPv4 e un indirizzo IPv6 esterno scelto dall'intervallo IPv6.

Elenca i dettagli del servizio:

kubectl --kubeconfig CLUSTER_KUBECONFIG get service my-lb-service --output yaml

Nell'output puoi vedere gli indirizzi esterni del servizio. Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
...
status:
  loadBalancer:
    ingress:
    - ip: 10.2.0.213
    - ip: fd12::4:101

Valori possibili per `ipFamilyPolicy`

Quando crei un servizio dual-stack, puoi impostare ipFamilyPolicy su uno di questi valori:

SingleStack: il controller alloca un indirizzo IP del cluster per il servizio, scelto dal primo intervallo specificato nel manifest del cluster in clusterNetwork.services.cidrBlocks.
PreferDualStack: il controller alloca gli indirizzi IP del cluster IPv4 e IPv6 per il servizio, scelti dagli intervalli specificati nel manifest del cluster in clusterNetwork.services.cidrBlocks. Se il cluster non è un cluster dual-stack, il comportamento è lo stesso di SingleStack.
RequireDualStack: il controller alloca gli indirizzi IP del cluster IPv4 e IPv6 per il servizio, scelti dagli intervalli specificati nel manifest del cluster in clusterNetwork.services.cidrBlocks. Imposta il valore di spec.clusterIP in base alla prima famiglia di indirizzi specificata nel manifest del servizio in ipFamilies.

Ulteriori informazioni

Per saperne di più su come creare servizi dual-stack, consulta Opzioni dual-stack sui nuovi servizi.