Criação de uma estratégia de cluster altamente disponível

Decidir quantos clusters serão criados

Seus usuários são menos propensos a experienciar o tempo de inatividade quando você distribui seus apps em diversos nós do trabalhador, zonas e clusters. Recursos integrados, como balanceamento de carga e isolamento, aumentam a resiliência com relação a potenciais falhas com hosts, redes ou apps.

O número de clusters que você cria depende da carga de trabalho, das políticas e normas da empresa, dos requisitos comerciais, dos contratos de nível de serviço que você tem com seus clientes, dos recursos que deseja gastar e do que deseja fazer com os recursos de computação.

• Vários clusters: Geralmente, o gerenciamento de vários clusters é mais complexo, mas pode ajudá-lo a atingir objetivos importantes, como os seguintes.

  • Obedecer às políticas de segurança que requerem o isolamento das cargas de trabalho.
  • Testar como seu app é executado em uma versão diferente do Kubernetes ou em outro software de cluster, como o Calico.
  • Obtenha maior desempenho para usuários em diferentes áreas geográficas.
  • Simplifique o acesso do usuário para controlar o acesso dentro de um cluster, configurando o acesso no nível da instância do cluster em vez de personalizar e gerenciar várias políticas RBAC no nível do namespace.
  • Mantenha o número de nós de trabalho mais baixo. A largura de banda da rede em máquinas virtuais em escala é de cerca de 1000 Mbps. Se você precisar de centenas de nós de trabalho em um cluster, poderá dividir a configuração em vários clusters com menos nós ou solicitar nós bare metal.
  • Permitir um número maior de integrações de serviços, como mais de 5.000 serviços.
  • Fornecer maior disponibilidade a um aplicativo. De modo semelhante ao uso de 3 zonas em clusters de várias zonas, você pode fornecer mais disponibilidade ao seu aplicativo configurando três clusters entre zonas.
  • Reduza os custos adquirindo máquinas menores para lidar com sua carga de trabalho.

• Um cluster com mais nós de trabalho: Um número menor de clusters pode ajudá-lo a reduzir o esforço operacional e os custos por cluster para recursos fixos. Em vez de criar mais clusters, você pode adicionar pools de trabalho a um cluster para obter diferentes tipos de recursos de computação disponíveis para seus componentes de aplicativos e serviços. Quando você desenvolve o app, os recursos usados por ele estão na mesma zona ou conectados de maneira próxima em uma multizona, para que seja possível fazer suposições sobre latência, largura da banda ou falhas correlacionadas. No entanto, torna-se ainda mais importante organizar o cluster usando namespaces, cotas de recursos e rótulos quando você tem apenas um cluster.

Determinar quantos locais são necessários

Um cluster pode distribuir réplicas entre nós de trabalho em um único local ou em vários locais. Essa escolha pode afetar os tipos de cluster disponíveis na próxima seção.

Distribuir sua carga de trabalho em três zonas garante alta disponibilidade para o seu app no caso de uma zona ficar indisponível. Deve-se ter os nós do trabalhador difundidos uniformemente em todas as três zonas de disponibilidade para atender ao acordo de nível de serviço (SLA) da IBM Cloud para configuração de HA.

Uma falha de zona afeta todos os hosts de cálculo físico e armazenamento NFS. As falhas incluem energia, resfriamento, rede ou indisponibilidades de armazenamento e desastres naturais, como inundações, terremotos e furacões. Para se proteger contra uma falha de zona, é necessário ter clusters em duas zonas diferentes que sejam balanceados por um balanceador de carga externo, criar um cluster em um local com várias zonas, que distribua o mestre entre as zonas, ou considerar a configuração de um segundo cluster em outra zona.

Selecione um tipo de cluster

Os tipos de nós do trabalhador e níveis de isolamento disponíveis para você dependem de sua plataforma de contêiner, tipo de cluster, provedor de infraestrutura a ser usado e local do IBM Cloud Kubernetes Service no qual seu cluster será criado. Você pode escolher entre clusters Classic, VPC ou Satellite. O tipo de cluster necessário é determinado pelas decisões que você tomou em relação ao número de clusters e locais.

Clusters do VPC

Os nós de trabalho podem ser provisionados usando nós de trabalho virtuais na infraestrutura padrão ou em hosts dedicados. Se a velocidade for um fator importante para você, os clusters VPC podem ser a melhor opção.

Clusters Satellite

Os nós de trabalho podem ser provisionados em máquinas virtuais em provedores de nuvem, como AWS, Azure, GCP e outros. Os nós de trabalho também podem ser provisionados usando sua própria infraestrutura local.

Classic clusters

Os nós de trabalho podem ser criados em nós de trabalho virtuais e bare metal. Se discos locais adicionais forem necessários, também será possível escolher um dos tipos de bare metal projetados para soluções de armazenamento definido por software, como o Portworx.

Selecione um sistema operacional para o cluster

Os sistemas operacionais disponíveis dependem do tipo de cluster escolhido.

Ubuntu 24

Para obter mais informações, consulte as notas de versão do site Ubuntu 24.04. Observe que, com Ubuntu 24, o NTP usa timesyncd e os comandos relacionados podem ser atualizados.

Migrando para um novo sistema operacional? Consulte Migrando para uma nova Ubuntu.

Definir uma estratégia de nomeação de cluster

Considere dar aos clusters nomes exclusivos entre grupos de recursos e regiões em sua conta para evitar conflitos de nomenclatura. Não é possível renomear um cluster depois que ele é criado.

Decidir quantos nós de trabalho para cada cluster

O nível de disponibilidade configurado para o seu cluster impacta a sua cobertura nos termos do acordo de nível de serviço de HA da IBM Cloud. Por exemplo, para receber cobertura completa de HA sob os termos do SLA, deve-se configurar um cluster multizona com um total de pelo menos seis nós do trabalhador, sendo dois nós do trabalhador por zona distribuídos uniformemente em três zonas.

O número total de nós do trabalhador em um cluster determina a capacidade de cálculo disponível para seus apps no cluster. Você pode proteger sua configuração durante uma falha no nó de trabalho configurando vários nós de trabalho em seu cluster. As falhas no nó do trabalhador podem incluir interrupções de hardware, como energia, resfriamento ou rede, e problemas na própria VM.

• Clusters de várias zonas Clássico VPC: Planeje ter pelo menos dois nós de trabalho por zona, portanto, seis nós em três zonas no total. Além disso, planeje a capacidade total de seu cluster para pelo menos 150% da capacidade total necessária da carga de trabalho, de modo que, se uma zona ficar inativa, você tenha recursos disponíveis para manter a carga de trabalho.

• Clusters de zona única Planeje ter pelo menos três nós de trabalho em seu cluster. Além disso, você deseja que um nó extra tenha capacidade de CPU e de memória disponível no cluster. Se seus aplicativos exigirem menos recursos do que os recursos disponíveis no nó de trabalho, você poderá limitar o número de pods implantados em um nó de trabalho.

Lembre-se:

• Você pode experimentar o autoscaler de cluster para ter certeza de que sempre terá nós de trabalho suficientes para cobrir sua carga de trabalho.
• O Kubernetes limita o número máximo de nós do trabalhador que é possível ter em um cluster. Revise as cotas do nó trabalhador e do pod para obter mais informações.

Selecionar tipos de nós de trabalho

Um nó de trabalho é uma VM executada em um hardware físico. Um tipo de nó do trabalhador descreve os recursos de cálculo, como CPU, memória e capacidade de disco, que serão obtidos após o provisionamento de seu nó do trabalhador. Os nós do trabalhador do mesmo tipo são agrupados em conjuntos de nós do trabalhador.

Ao escolher um tipo de cluster, você já pensou em como a localização do sabor do nó de trabalho e o tipo de máquina afetam sua decisão. Ao escolher entre os tipos de nós de trabalho, considere o seguinte.

• Tenancy: Dependendo do nível de isolamento de hardware de que você precisa, os nós de trabalho virtuais podem ser configurados como compartilhados por vários IBM clientes (multilocação) ou dedicados somente a você (locação única). As máquinas bare metal são sempre configuradas como dedicadas. Ao decidir entre nós compartilhados e dedicados, convém consultar seu departamento jurídico para discutir o nível de isolamento da infraestrutura e a conformidade exigida pelo seu ambiente de aplicativos.

  • Compartilhados: Os recursos físicos, como CPU e memória, são compartilhados entre todas as máquinas virtuais que são implantadas no mesmo hardware físico. Para assegurar que cada máquina virtual possa ser executada independentemente, um monitor de máquina virtual, também referido como hypervisor, segmenta os recursos físicos em entidades isoladas e aloca como recursos dedicados para uma máquina virtual (isolamento de hypervisor). Os nós compartilhados são geralmente menos dispendiosos que os nós dedicados porque os custos para o hardware subjacente são compartilhados entre diversos clientes.
  • Dedicado: Todos os recursos físicos são dedicados somente a você. É possível implementar diversos nós do trabalhador como máquinas virtuais no mesmo host físico. Semelhante à configuração de diversos locatários, o hypervisor assegura que cada nó do trabalhador obtenha seu compartilhamento dos recursos físicos disponíveis.

• Tipo de máquina: Você tem uma combinação de tipos de máquina que pode escolher.

  • Máquinas virtuais: Para obter maior flexibilidade, tempos de provisionamento mais rápidos, recursos de escalabilidade mais automáticos e um preço mais econômico, use VMs. É possível usar VMs para os casos de uso geral, como ambientes de teste e desenvolvimento, ambientes de preparação e produção, microsserviços e apps de negócios. No entanto, há uma compensação no desempenho.

  • Máquinas bare metal (físicas): Se você precisar de computação de alto desempenho para cargas de trabalho com uso intensivo de dados ou RAM, considere criar clusters clássicos com nós de trabalho bare metal. Como você tem controle total sobre o isolamento e o consumo de recursos para suas cargas de trabalho, é possível usar máquinas bare metal para atingir a conformidade de HIPAA e PCI para o seu ambiente. O bare metal dá acesso direto aos recursos físicos na máquina, como a memória ou CPU. Essa configuração elimina o hypervisor da máquina virtual que aloca recursos físicos para máquinas virtuais executadas no host. Em vez disso, todos os recursos em uma máquina bare metal são dedicados exclusivamente ao trabalhador, portanto, não é necessário se preocupar "vizinhos indesejados" que possam compartilhar recursos ou prejudicar o desempenho. Os tipos físicos têm mais armazenamento local do que virtual e alguns têm RAID para aumentar a disponibilidade de dados. O armazenamento local no nó de trabalho é apenas para processamento de curto prazo, e os discos primário e auxiliar são limpos quando você atualiza ou recarrega o nó de trabalho. As máquinas físicas estão disponíveis somente para clusters clássicos e não são suportadas em clusters VPC.

    Os servidores bare metal são faturados mensalmente. Se você cancelar um servidor bare metal antes do final do mês, será cobrado até o final do mês. Depois de pedir ou cancelar um servidor bare metal, o processo é concluído manualmente em sua conta de infraestrutura da IBM Cloud. Portanto, isso pode levar mais de um dia útil para ser concluído.

  • Máquinas SDS: os sabores de armazenamento definido por software (SDS) têm discos brutos adicionais para armazenamento local físico. Ao contrário do disco local primário e auxiliar, esses discos brutos não são limpos durante uma atualização ou recarga do nó de trabalho. Como os dados são colocados com o nó de cálculo, as máquinas SDS são adequadas para cargas de trabalho de alto desempenho. O tipo de armazenamento definido por software está disponível apenas para clusters clássicos e não é suportado em clusters VPC.

    Como você tem controle total sobre o isolamento e o consumo de recursos para suas cargas de trabalho, é possível usar as máquinas SDS para atingir a conformidade de HIPAA e PCI para o seu ambiente.

    Você normalmente usa máquinas SDS nos casos a seguir:

    • Se você usar um complemento de SDS, como o Portworx use uma máquina SDS.
    • Se seu aplicativo for um StatefulSet que exija armazenamento local, você poderá usar máquinas SDS e provisionar Kubernetes volumes persistentes locais.
    • Se você tiver aplicativos customizados que requerem armazenamento local bruto adicional.

• Custo: em geral, suas cargas de trabalho intensivas são mais adequadas para serem executadas em máquinas físicas bare metal, enquanto que, para testes econômicos e trabalho de desenvolvimento, você pode escolher máquinas virtuais em hardware compartilhado ou dedicado.

• Localização: Decida em quais locais você deseja ter um cluster. O local onde você quer que ele esteja também pode informar quantos clusters ou o tipo de clusters você precisa. Por exemplo, se você sabe que precisa que o local seja em Montreal, isso ajuda a restringir suas opções. Confira os locais disponíveis.

• Tamanho: Os nós maiores podem ser mais econômicos do que os nós menores, especialmente para cargas de trabalho projetadas para ganhar eficiência ao serem processadas em uma máquina de alto desempenho. No entanto, se um nó de trabalho grande ficar inativo, você precisará ter certeza de que o cluster tem capacidade suficiente para reprogramar com segurança todos os pods de carga de trabalho para outros nós de trabalho no cluster. Nós de trabalho menores podem ajudá-lo a escalar com segurança. Saiba mais sobre a capacidade.

• GPUs: você pode usar uma máquina com GPU para acelerar o tempo de processamento necessário para cargas de trabalho com uso intenso de computação, como IA, aprendizado de máquina, inferência e muito mais.

• Armazenamento: Cada VM vem com um disco conectado para armazenar as informações de que a VM precisa para ser executada, como o sistema de arquivos do sistema operacional, o tempo de execução do contêiner e o kubelet. O armazenamento local no nó do trabalhador é apenas para processamento de curto prazo, e os discos de armazenamento são limpos quando você exclui, recarrega, substitui ou atualiza o nó do trabalhador. Além disso, a infraestrutura clássica e VPC diferem na configuração do disco.

  • VMs clássicas: as VMs clássicas possuem dois discos conectados. O disco de armazenamento primário tem 25 GB para o sistema de arquivos do sistema operacional, e o disco de armazenamento auxiliar tem 100 GB para dados como o tempo de execução do contêiner e o kubelet. Para fins de confiabilidade, os volumes de armazenamento primário e auxiliar são discos locais em vez de rede de área de armazenamento (SAN). Os benefícios de confiabilidade incluem maior rendimento ao serializar bytes para o disco local e a degradação do sistema de arquivos reduzido devido a falhas de rede. O disco auxiliar é criptografado por padrão.
  • VMs de cálculo de VPC: as VMs de VPC possuem um disco primário que é um volume de armazenamento de blocos que é conectado pela rede. A camada de armazenamento não é separada das outras camadas de rede e o tráfego de rede e de armazenamento é roteado na mesma rede. O disco de armazenamento primário é usado para armazenar dados como o sistema de arquivos do S.O., o tempo de execução do contêiner e o kubelet e é criptografado por padrão. Para clusters VPC, você também pode provisionar um disco secundário nos nós de trabalho. Esse disco opcional é provisionado em sua conta e pode ser visto no console VPC. As cobranças por esses discos são separadas do custo de cada trabalhador e aparecem como um item de linha diferente em sua fatura. Esses volumes secundários também contam para o uso da cota da sua conta. Para evitar despejos de pods padrão, 10% do disco de dados Kubernetes (disco auxiliar no clássico, disco de inicialização principal no VPC) é reservado para componentes do sistema.

  Em um app stateful, os dados têm um papel importante para manter seu app funcionando. Certifique-se de que seus dados estejam altamente disponíveis para que seja possível recuperar-se de uma possível falha. No IBM Cloud Kubernetes Service, é possível escolher entre várias opções para persistir seus dados. Por exemplo, é possível provisionar o armazenamento NFS usando volumes persistentes nativos do Kubernetes ou armazenar seus dados usando um serviço de banco de dados do IBM Cloud. Para obter mais informações, consulte Planejamento de dados altamente disponíveis.

  Escolha uma variante, ou tipo de máquina, com a configuração de armazenamento correta para suportar sua carga de trabalho. Alguns tipos têm uma combinação dos discos e configurações de armazenamento a seguir. Por exemplo, alguns tipos podem ter um disco primário SATA com um disco secundário SSD bruto.

Para obter uma lista das variantes disponíveis, consulte VPC Gen 2 flavors ou Classic flavors.

Determinar a capacidade do nó de trabalho para os recursos

Para obter o máximo do desempenho do nó de trabalho, considere o seguinte ao configurar seus recursos:

• Considere o que seu aplicativo está fazendo: comece alinhando o tamanho do aplicativo com a capacidade de uma das variantes de nó de trabalho disponíveis. Considere também se o seu aplicativo extrai imagens grandes ou muitas imagens, pois elas podem ocupar o armazenamento local no nó de trabalho.

• Acompanhe a potência de seu núcleo: cada máquina possui um determinado número de núcleos. Configure um limite para o número de pods por núcleo, como 10, de acordo com a carga de trabalho do seu app.

• Evite a sobrecarga do nó: Mantenha seu nó de trabalho com cerca de 75% da capacidade para deixar espaço para outros pods que possam precisar ser agendados. Se seus apps precisam de mais recursos do que há disponíveis em seu nó do trabalhador, use um tipo diferente de nó do trabalhador que possa atender a esses requisitos. Configure um limite para o número de pods por nó, como 40, de acordo com a carga de trabalho de seu app.

• Escolha de serviços: Quantas integrações de serviço você decidiu incluir quando estava pensando em quantos clusters criar? Esses serviços e complementos integrados podem ativar pods que consomem e afetam os recursos do cluster.

• Réplicas de seu app: para determinar o número desejado de nós do trabalhador, também é possível considerar quantas réplicas de seu app você deseja executar. Por exemplo, se souber que sua carga de trabalho requer 32 núcleos da CPU e planejar executar 16 réplicas de seu app, cada pod de réplica precisará de 2 núcleos da CPU. Se desejar executar apenas um pod de app por nó do trabalhador, será possível solicitar um número apropriado de nós do trabalhador para seu tipo de cluster, para que seja possível suportar essa configuração.

• Deixe espaço para os requisitos de tempo de execução: Os nós de trabalho devem reservar determinadas quantidades de recursos de CPU e memória para executar os componentes necessários, como o sistema operacional ou o tempo de execução do contêiner.

  A capacidade reservada e as instâncias reservadas não são suportadas.

Escolha quantos namespaces serão criados no cluster

Configure diversos namespaces quando tiver diversas equipes e projetos que compartilham o cluster. Os namespaces são uma maneira de dividir os recursos do cluster usando cotas de recursos e limites padrão. Ao fazer novos namespaces, certifique-se de configurar as políticas RBAC adequadas para controlar o acesso. Para obter mais informações, consulte Compartilhar um cluster com namespaces na documentação do Kubernetes.

Se tiver um cluster pequeno, duas dúzias de usuários e recursos semelhantes (como versões diferentes do mesmo software), provavelmente não serão necessários diversos namespaces. Em vez disso, é possível usar rótulos.

Analise as informações de segurança sobre essa decisão em Isolamento e segurança de contêineres.

Estabelecer solicitações e limites de recursos para os namespaces

Para assegurar que toda equipe tenha os recursos necessários para implementar serviços e executar apps no cluster, deve-se configurar cotas de recursos para cada namespace. As cotas de recursos determinam as restrições de implementação, como o número de recursos Kubernetes que você pode implementar e a quantidade de CPU e memória que pode ser consumida por esses recursos. Depois de configurar uma cota, os usuários devem incluir solicitações de recurso e limites em suas implementações.

Ao criar uma implantação, limite-a também para que o pod do seu aplicativo seja implantado somente em máquinas com a melhor combinação de recursos. Por exemplo, é possível que você deseje limitar um aplicativo de banco de dados a uma máquina bare metal com uma quantidade significativa de armazenamento em disco local, como o md1c.28x512.4x4tb.

Torne seus aplicativos altamente disponíveis também

Os contêineres e os pods são, pelo design, de curta duração e podem falhar inesperadamente. Por exemplo, um contêiner ou pod pode travar se um erro ocorre em seu app. Para tornar seu aplicativo altamente disponível, você deve garantir que tenha instâncias suficientes para lidar com a carga de trabalho e instâncias adicionais no caso de uma falha. Você pode garantir que haja instâncias suficientes configurando o escalonamento automático.

Próximas etapas

Para continuar o processo de planejamento, escolha entre Rede de cluster VPC e Rede de cluster clássica. Se você estiver pronto para começar a criar um cluster, comece Preparando sua conta para criar clusters.