Conceba a separação de cargas de trabalho

Este documento oferece uma vista geral da gestão de cargas de trabalho no Google Distributed Cloud (GDC) isolado. Os seguintes tópicos são abordados:

Embora alguns dos designs de implementação de cargas de trabalho sejam recomendados, não é necessário segui-los exatamente como prescrito. Cada universo do GDC tem requisitos e considerações únicos que têm de ser cumpridos caso a caso.

Este documento destina-se aos administradores de TI no grupo de administradores da plataforma que são responsáveis pela gestão de recursos na respetiva organização e aos programadores de aplicações no grupo de operadores de aplicações que são responsáveis pelo desenvolvimento e manutenção de aplicações num universo da GDC.

Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.

Onde implementar cargas de trabalho

Na plataforma GDC, as operações para implementar cargas de trabalho de máquinas virtuais (VM) e cargas de trabalho de contentores são diferentes. O diagrama seguinte ilustra a separação da carga de trabalho na camada do plano de dados da sua organização.

Separação de cargas de trabalho no plano de dados da organização.

As cargas de trabalho baseadas em VMs funcionam numa VM. Por outro lado, as cargas de trabalho de contentores operam num cluster do Kubernetes. A separação fundamental entre as VMs e os clusters do Kubernetes oferece limites de isolamento entre as cargas de trabalho de VMs e as cargas de trabalho de contentores. Para mais informações, consulte Hierarquia de recursos.

As secções seguintes apresentam as diferenças entre cada tipo de carga de trabalho e o respetivo ciclo de vida de implementação.

Cargas de trabalho baseadas em VMs

Pode criar VMs para alojar as suas cargas de trabalho baseadas em VMs. Tem muitas opções de configuração para a forma e o tamanho da sua VM, de modo a ajudar a satisfazer melhor os requisitos da carga de trabalho baseada em VMs. Tem de criar uma VM num projeto, que pode ter muitas cargas de trabalho de VM. As VMs são um recurso secundário de um projeto. Para mais informações, consulte a vista geral das VMs.

Os projetos que contêm apenas cargas de trabalho baseadas em VMs não requerem um cluster do Kubernetes. Por conseguinte, não precisa de aprovisionar clusters do Kubernetes para cargas de trabalho baseadas em VMs.

Cargas de trabalho baseadas em contentores

Pode implementar cargas de trabalho baseadas em contentores num pod num cluster do Kubernetes. Um cluster do Kubernetes consiste nos seguintes tipos de nós:

  • Nó do plano de controlo: executa os serviços de gestão, como o agendamento, o etcd e um servidor da API.

  • Nó de trabalho: executa os seus pods e aplicações de contentores.

Arquitetura do cluster do Kubernetes

Os clusters do Kubernetes podem ser anexados a um ou vários projetos, mas não são um recurso secundário de um projeto. Esta é uma diferença fundamental que os clusters do Kubernetes têm em comparação com as VMs. Uma VM é um recurso secundário de um projeto, enquanto os clusters do Kubernetes funcionam como um recurso secundário de uma organização, o que lhes permite anexar-se a vários projetos.

Para o agendamento de pods num cluster do Kubernetes, o GDC adota os conceitos gerais do Kubernetes de agendamento, preemptividade e despejo. As práticas recomendadas para agendar pods num cluster variam consoante os requisitos da sua carga de trabalho.

Para mais informações sobre clusters do Kubernetes, consulte a vista geral do cluster do Kubernetes. Para mais informações sobre a gestão dos seus contentores num cluster do Kubernetes, consulte Cargas de trabalho de contentores no GDC.

Práticas recomendadas para criar clusters do Kubernetes

Esta secção apresenta as práticas recomendadas para criar clusters do Kubernetes:

Considere cada prática recomendada para criar um design de cluster resiliente para o ciclo de vida da carga de trabalho do contentor.

Crie clusters separados por ambiente de desenvolvimento de software

Além de projetos separados por ambiente de desenvolvimento de software, recomendamos que crie clusters do Kubernetes separados por ambiente de desenvolvimento de software. Um ambiente de programação de software é uma área no seu universo da GDC destinada a todas as operações que correspondem a uma fase do ciclo de vida designada. Por exemplo, se tiver dois ambientes de desenvolvimento de software denominados development e production na sua organização, pode criar um conjunto separado de clusters do Kubernetes para cada ambiente e anexar projetos a cada cluster com base nas suas necessidades. Recomendamos que os clusters do Kubernetes nos ciclos de vida de pré-produção e produção tenham vários projetos anexados.

Os clusters definidos para cada ambiente de programação pressupõem que as cargas de trabalho num ambiente de programação podem partilhar clusters. Em seguida, atribui projetos ao cluster do Kubernetes do ambiente adequado. Um cluster do Kubernetes pode ser subdividido em vários conjuntos de nós ou usar restrições para isolamento de cargas de trabalho.

Ao separar os clusters do Kubernetes por ambiente de desenvolvimento de software, isola o consumo de recursos, as políticas de acesso, os eventos de manutenção e as alterações de configuração ao nível do cluster entre as suas cargas de trabalho de produção e não de produção.

O diagrama seguinte mostra um exemplo de design de cluster do Kubernetes para várias cargas de trabalho que abrangem projetos, clusters, ambientes de desenvolvimento de software e classes de máquinas.

Configuração da GDC

Esta arquitetura de exemplo pressupõe que as cargas de trabalho num ambiente de desenvolvimento de software de produção e desenvolvimento podem partilhar clusters. Cada ambiente tem um conjunto separado de clusters do Kubernetes, que são ainda subdivididos em vários node pools para diferentes requisitos de classe de máquina.

Em alternativa, criar vários clusters do Kubernetes é útil para operações de contentores, como os seguintes cenários:

  • Tem algumas cargas de trabalho fixadas a uma versão específica do Kubernetes, pelo que mantém diferentes clusters em versões diferentes.
  • Tem algumas cargas de trabalho que requerem diferentes necessidades de configuração do cluster, como a política de cópia de segurança, pelo que cria vários clusters com configurações diferentes.
  • Executa cópias de um cluster em paralelo para facilitar as atualizações disruptivas de versões ou uma estratégia de implementação azul/verde.
  • Cria uma carga de trabalho experimental que corre o risco de limitar o servidor da API ou outros pontos únicos de falhas num cluster, pelo que a isola das cargas de trabalho existentes.

O diagrama seguinte mostra um exemplo em que estão configurados vários clusters por ambiente de desenvolvimento de software devido a requisitos como as operações de contentores descritas na secção anterior.

Configuração da GDC

Crie menos clusters

Para uma utilização eficiente dos recursos, recomendamos que crie o menor número de clusters do Kubernetes que satisfaçam os seus requisitos de separação dos ambientes de desenvolvimento de software e das operações de contentores. Cada cluster adicional incorre num consumo de recursos gerais adicional, como nós do plano de controlo adicionais necessários. Por conseguinte, um cluster maior com muitas cargas de trabalho usa os recursos de computação subjacentes de forma mais eficiente do que muitos clusters pequenos.

Quando existem vários clusters com configurações semelhantes, cria-se uma sobrecarga de manutenção adicional para monitorizar a capacidade do cluster e planear dependências entre clusters.

Se um cluster estiver a aproximar-se da capacidade, recomendamos que adicione nós adicionais a um cluster em vez de criar um novo cluster.

Crie menos node pools num cluster

Para uma utilização eficiente dos recursos, recomendamos que crie menos pools de nós maiores num cluster do Kubernetes.

A configuração de vários conjuntos de nós é útil quando precisa de agendar pods que requerem uma classe de máquina diferente das outras. Crie um node pool para cada classe de máquina que as suas cargas de trabalho exigem e defina a capacidade de nós para a criação de uma escala automática para permitir uma utilização eficiente dos recursos de computação.

O que se segue?