Regiões clássicas com vários data centers

Se você criar um cluster clássico com vários data centers, as réplicas do mestre altamente disponível do Kubernetes serão automaticamente distribuídas entre os data centers. Você tem a opção de distribuir seus nós de trabalho em zonas clássicas (data centers) para proteger seus aplicativos de uma falha de zona. Para determinar se uma região clássica tem vários data centers na CLI, você pode executar ibmcloud ks locations e procurar o valor na coluna Multizone Metro.

* lon05 substitui lon02. Os novos clusters devem usar o lon05, que suporta os mestres de alta disponibilidade que são distribuídos entre zonas.

Regiões clássicas com um data center

Se você criar um cluster clássico em uma região com apenas um data center, o mestre altamente disponível incluirá três réplicas em hosts separados, mas não estará espalhado pelas zonas clássicas.

As regiões clássicas com um data center são gerenciadas a partir do ponto de extremidade regional localizado na região mais próxima que oferece suporte a data centers clássicos, como mon01 a us-east ou sao01 a us-south.

O data center de Milão (mil01) está obsoleto e será encerrado em 31 de outubro de 2025. Migre seus clusters IBM Cloud Kubernetes Service em IBM Cloud atualmente hospedados em mil01 para outro data center IBM Cloud até 31 de outubro de 2025.

Regiões multizona VPC

Os recursos de VPC são provisionados em uma região, que é um grupo separado de zonas em um metrô. As zonas são mapeadas para data centers separados para assegurar que os recursos sejam distribuídos uniformemente entre as zonas em uma arquitetura multizona. Na API e na CLI, as zonas usam o nome da zona regional na API e na linha de comando (us-south-1), mas no console, as zonas são usadas pelo local do data center (Dallas 1). Para saber o código do data center ao qual a zona e o local do VPC correspondem, como us-south-1 e DAL10, consulte Regiões de várias zonas.

† Essas regiões estão disponíveis como regiões multizona para clusters somente na infraestrutura do VPC

Recursos em clusters de zona única

Os recursos do seu cluster permanecem no data center no qual o cluster está implantado, mas as operações de gerenciamento podem ser roteadas por meio de um endpoint regional.

Os recursos de seu cluster, incluindo o principal e os nós do trabalhador, estão na mesma zona na qual o cluster foi implementado. Quando você inicia ações de orquestração de contêiner local, como comandos kubectl, as informações são trocadas entre os nós principal e do trabalhador dentro da mesma zona.

Se você configurar outros recursos do cluster, como armazenamento, rede, computação ou aplicativos executados em pods, os recursos e seus dados permanecerão no data center no qual você implantou o cluster.

Quando você inicia ações de gerenciamento de cluster, como a execução de comandos ibmcloud ks quando você inicia ações de gerenciamento de cluster, como executar comandos, informações básicas sobre o cluster, como nome, ID, usuário, o comando é roteado por meio de um ponto de extremidade regional e do ponto de extremidade global.

Recursos em clusters de várias zonas

Em clusters de várias zonas, os recursos do cluster são distribuídos em vários locais (zonas para VPC e data centers para o Classic) para aumentar a disponibilidade.

Os nós de trabalho são distribuídos em várias zonas VPC ou em data centers Classic na região para oferecer mais disponibilidade ao cluster. As Kubernetes também estão espalhadas por zonas ou data centers clássicos. Quando você inicia ações de orquestração de contêineres locais, como comandos kubectl as informações são trocadas entre os nós mestre e de trabalho por meio do endpoint global.

Outros recursos do cluster, como armazenamento, rede, computação ou aplicativos executados em pods, variam na forma como são implantados nas zonas do cluster. Para obter mais informações, revise estes tópicos:

• Configurar o armazenamento de arquivos e o armazenamento de blocos em clusters ou escolher uma solução de armazenamento persistente multizona.
• Habilitação de acesso público ou privado a um aplicativo usando um serviço de balanceador de carga de rede(NLB)em um cluster.
• Gerenciando o tráfego de rede usando o Ingress.
• Aumentando a disponibilidade de seu app.

Quando você inicia ações de gerenciamento de cluster, como a execução de comandos ibmcloud ks, informações básicas sobre o cluster, como nome, ID, usuário, o comando é roteado pelo endpoint global.