En esta página, se describen los parámetros para manifiestos de Services que controlan el comportamiento y la configuración de Services LoadBalancer. Antes de leer esta página, asegúrate de estar familiarizado con los conceptos de Services LoadBalancer de Google Kubernetes Engine (GKE).
Parámetros de servicio
GKE admite los siguientes parámetros para los Services LoadBalancer.
| Parámetro | Campo y descripción del Service | Interno | Externo | Compatibilidad con las versiones |
|---|---|---|---|---|
| Balanceador de cargas de red de transferencia interno | networking.gke.io/load-balancer-type: "Internal"
Indica a GKE que cree un balanceador de cargas de red de transferencia interno. Para obtener más detalles, consulta los conceptos de Services LoadBalancer. |
Todas las versiones compatibles. | ||
| Balanceador de cargas de red de transferencia externo basado en servicios de backend | cloud.google.com/l4-rbs: "enabled"
Indica a GKE que cree un balanceador de cargas de red de transferencia externo basado en servicios de backend. Para obtener más detalles, consulta los conceptos de Services LoadBalancer. |
GKE 1.25.5+ | ||
| Política de tráfico interno | spec.internalTrafficPolicy
Cuando se configura como Este parámetro no es compatible con clústeres que ejecutan GKE Dataplane V2. |
GKE 1.22+ | ||
| Política de tráfico externo | spec.externalTrafficPolicy
Controla cuáles VM del nodo pasan las verificaciones de estado del balanceador de cargas y cómo se enrutan los paquetes a los Pods que están listos y en funcionamiento en el clúster. También controla cómo los nodos se agrupan en los NEG Para obtener más detalles, consulta los conceptos de Services LoadBalancer. |
GKE 1.14+ (1.23.4-gke.400+ para el grupo de nodos de Windows). | ||
| Puerto de verificación de estado | spec.healthCheckNodePort
Implementa una verificación de estado del balanceador de cargas para los objetos Service de tipo LoadBalancer. Este parámetro solo es válido si |
Todas las versiones compatibles. | ||
| Reglas de firewall y lista de direcciones IP de origen permitidas | spec.loadBalancerSourceRanges
Configura reglas de firewall opcionales en GKE y en la red de VPC para permitir solo ciertos rangos de origen.
|
Todas las versiones compatibles. | ||
| Direcciones IP estáticas |
Especifica una dirección IPv4 estática, un rango de direcciones IPv6 estáticas o ambos, que se asignan a las reglas de reenvío del balanceador de cargas. Consulta Consideraciones para compartir una dirección IP común a fin de obtener información sobre los requisitos de configuración importantes y los detalles de implementación. |
|
||
| Niveles de servicio de red | cloud.google.com/network-tier
Especifica qué niveles de servicio de red usa GKE para la regla de reenvío externa y la dirección IP. Los valores válidos de anotación son |
GKE 1.19 y versiones posteriores. | ||
| Subred personalizada |
|
(solo se aplica a IPv6) |
|
|
| Acceso global | networking.gke.io/internal-load-balancer-allow-global-access: "true"
Permite que los clientes de cualquier región de la red de VPC o una red conectada puedan acceder a la dirección IP de la regla de reenvío. |
Vista previa en GKE 1.16+. Disponibilidad general en GKE 1.17.9-gke.600+. | ||
| Se reenvían todos los puertos | No se requiere anotación, pero la subdivisión de GKE debe estar habilitada. GKE configura de forma automática la regla de reenvío para usar todos los puertos si se especifican al menos seis puertos únicos (hasta 100) en |
Versión de GKE 1.18.19-gke.1400 o posterior | ||
| ipFamilyPolicy |
Define cómo GKE asigna direcciones IP a un Service.
Puedes definir Para obtener más información, consulta Services de pila doble de IPv4/IPv6. |
Los clústeres de GKE en la versión 1.29 o posterior admiten la red de pila doble para los objetos Service de LoadBalancer. | ||
| ipFamilies (opcional) |
Define la familia de direcciones IP para asignar Services de pila única o doble. Usa cualquiera de los siguientes valores:
|
Los clústeres de GKE en la versión 1.29 o posterior admiten la red de pila doble para los objetos Service de LoadBalancer. |
Puerto de verificación de estado
Como se describe en Verificaciones de estado del balanceador de cargas y , GKE siempre implementa una verificación de estado del balanceador de cargas cuando crea un balanceador de cargas de red de transferencia externo o un balanceador de cargas de red de transferencia interno.
Si puedes establecer el parámetro healthCheckNodePort o no depende de la siguiente configuración de externalTrafficPolicy:
externalTrafficPolicy |
Puerto de verificación de estado |
|---|---|
Cluster |
No puedes utilizar |
Local |
Puedes seleccionar un puerto personalizado con |
Reglas de firewall y lista de entidades permitidas de direcciones IP de origen
Cuando creas un objeto Service de tipo LoadBalancer, GKE crea una regla de firewall de VPC correspondiente al objeto Service. Cada regla de firewall tiene las siguientes características:
- La dirección de la regla de firewall es de entrada y su acción es permitir. Las reglas de firewall de denegación de entrada implícitas en Google Cloud significan que GKE usa un modelo de lista de entidades permitidas cuando se crean reglas de firewall de entrada.
- GKE establece el protocolo y el puerto de destino de la regla de firewall en aquellos especificados en la lista
spec.ports[]del objeto Service. - GKE establece el destino de la regla de firewall mediante la configuración de su parámetro de destino en la dirección IP virtual de LoadBalancer.
- Si el objeto Service incluye
spec.loadBalancerSourceRanges[], GKE establece el parámetro de origen de la regla de firewall en las direcciones IP de esa lista. Además, la instancia dekube-proxyque se ejecuta en cada nodo configura las reglas deiptablesde ese nodo para restringir el tráfico a las direcciones IP especificadas. Si el objeto Service no incluyeloadBalancerSourceRanges[], GKE establece el parámetro de origen de la regla de firewall en todas las direcciones IP(0.0.0.0/0).
La regla de firewall creada para un objeto Service de tipo LoadBalancer permite paquetes, que coinciden con los puertos de destino y el protocolo de ese servicio, con la dirección IP virtual del servicio.
Objetos Service que usan puertos comunes
Cuando un clúster contiene dos o más objetos Service que comparten al menos un protocolo y un puerto de destino comunes, el conjunto efectivo de rangos de origen es la unión de loadBalancerSourceRanges para todos los objetos Service que especifican esa combinación de protocolo y puerto de destino. Esto se debe a que el parámetro objetivo de una regla de firewall de entrada define las direcciones IP de destino como todas las direcciones IP asociadas con una VM.
Considera un clúster que tiene dos objetos Service de tipo LoadBalancer:
- El primer
spec.ports[0].portde un objeto Service es el puerto TCP80y suspec.loadBalancerSourceRanges=[100.10.0.0/16]. El balanceador de cargas resultante correspondiente a este objeto Service tiene la dirección IP192.0.2.2. - El segundo
spec.ports[0].portdel objeto Service es el puerto TCP80,spec.ports[1].portes el puerto TCP90y suspec.loadBalancerSourceRanges=[172.16.0.0/24]. El balanceador de cargas resultante correspondiente a este objeto Service tiene la dirección IP198.51.100.3.
GKE crea dos reglas de firewall ingress-allow en la red de nube privada virtual del clúster. Ambas reglas de firewall especifican todos los nodos del clúster como sus objetivos:
- La primera regla de firewall permite los paquetes en el puerto de destino TCP
80desde el valor100.10.0.0/16de origen. - La segunda regla de firewall permite los paquetes en los puertos de destino TCP
80y90desde el valor172.16.0.0/24de origen.
La primera regla de reenvío enruta el tráfico que coincide con el destino 192.0.2.2:80. La segunda regla de reenvío enruta el tráfico que coincide con los destinos 198.51.100.3:80 y 198.51.100.3:90. Los siguientes tres valores son destinos válidos en cada nodo: 192.0.2.2:80, 198.51.100.3:80 y 198.51.100.3:90. Esto significa que:
- Ambos objetos Service aceptan paquetes al puerto TCP
80desde la unión de los rangos de origen de direcciones IP, ya sea100.10.0.0/16o172.16.0.0/24. - El segundo objeto Service acepta paquetes para el puerto TCP
90de172.16.0.0/24.
El conjunto efectivo de rangos de origen para todos los objetos Service que usan la misma combinación de protocolo y puerto de destino se convierte en todas las direcciones IP si se omite spec.loadBalancerSourceRanges en al menos un objeto Service que usa esa combinación de protocolo y puerto de destino. Por ejemplo, si el segundo objeto Service omitiera spec.loadBalancerSourceRanges, la fuente del segundo firewall sería 0.0.0.0/0, y:
- Ambos objetos Service aceptarían paquetes en el puerto TCP 80 de la unión de los rangos de origen de direcciones IP, ya sea
100.10.0.0/16o0.0.0.0/0. Debido a que el rango0.0.0.0/0incluye el rango100.10.0.0/16, la fuente efectiva para los paquetes en el puerto TCP 80 es cualquier dirección IP. - El segundo Objeto Serive acepta paquetes en el puerto TCP
90desde0.0.0.0/0(cualquier dirección IP).
Direcciones IP estáticas
Puedes crear una dirección IP estática y configurar GKE para que asigne esa dirección IP estática a la regla de reenvío del balanceador de cargas. El uso de una dirección IP estática garantiza que la dirección IP del balanceador de cargas permanezca igual, incluso si realizas cambios en el Service LoadBalancer.
Sin una dirección IP estática, GKE podría asignar una dirección IP diferente a la regla de reenvío del balanceador de cargas cuando actualizas un objeto Service LoadBalancer. La dirección IP de la regla de reenvío no es la misma que la dirección spec.clusterIP del Service. La dirección ClusterIP de un Service nunca cambia cuando actualizas un Service LoadBalancer.
Parámetros de dirección IP estática
Para indicarle a un Service LoadBalancer que use una dirección IP estática, usa el parámetro spec.loadBalancerIP o la anotación networking.gke.io/load-balancer-ip-addresses. En la versión 1.29 de GKE y versiones posteriores, la anotación tiene prioridad sobre spec.loadBalancerIP si el manifiesto del Service contiene el parámetro y la anotación.
| Parámetro o anotación y valor | Requisitos y capacidades |
|---|---|
spec.loadBalancerIP:IPv4_ADDRESS
|
Puedes especificar una dirección IPv4 interna estática para un Service de LoadBalancer interno solo IPv4. Puedes especificar una dirección IPv4 externa estática para un objeto Service LoadBalancer externo solo IPv4. El parámetro funciona con todas las versiones de GKE compatibles. |
networking.gke.io/load-balancer-ip-addresses:IP_ADDRESS_RESOURCE_NAME
|
Puedes especificar direcciones IPv4 estáticas, un rango de direcciones IPv6 estáticas o ambos para Services LoadBalancer internos y externos de pila doble, solo IPv4 y solo IPv6. La anotación requiere GKE 1.29 o una versión posterior y los siguientes requisitos adicionales:
|
Consideraciones para compartir una dirección IP común
Dos o más Services LoadBalancer pueden hacer referencia a la misma dirección IP estática si la regla de reenvío para cada balanceador de cargas usa una combinación única de dirección IP, protocolo, especificación de puerto y especificación de Niveles de servicio de red, como se indica en la tabla de esta sección. Además:
Las direcciones IPv6 estáticas en realidad son rangos de direcciones IPv6
/96, pero GKE solo configura los nodos para que acepten paquetes en la primera dirección IPv6 (/128) en el rango/96.Para que dos o más Service LoadBalancer internos usen la misma dirección IPv4 interna o el rango de direcciones IPv6 interno, la dirección IP estática debe crearse con el propósito
SHARED_LOADBALANCER_VIP.
| Service LoadBalancer interno | Servicio LoadBalancer externo | |
|---|---|---|
| Especificación de puerto | Las reglas de reenvío para balanceadores de cargas de red de transferencia internos admiten hasta cinco números de puerto discretos o se pueden configurar para usar todos los puertos. Cuando un Service LoadBalancer interno tiene seis o más Cuando una regla de reenvío usa todos los puertos, ninguna otra regla de reenvío (por lo tanto, ningún otro Service LoadBalancer interno) puede usar la misma dirección IP. |
GKE crea un balanceador de cargas de red de transferencia externo basado en grupos de destino si el manifiesto del Service LoadBalancer no tiene la anotación Las reglas de reenvío para balanceadores de cargas de red de transferencia externos basados en grupos de destino deben usar rangos de puertos contiguos. El rango de puertos contiguo incluye todos los puertos que necesita el Service, pero el rango también puede incluir puertos adicionales que el Service no usa. Por ejemplo, un Service LoadBalancer externo alimentado por un balanceador de cargas de red de transferencia externo basado en grupos de destino que especifica los puertos 80 y 443 en su manifiesto de Service usa una regla de reenvío del balanceador de cargas con un rango de puertos 80-443. Este rango de puertos evita que otros objetos Service LoadBalancer externos usen los puertos 80, 443 y cualquiera de los números entre el 80 y el 443. GKE crea un balanceador de cargas de red de transferencia externo basado en servicios de backend si el manifiesto del Service LoadBalancer incluye la anotación |
| Niveles de servicio de red | No configurable: las direcciones internas siempre son de nivel Premium. | Configurable para direcciones IPv4 externas regionales estáticas. Los rangos de direcciones IPv6 externas regionales estáticas solo se pueden crear en el nivel Premium. La especificación de los niveles de servicio de red de la dirección IP externa estática debe coincidir con una de las siguientes opciones:
El nivel predeterminado del proyecto es Premium, a menos que lo hayas configurado de manera diferente. |
Subred de LoadBalancer
Puedes configurar un Service LoadBalancer interno para usar una dirección IPv4 efímera o estática, un rango de direcciones IPv6 o ambos, en una subred personalizada ubicada en la misma región y red de VPC que el clúster. Usa una subred personalizada para un Service LoadBalancer interno a fin de realizar las siguientes acciones:
- Agrupa los balanceadores de cargas de red de transferencia internos creados por los Services LoadBalancer internos de dos o más clústeres de GKE en la misma red de VPC y región.
- Crea Services LoadBalancer internos cuyos balanceadores de cargas de red de transferencia internos tengan direcciones IPv4 separadas de las direcciones IPv4 del nodo del clúster.
- En un clúster de pila doble, crea Services LoadBalancer internos cuyos balanceadores de cargas de red de transferencia internos tengan rangos de direcciones IPv6 separados de las direcciones IPv6 del nodo y del Pod del clúster. Es obligatoria una subred LoadBalancer personalizada para admitir Services LoadBalancer internos si la subred del clúster tiene un rango de direcciones IPv6 externas.
Puedes configurar un Service LoadBalancer externo para usar un rango de direcciones IPv6 efímeras o estáticas en una subred personalizada que se encuentre en la misma región y red de VPC que el clúster. Usa una subred personalizada para crear objetos Service LoadBalancer externos cuyos balanceadores de cargas de red de transferencia externos tienen rangos de direcciones IPv6 separados de las direcciones IPv6 del nodo y del Pod del clúster. Es obligatoria una subred LoadBalancer personalizada para admitir Services LoadBalancer externos en un clúster privado de pila doble porque la subred del clúster tiene un rango de direcciones IPv6 interno.
Anotaciones de subred personalizadas
Usa una de las siguientes anotaciones para indicarle a un Service LoadBalancer que use una dirección IP estática o efímera en una subred personalizada. Si un manifiesto de Service LoadBalancer incluye ambas anotaciones, la anotación networking.gke.io/load-balancer-subnet tiene prioridad siempre que se cumplan los requisitos de anotación.
| Anotación y valor | Requisitos y capacidades |
|---|---|
networking.gke.io/internal-load-balancer-subnet:SUBNET_RESOURCE_NAME
|
Solo puedes usar la anotación a fin de especificar una subred personalizada para un Service LoadBalancer interno solo IPv4. La anotación funciona con todas las versiones de GKE compatibles. |
networking.gke.io/load-balancer-subnet:SUBNET_RESOURCE_NAME
|
Puedes especificar una subred personalizada para un objeto Service LoadBalancer interno de solo IPv4, solo IPv6 o de pila doble. Puedes especificar una subred personalizada para un objeto Service LoadBalancer externo solo IPv6 o de pila doble. La anotación requiere GKE 1.29 o una versión posterior y los siguientes requisitos adicionales:
|
Subred y dirección IPv4 para un Service LoadBalancer interno
En la siguiente tabla, se describen las especificaciones de subred y las combinaciones de direcciones IPv4 válidas para un Service LoadBalancer interno solo IPv4 o de pila doble.
Dirección IPv4 estática
|
Dirección IPv4 efímera | |
|---|---|---|
Subred personalizada
|
Subred personalizada y dirección IPv4 estática: la dirección IPv4 interna estática debe haberse creado en el rango de direcciones IPv4 principal de la subred personalizada. | Subred personalizada y dirección IPv4 efímera: GKE usa una dirección IPv4 interna sin asignar en el rango de direcciones IPv4 principal de la subred personalizada. |
| Subred del clúster | Subred del clúster y dirección IPv4 estática: La dirección IPv4 interna estática debe haberse creado en el rango de direcciones IPv4 principal de la subred del clúster. | Subred del clúster y dirección IPv4 efímera: GKE usa una dirección IPv4 interna sin asignar en el rango de direcciones IPv4 principal de la subred del clúster. |
Subred y rango de direcciones IPv6 para un Service LoadBalancer interno
En la siguiente tabla, se describen las combinaciones válidas de especificación de subred y rango de direcciones IPv6 para un Service LoadBalancer interno solo IPv6 o de pila doble. Aunque la regla de reenvío IPv6 del balanceador de cargas de red de transferencia interno usa un rango de direcciones IPv6 /96 interno, GKE solo configura nodos para aceptar paquetes cuyos destinos coincidan con la primera dirección IPv6 (/128) del rango /96 de la regla de reenvío.
Rango de direcciones IPv6 estáticas
|
Rango de direcciones IPv6 efímero | |
|---|---|---|
Subred personalizada de pila doble
|
Subred personalizada y rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 internas /96 deben haberse creado en el rango de direcciones IPv6 interno /64 de la subred personalizada.
|
Subred personalizada y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 internas /96 sin asignar del rango de direcciones IPv6 interno /64 de la subred personalizada.
|
Subred de pila doble del clúster
|
Subred del clúster y el rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 internas /96 deben haberse creado en el rango de direcciones IPv6 interno /64 de la subred del clúster.
|
Subred del clúster y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 internas /96 no asignado del rango de direcciones IPv6 interno /64 de la subred del clúster.
|
Subred y dirección IPv4 para un Service LoadBalancer externo
Para los Services LoadBalancer externos de pila doble y solo IPv4, la dirección IPv4 externa (ya sea una dirección IPv4 externa estática o una dirección IPv4 externa efímera) no viene desde una subred.
Subred y rango de direcciones IPv6 para un Service LoadBalancer externo
En la siguiente tabla, se describen las combinaciones válidas de especificación de subred y rango de direcciones IPv6 para un Service LoadBalancer externo solo IPv6 o de pila doble. Aunque la regla de reenvío IPv6 del balanceador de cargas de red de transferencia externo usa un rango de direcciones IPv6 /96 externo, GKE solo configura nodos para aceptar paquetes cuyos destinos coincidan con la primera dirección IPv6 (/128) del rango /96 de la regla de reenvío.
Rango de direcciones IPv6 estáticas
|
Rango de direcciones IPv6 efímero | |
|---|---|---|
Subred personalizada de pila doble
|
Subred personalizada y rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 externas estáticas /96 debe haberse creado en el rango de direcciones IPv6 externas /64 de la subred personalizada. Los rangos de direcciones IPv6 externas estáticas solo se pueden crear en el nivel Premium.
|
Subred personalizada y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 externas /96 sin asignar del rango de direcciones IPv6 externas /64 de la subred personalizada.
|
Subred de pila doble del clúster
|
Subred del clúster y rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 externas estáticas /96 debe haberse creado en el rango de direcciones IPv6 externas /64 de la subred del clúster. Los rangos de direcciones IPv6 externas estáticas solo se pueden crear en el nivel Premium.
|
Subred del clúster y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 externas /96 sin asignar del rango de direcciones IPv6 externo /64 de la subred del clúster.
|
Acceso global
Cuando la anotación networking.gke.io/internal-load-balancer-allow-global-access es false o no se especifica para un Service LoadBalancer interno, GKE crea un balanceador de cargas de red de transferencia interno cuya regla de reenvío tiene inhabilitado el acceso global. Cuando el acceso global está inhabilitado, los clientes que necesitan acceder al balanceador de cargas deben estar ubicados en la misma región y red de VPC, o en una red conectada a la red de VPC del clúster.
Cuando la anotación networking.gke.io/internal-load-balancer-allow-global-access es true para un Service LoadBalancer interno, GKE habilita la opción de acceso global en la regla de reenvío del balanceador de cargas de red de transferencia interno.
Los clientes ubicados en cualquier región de la red de VPC o una red conectada a la red de VPC del clúster pueden acceder al balanceador de cargas.
Para obtener más información sobre el acceso global a los clientes de una red conectada, consulta:
- Acceso del cliente en la documentación del balanceador de cargas de red de transferencia interno
- Balanceadores de cargas de red de transferencia internos y redes conectadas
Todas las reglas de reenvío de puertos
Las reglas de reenvío para balanceadores de cargas de red de transferencia internos admiten cinco números de puerto únicos o todos los puertos.
En los clústeres de GKE con la subdivisión de GKE inhabilitada, un Service LoadBalancer interno solo puede admitir cinco puertos únicos en el spec.ports[].port del Service.
En los clústeres de GKE con la subdivisión de GKE habilitada, un Service LoadBalancer interno solo puede admitir hasta 100 puertos en el spec.ports[].port del Service. Para los Services LoadBalancer internos con entre seis y 100 entradas spec.ports[].port únicas, GKE configura la regla de reenvío del balanceador de cargas de red de transferencia interno para usar todos los puertos desde su creación. El controlador de GKE habilita todos los puertos en la regla de reenvío porque el Service tiene más de cinco puertos. Cuando configuras una regla de reenvío a fin de usar todos los puertos, GKE solo crea reglas de firewall de permiso de entrada para los puertos específicos configurados en spec.ports[].port en el Service.
Para obtener más información sobre las reglas de reenvío del balanceador de cargas de red de transferencia interno y las especificaciones de puertos válidas, consulta Reglas de reenvío y especificaciones de puertos.
Service LoadBalancer de pila doble IPv4/IPv6
Puedes crear un objeto Service LoadBalancer interno o externo que pueda ser de pila única (solo IPv4 o IPv6) o de pila doble. Los objetos Service LoadBalancer de pila única crean una sola regla de reenvío con una dirección IPv4 o IPv6. Los objetos Service LoadBalancer de doble pila crean dos reglas de reenvío: una con una dirección IPv4 y otra con una dirección IPv6. Para crear un Service LoadBalancer de pila doble IPv4/IPv6, impleméntalo en un clúster de pila doble de IPv4/IPv6 y completa cualquiera de las siguientes opciones según el tipo de balanceador de cargas que uses:
- Para los objetos Service LoadBalancer internos, debes tener habilitada la subdivisión de GKE. Para obtener más información, consulta subdivisión del balanceador de cargas interno.
- Para los Services LoadBalancer externos, debes usar un balanceador de cargas de red de transferencia basado en servicios de backend que use servicios de backend regionales. Para obtener más información, consulta Balanceador de cargas de red externo basado en servicios de backend.
Para cada servicio, puedes definir las especificaciones ipFamilyPolicy y ipFamilies. Para obtener más información, consulta Pila doble de IPv4/IPv6.
Restricciones de Service LoadBalancer de pila doble
- Los objetos Service LoadBalancer con direcciones IPv6 solo son compatibles con los clústeres con tipo de pila
ipv4-ipv6. Si deseas obtener más información, consulta Usa una dirección IP de pila doble para un clúster nativo de la VPC. Los objetos Service LoadBalancer creados con una dirección de pila única no se pueden actualizar a servicios de pila doble.
Los objetos Service LoadBalancer creados con direcciones de pila doble se pueden cambiar a una sola pila según las siguientes condiciones:
- Un Service con ipFamilies
["IPv4","IPv6"]se puede cambiar a uno con ipFamiliesIPv4, pero no conIPv6. - Un Service con ipFamilies
["IPv6","IPv4"]se puede cambiar a uno con ipFamiliesIPv6, pero no conIPv4.
- Un Service con ipFamilies