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 da 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.
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.
Existem dois tipos de configuração para clusters do Kubernetes:
- Clusters partilhados: um cluster Kubernetes ao nível da organização que pode abranger vários projetos e não é gerido por um único projeto, mas sim anexado a eles.
- Clusters padrão: um cluster Kubernetes com âmbito de projeto que gere os recursos do cluster num projeto e não pode abranger vários projetos.
Para mais informações, consulte o artigo Configurações do cluster do Kubernetes.
Os clusters do Kubernetes oferecem várias opções hierárquicas de recursos, uma vez que os clusters partilhados têm âmbito da organização e os clusters padrão têm âmbito do 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 e não pode ser configurada para funcionar fora de um projeto. Para mais informações sobre como estruturar a infraestrutura do cluster do Kubernetes, consulte o artigo Melhores práticas para estruturar clusters do Kubernetes.
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 o artigo 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:
- Crie clusters separados por ambiente de desenvolvimento de software
- Crie menos clusters maiores
- Crie menos node pools, mas maiores, num cluster
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 três ambientes de desenvolvimento de software denominados development, staging 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 a utilização de clusters padrão em ciclos de vida de pré-produção com âmbito num único projeto, o que permite que quaisquer processos destrutivos relacionados com os testes sejam isolados dos projetos de produção. Por outro lado, os clusters partilhados são ideais para ambientes de produção que podem abranger vários projetos. Um cluster partilhado que aloja cargas de trabalho de produção que abrangem vários projetos oferece uma área de implementação partilhada onde os clusters padrão com âmbito num único projeto podem promover as respetivas cargas de trabalho diretamente para o ambiente de produção.
Os clusters padrão definidos para cada ambiente de programação de software pressupõem que as cargas de trabalho de pré-produção num ambiente de programação de software estão confinadas a esse cluster. Um cluster do Kubernetes pode ser ainda mais subdividido em vários node pools 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 fornecidas por diferentes conjuntos de nós.
Esta arquitetura de exemplo pressupõe que as cargas de trabalho nos ambientes de desenvolvimento de software de desenvolvimento, teste e produção podem partilhar clusters. Cada ambiente tem um cluster padrão separado, que são subdivididos em vários conjuntos de nós para diferentes requisitos de classe de máquinas. O cluster partilhado abrange todos os ambientes de programação de software, oferecendo uma área de implementação comum para todos os ambientes.
Em alternativa, a conceção de vários clusters padrão por ambiente de desenvolvimento de software é ú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.
Tem de adaptar os seus ambientes de programação de software aos requisitos definidos pelas operações do seu contentor.
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?
- Hierarquia de recursos
- Crie uma app de contentor de elevada disponibilidade
- Crie uma app de VM de alta disponibilidade