GKE en Bare Metal admite herramientas de redes de doble pila IPv4/IPv6. Esto significa que un clúster puede aceptar tráfico de dispositivos externos que usan la versión 4 del Protocolo de Internet (IPv4) o la versión 6 del Protocolo de Internet (IPv6).
Las redes de doble pila asignan direcciones IPv4 e IPv6 a los Pods y nodos. Un Service de Kubernetes puede tener una dirección IPv4, IPv6 o ambas.
Todos los clústeres de doble pila usan el modo plano para IPv6. De forma predeterminada, un clúster de doble pila usa el modo de isla para IPv4, pero puedes configurarlo de modo que use el modo plano para IPv4.
Para crear un clúster de pila doble, la red subyacente debe tener habilitada la pila doble. Si la red subyacente es una red IPv4 o IPv6 de una sola pila, no puedes iniciar un clúster de pila doble.
Antes de comenzar
Si los nodos de tu clúster ejecutan CentOS o Red Hat Enterprise Linux y tienen SELinux habilitado, sucede lo siguiente en cada nodo:
En
/etc/firewalld/firewalld.conf
, configuraIPv6_rpfilter=no
.Ejecuta
systemctl restart firewalld
.
Descripción general de la creación de un clúster de doble pila
Puedes habilitar las redes de pila doble cuando creas un clúster nuevo, pero no puedes habilitarlas para un clúster existente.
Sigue las instrucciones de uno de los documentos sobre la creación de clústeres.
En el archivo de configuración, incluye los manifiestos de lo siguiente:
- Un recurso de espacio de nombres
- Un recurso de clúster
- Uno o más recursos de grupo de nodos
- Uno o más recursos ClusterCIDRConfig
Completa el manifiesto del Espacio de nombres y los manifiestos del grupo de nodos como lo harías con un clúster de una sola pila.
En el manifiesto del clúster, en clusterNetwork.services.cidrBlocks
, especifica un rango de CIDR de IPv4 y un rango de CIDR de IPv6. Este es el criterio de habilitación para un clúster de pila doble. Es decir, si proporcionas rangos de CIDR de Service para IPv4 y también para IPv6, tu clúster tendrá una red de doble pila.
En el manifiesto del clúster, en clusterNetwork.pods.cidrBlocks
, especifica un rango CIDR de IPv4, pero no especifiques un rango de CIDR de IPv6. Los rangos de CIDR de IPv6 para los 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 del clúster.
Los recursos ClusterCIDRConfig sirven para especificar rangos de CIDR IPv4 e IPv6 para Pods. Puedes usar un solo recurso ClusterCIDRConfig para especificar rangos CIDR que estén en todo el clúster. Es decir, las direcciones del Pod IPv4 de todos los nodos se toman de un único rango de CIDR, y las direcciones del Pod IPv6 de todos los nodos se toman de un solo rango de CIDR. También puedes usar varios recursos ClusterCIDRConfig para especificar los rangos CIDR que se aplican a un grupo de nodos en particular o a un nodo en particular.
Accesibilidad para direcciones IP de Pods
Un clúster de doble pila usa el modo plano para las redes IPv6. El ejemplo que se brinda en este documento corresponde a un clúster que usa herramientas de redes estáticas de modo plano para IPv6. Es decir, el clúster no está configurado para usar el Protocolo de Puerta de Enlace Fronteriza (BGP).
Para un clúster que usa herramientas de redes estáticas de modo plano, debes especificar direcciones IP de nodos y Pods que formen parte de la misma subred. Esto permite que los clientes fuera del clúster, pero en el mismo dominio de capa 2 (L2) que los nodos del clúster, envíen paquetes directamente a las direcciones IP del Pod.
Por ejemplo, supongamos que los nodos de tu clúster y algunas otras máquinas están todas en el mismo dominio L2. Aquí te mostramos una manera de especificar rangos de direcciones:
Objetivo | Rango | Cantidad de direcciones |
---|---|---|
Dominio de L2 completo | fd12::/108 | 2^20 |
Pods | fd12::1:0/112 | 2^16 |
Nodos | fd12::2:0/112 | 2^16 |
Otras máquinas | fd12::3:0/112 | 2^16 |
VIP | fd12::4:0/112 | 2^16 |
En el ejemplo anterior, estos son los puntos clave a comprender:
Todas las direcciones de nodos, Pods y máquinas se encuentran en el rango amplio: fd12::/108.
Las direcciones IP del Pod se encuentran en un subconjunto del gran rango.
Las direcciones IP del nodo se encuentran en un subconjunto diferente del gran rango.
Las direcciones IP de otras máquinas se encuentran en un subconjunto diferente del gran rango.
Todos los rangos del subconjunto son diferentes entre sí.
En el ejemplo anterior, cada máquina en el dominio L2, incluidos los nodos del clúster, debe tener una regla de reenvío para el gran rango. Por ejemplo:
inet fd12::/108 scope global eth0
Ejemplo: Crea un clúster de doble pila
Cuando creas un clúster de pila doble, tienes varias opciones. Por ejemplo, podrías tener rangos de CIDR en todo el clúster o rangos de CIDR que se apliquen a grupos de nodos particulares. Puedes combinar una red IPv6 plana con una red IPv4 en modo de isla. También es posible que las redes IPv4 e IPv6 sean planas. Puedes usar el balanceo de cargas en paquetes o el balanceo de cargas manual.
En esta sección, se muestra 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 IPv4 CIDR de todo el clúster para Pods
- Un rango de CIDR IPv6 en todo el clúster para Pods
- Un rango IPv4 CIDR en todo el clúster para objetos Service
- Un rango de CIDR IPv6 en todo el clúster para objetos Service
- Un grupo de direcciones IPv4 que se usará para los servicios de tipo
LoadBalancer
- Un grupo de direcciones IPv6 que se usará para los servicios de tipo
LoadBalancer
- Balanceo de cargas en paquetes
Para ver ejemplos de configuración adicionales, consulta Variaciones sobre el uso de ClusterCIDRConfig.
Completa un archivo de configuración
Sigue las instrucciones de uno de los documentos sobre la creación de clústeres.
En el archivo de configuración, en el manifiesto Cluster
:
Para
clusterNetwork.pods.cidrBlocks
, proporciona un solo rango de CIDR IPv4.En
clusterNetwork.services.cidrBlocks
, proporciona dos rangos de CIDR: uno para IPv4 y otro para IPv6.En
loadBalancer.addressPools
, proporciona dos rangos de direcciones: uno para IPv4 y otro para IPv6. Cuando creas un servicio de tipoLoadBalancer
, las direcciones IP externas del servicio se eligen de estos rangos.
A continuación, se incluye un ejemplo en el que se muestran las partes relevantes del manifiesto de un 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
.
Configura
ipv4.cidr
en el mismo rango CIDR que proporcionaste en el manifiestoCluster
. Esto es un requisito si IPv4 está en modo isla.Configura
namespace
con el mismo valor que proporcionaste en el manifiestoCluster
.Configura
ipv6.cidr
como un rango CIDR de IPv6 para los Pods.Para cada rango CIDR, proporciona un valor para
perNodeMaskSize
a fin de 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 paraperNodeMaskSize
según corresponda. Por ejemplo, si deseas 2^8 direcciones por nodo, configura los valores deperNodeMaskSize
de la siguiente manera:ipv4.perNodeMaskSize: 24
N° (32 - 8 = 24)ipv6.perNodeMaskSize: 120
N° (128 - 8 = 120)
Este es 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 de CIDR del Pod IPv4 tiene 2^(32-16) = 2^16 direcciones. El tamaño de la máscara por nodo es de 24, por lo que la cantidad de direcciones asignadas a cada nodo es 2^(32-24) = 2^8.
El rango de CIDR del Pod de IPv6 tiene 2^(128-112) = 2^16 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^8.
Archivo de configuración de ejemplo
Termina de crear el clúster
Termina de crear tu clúster como se describe en el documento de creación de clústeres.
Visualiza los nodos y Pods del clúster
Enumera los nodos del clúster:
kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes --output yaml
Reemplaza CLUSTER_KUBECONFIG
por la ruta de acceso del archivo kubeconfig del clúster.
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 los Pods del 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, luego, enumera 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 sobre el uso de ClusterCIDRConfig
En el ejemplo anterior, se usó un objeto ClusterCIDRConfig para especificar rangos de CIDR del Pod de todo el clúster. Es decir, se usa un solo rango de CIDR IPv4 para todos los Pods del clúster. Se usa un solo rango de CIDR 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.
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 Service de doble pila 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 Deployment:
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-deployment.yaml
Reemplaza CLUSTER_KUBECONFIG
por la ruta de acceso del archivo kubeconfig del clúster.
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 para comprender el manifiesto de servicio anterior:
El campo
ipFamilyPolicy
está configurado comoRequireDualStack
. Esto significa que se asignan las direcciones IPv6 e IPv4ClusterIP
para el Service.El campo
ipFamilies
especifica primero la familia IPv6 y, en segundo lugar, la familia IPv4. Esto significa quespec.ClusterIP
para el servicio será una dirección IPv6 elegida declusterNetwork.services.cidrBlocks
en el manifiesto del clúster.
Guarda el manifiesto en un archivo llamado my-cip-service.yaml
y crea el Service:
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-cip-service.yaml
Enumera los detalles sobre el Service:
kubectl --kubeconfig CLUSTER_KUBECONFIG get service my-service --output yaml
En el resultado, puedes ver las direcciones IP del clúster para el Service. 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 Service:
curl IPV4_CLUSTER_IP curl [IPV6_CLUSTER_IP]
El resultado muestra el mensaje “Hello World”:
Hello, world! Version: 2.0.0 Hostname: my-deployment-xxx
Crea un Service de doble pila 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 Service:
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-lb-service.yaml
Recuerda que, en el manifiesto del clúster, especificaste un rango de direcciones IPv6 y un rango de direcciones IPv4 que se usarán con 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 otra externa del rango IPv6.
Enumera los detalles del Service:
kubectl --kubeconfig CLUSTER_KUBECONFIG get service my-lb-service --output yaml
En el resultado, puedes ver las direcciones externas del Service. 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, que se elige del primer rango especificado en el manifiesto del clúster, enclusterNetwork.services.cidrBlocks
.PreferDualStack
: El controlador asigna direcciones IP de clústeres IPv4 e IPv6 para el Service, elegidas de los rangos especificados en el manifiesto del clúster enclusterNetwork.services.cidrBlocks
. Si el clúster no es de doble pila, el comportamiento es el mismo que conSingleStack
.RequireDualStack
: El controlador asigna direcciones IP de clústeres IPv4 e IPv6 para el Service, elegidas de los rangos especificados en el manifiesto del clúster enclusterNetwork.services.cidrBlocks
. Establece el valor despec.clusterIP
según la primera familia de direcciones especificada en el manifiesto de servicio, enipFamilies
.
Más información
Si quieres obtener más información para crear servicios de doble pila, consulta Opciones de pila doble en servicios nuevos.