Este documento fornece 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.
Este documento é destinado a administradores de TI do grupo de administradores de plataforma responsáveis por gerenciar recursos na organização e a desenvolvedores de aplicativos do 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 isolada do GDC.
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. O diagrama a seguir ilustra a separação de cargas de trabalho na camada de plano de dados da sua organização.
As cargas de trabalho baseadas em VM operam em uma VM. Por outro lado, as cargas de trabalho de contêineres operam em um cluster do Kubernetes. A separação fundamental entre VMs e clusters do Kubernetes fornece limites de isolamento entre suas cargas de trabalho de VM e 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 delas.
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, o que ajuda a atender melhor aos requisitos de carga de trabalho baseada em VM. É preciso 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.
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. 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.
Os clusters do Kubernetes podem ser anexados a um ou vários projetos, mas não são um recurso filho de um projeto. Essa é uma diferença fundamental entre os clusters do Kubernetes e as VMs. Uma VM é um recurso filho de um projeto, enquanto os clusters do Kubernetes operam como um recurso filho de uma organização, permitindo que eles sejam anexados a vários projetos.
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 de clusters do Kubernetes. Para mais informações sobre como gerenciar contêineres em um cluster do Kubernetes, consulte Cargas de trabalho de contêineres no GDC.
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 desenvolvimento de software
- Crie menos clusters, mas maiores
- Criar menos pools de nós maiores em um cluster
Considere cada prática recomendada para projetar um cluster resiliente para o ciclo de vida da carga de trabalho de contêineres.
Crie clusters separados por ambiente de desenvolvimento de software
Além de projetos separados por ambiente de desenvolvimento de software, recomendamos que você crie 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 designada do ciclo de vida. Por exemplo, se você tiver dois ambientes de desenvolvimento de software chamados development 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 que os clusters do Kubernetes em ciclos de vida de pré-produção e produção tenham vários projetos anexados a eles.
Os clusters definidos para cada ambiente de desenvolvimento de software pressupõem que as cargas de trabalho em um ambiente de desenvolvimento de software podem compartilhar clusters. Em seguida, atribua projetos ao cluster do Kubernetes do ambiente adequado. 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 suas 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 desenvolvimento de software e classes de máquinas.
Essa arquitetura de exemplo pressupõe que as cargas de trabalho em um ambiente de desenvolvimento de software de produção e desenvolvimento podem compartilhar clusters. Cada ambiente tem um conjunto separado de clusters do Kubernetes, que são subdivididos 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. Por isso, 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 desenvolvimento de software 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 desenvolvimento de software e operações de contêineres. Cada cluster extra gera um consumo adicional de recursos de sobrecarga, como nós extras do plano de controle necessários. Portanto, um cluster maior com muitas cargas de trabalho usa os recursos de computação subjacentes de maneira mais eficiente 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 chegando à 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 outras. 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.
A seguir
- Hierarquia de recursos
- Criar um app contêiner de alta disponibilidade
- Criar um app de VM altamente disponível