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: Vários clusters costumam ser mais complexos de gerenciar, mas podem 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, pode 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. Da mesma forma que ao usar três zonas em clusters multizona, você pode garantir maior disponibilidade para seu aplicativo configurando três clusters distribuídos entre zonas.
  • Reduza os custos adquirindo máquinas menores para dar conta da 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 que você organize seu cluster utilizando namespaces, cotas de recursos e rótulos quando houver 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 de que você precisa é determinado pelas decisões que você tomou quanto ao número de clusters e às localizações.

Clusters do VPC

Os nós de trabalho são provisionados como instâncias de servidor virtual na infraestrutura VPC. O VPC é o tipo de infraestrutura recomendado para novos clusters. Ele oferece isolamento de rede por padrão e é compatível com os recursos mais recentes do IBM Cloud Kubernetes Service, incluindo hosts dedicados e segurança por padrão.

Clusters Satellite

Os nós de trabalho são provisionados em sua própria infraestrutura, incluindo hardware local ou máquinas virtuais em outros provedores de nuvem, como AWS, Azure e GCP. Utilize o Satellite quando precisar executar clusters gerenciados pel IBM Cloud fora dos data centers do IBM Cloud.

Classic clusters

Os nós de trabalho são provisionados em máquinas virtuais ou físicas em uma infraestrutura clássica d IBM Cloud. Utilize o Classic caso precise de nós de trabalho em bare metal, opções de armazenamento definido por software (SDS) ou conexões com recursos existentes da infraestrutura clássica.

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.

Vai migrar para um novo sistema operacional? Consulte Migração para uma nova versão do site 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 em caso de falha de um nó de trabalho configurando vários nós de trabalho em seu cluster. As falhas nos nós de trabalho podem incluir interrupções de hardware, como problemas de energia, refrigeração ou rede, e problemas no próprio servidor de armazenamento em bloco ( VM ).

• Clusters multizona Classic VPC: Planeje ter pelo menos dois nós de trabalho por zona, totalizando seis nós distribuídos por três zonas. 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 disponíveis no nó de trabalho, talvez seja possível limitar o número de pods implantados em um único 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 é um VM que é executado em 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, talvez seja recomendável consultar seu departamento jurídico para discutir o nível de isolamento da infraestrutura e de conformidade exigido pelo ambiente do seu aplicativo.

  • Compartilhados: Recursos físicos, como CPU e memória, são compartilhados entre todas as máquinas virtuais 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 em termos de desempenho.

  • Máquinas bare metal (físicas): Se você precisar de computação de alto desempenho para cargas de trabalho que exigem muito dos dados ou da memória RAM, considere criar clusters 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 destina-se apenas ao processamento de curto prazo, e os discos principal e auxiliar são apagados quando você atualiza ou recarrega o nó de trabalho. Estão disponíveis profissionais especializados em bare metal para clusters clássicos e para configurações de bare metal do VPC.

    A cobrança pelos nós de trabalho em bare metal varia de acordo com o tipo de infraestrutura. Os servidores bare metal clássicos são cobrados mensalmente. Se você cancelar um servidor bare metal clássico antes do final do mês, será cobrado até o final desse mês. Após solicitar ou cancelar um servidor bare metal clássico, o processo é concluído manualmente na sua conta da infraestrutura do IBM Cloud; portanto, pode levar mais de um dia útil para ser concluído. Os servidores bare metal do VPC são cobrados por hora, sem período mínimo de compromisso.

  • 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 do disco local auxiliar, esses discos brutos não são apagados 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 SDS, como Portworx, use uma máquina SDS. * Se o seu aplicativo for um StatefulSet que exija armazenamento local, você pode usar máquinas SDS e provisionar volumes persistentes locais d Kubernetes. * 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 trabalhos de teste e desenvolvimento com boa relação custo-benefício, você pode optar por 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: Nós maiores podem ser mais econômicos do que nós menores, especialmente para cargas de trabalho projetadas para obter maior eficiência quando processadas em uma máquina de alto desempenho. No entanto, se um nó de trabalho de grande porte ficar fora de serviço, é preciso garantir que o cluster tenha capacidade suficiente para remalhar com segurança todos os pods da carga de trabalho para outros nós de trabalho do cluster. Nós de trabalho menores podem ajudá-lo a escalar com segurança. Saiba mais sobre 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 integrado para armazenamento das informações necessárias ao funcionamento do VM, tais como o sistema de arquivos do SO, o ambiente de execução de contêineres 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 principal possui 25 GB para o sistema de arquivos do SO, e o disco de armazenamento auxiliar possui 100 GB para dados como o ambiente de execução de contêineres e o kubelet. Por uma questão de confiabilidade, os volumes de armazenamento primário e auxiliar são discos locais, em vez de uma 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 vem 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. Este disco opcional está provisionado na sua conta e você pode visualizá-lo no console da 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 são contabilizados no uso da cota da sua conta. Para evitar a remoção automática de pods, 10% do disco de dados do Kubernetes (disco auxiliar no Classic, disco de inicialização primário 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 de alta disponibilidade ”.

  Escolha um modelo ou tipo de máquina com a configuração de armazenamento adequada para atender à 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 Variantes de VPC ou Variantes clássicas.

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 seu aplicativo carrega imagens grandes ou em grande quantidade, já que elas podem ocupar espaço no armazenamento local do 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 integrados e complementos podem criar 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 compatíveis.

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 implantação, como o número de recursos do Kubernetes que você pode implantar e a quantidade de CPU e memória que esses recursos podem consumir. 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 apenas 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 garantir a alta disponibilidade do seu aplicativo, é preciso certificar-se de que há instâncias suficientes para lidar com a carga de trabalho, além de instâncias adicionais para o 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.