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 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 do GDC com isolamento físico.
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, que ajudam a atender melhor aos requisitos da 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.
Há dois tipos de configuração para clusters do Kubernetes:
- Clusters compartilhados: um cluster do Kubernetes no escopo da organização que pode abranger vários projetos e não é gerenciado por um único projeto, mas sim vinculado 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 de hierarquia de recursos, já que os clusters compartilhados têm escopo da organização e os clusters padrão têm escopo do projeto. Essa é uma diferença fundamental entre os clusters do Kubernetes e as VMs. Uma VM é um recurso filho de um projeto e não pode ser configurada para operar fora dele. Para mais informações sobre como projetar sua infraestrutura de 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 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 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 usar clusters padrão em ciclos de vida de pré-produção com escopo em um único projeto, permitindo que processos destrutivos relacionados a testes sejam isolados de projetos de produção. Já 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 em vários projetos fornece uma área de implantação compartilhada em que clusters padrão no 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 estão 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 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 fornecidas por diferentes pools de nós.
Esta 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, oferecendo uma área de implantação comum para todos os ambientes.
Outra opção é projetar vários clusters padrão por ambiente de desenvolvimento de software, o que é útil para operações de contêineres, como nos 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.
É preciso adaptar os ambientes de desenvolvimento de software aos requisitos definidos pelas operações de contêiner.
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 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.
A seguir
- Hierarquia de recursos
- Criar um app de contêiner altamente disponível
- Criar um app de VM altamente disponível