Este documento oferece uma visão geral do gerenciamento de carga de trabalho no Google Distributed Cloud (GDC) com isolamento físico. Os seguintes tópicos são abordados:
Embora alguns dos projetos de implantação de carga de trabalho sejam recomendados, não é necessário segui-los exatamente como prescrito. Cada universo do GDC tem requisitos e considerações exclusivos que precisam ser atendidos caso a caso.
Onde implantar cargas de trabalho
Na plataforma GDC, as operações para implantar cargas de trabalho de máquinas virtuais (VMs) e contêineres são diferentes. Esta seção apresenta as diferenças e onde você implanta cada recurso.
Cargas de trabalho baseadas em VM
É possível criar VMs para hospedar suas cargas de trabalho baseadas em VM. Há muitas opções de configuração para o formato e o tamanho da VM, que ajudam a atender melhor aos requisitos de carga de trabalho baseada em VM. É necessário criar uma VM em um projeto, que pode ter muitas VMs e cargas de trabalho de VM. Para mais informações, consulte a visão geral das VMs.
Projetos que contêm apenas cargas de trabalho baseadas em VM não exigem um cluster do Kubernetes. Portanto, não é necessário provisionar clusters do Kubernetes para cargas de trabalho baseadas em VM.
Cargas de trabalho baseadas em contêineres
É possível implantar cargas de trabalho baseadas em contêineres em um pod em um cluster do Kubernetes. Os clusters do Kubernetes podem ser anexados a um ou vários projetos, mas não são um recurso filho de um projeto. Recomendamos anexar clusters apenas a projetos no ambiente de implantação adequado. Por exemplo, um cluster para cargas de trabalho de produção é anexado a um projeto para cargas de trabalho de produção.
Para o agendamento de pods em um cluster do Kubernetes, o GDC adota os conceitos gerais do Kubernetes de agendamento, preempção e remoção. As práticas recomendadas para programar pods em um cluster variam de acordo com os requisitos da sua carga de trabalho.
Para mais informações sobre clusters do Kubernetes, consulte a visão geral dos clusters do Kubernetes. Consulte a visão geral das cargas de trabalho de contêineres para detalhes sobre como gerenciar seus contêineres em um cluster do Kubernetes.
Práticas recomendadas para projetar clusters do Kubernetes
Esta seção apresenta as práticas recomendadas para projetar clusters do Kubernetes:
- Crie clusters separados por ambiente de implantação
- Crie menos clusters, mas maiores
- Criar menos pools de nós maiores em um cluster
Criar clusters separados por ambiente de implantação
Além de projetos separados por ambiente de implantação, recomendamos que você crie clusters separados do Kubernetes por ambiente de implantação. Ao separar o cluster do Kubernetes e o projeto por ambiente, você isola o consumo de recursos, as políticas de acesso, os eventos de manutenção e as mudanças de configuração no nível do cluster entre as cargas de trabalho de produção e não produção.
O diagrama a seguir mostra um exemplo de design de cluster do Kubernetes para várias cargas de trabalho que abrangem projetos, clusters, ambientes de implantação e classes de máquinas.
Essa arquitetura de exemplo pressupõe que as cargas de trabalho em um ambiente de implantação podem compartilhar clusters. Cada ambiente de implantação tem um conjunto separado de clusters do Kubernetes. Em seguida, atribua projetos ao cluster do Kubernetes do ambiente de implantação adequado. Um cluster do Kubernetes pode ser subdividido em vários pools de nós para diferentes requisitos de classe de máquina.
Como alternativa, projetar vários clusters do Kubernetes é útil para operações de contêineres, como os seguintes cenários:
- Você tem algumas cargas de trabalho fixadas em uma versão específica do Kubernetes, então mantém clusters diferentes em versões diferentes.
- Você tem algumas cargas de trabalho que exigem diferentes necessidades de configuração de cluster, como a política de backup, então você cria vários clusters com configurações diferentes.
- Você executa cópias de um cluster em paralelo para facilitar upgrades de versão disruptivos ou uma estratégia de implantação azul-verde.
- Você cria uma carga de trabalho experimental que corre o risco de limitar o servidor de API ou outros pontos únicos de falha em um cluster. Por isso, é necessário isolá-la das cargas de trabalho atuais.
O diagrama a seguir mostra um exemplo em que vários clusters são configurados por ambiente de implantação devido a requisitos como as operações de contêiner descritas na seção anterior.
Criar menos clusters
Para uma utilização eficiente dos recursos, recomendamos projetar o menor número de clusters do Kubernetes que atendam aos seus requisitos de separação de ambientes de implantação e operações de contêiner. Cada cluster extra gera um consumo adicional de recursos de sobrecarga, como nós de plano de controle extras necessários. Portanto, um cluster maior com muitas cargas de trabalho usa os recursos de computação subjacentes com mais eficiência do que muitos clusters pequenos.
Quando há vários clusters com configurações semelhantes, isso cria uma sobrecarga de manutenção adicional para monitorar a capacidade do cluster e planejar dependências entre clusters.
Se um cluster estiver se aproximando da capacidade máxima, recomendamos adicionar mais nós em vez de criar um novo.
Crie menos pools de nós em um cluster
Para uma utilização eficiente dos recursos, recomendamos projetar menos pools de nós maiores em um cluster do Kubernetes.
Configurar vários pools de nós é útil quando você precisa programar pods que exigem uma classe de máquina diferente de outros. Crie um pool de nós para cada classe de máquina exigida pelas cargas de trabalho e defina a capacidade do nó como escalonamento automático para permitir o uso eficiente dos recursos de computação.