Este documento oferece uma vista geral da gestão de cargas de trabalho no Google Distributed Cloud (GDC) air-gapped. São abordados os seguintes tópicos:
Embora alguns dos designs de implementação de cargas de trabalho sejam recomendados, não é obrigatório segui-los exatamente conforme prescrito. Cada universo do GDC tem requisitos e considerações únicos que têm de ser cumpridos caso a caso.
Este documento destina-se a administradores de TI no grupo de administradores da plataforma responsáveis pela gestão de recursos na respetiva organização e a programadores de aplicações no grupo de operadores de aplicações responsáveis pelo desenvolvimento e manutenção de aplicações num universo do GDC.
Para mais informações, consulte o artigo Públicos para a documentação do GDC air-gapped.
Onde implementar cargas de trabalho
Na plataforma do GDC, as operações para implementar cargas de trabalho de máquinas virtuais (VMs) e cargas de trabalho de contentores são diferentes. O diagrama seguinte ilustra a separação de cargas 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 funcionam num cluster do Kubernetes. A separação fundamental entre VMs e 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 o artigo 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 VM, de modo a ajudar a cumprir da melhor forma os requisitos da carga de trabalho baseada em VMs. Tem de criar uma VM num projeto, que pode ter muitas cargas de trabalho de VMs. 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 tem 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 a programação, o etcd e um servidor de 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 do Kubernetes ao nível da organização que pode abranger vários projetos e não é gerido por um único projeto, mas sim anexado aos mesmos.
- Clusters padrão: um cluster do Kubernetes ao nível do 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 de clusters do Kubernetes.
Os clusters do Kubernetes oferecem várias opções de hierarquia de recursos, uma vez que os clusters partilhados estão ao nível da organização e os clusters padrão estão ao nível 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 criar a infraestrutura do cluster do Kubernetes, consulte o artigo Práticas recomendadas para criar clusters do Kubernetes.
Para a programação de pods num cluster do Kubernetes, o GDC adota os conceitos gerais do Kubernetes de programação, preempção e remoção. As práticas recomendadas para programar pods num cluster variam consoante os requisitos da carga de trabalho.
Para mais informações sobre os clusters do Kubernetes, consulte a vista geral dos clusters 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, mas maiores
- Crie menos node pools, mas maiores, num cluster
Tenha em conta cada prática recomendada para criar um design de cluster resiliente para o ciclo de vida da carga de trabalho de contentores.
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 desenvolvimento de software é uma área no universo do 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 que use clusters padrão em ciclos de vida de pré-produção ao nível de um único projeto, o que permite isolar quaisquer processos destrutivos relacionados com os testes 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 ao nível de um ú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 desenvolvimento de software partem do princípio de que as cargas de trabalho de pré-produção num ambiente de desenvolvimento de software estão confinadas a esse cluster. Um cluster do Kubernetes pode ser subdividido em vários node pools ou usar taints para o 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 cargas de trabalho de produção e não 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 node pools.
Esta arquitetura de exemplo pressupõe que as cargas de trabalho nos ambientes de desenvolvimento, teste e produção de software podem partilhar clusters. Cada ambiente tem um cluster padrão separado, que são subdivididos em vários node pools para diferentes requisitos de classe de máquina. O cluster partilhado abrange todos os ambientes de desenvolvimento de software, oferecendo uma área de implementação comum para todos os ambientes.
Em alternativa, criar 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 diferentes versões.
- Tem algumas cargas de trabalho que requerem diferentes necessidades de configuração do cluster, tais como a política de cópia de segurança, pelo que cria vários clusters com diferentes configurações.
- Executa cópias de um cluster em paralelo para facilitar atualizações de versões disruptivas ou uma estratégia de implementação azul-verde.
- Cria uma carga de trabalho experimental que corre o risco de limitar o servidor de API ou outro ponto único de falha num cluster, pelo que a isola das cargas de trabalho existentes.
Tem de adaptar os ambientes de desenvolvimento de software aos requisitos definidos pelas operações de contentores.
Crie menos clusters
Para uma utilização eficiente dos recursos, recomendamos que crie o menor número possível de clusters do Kubernetes que cumpram os seus requisitos de separação de ambientes de desenvolvimento de software e operações de contentores. Cada cluster adicional implica um consumo de recursos de sobrecarga 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 uma sobrecarga de manutenção adicional para monitorizar a capacidade do cluster e planear dependências entre clusters.
Se um cluster se estiver a aproximar 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 node pools, mas maiores, num cluster do Kubernetes.
Configurar vários node pools é útil quando precisa de programar pods que requerem uma classe de máquina diferente da de outros. Crie um node pool para cada classe de máquina que as cargas de trabalho requerem e defina a capacidade de nós para a escala automática para permitir uma utilização eficiente dos recursos de computação.