Cluster Anthos on bare metal supporta il networking dual stack IPv4/IPv6. Ciò significa che un cluster può accettare il traffico da dispositivi esterni che utilizzano Protocollo Internet versione 4 (IPv4) o Protocollo Internet versione 6 (IPv6).
Le reti dual stack consentono di assegnare indirizzi IPv4 e IPv6 a pod e nodi. Un servizio Kubernetes può avere un indirizzo IPv4, un indirizzo IPv6 o entrambi.
Tutti i cluster a doppio stack utilizzano la modalità normale per IPv6. Per impostazione predefinita, un cluster a doppio stack utilizza la modalità isola per IPv4, ma puoi configurarlo per l'utilizzo della modalità piatta per IPv4.
Per creare un cluster a doppio stack, la rete sottostante deve essere abilitata a doppio stack. Se la rete sottostante è una rete IPv4 o IPv6 a stack singolo, non puoi avviare un cluster a doppio stack.
Prima di iniziare
Se i nodi del cluster eseguono CentOS o RedHat Enterprise Linux e hanno abilitato SELinux, su ogni nodo:
In
/etc/firewalld/firewalld.conf
, impostaIPv6_rpfilter=no
.Esegui
systemctl restart firewalld
.
Panoramica della creazione di un cluster a doppio stack
Puoi abilitare il networking a doppio stack quando crei un nuovo cluster, ma non puoi abilitare il networking a doppio stack per un cluster esistente.
Segui le istruzioni in uno dei documenti per la creazione del cluster.
Nel file di configurazione, includi i manifest per:
- Una risorsa spazio dei nomi
- Una risorsa cluster
- Una o più risorse NodePool
- Una o più risorse ClusterCIDRConfig
Compila i file manifest dello spazio dei nomi e del pool di nodi come faresti per un cluster a stack singolo.
Nel manifest del cluster, in clusterNetwork.services.cidrBlocks
, specifica sia un intervallo CIDR IPv4 sia un intervallo CIDR IPv6. Questo è il criterio di abilitazione per un cluster a doppio stack. In altre parole, se fornisci intervalli CIDR Service per IPv4 e IPv6, il cluster avrà una rete a doppio stack.
Nel manifest del cluster, in clusterNetwork.pods.cidrBlocks
, specifica un intervallo IPv4 CIDR, ma non specificare un intervallo CIDR IPv6. Gli intervalli CIDR IPv6 per i pod sono specificati nei manifest ClusterCIDRConfig.
Se utilizzi il bilanciamento del carico in bundle, fornisci sia gli indirizzi IPv4 sia gli 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 dei pod IPv4 per tutti i nodi vengono recuperati da un singolo intervallo CIDR e gli indirizzi dei pod IPv6 per tutti i nodi vengono recuperati da un singolo intervallo CIDR. In alternativa, puoi utilizzare diverse risorse ClusterCIDRConfig per specificare intervalli CIDR applicabili a un particolare pool di nodi o a un particolare nodo.
Raggiungibilità per gli indirizzi IP dei pod
Un cluster a doppio stack utilizza la modalità piatta per il networking IPv6. L'esempio riportato in questo documento riguarda un cluster che utilizza un networking statico a modalità piatta per IPv6. Ciò significa che il cluster non è configurato per l'utilizzo del protocollo BGP (Border Gateway Protocol).
Per un cluster che utilizza un networking statico a modalità piatta, devi specificare gli indirizzi IP dei nodi e dei pod che fanno parte della stessa subnet. In questo modo, i client al di fuori del cluster possono utilizzare lo stesso dominio di livello 2 (L2) dei nodi del cluster per inviare pacchetti direttamente agli indirizzi IP del pod.
Ad esempio, supponiamo che i nodi del cluster e alcune altre macchine siano tutti nello stesso dominio L2. Ecco un modo per specificare gli intervalli di indirizzi:
Purpose | Azione | Numero di indirizzi |
---|---|---|
Intero dominio L2 | fd12::/108 | 2^20 |
Pod | fd12::1:0/112 | 2^16 |
Nodi | fd12::2:0/112 | 2^16 |
Altre macchine | fd12::3:0/112 | 2^16 |
VIP | fd12::4:0/112 | 2^16 |
Nell'esempio precedente, questi sono i punti chiave da comprendere:
Tutti gli indirizzi dei nodi, pod e macchine sono nell'intervallo ampio: fd12::/108.
Gli indirizzi IP dei pod si trovano in un sottoinsieme dell'intervallo ampio.
Gli indirizzi IP del nodo si trovano in un sottoinsieme diverso dell'intervallo ampio.
Gli indirizzi IP di altre macchine si trovano in un sottoinsieme diverso dell'ampio intervallo.
Tutti gli intervalli di sottoinsiemi sono diversi l'uno dall'altro.
Nell'esempio precedente, ogni macchina nel dominio L2, inclusi i nodi del cluster, deve avere una regola di forwarding per l'intervallo ampio. Ad esempio:
inet fd12::/108 scope global eth0
Esempio: crea un cluster a doppio stack
Quando crei un cluster a doppio stack, sono disponibili varie opzioni. Ad esempio, potresti avere intervalli CIDR a livello di cluster o intervalli CIDR applicabili a pool di nodi specifici. Puoi combinare una rete piatta IPv6 con una rete in modalità isola IPv4. Oppure entrambe le reti IPv4 e IPv6 potrebbero essere piatte. Puoi utilizzare il bilanciamento del carico in bundle o il bilanciamento del carico manuale.
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à piatta
- 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 in uno dei documenti per la creazione del 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 tipoLoadBalancer
, gli indirizzi IP esterni per il servizio vengono scelti da questi intervalli.
Ecco un esempio che mostra le parti pertinenti di un manifest del 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 ClusterCIDRConfig
.
Imposta
ipv4.cidr
sullo stesso intervallo CIDR che hai fornito nel manifestCluster
. Questo è un requisito se IPv4 è in modalità isola.Impostare
namespace
sullo stesso valore che hai specificato nel manifestCluster
.Imposta
ipv6.cidr
su un intervallo CIDR IPv6 per i pod.Per
perNodeMaskSize
intervallo CIDR, fornisci un valore per specificare quanti indirizzi dei pod verranno assegnati a ciascun nodo. Il numero di indirizzi IPv4 assegnati a ciascun nodo deve corrispondere al numero di indirizzi IPv6 assegnati a ciascun nodo. Devi impostare i valori diperNodeMaskSize
di conseguenza. Ad esempio, se vuoi 2^8 indirizzi per nodo, imposta i valoriperNodeMaskSize
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 pod IPv4 ha 2^(32-16) = 2^16 indirizzi. La dimensione della maschera per nodo è 24, quindi il numero di indirizzi assegnati a ciascun nodo è 2^(32-24) = 2^8.
L'intervallo CIDR pod IPv6 ha 2^(128-112) = 2^16 indirizzi. La dimensione della maschera per nodo è 120, quindi il numero di indirizzi assegnati a ciascun nodo è 2^(128-120) = 2^8.
Esempio di file di configurazione
Completa la creazione del cluster
Completa la creazione del cluster come descritto nel documento per la creazione del cluster.
Visualizza nodi e 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 nel cluster:
kubectl --kubeconfig CLUSTER_KUBECONFIG get pods --all-namespaces
Scegli un pod ed elenca i dettagli. Ad esempio:
kubectl --kubeconfig CLUSTER_KUBECONFIG get pod gke-metrics-agent-b9qrv \ --namespace kube-system \ -- output yaml
Nell'output puoi vedere 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
Variazioni sull'utilizzo di ClusterCIDRConfig
L'esempio precedente utilizzava un oggetto ClusterCIDRConfig per specificare intervalli di pod di pod a livello di cluster. Ciò significa che viene utilizzato un unico intervallo CIDR IPv4 per tutti i pod nel cluster. Inoltre, viene utilizzato un unico intervallo CIDR IPv6 per tutti i pod del cluster.
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 oppure un intervallo CIDR separato per ogni nodo.
Ad esempio, il seguente ClusterCIDRConfig specifica un intervallo CIDR per un pool di nodi 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 a doppio stack di tipo ClusterIP
Di seguito è riportato 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.
Di seguito è riportato 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, questi sono i punti chiave da comprendere in merito al manifest del servizio precedente:
Il campo
ipFamilyPolicy
è impostato suRequireDualStack
. Ciò significa che entrambi gli indirizzi IPv6 e IPv4ClusterIP
sono allocati per il servizio.Il campo
ipFamilies
specifica prima la famiglia IPv6 e la seconda famiglia IPv4. Ciò significa chespec.ClusterIP
per il servizio sarà un indirizzo IPv6 scelto daclusterNetwork.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 vedere 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]
Nell'output viene visualizzato il messaggio "Hello World":
Hello, world! Version: 2.0.0 Hostname: my-deployment-xxx
Crea un servizio a doppio stack di tipo LoadBalancer
Di seguito è riportato 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 per il servizio:
kubectl --kubeconfig CLUSTER_KUBECONFIG get service my-lb-service --output yaml
Nell'output puoi vedere gli indirizzi esterni per il Service. 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 a doppio stack, puoi impostare ipFamilyPolicy
su uno dei seguenti valori:
SingleStack
: il controller alloca un indirizzo IP del cluster per il servizio, scelto dal primo intervallo specificato nel manifest del cluster inclusterNetwork.services.cidrBlocks
.PreferDualStack
: il controller alloca gli indirizzi IP dei cluster IPv4 e IPv6 per il servizio, scelti tra gli intervalli specificati nel manifest del cluster inclusterNetwork.services.cidrBlocks
. Se il cluster non è a doppio stack, il comportamento è lo stesso diSingleStack
.RequireDualStack
: il controller alloca gli indirizzi IP del cluster IPv4 e IPv6 per il servizio, scelti tra gli intervalli specificati nel manifest del cluster inclusterNetwork.services.cidrBlocks
. Imposta il valore dispec.clusterIP
in base alla prima famiglia di indirizzi specificata nel manifest del servizio inipFamilies
.
Informazioni dettagliate
Per ulteriori informazioni su come creare servizi a doppio stack, consulta le opzioni per il doppio stack sui nuovi servizi.