Acerca de las cookies de este sitio Nuestros sitios web necesitan algunas cookies para funcionar correctamente (necesarias). Además, se pueden utilizar otras cookies con su consentimiento para analizar el uso del sitio, para mejorar la experiencia del usuario y para publicidad. Para obtener más información, consulte sus opciones de. Al visitar nuestro sitio web, acepta que procesemos la información tal y como se describe en ladeclaración de privacidad de IBM. Para facilitar la navegación, sus preferencias de cookies se compartirán entre los dominios web de IBM que se muestran aquí.
Ubicaciones
IBM Cloud los recursos se organizan en una jerarquía de ubicaciones geográficas. Red Hat OpenShift on IBM Cloud está disponible en un subconjunto de las ubicaciones IBM Cloud, incluidas las regiones multizona (MZR) mundiales y las regiones multizona de un solo campus (SC-MZR).
Esta imagen es una representación artística y no refleja los límites políticos o geográficos reales.
- Montreal (
ca-mon
) Limitaciones MZR -
Webhooks: Solo funcionan los webhooks que acceden a un servicio in-cluster. Los webhooks que acceden directamente a un URL externo, fuera del clúster, están bloqueados.
-
Sistemas operativos: Sólo se pueden crear clústeres en la versión 4.16 y posteriores en Montreal y sólo se pueden utilizar nodos trabajadores RHEL 9 o RHCOS.
-
Portworx Enterprise y Portworx Backup: El método de instalación predeterminado para Portworx Enterprise y Portworx Backup aún no es compatible con los clústeres privados de la región de Montreal. Póngase en contacto con el servicio de asistencia Portworx si necesita instalar Portworx Enterprise o Portworx Backup en un clúster privado en Montreal. Para más información, consulte Portworx Support.
-
La herramienta de diagnóstico y depuración no está disponible actualmente en los clusters de la región de Montreal (
ca-mon
).
Ubicaciones de Red Hat OpenShift on IBM Cloud
La disponibilidad de un clúster se basa en el tipo de clúster que es y en cuántas réplicas de los recursos tiene.
El término zone
en este documento se refiere a cosas diferentes dependiendo del tipo de infraestructura que se utilice. Para VPC, el término zone
se refiere a los nombres de zona dentro de un MZR, como us-south-1
.
Para la infraestructura clásica, el término zone
se refiere a un centro de datos clásico, como dal10
.
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 oc locations
y buscar el valor en la columna Multizone Metro
.
Área geográfica | País | Área metropolitana | Región | Zonas |
---|---|---|---|---|
Asia Pacífico | Australia | Sydney | au-syd | syd01, syd04, syd05 |
Asia Pacífico | Japón | Osaka | jp-osa | osa21, osa22, osa23 |
Asia Pacífico | Japón | Tokio | jp-tok | tok02, tok04, tok05 |
Europa | Alemania | Frankfurt | des-fra | fra02, fra04, fra05 |
Europa | Reino Unido | Londres | uk-lón | lon02, lon04, lon05, lon06 |
América del Norte | Estados Unidos | Dallas | Us-dal | dal10, dal12, dal13 |
América del Norte | Estados Unidos | Washington DC | us-wdc | wdc04, wdc06, wdc07 |
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 Red Hat OpenShift on IBM Cloud 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.
Área geográfica | País | Área metropolitana | Región | Zona | Gestionado desde región |
---|---|---|---|---|---|
Asia Pacífico | India | Chennai | in-che | che01 | AP norte (ap-north , jp-tok ) |
Asia Pacífico | Singapur | Singapur | Sng-mtr | sng01 | AP norte (ap-north , jp-tok ) |
Europa | Francia | París | fr-par | par01 | UE central (eu-central , eu-de ) |
Europa | Italia | Milán | It-mil | mil01 | UE central (eu-central , eu-de ) |
Europa | Países Bajos | Amsterdam | nl-ams | ams03 | UE central (eu-central , eu-de ) |
América del Norte | Canadá | Montreal | ca-mon | mon01 | EE. UU. este (us-east ) |
América del Norte | Canadá | Toronto | ca-tor | tor01 | EE. UU. este (us-east ) |
América del Norte | Estados Unidos | San José | us-sjc | sjc03, sjc04 | EE. UU. sur (us-south ) |
América del Sur | Brasil | Sao Paulo | br-sao | sao01 | EE. UU. sur (us-south ) |
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.
Área geográfica | País | Área metropolitana | Región | Zonas |
---|---|---|---|---|
Asia Pacífico | Australia | Sydney | au-syd | au-syd-1, au-syd-2, au-syd-3 |
Asia Pacífico | Japón | Osaka | jp-osa | jp-osa-1, jp-osa-2, jp-osa-3 |
Asia Pacífico | Japón | Tokio | jp-tok | jp-tok-1, jp-tok-2, jp-tok-3 |
Europa | Alemania | Frankfurt | eu-de | eu-de-1, eu-de-2, eu-de-3 |
Europa | España | † Madrid |
eu-es | eu-es-1, eu-es-2, eu-es-3 |
Europa | Reino Unido | Londres | eu-gb | eu-gb-1, eu-gb-2, eu-gb-3 |
América del Norte | Canadá | † Montreal |
ca-mon | ca-mon-1, ca-mon-2, ca-mon-3 |
América del Norte | Canadá | † Toronto |
ca-tor | ca-tor-1, ca-tor-2, ca-tor-3 |
América del Norte | Estados Unidos | Dallas | us-south | us-south-1, us-south-2, us-south-3 |
América del Norte | Estados Unidos | Washington DC | us-east | us-east-1, us-east-2, us-east-3 |
América del Sur | Brasil | † São Paulo |
br-sao | br-sao-1, br-sao-2, br-sao-3 |
†
Estas regiones solo están disponibles como regiones multizona para clústeres en la infraestructura de VPC.
Regiones Satellite
Para ver una lista de las regiones Managed from
soportadas para clústeres de Satellite, Ubicaciones de Satellite soportadas.
¿Dónde están los recursos?
Dónde se almacenan sus recursos en el clúster depende de la disponibilidad del clúster Un clúster puede estar disponible en una sola zona o en varias zonas (multizona).
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 oc
, 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 oc
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 oc
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 oc
, la información básica sobre el clúster, como el nombre, ID, usuario,
el comando se enruta a través del endpoint global.