IBM Cloud Docs
Configuración de direcciones IP y subredes clásicas

Configuración de direcciones IP y subredes clásicas

Cambie la agrupación de las direcciones IP públicas o privadas portátiles disponibles añadiendo subredes a su clúster de IBM Cloud® Kubernetes Service.

Visión general de la red clásica en IBM Cloud Kubernetes Service

Descripción de los conceptos básicos de las redes clásicas en los clústeres de IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service utiliza VLAN, subredes y direcciones IP para proporcionar conectividad de red de componentes de clúster.

VLAN

Cuando se crea un clúster, los nodos trabajadores del clúster se conectan automáticamente a una VLAN. Una VLAN configura un grupo de nodos trabajadores y pods como si estuvieran conectadas a la misma conexión física y ofrece un canal para la conectividad entre los nodos trabajadores y los pods.

VLAN para clústeres estándares
En los clústeres estándares, la primera vez que crea un clúster en una zona, se suministra automáticamente una VLAN pública y una VLAN privada en dicha zona en su cuenta de infraestructura de IBM Cloud. Para los demás clústeres que cree en dicha zona, debe especificar el par de VLAN que desee utilizar en la zona. Puede reutilizar las mismas VLAN pública y privada que se han creado porque varios clústeres pueden compartir las VLAN. Puede conectar los nodos trabajadores tanto a una VLAN pública y a la VLAN privada, o solo a la VLAN privada. Si desea conectar sus nodos trabajadores únicamente a una VLAN privada, utilice el ID de una VLAN privada existente o cree una VLAN privada y utilice el ID durante la creación del clúster.

Para ver las VLAN que se suministran en cada zona para la cuenta, ejecute ibmcloud ks vlan ls --zone <zone>.. Para ver las VLAN en las que se suministra un clúster, ejecute ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources y busque la sección VLAN de subred.

La infraestructura de IBM Cloud gestiona las VLAN que se suministran automáticamente cuando crea el primer clúster en una zona. Si deja que una VLAN quede sin utilizar, por ejemplo eliminando todos los nodos trabajadores de una VLAN, la infraestructura de IBM Cloud reclama la VLAN. Después, si necesita una nueva VLAN, póngase en contacto con el equipo de soporte de IBM Cloud.

¿Puedo cambiar mi decisión sobre VLAN más adelante?
Puede cambiar la configuración de la VLAN modificando las agrupaciones de nodos trabajadores del clúster. Para obtener más información, consulte Cambio de las conexiones de VLAN de nodo trabajador.

Subredes y direcciones IP

Además de los nodos trabajadores y los pods, las subredes también se suministran automáticamente en las VLAN. Las subredes proporcionan conectividad de red a los componentes del clúster mediante la asignación de direcciones IP a los mismos.

Las siguientes subredes se aprovisionan automáticamente en las VLAN pública y privada predeterminadas.

Subredes de la VLAN pública

  • La subred pública primaria determina las direcciones IP públicas que se asignan a los nodos trabajadores durante la creación del clúster. Varios clústeres en la misma VLAN pueden compartir una subred pública primaria.
  • La subred pública portátil sólo está enlazada a un clúster, y proporciona al clúster 8 direcciones IP públicas. 3 IP están reservadas para las funciones de infraestructura de IBM Cloud. 1 IP se utiliza para el ALB de Ingress público predeterminado y 4 IP se pueden utilizar para crear servicios de equilibrador de carga de red (NLB) públicos o más ALB públicos. Las IP públicas portátiles son direcciones IP fijas y permanentes que se pueden utilizar para acceder a los NLB y a los ALB por internet. Si necesita más de 4 IP para los NLB o los ALB, consulte Adición de direcciones IP portátiles. Tenga en cuenta que estas direcciones IP están pensadas para ser utilizadas en IBM Cloud Kubernetes Service. No utilice estas direcciones IP para otros fines que no sean IBM Cloud Kubernetes Service.

Subredes de la VLAN privada

  • La subred privada primaria determina las direcciones IP privadas que se asignan a los nodos trabajadores durante la creación del clúster. Varios clústeres en la misma VLAN pueden compartir una subred privada primaria.
  • La subred privada portátil sólo está enlazada a un clúster, y proporciona al clúster 8 direcciones IP privadas. 3 IP están reservadas para las funciones de infraestructura de IBM Cloud. 1 IP se utiliza para el ALB de Ingress privado predeterminado y 4 IP se pueden utilizar para crear servicios de equilibrador de carga de red (NLB) privados o más ALB privados. Las IP privadas portátiles son direcciones IP fijas y permanentes, que se pueden utilizar para acceder a los NLB o ALB por una red privada. Si necesita más de 4 IP para los NLB o los ALB privados, consulte Adición de direcciones IP portátiles. Tenga en cuenta que estas direcciones IP están pensadas para ser utilizadas en IBM Cloud Kubernetes Service. No utilice estas direcciones IP para otros fines que no sean IBM Cloud Kubernetes Service.

Búsqueda de las subredes suministradas en la cuenta

Para ver todas las subredes suministradas en todos los grupos de recursos de la cuenta, ejecute ibmcloud ks subnets --provider classic. Para ver las subredes portátiles privadas y públicas que están vinculadas a un clúster, puede ejecutar ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources y buscar la sección VLAN de subred.

En IBM Cloud Kubernetes Service, las VLAN tienen un límite de 40 subredes. Si alcanza este límite, compruebe en primer lugar si puede reutilizar subredes en la VLAN para crear nuevos clústeres. Si necesita una nueva VLAN, póngase en contacto con el equipo de soporte de IBM Cloud para solicitar una. A continuación, cree un clúster que utilice esta nueva VLAN.

¿Cambian las direcciones IP de mis nodos de trabajo?
A su nodo trabajador se le asigna una dirección IP en las VLAN públicas o privadas que utiliza el clúster. Una vez suministrado el nodo trabajador, la dirección IP del nodo trabajador persiste entre operaciones reboot y update, pero la dirección IP del nodo trabajador cambia tras una operación replace. Además, la dirección IP privada del nodo trabajador se utiliza para la identidad del nodo trabajador en la mayoría de los mandatos kubectl. Si cambia las VLAN que utiliza la agrupación de nodos trabajadores, los nuevos nodos trabajadores que se suministran en esa agrupación utilizan las nuevas VLAN para sus direcciones IP. Las direcciones IP de nodo de trabajador existentes no cambian, pero puede eliminar los nodos de trabajador que utilizan las VLAN antiguas.
¿Puedo especificar subredes para pods y servicios en mi clúster?
Si tiene previsto conectar el clúster a redes locales mediante IBM Cloud Direct Link o un servicio VPN, puede evitar conflictos de subred si especifica un CIDR de subred personalizada que proporcione las direcciones IP privadas de los pods y un CIDR de subred personalizado para proporcionar las direcciones IP privadas de los servicios.

Para especificar subredes de servicio y pod personalizadas durante la creación del clúster, utilice las opciones --pod-subnet y --service-subnet en el comando CLI ibmcloud ks cluster create.

Pods

Rango predeterminado

De forma predeterminada, todos los servicios que se despliegan en el clúster tienen asignada una dirección IP privada en el rango 172.30.0.0/16.

Requisitos de tamaño

Al especificar una subred personalizada, tenga en cuenta el tamaño del clúster que tenga previsto crear y el número de nodos de trabajador que podría añadir en el futuro. La subred debe tener un CIDR de al menos /23, que proporciona suficientes IP de pod para un máximo de cuatro nodos trabajadores en un clúster. Para clústeres más grandes, utilice /22 para tener suficientes direcciones IP de pod para ocho nodos trabajadores, /21 para tener suficientes direcciones IP de pod para 16 nodos trabajadores, etc.

Requisitos de rango

Las subredes de pod y servicio no se pueden solapar entre sí, y la subred de pod no se puede solapar con las subredes para los nodos de trabajador. La subred elegida tiene que pertenecer a uno de los siguientes rangos.

  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.255.255

  • 198.18.0.0 - 198.19.255.255

Los rangos 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16 están prohibidos.

Servicios

Rango predeterminado

De forma predeterminada, todos los servicios que se despliegan en el clúster tienen asignada una dirección IP privada en el rango 172.21.0.0/16.

Requisitos de tamaño

Cuando se especifica una subred personalizada, la subred debe especificarse en formato CIDR con un tamaño de al menos /24, lo que permite un máximo de 255 servicios en el clúster, o con un tamaño mayor.

Requisitos de rango

Las subredes de pod y servicio no se pueden solapar entre sí. La subred que elija debe estar dentro de uno de los rangos siguientes:

  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.255.255

  • 198.18.0.0 - 198.19.255.255

Los rangos 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16 están prohibidos.

Segmentación de red

La segmentación de red describe el enfoque para dividir una red en varias subredes. Las aplicaciones que se ejecutan en una subred no pueden ver las aplicaciones de otra subred ni acceder a ellas. Para obtener más información sobre las opciones de segmentación de red y sobre cómo se relacionan con las VLAN, consulte este tema sobre la seguridad del clúster.

Sin embargo, en varias situaciones, los componentes del clúster deben poder comunicarse entre varias VLAN privadas. Por ejemplo, si desea crear un clúster multizona, si tiene varias VLAN para un clúster, o si tiene varias subredes en la misma VLAN, los nodos de trabajador en distintas subredes de la misma VLAN o en distintas VLAN no se pueden comunicar automáticamente entre sí. Debe habilitar una función de direccionador virtual (VRF) o una distribución de VLAN para la cuenta de infraestructura de IBM Cloud.

Direccionamiento y reenvío virtual (VRF)
VRF permite que todas las VLAN y subredes de la cuenta de infraestructura se comuniquen entre sí. Además, se necesita una VRF para permitir que los trabajadores y el maestro se comuniquen a través del punto final de servicio en la nube privado. Para habilitar VRF, consulte Habilitación de VRF. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show. Tenga en cuenta que VRF elimina la opción de distribución de VLAN para la cuenta, ya que todas las VLAN pueden comunicarse a menos que configure un dispositivo de pasarela para gestionar el tráfico.
Expansión de VLAN
Si no puede o no desea habilitar VRF, habilite Expansión de VLAN. Para realizar esta acción, necesita Red > Gestionar expansión de VLAN de red permiso de infraestructura, o bien puede solicitar al propietario de la cuenta que lo habilite. Para comprobar si la expansión de VLAN ya está habilitada, utilice el mandato ibmcloud ks vlan spanning get --region <region>. Tenga en cuenta que no puede habilitar el punto final de servicio de nube privada si elige habilitar la expansión de VLAN en lugar de VRF.
¿Cómo afecta la extensión de VRF o VLAN a la segmentación de la red?
Cuando se habilita la VRF o la distribución de VLAN, cualquier sistema que esté conectado a cualquiera de las VLAN privadas de la misma cuenta de IBM Cloud se puede comunicar con los nodos trabajadores. Puede aislar el clúster de otros sistemas de la red privada aplicando políticas de red privada deCalico. IBM Cloud Kubernetes Service también es compatible con todas las ofertas de cortafuegos de infraestructura de IBM Cloud. Puede configurar un cortafuegos, como por ejemplo un dispositivo de direccionamiento virtual, con políticas de red personalizadas para proporcionar seguridad de red dedicada para el clúster estándar y para detectar y solucionar problemas de intrusión en la red.

Utilización de subredes existentes para crear un clúster

Cuando se crea un clúster estándar, se crean subredes automáticamente. Sin embargo, en lugar de utilizar las subredes suministradas automáticamente, puede utilizar subredes portátiles existentes de la cuenta de infraestructura de IBM Cloud o reutilizar las subredes de un clúster suprimido.

Esta opción permite retener las direcciones IP estáticas estables al crear, eliminar o solicitar bloques grandes de direcciones de IP. Si, en su lugar, desea obtener más direcciones IP públicas o privadas portátiles para crear servicios de equilibrador de carga de red (NLB) o de equilibrador de carga de aplicación (ALB) de Ingress, consulte Adición de direcciones IP portátiles.

Todas las subredes solicitadas automáticamente durante la creación del clúster se marcan inmediatamente para suprimirlas tras suprimir un clúster, y no se pueden reutilizar las subredes para crear un nuevo clúster.

Antes de empezar

Para crear un clúster utilizando subredes existentes:

  1. Obtenga el ID de subred y el ID de la VLAN en la que se encuentra la subred.

    ibmcloud ks subnets --provider classic
    

    En este ejemplo, el ID de subred es 1602829 y el ID de la VLAN es 2234945:

    GETting subnet list...
    OK
    ID        Network             Gateway          VLAN ID   Type      Bound Cluster
    1550165   10.xxx.xx.xxx/26    10.xxx.xx.xxx    2234947   private
    1602829   169.xx.xxx.xxx/28   169.xx.xxx.xxx   2234945   public
    
  2. Cree un clúster desde la CLI utilizando el ID de VLAN que ha identificado. Incluya la opción " --no-subnet " para evitar que se creen automáticamente una nueva subred IP pública portátil y una nueva subred IP privada portátil.

    ibmcloud ks cluster create classic --zone dal10 --flavor b3c.4x16 --no-subnet --public-vlan 2234945 --private-vlan 2234947 --workers 3 --name my_cluster
    

    Si no recuerda en qué zona se encuentra la VLAN para la opción --zone, puede comprobar si la VLAN está en una zona determinada ejecutando ibmcloud ks vlan ls --zone <zone>.

  3. Verifique que el clúster se ha creado. Se puede tardar hasta 15 minutos en solicitar las máquinas de nodo trabajador y en configurar y suministrar el clúster en la cuenta.

    ibmcloud ks cluster ls
    

    Cuando el clúster se haya suministrado por completo, el Estado (State) cambia a deployed.

    NAME         ID                                   State      Created          Workers    Zone      Version     Resource Group Name   Provider
    mycluster    aaf97a8843a29941b49a598f516da72101   deployed   20170201162433   3          dal10     1.32      Default             classic
    
  4. Compruebe el estado de los nodos trabajadores.

    ibmcloud ks worker ls --cluster <cluster_name_or_ID>
    

    Antes de continuar con el paso siguiente, los nodos trabajadores deben estar preparados. El Estado (State) cambia a normal y el Estatus (Status) es Ready.

    ID                                                  Public IP        Private IP     Machine Type   State      Status   Zone     Version
    prod-dal10-pa8dfcc5223804439c87489886dbbc9c07-w1    169.xx.xxx.xxx   10.xxx.xx.xxx  free           normal     Ready    dal10      1.32
    
  5. Añada la subred al clúster especificando el ID de subred. Cuando pone una subred a disponibilidad de un clúster, se crea automáticamente un mapa de configuración de Kubernetes que incluye todas las direcciones IP públicas portátiles disponibles que puede utilizar. Si no existe ningún ALB de Ingress en la zona en la que se encuentra la VLAN de la subred, se utiliza automáticamente una dirección IP pública portátil y una dirección IP privada portátil para crear los ALB públicos y privados para dicha zona. Puede utilizar el resto de las direcciones IP públicas y privadas portátiles para crear servicios de NLB para las apps.

    ibmcloud ks cluster subnet add --cluster <cluster_name_or_id> --subnet-id <subnet_ID>
    
  6. Verifique que la subred se ha añadido al clúster.

    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
  7. Importante: para habilitar la comunicación entre nodos trabajadores que están en distintas subredes en la misma VLAN, debe habilitar el direccionamiento entre subredes en la misma VLAN.

Gestión de las direcciones IP portátiles existentes

De forma predeterminada, se pueden utilizar 4 direcciones IP públicas portátiles y 4 direcciones IP privadas portátiles para exponer apps individuales a la red privada o pública mediante la creación de un servicio de equilibrador de carga de red (NLB) o mediante la creación de equilibradores de carga de aplicación (ALB) de Ingress. Para crear un servicio de NLB o ALB, debe tener disponible al menos una dirección IP portátil del tipo correcto. Puede ver las direcciones IP portátiles disponibles o puede liberar una dirección IP portátil utilizada.

Visualización de direcciones IP públicas portátiles disponibles

Para obtener una lista de todas las direcciones IP portátiles del clúster, tanto utilizadas como disponibles, puede ejecutar el mandato siguiente.

kubectl get cm ibm-cloud-provider-vlan-ip-config -n kube-system -o yaml

Para obtener una lista solo de las direcciones IP públicas portátiles disponibles para crear NLB o más ALB públicos, puede seguir los pasos siguientes:

Antes de empezar

Para listar las direcciones IP públicas portátiles disponibles,

  1. Cree un archivo de configuración de servicio Kubernetes denominado myservice.yaml y defina un servicio de tipo LoadBalancer con una dirección IP de NLB ficticia. En el ejemplo siguiente se utiliza la dirección IP 1.1.1.1 como dirección IP de NLB. Sustituya <zone> por la zona en la que desea comprobar las IP disponibles.

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        run: myservice
      name: myservice
      namespace: default
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        run: myservice
      sessionAffinity: None
      type: LoadBalancer
      loadBalancerIP: 1.1.1.1
    
  2. Cree el servicio en el clúster.

    kubectl apply -f myservice.yaml
    
  3. Inspeccione el servicio.

    kubectl describe service myservice
    

    La creación de este servicio falla porque el maestro de Kubernetes no puede encontrar la dirección IP de NLB especificada en el mapa de configuración de Kubernetes. Cuando se ejecuta este mandato, puede ver el mensaje de error y una lista de las direcciones IP públicas disponibles para el clúster.

    Error on cloud load balancer a8bfa26552e8511e7bee4324285f6a4a for service default/myservice with UID 8bfa2655-2e85-11e7-bee4-324285f6a4af: Requested cloud provider IP 1.1.1.1 is not available. The following cloud provider IP addresses are available: <list_of_IP_addresses>
    

Liberación de direcciones IP utilizadas

Puede liberar una dirección IP portátil utilizada suprimiendo el servicio de equilibrador de carga de red (NLB) o inhabilitando el equilibrador de carga de aplicación (ALB) de Ingress que está utilizando la dirección IP portátil.

Antes de empezar

Para suprimir un NLB (equilibrador de cargas de red) o inhabilitar un ALB (equilibrador de cargas de aplicación),

  1. Obtenga una lista de los servicios disponibles en el clúster.
    kubectl get services | grep LoadBalancer
    
  2. Elimine el servicio equilibrador de carga o inhabilite el ALB que utiliza una dirección IP pública o privada.
    • Suprima un NLB:
      kubectl delete service <service_name>
      
    • Inhabilite un ALB:
      ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
      

Adición de direcciones IP portátiles

De forma predeterminada, se pueden utilizar 4 direcciones IP públicas portátiles y 4 direcciones IP privadas portátiles para exponer apps individuales a la red privada o pública mediante la creación de un servicio de equilibrador de carga de red (NLB). Para crear más de 4 NLB públicos o 4 privados, puede obtener más direcciones IP portátiles añadiendo subredes de red al clúster.

Cuando pone una subred a disponibilidad de un clúster, las direcciones IP de esta subred se utilizan para la gestión de redes del clúster. Para evitar conflictos de direcciones IP, asegúrese de utilizar una subred con un solo clúster. No utilice una subred para varios clústeres o para otros fines externos a IBM Cloud Kubernetes Service al mismo tiempo.

Adición de direcciones IP portátiles mediante la solicitud de más subredes

Puede obtener más IP portátiles para los servicios de NLB creando una nueva subred en una cuenta de infraestructura de IBM Cloud y poniéndola a disposición del clúster especificado.

Las direcciones IP públicas portátiles se facturan mensualmente. Si elimina direcciones IP públicas portátiles una vez suministrada la subred, todavía tendrá que pagar el cargo mensual, aunque solo las haya utilizado un breve periodo de tiempo.

Antes de empezar

Para pedir una subred,

  1. Suministre una subred nueva.

    ibmcloud ks cluster subnet create --cluster <cluster_name_or_id> --size <subnet_size> --vlan <VLAN_ID>
    
    Parámetros de una subred
    Parámetro Descripción
    <cluster_name_or_id> Sustituya <cluster_name_or_id> por el nombre o el ID del clúster.
    <subnet_size> Sustituya <subnet_size> por el número de direcciones IP que desea crear en la subred portátil. Los valores aceptados son 8, 16, 32 o 64. Tenga en cuenta que, cuando se añaden direcciones IP portátiles a la subred, se utilizan tres de ellas para establecer la comunicación de red interna del clúster. No puede utilizar estas tres direcciones IP para los equilibradores de carga de aplicaciones (ALB) de Ingress o para crear servicios de equilibrador de carga de red (NLB). Por ejemplo, si solicita ocho direcciones IP públicas portátiles, puede utilizar cinco de ellas para exponer sus apps al público.
    <VLAN_ID> Sustituya <VLAN_ID> por el ID de la VLAN pública o privada en la que quiera asignar las direcciones IP portátiles públicas o privadas. Debe seleccionar una VLAN pública o privada a la que está conectado el nodo trabajador existente. Para revisar las VLAN públicas o privadas a las que están conectados los nodos de trabajador, ejecute ibmcloud ks cluster get --cluster <cluster> --show-resources y busque la sección VLAN de subred en la salida. La subred se suministra en la misma zona en la que se encuentra la VLAN.
  2. Compruebe que la subred se haya creado y añadido correctamente al clúster. El CIDR de subred se muestra en la sección Subnet VLANs.

    ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
    

    En esta salida de ejemplo, se ha añadido una segunda subred a la VLAN pública 2234945.

    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.xx.xxx.xxx/29    true     false
    
  3. Importante: para habilitar la comunicación entre nodos trabajadores que están en distintas subredes en la misma VLAN, debe habilitar el direccionamiento entre subredes en la misma VLAN.

Adición de IP portátiles añadiendo subredes existentes a su clúster

Puede obtener más IP portátiles para servicios de NLB mediante la creación de una subred existente en una cuenta de infraestructura de IBM Cloud disponible para su clúster.

Antes de empezar

Para hacer que una subred esté disponible para el clúster,

  1. Revise los ID de las VLAN públicas o privadas en las que desea asignar las direcciones IP públicas o privadas portátiles. Debe seleccionar una VLAN pública o privada a la que está conectado el nodo trabajador existente.
    ibmcloud ks cluster get --cluster <cluster_name_or_id> --show-resources
    
    En la salida, busque los ID de VLAN en la sección VLAN de subred.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    
  2. Obtenga el ID de la subred que se va a utilizar. Asegúrese de que la subred está en uno de los ID de VLAN que ha encontrado en el paso anterior, y que la subred ya no esté enlazada a otro clúster.
    ibmcloud ks subnets --provider classic
    
    En esta salida de ejemplo, el ID de subred es 1602829, que está en el ID de VLAN 2234945.
    GETting subnet list...
    OK
    ID        Network             Gateway          VLAN ID   Type      Bound Cluster
    1550165   10.xxx.xx.xxx/26    10.xxx.xx.xxx    2234947   private
    1602829   169.xx.xxx.xxx/28   169.xx.xxx.xxx   2234945   public
    
  3. Haga que la subred esté disponible para su clúster.
    ibmcloud ks cluster subnet add --cluster <cluster_name_or_id> --subnet-id <subnet_ID>
    
  4. Compruebe que la subred se haya creado y añadido correctamente al clúster. El CIDR de subred se muestra en la sección Subnet VLANs.
    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
    En esta salida de ejemplo, se ha añadido una segunda subred a la VLAN pública 2234945.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.xx.xxx.xxx/29    true     false
    
  5. Importante: para habilitar la comunicación entre nodos trabajadores que están en distintas subredes en la misma VLAN, debe habilitar el direccionamiento entre subredes en la misma VLAN.

Gestión del direccionamiento de subred

En clústeres clásicos, si tiene varias VLAN para un clúster, varias subredes en la misma VLAN o un clúster multizona, debe habilitar una función de direccionador virtual (VRF) para la cuenta de infraestructura de IBM Cloud para que los nodos trabajadores puedan comunicarse entre sí en la red privada. Para habilitar VRF, consulte Habilitación de VRF. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show. Si no puede o no desea habilitar VRF, habilite Expansión de VLAN. Para realizar esta acción, necesita el permiso de infraestructura Red > Gestionar red VLAN, o puede solicitar al propietario de la cuenta que lo habilite. Para comprobar si la expansión de VLAN ya está habilitada, utilice el ibmcloud ks vlan spanning get --region <region> dominio.

Revise los siguientes casos de ejemplo en los que también es necesaria la distribución de VLAN.

La opción de expansión de VLAN está inhabilitada para los clústeres que se crean en una cuenta habilitada para VRF. Cuando VRF está habilitado, todas las VLAN de la cuenta se pueden comunicar automáticamente entre sí a través de la red privada. Para obtener más información, consulte Planificación de su configuración de red en clúster: comunicación trabajador-a-trabajador.

Habilitación del direccionamiento entre subredes primarias en la misma VLAN

Cuando se crea un clúster, las subredes públicas y privadas primarias se suministran en las VLAN públicas y privadas. La subred pública primaria termina en /28 y proporciona 14 IP públicas para los nodos trabajadores. La subred privada primaria termina en /26 y proporciona IP privadas para un máximo de 62 nodos trabajadores.

Puede superar las 14 IP iniciales públicas y 62 IP privadas iniciales para los nodos trabajadores si tiene un clúster grande o varios clústeres pequeños en la misma ubicación en la misma VLAN. Cuando una subred pública o privada alcanza el límite de nodos trabajadores, se solicita otra subred primaria en la misma VLAN.

Para asegurarse de que los nodos trabajadores de estas subredes primarias de la misma VLAN pueden comunicarse, debe activar la distribución de VLAN. Para obtener instrucciones, consulte Habilitar o inhabilitar la distribución de VLAN.

Para comprobar si la expansión de VLAN ya está habilitada, utilice el mandato ibmcloud ks vlan spanning get --region <region>.

Gestión del direccionamiento de subred para dispositivos de pasarela

Cuando se crea un clúster, se solicita una subred pública portátil y una subred privada portátil en las VLAN a las que está conectado el clúster. Estas subredes proporcionan direcciones IP para los servicios de equilibrador de carga de aplicación (ALB) de Ingress y de equilibrador de carga de red (NLB).

Sin embargo, si tiene un dispositivo direccionador existente, como por ejemplo un dispositivo direccionador virtual (VRA), las subredes portátiles recién añadidas de las VLAN a las que está conectado el clúster no están configuradas en el direccionador. Para utilizar los NLB o los ALB de Ingress, debe asegurarse de que los dispositivos de red pueden direccionar entre distintas subredes de la misma VLAN habilitando una Función de direccionador virtual (VRF) para la cuenta de infraestructura de IBM Cloud. Para habilitar VRF, consulte Habilitación de VRF. Si no puede o no desea habilitar VRF, habilite Expansión de VLAN.

Eliminación de subredes de un clúster

Si ya no necesita subredes, puede eliminarlas del clúster. Después de eliminar la subred, ya no está disponible para el clúster, pero todavía existe en la cuenta de infraestructura de IBM Cloud.

Antes de empezar, revise las siguientes consideraciones:

  • Las subredes solo se pueden desconectar de un clúster si no se utilizan en el clúster ninguna de las direcciones IP derivadas de dicho rango de subred.
  • Las direcciones IP públicas portátiles se facturan mensualmente. Si elimina la subred, todavía debe pagar el cargo mensual para las direcciones IP, incluso si las ha utilizado solo durante un breve periodo de tiempo.
  • Si los nodos trabajadores han utilizado anteriormente la subred que desea desconectar, pero actualmente no hay ningún trabajador conectado a ninguna subred de la VLAN de esta subred, la subred no está visible para el clúster. En su lugar, puede cancelar la subred directamente en la consola de infraestructura clásica de IBM Cloud.
  1. Busque el CIDR de la subred que quiera eliminar.
    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
    En esta salida de ejemplo, el CIDR de la subred que se va a eliminar es 169.1.1.1/29.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.1.1.1/29         true     false
    
  2. Utilizando el CIDR que ha encontrado en el paso anterior, obtenga el ID de la subred que desea eliminar.
    ibmcloud ks subnets --provider classic
    
    En esta salida de ejemplo, la subred con el CIDR de 169.1.1.1/29 tiene el ID 1602829.
    ID        Network             Gateway          VLAN ID   Type      Bound Cluster
    ...
    1602829   169.1.1.1/29        169.1.1.2        2234945   public    df253b6025d64944ab99ed63bb4567b6
    
  3. Desconectar la subred del clúster. La subred sigue estando disponible en su cuenta de infraestructura de IBM Cloud.
    ibmcloud ks cluster subnet detach --cluster <cluster_name_or_ID> --subnet-id <subnet_ID>
    
  4. Verifique que la subred ya no está enlazada con su clúster.
    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
    En esta salida de ejemplo, la subred con el CIDR de 169.1.1.1/29 se elimina.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false