Este documento oferece uma visão geral do gerenciamento de cargas 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.
Este documento é destinado a administradores de TI no grupo de administradores de plataforma responsáveis por gerenciar recursos na organização e desenvolvedores de aplicativos no grupo de operadores de aplicativos responsáveis por desenvolver e manter aplicativos em um universo do GDC.
Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.
Onde implantar cargas de trabalho
Na plataforma do GDC, as operações para implantar cargas de trabalho de máquinas virtuais (VMs) e contêineres são diferentes. O diagrama a seguir ilustra a separação de cargas de trabalho na camada do plano de dados da sua organização.
As cargas de trabalho baseadas em VM operam dentro de uma VM. Por outro lado, as cargas de trabalho de contêiner operam em um cluster do Kubernetes. A separação fundamental entre VMs e clusters do Kubernetes fornece limites de isolamento entre as cargas de trabalho de VM e as cargas de trabalho de contêiner. Para mais informações, consulte Hierarquia de recursos.
As seções a seguir apresentam as diferenças entre cada tipo de carga de trabalho e o ciclo de vida de implantação.
Cargas de trabalho baseadas em VM
É possível criar VMs para hospedar cargas de trabalho baseadas em VM. Você tem muitas opções de configuração para o formato e o tamanho da VM para atender melhor aos requisitos da carga de trabalho baseada em VM. É necessário criar uma VM em um projeto, que pode ter muitas cargas de trabalho de VM. As VMs são um recurso filho de um projeto. Para mais informações, consulte a visão geral das VMs.
Os 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êiner
É possível implantar cargas de trabalho baseadas em contêiner em um pod em um cluster do Kubernetes. Um cluster do Kubernetes consiste nos seguintes tipos de nós:
Nó do plano de controle: executa os serviços de gerenciamento, como programação, etcd e um servidor de API.
Nó de trabalho: executa seus pods e aplicativos de contêiner.
Há dois tipos de configuração para clusters do Kubernetes:
- Clusters compartilhados: um cluster do Kubernetes com escopo da organização que pode abranger vários projetos e não é gerenciado por um único projeto, mas sim anexado a eles.
- Clusters padrão: um cluster do Kubernetes com escopo de projeto que gerencia recursos de cluster em um projeto e não pode abranger vários projetos.
Para mais informações, consulte Configurações de cluster do Kubernetes.
Os clusters do Kubernetes oferecem várias opções hierárquicas de recursos, já que os clusters compartilhados têm escopo da organização e os clusters padrão têm escopo de projeto. Essa é uma diferença fundamental que os clusters do Kubernetes têm em comparação com as VMs. Uma VM é um recurso filho de um projeto e não pode ser configurada para operar fora de um projeto. Para mais informações sobre como projetar a infraestrutura do cluster do Kubernetes, consulte Práticas recomendadas para projetar clusters do Kubernetes.
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 agendar pods em um cluster variam de acordo com os requisitos da carga de trabalho.
Para mais informações sobre clusters do Kubernetes, consulte a visão geral de clusters do Kubernetes. Para mais informações sobre como gerenciar contêineres em um cluster do Kubernetes, consulte Cargas de trabalho de contêiner no GDC.
Práticas recomendadas para projetar clusters do Kubernetes
Esta seção apresenta as práticas recomendadas para projetar clusters do Kubernetes:
- Criar clusters separados por ambiente de desenvolvimento de software
- Criar clusters maiores e em menor número
- Criar pools de nós maiores e em menor número em um cluster
Considere cada prática recomendada para projetar um cluster resiliente para o ciclo de vida da carga de trabalho do contêiner.
Criar clusters separados por ambiente de desenvolvimento de software
Além de projetos separados por ambiente de desenvolvimento de
software,
recomendamos que você projete clusters do Kubernetes separados por ambiente de desenvolvimento de
software. Um ambiente de desenvolvimento de software é uma área no universo do GDC destinada a todas as operações que correspondem a uma fase de ciclo de vida designada. Por exemplo, se você tiver três ambientes de desenvolvimento de software chamados development, staging e production na sua organização, poderá criar um conjunto separado de clusters do Kubernetes para cada ambiente e anexar projetos a cada cluster com base nas suas necessidades.
Recomendamos o uso de clusters padrão em ciclos de vida de pré-produção com escopo de um único projeto, permitindo que todos os processos destrutivos relacionados a testes sejam isolados de projetos de produção, enquanto os clusters compartilhados são ideais para ambientes de produção que podem abranger vários projetos. Um cluster compartilhado que hospeda cargas de trabalho de produção que abrangem vários projetos fornece uma área de implantação compartilhada em que clusters padrão com escopo de um único projeto podem promover as cargas de trabalho diretamente para o ambiente de produção.
Os clusters padrão definidos para cada ambiente de desenvolvimento de software pressupõem que as cargas de trabalho de pré-produção em um ambiente de desenvolvimento de software estejam confinadas a esse cluster. Um cluster do Kubernetes pode ser subdividido em vários pools de nós ou usar taints para isolamento de carga de trabalho.
Ao separar os clusters do Kubernetes por ambiente de desenvolvimento de software, 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 projeto de cluster do Kubernetes para várias cargas de trabalho que abrangem projetos, clusters, ambientes de desenvolvimento de software e classes de máquinas fornecidas por diferentes pools de nós.
Essa arquitetura de exemplo pressupõe que as cargas de trabalho nos ambientes de desenvolvimento, preparação e produção de software possam compartilhar clusters. Cada ambiente tem um cluster padrão separado, que é subdividido em vários pools de nós para diferentes requisitos de classe de máquina. O cluster compartilhado abrange todos os ambientes de desenvolvimento de software, fornecendo uma área de implantação comum para todos os ambientes.
Como alternativa, projetar vários clusters padrão por ambiente de desenvolvimento de software é útil para operações de contêiner, 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 necessidades de configuração de cluster diferentes, como a política de backup, então 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 outro ponto único de falhas em um cluster, então a isola das cargas de trabalho atuais.
É necessário adaptar os ambientes de desenvolvimento de software aos requisitos definidos pelas operações de contêiner.
Criar menos clusters
Para uma utilização eficiente de recursos, recomendamos projetar o menor número de clusters do Kubernetes que atendam aos requisitos de separação de ambientes de desenvolvimento de software e operações de contêiner. Cada cluster adicional incorre em consumo de recursos de sobrecarga adicional, como nós de plano de controle extras necessários. Portanto, um cluster maior com muitas cargas de trabalho utiliza 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, recomendamos adicionar mais nós a um cluster em vez de criar um novo.
Criar menos pools de nós em um cluster
Para uma utilização eficiente de recursos, recomendamos projetar pools de nós menores e maiores em um cluster do Kubernetes.
A configuração de vários pools de nós é útil quando você precisa programar pods que exigem uma classe de máquina diferente de outras. Crie um pool de nós para cada classe de máquina exigida pelas cargas de trabalho e defina a capacidade do nó para escalonamento automático para permitir o uso eficiente de recursos de computação.
A seguir
- Hierarquia de recursos
- Criar um app de contêiner de alta disponibilidade
- Criar um app de VM de alta disponibilidade