Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Herramientas de redes de pila doble IPv4/IPv6

Google Distributed Cloud admite herramientas de redes de pila doble IPv4/IPv6. Esto significa que un clúster puede aceptar tráfico de dispositivos externos que usan el Protocolo de Internet versión 4 (IPv4) o el Protocolo de Internet versión 6 (IPv6).

Las herramientas de redes de pila doble asignan direcciones IPv4 e IPv6 a los Pods y nodos. Un servicio de Kubernetes puede tener una dirección IPv4, una dirección IPv6 o ambas.

Todos los clústeres de pila doble usan el modo plano para IPv6. De forma predeterminada, un clúster de pila doble usa el modo isla para IPv4, pero puedes configurarlo para que use el modo plano para IPv4.

Para crear un clúster de pila doble, tu red subyacente debe tener habilitada la pila doble. Si tu red subyacente es una red IPv4 o IPv6 de pila única, no puedes iniciar un clúster de pila doble.

Antes de comenzar

Si los nodos de tu clúster ejecutan RedHat Enterprise Linux, y tienen habilitado SELinux, haz lo siguiente en cada nodo:

En /etc/firewalld/firewalld.conf, establece IPv6_rpfilter=no.
Ejecuta systemctl restart firewalld.

Descripción general de la creación de un clúster de pila doble

Puedes habilitar las herramientas de redes de pila doble cuando creas un clúster nuevo, pero no puedes habilitarlas en un clúster existente.

Sigue las instrucciones de uno de los documentos de creación de clústeres.

En tu archivo de configuración, incluye manifiestos para lo siguiente:

Un recurso de espacio de nombres
Un recurso de clúster
Uno o más recursos de NodePool
Uno o más recursos de ClusterCIDRConfig

Completa el manifiesto de espacio de nombres y los manifiestos de NodePool como lo harías para un clúster de pila única.

En el manifiesto de clúster, en clusterNetwork.services.cidrBlocks, especifica un rango CIDR de IPv4 y un rango CIDR de IPv6. Este es el criterio de habilitación para un clúster de pila doble. Es decir, si proporcionas rangos CIDR de servicio para IPv4 e IPv6, tu clúster tendrá una red de pila doble.

En el manifiesto de clúster, en clusterNetwork.pods.cidrBlocks, especifica un rango CIDR de IPv4, pero no especifiques un rango CIDR de IPv6. Los rangos CIDR de IPv6 para Pods se especifican en los manifiestos de ClusterCIDRConfig.

Si usas el balanceo de cargas en paquetes, proporciona direcciones IPv4 e IPv6 en la sección loadBalancer.addressPools del manifiesto de clúster.

Los recursos ClusterCIDRConfig se usan para especificar rangos CIDR de IPv4 e IPv6 para Pods. Puedes usar un solo recurso ClusterCIDRConfig para especificar rangos CIDR que abarquen todo el clúster. Es decir, las direcciones IPv4 de Pod para todos los nodos se toman de un solo rango CIDR, y las direcciones IPv6 de Pod para todos los nodos se toman de un solo rango CIDR. O bien, puedes usar varios recursos ClusterCIDRConfig para especificar rangos CIDR que se apliquen a un grupo de nodos o a un nodo en particular.

Accesibilidad para las direcciones IP del Pod

Un clúster de pila doble usa el modo plano para las herramientas de redes IPv6. El ejemplo que se proporciona en este documento es para un clúster que usa herramientas de redes de modo plano estático para IPv6. Es decir, el clúster no está configurado para usar el protocolo de puerta de enlace de frontera (BGP).

Para un clúster que usa herramientas de redes de modo plano estático, debes especificar direcciones IP de nodo y Pod que formen parte de la misma subred. Esta configuración permite que los clientes fuera del clúster, pero en el mismo dominio de capa 2 que los nodos del clúster, envíen paquetes directamente a las direcciones IP de Pod.

Por ejemplo, supongamos que los nodos de tu clúster y algunas otras máquinas están en el mismo dominio de capa 2. Esta es una forma de especificar rangos de direcciones:

Objetivo	Rango	Cantidad de direcciones
Dominio completo de capa 2	`fd12::/108`	2²⁰
Pods	`fd12::1:0/112`	2¹⁶
Nodos	`fd12::2:0/112`	2¹⁶
Otras máquinas	`fd12::3:0/112`	2¹⁶
VIP	`fd12::4:0/112`	2¹⁶

En el ejemplo anterior, estos son los puntos clave que debes comprender:

Todas las direcciones de nodos, Pods y máquinas están en el rango grande: fd12::/108.
Las direcciones IP de Pod están en un subconjunto del rango grande.
Las direcciones IP de nodo están en un subconjunto diferente del rango grande.
Las direcciones IP de otras máquinas están en un subconjunto diferente del rango grande.
Todos los rangos de subconjuntos son distintos entre sí.

En el ejemplo anterior, cada máquina del dominio de capa 2, incluidos los nodos del clúster, debe tener una regla de reenvío para el rango grande. Por ejemplo:

inet fd12::/108 scope global eth0

Ejemplo: Crea un clúster de pila doble

Cuando creas un clúster de pila doble, tienes varias opciones. Por ejemplo, puedes tener rangos CIDR en todo el clúster o rangos CIDR que se apliquen a grupos de nodos específicos. Puedes combinar una red plana de IPv6 con una red de modo isla de IPv4. O bien, tus redes IPv4 e IPv6 podrían ser planas. Puedes usar el balanceo de cargas en paquetes o el balanceo de cargas manual.

En esta sección, se proporciona un ejemplo de cómo crear un clúster de pila doble. El clúster de este ejemplo tiene las siguientes características:

Una red IPv4 en modo isla
Una red IPv6 en modo plano
Un rango CIDR de IPv4 en todo el clúster para Pods
Un rango CIDR de IPv6 en todo el clúster para Pods
Un rango CIDR de IPv4 en todo el clúster para Services
Un rango CIDR de IPv6 en todo el clúster para Services
Un grupo de direcciones IPv4 que se usará para los Services de tipo LoadBalancer
Un grupo de direcciones IPv6 que se usará para los Services de tipo LoadBalancer
Balanceo de cargas en paquetes

Para obtener ejemplos de configuración adicionales, consulta Variaciones en el uso de ClusterCIDRConfig.

Completa un archivo de configuración

Sigue las instrucciones de uno de los documentos de creación de clústeres.

En el archivo de configuración, en el manifiesto Cluster, haz lo siguiente:

Para clusterNetwork.pods.cidrBlocks, proporciona un solo rango CIDR de IPv4.
Para clusterNetwork.services.cidrBlocks, proporciona dos rangos CIDR: uno para IPv4 y otro para IPv6.
Para loadBalancer.addressPools, proporciona dos rangos de direcciones: uno para IPv4 y otro para IPv6. Cuando creas un servicio de tipo LoadBalancer, las direcciones IP externas del Service se eligen a partir de estos rangos.

Este es un ejemplo en el que se muestran las partes relevantes de un manifiesto de clúster:

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"

En el mismo archivo de configuración, incluye un manifiesto para un ClusterCIDRConfig.

Establece ipv4.cidr en el mismo rango CIDR que proporcionaste en el manifiesto Cluster. Este es un requisito si IPv4 está en modo isla.
Establece namespace en el mismo valor que proporcionaste en el manifiesto Cluster.
Establece ipv6.cidr en un rango CIDR de IPv6 para Pods.
Para cada rango CIDR, proporciona un valor para perNodeMaskSize para especificar cuántas direcciones de Pods se asignarán a cada nodo. La cantidad de direcciones IPv4 asignadas a cada nodo debe ser la misma que la cantidad de direcciones IPv6 asignadas a cada nodo. Debes establecer los valores de perNodeMaskSize en consecuencia. Por ejemplo, si deseas 2⁸ direcciones por nodo, establece los valores de perNodeMaskSize de la siguiente manera:
- ipv4.perNodeMaskSize: 24 # (32 - 8 = 24)
- ipv6.perNodeMaskSize: 120 # (128 - 8 = 120)

Este un ejemplo de un manifiesto 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

En el ejemplo anterior:

El rango CIDR de Pod de IPv4 tiene 2^(32-16) = 2¹⁶ direcciones. El tamaño de la máscara por nodo es 24, por lo que la cantidad de direcciones asignadas a cada nodo es 2^(32-24) = 2⁸.
El rango CIDR de Pod de IPv6 tiene 2^(128-112) = 2¹⁶ direcciones. El tamaño de la máscara por nodo es 120, por lo que la cantidad de direcciones asignadas a cada nodo es 2^(128-120) = 2⁸.

Archivo de configuración de ejemplo

Haz clic para ver un ejemplo de un archivo de configuración completo.

Precaución: No uses este ejemplo tal como está. Reemplaza los rangos de direcciones y las rutas de acceso de claves por valores adecuados para tu red.

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

Termina de crear el clúster

Termina de crear tu clúster como se describe en tu documento de creación de clústeres.

Visualiza los nodos y Pods del clúster

Haz una lista de los nodos del clúster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes --output yaml

Reemplaza CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.

En el resultado, puedes ver las direcciones IPv4 e IPv6 de cada nodo. También puedes ver los rangos de direcciones IPv4 e IPv6 para Pods en el nodo. Por ejemplo:

- 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

Obtén una lista de los Pods del clúster:

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

Elige un Pod y haz una lista de los detalles. Por ejemplo:

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

En el resultado, puedes ver las direcciones IPv4 e IPv6 del Pod. Por ejemplo:

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

Variaciones en el uso de ClusterCIDRConfig

En el ejemplo anterior, se usó un objeto ClusterCIDRConfig para especificar rangos CIDR de Pod en todo el clúster. Es decir, se usa un solo rango CIDR de IPv4 para todos los Pods del clúster. Y se usa un solo rango CIDR de IPv6 para todos los Pods del clúster.

En ciertas situaciones, es posible que no desees usar un solo rango CIDR para todos los Pods de un clúster. Por ejemplo, es posible que desees especificar un rango CIDR separado para cada grupo de nodos o un rango CIDR separado para cada nodo. Para obtener más información sobre ClusterCIDRConfig y ejemplos de su uso, consulta Comprende el recurso personalizado ClusterCIDRConfig.

Por ejemplo, el siguiente ClusterCIDRConfig especifica un rango CIDR para un grupo de nodos llamado "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"

El siguiente ClusterCIDRConfig especifica un rango CIDR para un solo nodo que tiene la dirección 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 servicio de pila doble de tipo `ClusterIP`

A continuación, se muestra un manifiesto de 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"

Guarda el manifiesto en un archivo llamado my-deployment.yaml y crea el Ingress.

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

Reemplaza CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.

Aquí hay un manifiesto para un servicio de 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

En el contexto de este ejercicio, estos son los puntos clave que debes comprender sobre el manifiesto de servicio anterior:

El campo ipFamilyPolicy se establece en RequireDualStack. Esto significa que se asignan direcciones ClusterIP IPv6 e IPv4 para el servicio.
El campo ipFamilies especifica primero la familia IPv6 y, luego, la familia IPv4. Esto significa que spec.ClusterIP para el servicio será una dirección IPv6 elegida de clusterNetwork.services.cidrBlocks en el manifiesto de clúster.

Guarda el manifiesto en un archivo llamado my-cip-service.yaml y crea el Ingress.

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

Obtén detalles sobre el servicio:

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

En el resultado, puedes ver las direcciones IP del clúster para el servicio. Por ejemplo:

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

En un nodo del clúster, llama al servicio:

curl IPV4_CLUSTER_IP
curl IPV6_CLUSTER_IP

El resultado muestra un mensaje “Hello World”:

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

Crea un servicio de pila doble de tipo `LoadBalancer`

Aquí hay un manifiesto para un servicio de 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

Guarda el manifiesto en un archivo llamado my-lb-service.yaml y crea el Ingress.

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

Recuerda que, en tu manifiesto de clúster, especificaste un rango de direcciones IPv6 y un rango de direcciones IPv4 para que se usen para los servicios de tipo LoadBalancer:

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

A tu servicio se le asignará una dirección IPv4 externa elegida del rango IPv4 y una dirección IPv6 externa elegida del rango IPv6.

Obtén detalles sobre el servicio:

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

En el resultado, puedes ver las direcciones externas del servicio. Por ejemplo:

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

Valores posibles para `ipFamilyPolicy`

Cuando creas un servicio de pila doble, puedes establecer ipFamilyPolicy en uno de estos valores:

SingleStack: El controlador asigna una dirección IP de clúster para el servicio, elegida del primer rango especificado en el manifiesto de clúster en clusterNetwork.services.cidrBlocks.
PreferDualStack: El controlador asigna direcciones IP de clúster IPv4 e IPv6 para el servicio, elegidas de los rangos especificados en el manifiesto de clúster en clusterNetwork.services.cidrBlocks. Si el clúster no es un clúster de pila doble, el comportamiento es el mismo que con SingleStack.
RequireDualStack: El controlador asigna direcciones IP de clúster IPv4 e IPv6 para el servicio, elegidas de los rangos especificados en el manifiesto de clúster en clusterNetwork.services.cidrBlocks. Establece el valor de spec.clusterIP según la primera familia de direcciones especificada en el manifiesto de servicio en ipFamilies.

Más información

Para obtener más información sobre cómo crear Services de pila doble, consulta Opciones de pila doble en Services nuevos.