Esta página oferece uma visão geral do Google Distributed Cloud, incluindo informações sobre quando usar, limitações e problemas conhecidos.
Com a Distributed Cloud, é possível executar clusters do Google Kubernetes Engine (GKE) em hardware dedicado fornecido e mantido pelo Google, separado do data center tradicional Google Cloud . O Google entrega e instala o hardware do Distributed Cloud no local.
A implantação de cargas de trabalho em uma instalação do Distributed Cloud funciona de maneira semelhante à implantação de cargas de trabalho em clusters do GKE baseados na nuvem. Depois que o hardware for implantado, o administrador do cluster vai provisionar clusters do Distributed Cloud usando o console Google Cloud ou a Google Cloud CLI. Além disso, o administrador de rede configura os componentes de rede do Distributed Cloud para que as cargas de trabalho possam se comunicar com a rede local e entre si. Os proprietários de aplicativos podem implantar cargas de trabalho nesses clusters. O Distributed Cloud permite executar cargas de trabalho em contêineres do Kubernetes e em máquinas virtuais, incluindo cargas de trabalho baseadas em GPU, que são executadas em GPUs NVIDIA Tesla T4.
O Google monitora e mantém remotamente sua instalação do Distributed Cloud, o que inclui instalar atualizações de software e patches de segurança, resolver problemas de configuração e diagnosticar o hardware do Distributed Cloud. Para resolver um problema que não pode ser resolvido remotamente, você precisa dar acesso físico ao hardware do Distributed Cloud para o pessoal autorizado do Google.
A implantação do Distributed Cloud usa uma conexão segura do Cloud VPN para acessar serviços do Google Cloud e seus aplicativos que são executados no Google Cloud e na rede de nuvem privada virtual (VPC).
Para uma visão geral técnica do Distributed Cloud, consulte Como o Distributed Cloud funciona.
Quando usar o Distributed Cloud
O Distributed Cloud foi projetado especificamente para lidar com os seguintes cenários em que as implantações convencionais do Google Cloud podem não ser suficientes:
- Seus aplicativos exigem uma conexão de rede muito estável e não podem tolerar possíveis interrupções de tráfego que ocorrem com frequência ao transferir dados pela Internet.
Seus aplicativos exigem a menor latência de rede possível e são sensíveis a picos ou instabilidade de latência. O Distributed Cloud também oferece suporte a tecnologias de rede de alto desempenho, como a virtualização de entrada/saída de raiz única (SR-IOV) e o Kit de desenvolvimento do plano de dados (DPDK), para cenários ainda mais avançados que utilizam o operador de função de rede.
Seus aplicativos geram grandes quantidades de dados que seriam proibitivos em termos de desempenho ou custo para transferir de e para oGoogle Cloud.
As leis ou regulamentações locais determinam que seus dados precisam permanecer no local e não podem ser armazenados fora da empresa ou de uma jurisdição geográfica específica.
Limitações do Distributed Cloud
Uma zona do Distributed Cloud tem as seguintes limitações em comparação com uma zona convencional do GKE baseada na nuvem:
- Capacidade de processamento. Ao contrário de uma zona convencional baseada na nuvem, sua instalação do Distributed Cloud tem capacidade de processamento limitada. Considere essa limitação ao planejar e implantar suas cargas de trabalho.
- Restrições de carga de trabalho. O Distributed Cloud impõe várias restrições às suas cargas de trabalho.
- Recursos do GKE Enterprise. O Distributed Cloud não é compatível com recursos do GKE Enterprise, como o Cloud Service Mesh, exceto pelo recurso ConfigSync do Gerenciamento de configuração.
Problemas conhecidos nesta versão do Distributed Cloud
Esta versão do Distributed Cloud tem os seguintes problemas conhecidos:
- Um grande número de chamadas de webhook pode causar uma falha temporária no proxy de conectividade.
- Os agentes de métricas em execução nos nós do Distributed Cloud podem acumular um backlog de eventos e ficar parados, impedindo a captura de mais métricas.
- A coleta de lixo falha intermitentemente ao limpar pods encerrados.
- As sessões do BGP não são recuperadas quando a interface de rede correspondente fica inativa e depois volta a ficar ativa.