Regiones clásicas con múltiples centros de datos

Si crea un clúster clásico con varios centros de datos, las réplicas del maestro Kubernetes de alta disponibilidad se reparten automáticamente entre los centros de datos. Tiene la opción de repartir sus nodos de trabajadores entre zonas clásicas (centros de datos) para proteger sus aplicaciones de un fallo de zona. Para determinar si una región clásica tiene varios centros de datos desde la CLI, puede ejecutar ibmcloud ks locations y buscar el valor en la columna Multizone Metro.

* lon05 sustituye a lon02. Los nuevos clústeres deben utilizar lon05, que da soporte a los maestros de alta disponibilidad que se dispersan en zonas.

Regiones clásicas con un centro de datos

Si crea un clúster clásico en una región con un único centro de datos, el maestro de alta disponibilidad incluye tres réplicas en hosts independientes, pero no está repartido por las zonas clásicas.

Las regiones clásicas con un centro de datos se gestionan desde el punto final regional situado en la región más cercana que admita centros de datos clásicos, como mon01 a us-east o sao01 a us-south.

El centro de datos de Milán (mil01) está en desuso y cerrará el 31 de octubre de 2025. Migrar su IBM Cloud Kubernetes Service en clústeres de IBM Cloud alojados actualmente en mil01 a otro centro de datos de IBM Cloud antes del 31 de octubre de 2025.

Regiones multizona de VPC

Los recursos de la VPC se aprovisionan en una región, que es un grupo separado de zonas dentro de un metro. Las zonas se correlacionan con centros de datos separados para garantizar que los recursos se distribuyen uniformemente entre zonas en una arquitectura multizona. En la API y la CLI, las zonas utilizan el nombre de la zona regional en la API y la línea de comandos (us-south-1), pero en la consola, las zonas utilizan por la ubicación del centro de datos (Dallas 1). Para conocer el código del centro de datos al que corresponde la zona y la ubicación de la VPC, como us-south-1 y DAL10, consulte Regiones multizona.

† Estas regiones solo están disponibles como regiones multizona para clústeres en la infraestructura de VPC.

Recursos en agrupaciones de una sola zona

Los recursos de su clúster permanecen en el centro de datos en el que se despliega el clúster, pero las operaciones de gestión pueden enrutarse a través de un punto final regional.

Los recursos del clúster, incluidos los nodos maestro y trabajadores, están en la misma ubicación en la que se ha desplegado el clúster. Al iniciar acciones de orquestación del contenedor local, como por ejemplo mandatos kubectl, la información se intercambia entre los nodos maestro y trabajador dentro de la misma zona.

Si configura otros recursos de clúster, como almacenamiento, redes, computación o aplicaciones que se ejecutan en pods, los recursos y sus datos permanecen en el centro de datos en el que desplegó el clúster.

Cuando se inician acciones de gestión del clúster, como la ejecución de comandos ibmcloud ks comandos, la información básica sobre el clúster, como nombre, ID, usuario, el comando se enruta a través de un endpoint regional y el endpoint global.

Recursos en clusters multizona

En los clústeres multizona, los recursos del clúster se reparten entre varias ubicaciones (zonas para VPC y centros de datos para Classic) para una mayor disponibilidad.

Los nodos de trabajo se reparten entre varias zonas de VPC o centros de datos clásicos de la región para ofrecer más disponibilidad a su clúster. Las Kubernetes también están repartidas por zonas o centros de datos clásicos. Cuando se inician acciones de orquestación de contenedores locales, como comandos kubectl la información se intercambia entre los nodos maestro y trabajador a través del endpoint global.

Otros recursos del clúster, como el almacenamiento, las redes, la informática o las aplicaciones que se ejecutan en pods, varían en la forma en que se despliegan en las zonas de su clúster. Para obtener más información, revise estos temas:

• Configurar almacenamiento de archivos y almacenamiento de bloques en clústeres, o elegir una solución de almacenamiento persistente multizona.
• Permitir el acceso público o privado a una aplicación mediante el uso de un servicio de equilibrador de carga de red(NLB)en un clúster.
• Gestión del tráfico de red mediante Ingress.
• Cómo aumentar la disponibilidad de la app.

Cuando se inician acciones de gestión del clúster, como la ejecución de comandos ibmcloud ks, la información básica sobre el clúster, como el nombre, ID, usuario, el comando se enruta a través del endpoint global.