Esta página foi traduzida pela API Cloud Translation.

Redes de pilha dupla IPv4/IPv6

O Google Distributed Cloud suporta a rede de pilha dupla IPv4/IPv6. Isto significa que um cluster pode aceitar tráfego de dispositivos externos que usam a versão 4 do Protocolo de Internet (IPv4) ou a versão 6 do Protocolo de Internet (IPv6).

A rede de pilha dupla atribui endereços IPv4 e IPv6 a pods e nós. Um serviço do Kubernetes pode ter um endereço IPv4, um endereço IPv6 ou ambos.

Todos os clusters de pilha dupla usam o modo simples para IPv6. Por predefinição, um cluster de pilha dupla usa o modo de ilha para IPv4, mas pode configurá-lo para usar o modo simples para IPv4.

Para criar um cluster de pilha dupla, a sua rede subjacente tem de ter a pilha dupla ativada. Se a sua rede subjacente for uma rede IPv4 ou IPv6 de pilha única, não pode iniciar um cluster de pilha dupla.

Antes de começar

Se os nós do cluster estiverem a executar o RedHat Enterprise Linux e tiverem o SELinux ativado, em cada nó:

Em /etc/firewalld/firewalld.conf, defina IPv6_rpfilter=no.
Corrida systemctl restart firewalld.

Vista geral da criação de um cluster de pilha dupla

Pode ativar a rede de pilha dupla quando cria um novo cluster, mas não pode ativar a rede de pilha dupla para um cluster existente.

Siga as instruções num dos documentos de criação de clusters.

No ficheiro de configuração, inclua manifestos para o seguinte:

Um recurso de espaço de nomes
Um recurso de cluster
Um ou mais recursos NodePool
Um ou mais ClusterCIDRConfigrecursos

Preencha o manifesto do espaço de nomes e os manifestos do NodePool como faria para um cluster de pilha única.

No manifesto do cluster, em clusterNetwork.services.cidrBlocks, especifique um intervalo CIDR IPv4 e um intervalo CIDR IPv6. Este é o critério de ativação de um cluster de pilha dupla. Ou seja, se fornecer intervalos CIDR de serviços para IPv4 e IPv6, o cluster terá uma rede de pilha dupla.

No manifesto do cluster, em clusterNetwork.pods.cidrBlocks, especifique um intervalo CIDR IPv4, mas não especifique um intervalo CIDR IPv6. Os intervalos CIDR IPv6 para pods são especificados em manifestos ClusterCIDRConfig.

Se estiver a usar o equilíbrio de carga agrupado, forneça endereços IPv4 e IPv6 na secção loadBalancer.addressPools do manifesto do cluster.

Os recursos ClusterCIDRConfig destinam-se a especificar intervalos CIDR IPv4 e IPv6 para Pods. Pode usar um único recurso ClusterCIDRConfig para especificar intervalos CIDR que abrangem todo o cluster. Ou seja, os endereços IPv4 dos pods de todos os nós são retirados de um único intervalo CIDR e os endereços IPv6 dos pods de todos os nós são retirados de um único intervalo CIDR. Em alternativa, pode usar vários recursos ClusterCIDRConfig para especificar intervalos CIDR que se aplicam a um conjunto de nós ou a um nó específico.

Acessibilidade para endereços IP de pods

Um cluster de pilha dupla usa o modo simples para a rede IPv6. O exemplo apresentado neste documento destina-se a um cluster que usa redes de modo simples estáticas para IPv6. Ou seja, o cluster não está configurado para usar o Border Gateway Protocol (BGP).

Para um cluster que usa redes de modo simples estáticas, tem de especificar endereços IP de nós e de pods que fazem todos parte da mesma sub-rede. Esta configuração permite que os clientes fora do cluster, mas no mesmo domínio da camada 2, enviem pacotes diretamente para os endereços IP dos pods.

Por exemplo, suponha que os nós do cluster e algumas outras máquinas estão todos no mesmo domínio da camada 2. Veja uma forma de especificar intervalos de endereços:

Finalidade	Intervalo	Número de endereços
Todo o domínio da camada 2	`fd12::/108`	2²⁰
Agrupamentos	`fd12::1:0/112`	2¹⁶
Nós	`fd12::2:0/112`	2¹⁶
Outras máquinas	`fd12::3:0/112`	2¹⁶
VIPs	`fd12::4:0/112`	2¹⁶

No exemplo anterior, estes são os pontos-chave a compreender:

Todos os endereços de nós, pods e máquinas estão no intervalo grande: fd12::/108.
Os endereços IP dos pods estão num subconjunto do intervalo grande.
Os endereços IP dos nós estão num subconjunto diferente do intervalo grande.
Os endereços IP de outras máquinas estão num subconjunto diferente do intervalo grande.
Todos os intervalos de subconjuntos são distintos entre si.

No exemplo anterior, cada máquina no domínio da camada 2, incluindo os nós do cluster, tem de ter uma regra de encaminhamento para o intervalo grande. Por exemplo:

inet fd12::/108 scope global eth0

Exemplo: crie um cluster de pilha dupla

Quando cria um cluster de pilha dupla, tem várias opções. Por exemplo, pode ter intervalos CIDR ao nível do cluster ou intervalos CIDR que se aplicam a pools de nós específicos. Pode combinar uma rede simples IPv6 com uma rede no modo isolado IPv4. Em alternativa, as suas redes IPv4 e IPv6 podem ser simples. Pode usar o balanceamento de carga agrupado ou o balanceamento de carga manual.

Esta secção apresenta um exemplo de como criar um cluster de pilha dupla. O cluster neste exemplo tem as seguintes características:

Uma rede IPv4 no modo isolado
Uma rede IPv6 no modo simples
Um intervalo CIDR IPv4 ao nível do cluster para pods
Um intervalo CIDR IPv6 ao nível do cluster para pods
Um intervalo CIDR IPv4 ao nível do cluster para serviços
Um intervalo CIDR de IPv6 ao nível do cluster para serviços
Um conjunto de endereços IPv4 a usar para serviços do tipo LoadBalancer
Um conjunto de endereços IPv6 a usar para serviços do tipo LoadBalancer
Balanceamento de carga agrupado

Para ver exemplos de configuração adicionais, consulte o artigo Variações na utilização de ClusterCIDRConfig.

Preencha um ficheiro de configuração

Siga as instruções num dos documentos de criação de clusters.

No ficheiro de configuração, no manifesto Cluster:

Para clusterNetwork.pods.cidrBlocks, forneça um único intervalo CIDR IPv4.
Para clusterNetwork.services.cidrBlocks, indique dois intervalos CIDR: um para IPv4 e outro para IPv6.
Para loadBalancer.addressPools, indique dois intervalos de endereços: um para IPv4 e um para IPv6. Quando cria um serviço do tipo LoadBalancer, os endereços IP externos do serviço são escolhidos a partir destes intervalos.

Segue-se um exemplo que mostra as partes relevantes de um manifesto de 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"

No mesmo ficheiro de configuração, inclua um manifesto para um ClusterCIDRConfig.

Defina ipv4.cidr para o mesmo intervalo CIDR que indicou no Clustermanifesto. Este é um requisito se o IPv4 estiver no modo de ilha.
Defina namespace com o mesmo valor que indicou no manifesto Cluster.
Defina ipv6.cidr para um intervalo CIDR IPv6 para pods.
Para cada intervalo CIDR, indique um valor para perNodeMaskSize para especificar quantos endereços de pods vão ser atribuídos a cada nó. O número de endereços IPv4 atribuídos a cada nó tem de ser igual ao número de endereços IPv6 atribuídos a cada nó. Tem de definir os valores para perNodeMaskSize em conformidade. Por exemplo, se quiser 2⁸ endereços por nó, defina os valores de perNodeMaskSize da seguinte forma:
- ipv4.perNodeMaskSize: 24 # (32 - 8 = 24)
- ipv6.perNodeMaskSize: 120 # (128 - 8 = 120)

Segue-se um exemplo de um manifesto 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

No exemplo anterior:

O intervalo CIDR do pod IPv4 tem 2^(32-16) = 2¹⁶ endereços. O tamanho da máscara por nó é 24, pelo que o número de endereços atribuídos a cada nó é 2^(32-24) = 2⁸.
O intervalo CIDR do pod IPv6 tem 2^(128-112) = 2¹⁶ endereços. O tamanho da máscara por nó é 120, pelo que o número de endereços atribuídos a cada nó é 2^(128-120) = 2⁸.

Exemplo de ficheiro de configuração

Clique para ver um exemplo de um ficheiro de configuração preenchido.

Aviso: não use este exemplo tal como está. Substitua os intervalos de endereços e os caminhos das chaves por valores adequados para a sua rede.

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

Conclua a criação do cluster

Conclua a criação do cluster conforme descrito no seu documento de criação de clusters.

Veja nós de cluster e pods

Liste os nós do cluster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes --output yaml

Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster.

No resultado, pode ver os endereços IPv4 e IPv6 de cada nó. Também pode ver os intervalos de endereços IPv4 e IPv6 para os pods no nó. Por exemplo:

- 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

Liste os pods no cluster:

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

Escolha um Pod e liste os detalhes. Por exemplo:

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

No resultado, pode ver os endereços IPv4 e IPv6 do pod. Por exemplo:

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

Variações na utilização de ClusterCIDRConfig

O exemplo anterior usou um objeto ClusterCIDRConfig para especificar intervalos CIDR de pods ao nível do cluster. Ou seja, é usado um único intervalo CIDR IPv4 para todos os pods no cluster. Além disso, é usado um único intervalo CIDR IPv6 para todos os pods no cluster.

Em determinadas situações, pode não querer usar um único intervalo CIDR para todos os pods num cluster. Por exemplo, pode querer especificar um intervalo CIDR separado para cada conjunto de nós ou um intervalo CIDR separado para cada nó. Para mais informações sobre ClusterCIDRConfig e exemplos de utilização, consulte o artigo Compreenda o recurso personalizado ClusterCIDRConfig.

Por exemplo, o seguinte ClusterCIDRConfig especifica um intervalo CIDR para um conjunto de nós denominado "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"

O seguinte ClusterCIDRConfig especifica um intervalo CIDR para um único nó com o endereço 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"

Crie um serviço de pilha dupla do tipo `ClusterIP`

Segue-se um manifesto para uma implementação:

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"

Guarde o manifesto num ficheiro com o nome my-deployment.yaml e crie a implementação:

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

Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster.

Segue-se um manifesto para um serviço do 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

No contexto deste exercício, estes são os pontos principais a compreender acerca do manifesto de serviço anterior:

O campo ipFamilyPolicy está definido como RequireDualStack. Isto significa que são atribuídos endereços IPv6 e IPv4 ClusterIP ao serviço.
O campo ipFamilies especifica primeiro a família IPv6 e, em segundo lugar, a família IPv4. Isto significa que spec.ClusterIP para o serviço será um endereço IPv6 escolhido a partir de clusterNetwork.services.cidrBlocks no manifesto do cluster.

Guarde o manifesto num ficheiro com o nome my-cip-service.yaml e crie o serviço:

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

Indique detalhes sobre o serviço:

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

No resultado, pode ver os endereços IP do cluster para o serviço. Por exemplo:

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

Num nó do cluster, chame o serviço:

curl IPV4_CLUSTER_IP
curl IPV6_CLUSTER_IP

O resultado apresenta a mensagem "Hello world":

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

Crie um serviço de pilha dupla do tipo `LoadBalancer`

Segue-se um manifesto para um serviço do 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

Guarde o manifesto num ficheiro com o nome my-lb-service.yaml e crie o serviço:

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

Recorde que, no manifesto do cluster, especificou um intervalo de endereços IPv6 e um intervalo de endereços IPv4 a serem usados para serviços do tipo LoadBalancer:

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

Ao seu serviço é atribuído um endereço IPv4 externo escolhido no intervalo IPv4 e um endereço IPv6 externo escolhido no intervalo IPv6.

Detalhes da lista do serviço:

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

Na saída, pode ver os endereços externos do serviço. Por exemplo:

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

Valores possíveis para `ipFamilyPolicy`

Quando cria um serviço de pilha dupla, pode definir ipFamilyPolicy para um dos seguintes valores:

SingleStack: o controlador atribui um endereço IP do cluster ao serviço, escolhido a partir do primeiro intervalo especificado no manifesto do cluster em clusterNetwork.services.cidrBlocks.
PreferDualStack: O controlador atribui endereços IP do cluster IPv4 e IPv6 para o serviço, escolhidos nos intervalos especificados no manifesto do cluster em clusterNetwork.services.cidrBlocks. Se o cluster não for um cluster de pilha dupla, o comportamento é o mesmo que com SingleStack.
RequireDualStack: O controlador atribui endereços IP do cluster IPv4 e IPv6 para o serviço, escolhidos a partir dos intervalos especificados no manifesto do cluster em clusterNetwork.services.cidrBlocks. Define o valor de spec.clusterIP com base na primeira família de endereços especificada no manifesto do serviço em ipFamilies.

Mais informações

Para mais informações sobre como criar serviços de pilha dupla, consulte o artigo Opções de pilha dupla em novos serviços.