O Google Distributed Cloud suporta vários modelos de implementação para satisfazer diferentes necessidades de disponibilidade, isolamento e pegada de recursos. Esta página define os conceitos que todos os modelos de implementação partilham e descreve cada modelo de implementação.
Esta página destina-se a administradores, arquitetos e operadores que definem soluções de TI e arquitetura de sistemas de acordo com a estratégia da empresa em coordenação com as principais partes interessadas. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud
Clusters de utilizadores
Um cluster de utilizadores é um cluster do Kubernetes que executa as suas cargas de trabalho em contentores. É composto por nós do plano de controlo e nós de trabalho. O Google Distributed Cloud suporta um ou mais clusters de utilizadores. Os clusters de utilizadores têm de conter um ou mais nós de trabalho que executam cargas de trabalho do utilizador.
Clusters de administração
Um cluster de administrador é um cluster do Kubernetes que gere um ou mais clusters de utilizadores. O cluster de administrador pode realizar as seguintes tarefas:
- Crie clusters de utilizadores
- Atualize clusters de utilizadores
- Atualize clusters de utilizadores
- Elimine clusters de utilizadores
Para criar um cluster de utilizadores, o cluster de administrador configura os componentes do Google Distributed Cloud no plano de controlo e nos nós de trabalho do cluster de utilizadores. O seu cluster de administrador só tem nós do plano de controlo porque os componentes do Google Distributed Cloud são executados nos nós do plano de controlo.
O seu cluster de administração contém os seguintes tipos de dados confidenciais:
- Credenciais SSH: usadas para ativar a instalação remota
- Google Cloud Chaves de contas de serviço: usadas para aceder a funcionalidades como o Artifact Registry
Para proteger os dados confidenciais, restrinja o acesso ao cluster de administrador.
Alta disponibilidade
Pode executar clusters de administrador ou de utilizador no modo de alta disponibilidade (HA). Este modo requer três ou mais (número ímpar) nós do plano de controlo em execução no seu cluster. Se executar um cluster no modo não HA, o cluster requer apenas um nó do plano de controlo.
Para evitar ter um único ponto de falha, use o modo de HA para implementações de produção. Use o modo não HA para ambientes não críticos, por exemplo, um ambiente de teste, onde pode recriar o cluster se o nó do plano de controlo único falhar. Um cluster de utilizadores de HA tem de ter dois ou mais nós de trabalho no caso de um nó de trabalho falhar.
Quando atualiza os clusters, uma implementação de HA também reduz o risco de o cluster ficar inacessível se ocorrer um erro.
Modelos de implementação
O Google Distributed Cloud suporta os seguintes modelos de implementação para satisfazer diferentes requisitos:
- Implementação de clusters de administrador e de utilizador
- Implementação de cluster híbrido
- Implementação de cluster autónomo
Implementação de clusters de administrador e de utilizador
Use este modelo de implementação se tiver vários clusters no mesmo centro de dados que quer gerir a partir de um local centralizado, e para implementações maiores que precisam de isolamento entre diferentes equipas ou entre cargas de trabalho de desenvolvimento e produção.
Este modelo de implementação consiste nos seguintes clusters:
- Um cluster de administrador: o ponto de gestão central que fornece uma API para gerir clusters de utilizadores. O cluster de administrador apenas executa componentes de gestão.
- Um ou mais clusters de utilizadores: contêm os nós do plano de controlo e os nós de trabalho, que executam cargas de trabalho do utilizador.
Este modelo cumpre os seguintes requisitos:
- Fornece um plano de controlo centralizado e uma API para gerir os ciclos de vida dos seus clusters de utilizadores.
- Oferece isolamento entre diferentes equipas.
- Oferece isolamento entre cargas de trabalho de desenvolvimento e produção.
- Não tem de partilhar credenciais SSH nem chaves de contas de serviço com os proprietários do cluster.
- Pode integrar a sua implementação com os seus próprios planos de controlo
Pegada
Uma implementação de cluster de administrador e utilizador requer os seguintes nós:
Cluster de administrador
- Um nó do plano de controlo para não HA
- Três ou mais nós do plano de controlo para HA
Clusters de utilizadores: pode configurar a HA para cada cluster de utilizadores de forma independente.
Nós do plano de controlo:
- Um nó do plano de controlo para não HA
- Três ou mais nós do plano de controlo para HA
Nós trabalhadores:
- Um ou mais nós de trabalho para não HA
- Dois ou mais nós trabalhadores para HA
Implementação de clusters híbridos
Este modelo de implementação é uma implementação especializada de vários clusters. Um cluster híbrido é um cluster de administrador que pode executar cargas de trabalho do utilizador. O cluster híbrido continua a gerir clusters de utilizadores adicionais.
Funcionalidades deste modelo:
- A atribuição de um conjunto de máquinas a um cluster de administrador é frequentemente um desperdício, uma vez que os clusters de administrador usam relativamente poucos recursos. A implementação do cluster híbrido permite-lhe recuperar a capacidade não utilizada nessas máquinas porque permite executar cargas de trabalho do utilizador no cluster de administrador.
- O cluster de administrador contém dados confidenciais, como credenciais SSH (usadas pelo cluster de administrador para gerir clusters de utilizadores em máquinas remotas) eGoogle Cloud chaves de contas de serviço (usadas pelo cluster de administrador para aceder aGoogle Cloud serviços como o Cloud Storage). As implementações de clusters híbridos executam cargas de trabalho do utilizador no cluster de administrador, o que expõe potencialmente os dados confidenciais do cluster de administrador às cargas de trabalho do utilizador.
Pegada
Uma implementação de cluster híbrido requer os seguintes nós:
Cluster híbrido
Nós do plano de controlo:
- Um nó do plano de controlo para não HA
- Três ou mais nós do plano de controlo para HA
Nós trabalhadores:
- Um ou mais nós de trabalho para não HA
- Dois ou mais nós trabalhadores para HA e consoante o tipo de carga de trabalho
Clusters de utilizadores: pode configurar a HA para cada cluster de utilizadores de forma independente.
Nós do plano de controlo:
- Um nó do plano de controlo para não HA
- Três ou mais nós do plano de controlo para HA
Nós trabalhadores:
- Um ou mais nós de trabalho para não HA
- Dois ou mais nós trabalhadores para HA
Implementação de cluster autónomo
Este modelo de implementação tem um único cluster que funciona como um cluster de utilizadores e como um cluster de administrador.
Este modelo tem as seguintes vantagens:
- Não requer um cluster de administrador separado
- Suporta o perfil de limite, que reduziu significativamente os requisitos de recursos do sistema e é recomendado para dispositivos de limite com restrições de recursos elevadas.
Este modelo tem algumas concessões de segurança, porque as cargas de trabalho podem ser executadas num cluster com os seguintes dados confidenciais:
- Credenciais SSH
- Google Cloud chaves de contas de serviço
Use este modelo se cumprir alguma das seguintes condições:
- Gerir cada cluster de forma independente.
- Tem um pequeno número de nós de trabalho.
- Apoia uma única equipa.
- Executa um único tipo de carga de trabalho.
Este modelo funciona bem nas seguintes situações:
- Cada cluster é gerido de forma independente com diferentes chaves SSH e Google Cloud credenciais
- Clusters executados em partições isoladas da rede, separadas de redes não fidedignas
- Os clusters são executados em localizações periféricas
Pegada
Uma implementação de cluster autónoma requer os seguintes nós:
Nós do plano de controlo:
- Um nó do plano de controlo para não HA
- Três ou mais nós do plano de controlo para HA
Nós trabalhadores:
- Um ou mais nós de trabalho para não HA
- Dois ou mais nós trabalhadores para HA
Perfil do limite
Os clusters autónomos suportam um perfil de limite, que minimiza o consumo de recursos do cluster. Ativa o perfil de limite quando cria um cluster autónomo definindo profile no ficheiro de configuração do cluster como edge. O perfil de limite é recomendado para dispositivos de limite
com restrições de recursos restritivas. Para ver os requisitos de hardware associados ao perfil de
limite, consulte os
requisitos de recursos para clusters autónomos que usam o perfil de limite.
Num cluster autónomo configurado para usar o perfil de limite, os nós do plano de controlo são configurados automaticamente para aceitar cargas de trabalho do utilizador. Isto significa que não precisa de um conjunto de nós de trabalho. No entanto, a redução da pegada através da execução de cargas de trabalho no plano de controlo enfraquece a segurança e o isolamento de recursos entre os planos de controlo e de dados. Se a redução da pegada ecológica compensar esta troca, pode configurar um cluster autónomo com o perfil de extremidade para ser executado num único nó do plano de controlo ou em vários nós do plano de controlo para alta disponibilidade.