Configuración del punto final de servicio en la nube privado

Habilite el punto final de servicio en la nube privado para el clúster.

El punto final de servicio en la nube privado hace que el maestro de Kubernetes sea de acceso privado. Los nodos trabajadores y los usuarios autorizados del clúster se pueden comunicar con el maestro de Kubernetes a través de la red privada. Para determinar si puede habilitar el punto final de servicio en la nube privado, consulte Comunicación entre nodo trabajador y maestro y entre usuario y maestro. Tenga en cuenta que no puede inhabilitar el punto final de servicio de nube privada después de habilitarlo.

¿Ha creado un clúster solo con un punto final de servicio en la nube privado antes de habilitar la cuenta para VRF y puntos finales de servicio? Intente configurar el punto final de servicio en la nube público de modo que pueda utilizar el clúster hasta que se procesen los casos de soporte para actualizar la cuenta.

1. Habilite VRF en la cuenta de la infraestructura de IBM Cloud. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show.

2. Habilite la cuenta de IBM Cloud para que utilice puntos finales de servicio.

3. Habilite el punto final de servicio en la nube privado.

   ibmcloud ks cluster master private-service-endpoint enable --cluster CLUSTER_NAME_OR_ID
   

4. Renueve el servidor de API del nodo maestro de Kubernetes para que utilice el punto final de servicio en la nube privado. Puede seguir la indicación en la CLI o puede ejecutar manualmente el mandato siguiente. El nodo maestro puede tardar unos minutos en renovarse.

   ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
   

5. Cree un mapa de configuración para controlar el número máximo de nodos trabajadores que pueden no estar disponibles a la vez en el clúster. Cuando actualiza los nodos trabajadores, el mapa de configuración ayuda a evitar tiempo de inactividad para las apps a medida que las apps se replanifican de forma ordenada en los nodos trabajadores disponibles.

6. Actualice todos los nodos trabajadores del clúster para que adopten la configuración de punto final de servicio en la nube privado.

   Con el siguiente mandato de actualización, los nodos trabajadores se vuelven a cargar para que adopten la configuración de punto final de servicio. Si no hay ninguna actualización de nodo trabajador disponible, debe volver a cargar manualmente los nodos trabajadores. Si los vuelve a cargar, asegúrese de delimitar, drenar y gestionar el orden para controlar el número máximo de nodos trabajadores que no están disponibles a la vez.

   ibmcloud ks worker update --cluster CLUSTER_NAME_OR_ID --worker WORKER1,WORKER2
   

7. Si el clúster se encuentra en un entorno detrás de un cortafuegos:

   • Permita a los usuarios autorizados del clúster ejecutar mandatos kubectl para acceder al maestro a través del punto final de servicio en la nube privado.
   • Permita el tráfico de red de salida a las IP privadas para los recursos de la infraestructura y para los servicios de IBM Cloud que tiene previsto utilizar.

8. Opcional: para utilizar sólo el punto final de servicio en la nube privado:

   1. Inhabilite el punto final de servicio en la nube público.
   2. Configure el acceso al maestro en el punto final de servicio en la nube privado.

Configuración del punto final de servicio en la nube público

Habilite o inhabilite el punto final de servicio en la nube público para el clúster.

El punto final de servicio en la nube público hace que el maestro de Kubernetes sea de acceso público. Los nodos trabajadores y los usuarios autorizados del clúster se pueden comunicar de forma segura con el maestro de Kubernetes a través de la red pública. Para obtener más información, consulte Comunicación entre nodo trabajador y maestro y entre usuario y maestro.

Cómo pasar de un punto final de servicio en la nube público a un punto final de servicio en la nube privado

Permita que los nodos trabajadores se comuniquen con el nodo maestro a través de la red privada en lugar de hacerlo a través de la red pública habilitando el punto final de servicio en la nube privado.

Todos los clústeres que están conectados a una VLAN pública y a una privada utilizan de forma predeterminada el punto final de servicio en la nube público. Los nodos trabajadores y los usuarios autorizados del clúster se pueden comunicar de forma segura con el maestro de Kubernetes a través de la red pública. Para permitir que los nodos trabajadores se comuniquen con el maestro de Kubernetes a través de la red privada en lugar de hacerlo a través de la red pública, puede habilitar el punto final de en la nube servicio privado. A continuación, puede inhabilitar si lo desea el punto final de servicio en la nube público.

• Si habilita el punto final de servicio en la nube privado y mantiene el punto final de servicio en la nube público también habilitado, los nodos trabajadores siempre se comunican con el maestro a través de la red privada, pero los usuarios se pueden comunicar con el maestro a través de la red pública o privada.
• Si habilita el punto final de servicio en la nube privado pero inhabilita el punto final de servicio en la nube público, los nodos trabajadores y los usuarios deben comunicarse con el maestro a través de la red privada.

No se puede desactivar el punto final del servicio de nube privada una vez que se ha activado.

1. Habilite VRF en la cuenta de la infraestructura de IBM Cloud. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show.

2. Habilite la cuenta de IBM Cloud para que utilice puntos finales de servicio.

3. Habilite el punto final de servicio en la nube privado.

   ibmcloud ks cluster master private-service-endpoint enable --cluster CLUSTER_NAME_OR_ID
   

4. Renueve el servidor de API del maestro de Kubernetes para que utilice el punto final de servicio en la nube privado siguiendo la indicación de la CLI o ejecutando manualmente el mandato siguiente. El nodo maestro puede tardar unos minutos en renovarse.

   ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
   

5. Cree un mapa de configuración para controlar el número máximo de nodos trabajadores que pueden no estar disponibles a la vez en el clúster. Cuando actualiza los nodos trabajadores, el mapa de configuración ayuda a evitar tiempo de inactividad para las apps a medida que las apps se replanifican de forma ordenada en los nodos trabajadores disponibles.

6. Actualice todos los nodos trabajadores del clúster para que adopten la configuración de punto final de servicio en la nube privado.

   Con el siguiente mandato de actualización, los nodos trabajadores se vuelven a cargar para que adopten la configuración de punto final de servicio. Si no hay ninguna actualización de nodo trabajador disponible, debe volver a cargar manualmente los nodos trabajadores. Si los vuelve a cargar, asegúrese de delimitar, drenar y gestionar el orden para controlar el número máximo de nodos trabajadores que no están disponibles a la vez.

   ibmcloud ks worker update --cluster CLUSTER_NAME_OR_ID --worker WORKER1,WORKER2
   

7. Opcional: para utilizar sólo el punto final de servicio en la nube privado:

   1. Inhabilite el punto final de servicio en la nube público.

       ibmcloud ks cluster master public-service-endpoint disable --cluster CLUSTER_NAME_OR_ID
       ```
   2. [Configure el acceso al maestro en el punto final de servicio en la nube privado](/docs/containers?topic=containers-access-private-classic).
   
   
   
   

Cambio de las conexiones de VLAN de nodo trabajador

Cuando cree un clúster, debe elegir si desea conectar los nodos trabajadores a una VLAN privada y pública o solo a una VLAN privada. Los nodos trabajadores forman parte de agrupaciones de nodos trabajadores, que almacenan metadatos de red que incluyen las VLAN que se utilizarán para suministrar nodos trabajadores futuros en la agrupación. Es posible que desee cambiar posteriormente la configuración de la conectividad de VLAN del clúster, en casos como los siguientes.

• Las VLAN de la agrupación de nodos trabajadores de una zona se han quedado sin capacidad y es necesario suministrar una nueva VLAN para que los nodos trabajadores de clúster la utilicen.
• Tiene un clúster con nodos trabajadores que están en VLAN públicas y privadas, pero desea cambiar a un clúster solo privado.
• Tiene un clúster solo privado, pero desea que algunos nodos trabajadores, como por ejemplo una agrupación de nodos trabajadores de nodos de extremo en la VLAN pública, expongan las apps en Internet.

¿Está intentando cambiar el punto final de servicio para la comunicación entre maestro y trabajador? Consulte los temas para configurar puntos finales de servicio públicos y privados.

Al eliminar todos los trabajadores de una VLAN se elimina la dirección IP del ALB de Ingress en la zona de la VLAN.

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

Para cambiar las VLAN que utiliza una agrupación de nodos trabajadores para suministrar nodos trabajadores:

1. Obtenga una lista de los nombres de las agrupaciones de nodos trabajadores del clúster.

   ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID
   

2. Determine las zonas para una de las agrupaciones de nodos trabajadores. En la salida, busque el campo Zones.

   ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
   

3. Para cada zona que haya encontrado en el paso anterior, obtenga una VLAN pública y una privada disponibles que sean compatibles entre sí.

   1. Examine las VLAN públicas y privadas disponibles que se muestran bajo Type en la salida.

       ibmcloud ks vlan ls --zone ZONE
       ```
   2. Compruebe que las VLAN públicas y privadas de la zona son compatibles. Para que sean compatibles, el **Router** debe tener el mismo ID de pod. En esta salida de ejemplo, los ID de pod de **Router** coinciden: `01a` y `01a`. Si un ID de pod era `01a` y el otro `02a`, no puede establecer estos ID de VLAN públicos y privados para la agrupación de trabajadores.
   ```sh {: screen}
       ID        Name   Number   Type      Router         Supports Virtual Workers
       229xxxx          1234     private   bcr01a.dal12   true
       229xxxx          5678     public    fcr01a.dal12   true
       ```
   3. Si necesita solicitar una nueva VLAN pública o privada para la zona, puede solicitarla en la [consola de IBM Cloud](/docs/vlans?topic=vlans-ordering-premium-vlans#ordering-premium-vlans) o puede utilizar el siguiente mandato. Recuerde que las VLAN deben ser compatibles, con ID de pod de **Router** coincidentes como en el paso anterior. Si va a crear un par de nuevas VLAN pública y privada, estas deben ser compatibles entre sí.
   ```sh {: pre}
       ibmcloud sl vlan create -t [public|private] -d <zone> -r <compatible_router>
       ```
   4. Anote los ID de las VLAN compatibles.
   
   

4. Configure una agrupación de nodos trabajadores con los nuevos metadatos de red de VLAN para cada zona. Puede crear una nueva agrupación de nodos trabajadores o puede modificar una existente.

   • Crear un grupo de trabajadores: consulta cómo añadir nodos de trabajo creando un nuevo grupo de trabajadores.

   • Modifique una agrupación de nodos trabajadores existente: Establezca los metadatos de red de la agrupación de nodos trabajadores de modo que utilicen la VLAN para cada zona. Los nodos trabajadores que ya se han creado en la agrupación siguen utilizando las VLAN anteriores, pero los nuevos nodos trabajadores de la agrupación utilizan los nuevos metadatos de VLAN que ha definido.

   • Ejemplo para añadir VLAN tanto pública como privada, como en el caso de que se pase de solo privada a privada y pública:

       ibmcloud ks zone network-set --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --public-vlan PUBLIC_VLAN_ID
       ```
   - Ejemplo para añadir solo una VLAN privada, como en el caso de que se pase de VLAN pública y privada a solo privada cuando se dispone de una [cuenta habilitada para VRF que utiliza puntos finales de servicio](/docs/account?topic=account-vrf-service-endpoint):
   
   ```sh {: pre}
       ibmcloud ks zone network-set --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --private-only
       ```
   

5. Añada nodos trabajadores a la agrupación de nodos trabajadores cambiando el tamaño de la agrupación.

   ibmcloud ks worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --size-per-zone NUMBER_OF_WORKERS_PER_ZONE
   

   Si desea eliminar los nodos trabajadores que utilizan los metadatos de red anteriores, cambie el número de nodos trabajadores por zona para duplicar la cantidad anterior de nodos trabajadores por zona. Más adelante en estos pasos, puede delimitar, drenar y eliminar los nodos trabajadores anteriores.

6. Verifique que los nuevos nodos trabajadores se crean con las direcciones IP pública y la IP privada adecuadas en la salida. Por ejemplo, si cambia la agrupación de nodos trabajadores de una VLAN pública y privada a solo privada, los nuevos nodos trabajadores solo tendrán una IP privada. Si cambia la agrupación de nodos trabajadores de solo privada a VLAN pública y privada, los nuevos nodos trabajadores tienen IP tanto públicas como privadas.

   ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
   

7. Opcional: elimine los nodos trabajadores con los metadatos de red anteriores de la agrupación de nodos trabajadores.

   1. En la salida del paso anterior, anote el ID de los nodos trabajadores que desea eliminar de la agrupación de nodos trabajadores.
   2. Elimine el nodo trabajador.

       ibmcloud ks worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_NAME_OR_ID
       ```
   3. Verifique que se ha eliminado el nodo trabajador.
   ```sh {: pre}
       ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
       ```
   4. Vuelva a equilibrar la agrupación de trabajadores.
   ```sh {: pre}
       ibmcloud ks worker-pool rebalance --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
       ```
   
   
   

8. Opcional: Repite los pasos 2 a 7 para cada grupo de trabajadores de tu clúster. Después de completar estos pasos, todos los nodos trabajadores del clúster estarán configurados con las nuevas VLAN.

9. Los ALB predeterminados en el clúster siguen enlazados a la VLAN antigua porque sus direcciones IP son una subred de dicha VLAN. Puesto que los ALB no se pueden mover entre VLAN, en su lugar puede crear ALB en las nuevas VLAN e inhabilitar los ALB de las VLAN antiguas.

10. Opcional: si ya no necesita las subredes en las VLAN antiguas, puede eliminarlas.