Nesta página, descrevemos como o Google Distributed Cloud funciona, incluindo informações sobre infraestrutura, hardware, armazenamento e recursos de rede.
O Google Distributed Cloud consiste nos seguintes componentes:
- A infraestrutura do Distributed Cloud. O Google fornece, implanta e mantém o hardware do Distributed Cloud, incluindo o gerenciamento remoto por uma equipe dedicada do Google.
- O serviço Distributed Cloud. Com ele, é possível gerenciar seus clusters e pools de nós do Distributed Cloud usando a Google Cloud CLI e a API Distributed Cloud Edge Container.
Os clusters do Distributed Cloud são registrados na sua
frota, e você pode usar a ferramenta CLI
kubectldo Kubernetes para interagir com eles.
Formatos do Distributed Cloud
O Distributed Cloud está disponível em um dos seguintes formatos:
- Rack de nuvem distribuída. Um rack com seis servidores do Distributed Cloud e dois switches de topo de rack (ToR). Esse formato é compatível com clusters de plano de controle local e de nuvem.
Distributed Cloud Server. Um servidor independente do Distributed Cloud que se conecta diretamente à sua rede local por switches ToR próprios. Esse formato só é compatível com clusters de plano de controle local. Os servidores do Distributed Cloud só podem ser implantados em grupos de três.
A tabela a seguir descreve as diferenças entre os racks do Distributed Cloud e os servidores do Distributed Cloud.
Funcionalidade Rack do GDC Edge Servidor do GDC Edge Formato físico Rack totalmente preenchido
(2 switches ToR, 6 máquinas para montagem em rack)Máquina de rack de meia profundidade 1RU
(implantada em grupos de 3)Fonte de alimentação CA e CC Somente AC Tipo de cluster Plano de controle da nuvem e plano de controle local Apenas plano de controle local Workloads de GPU Sim Sem suporte Conectividade de rede local Camada 3, compatível com BGP Camada 2, BGP não compatível Redes EdgeNetwork Totalmente configurável Apenas uma rede (padrão) Sub-redes do EdgeNetwork CIDR e ID da VLAN Somente ID da VLAN Interconexões do EdgeNetwork Sim Sem suporte Anexos de interconexão do EdgeNetwork Sim Sem suporte Conexões VPN do EdgeNetwork Sim Sem suporte Conectividade VPC Sim Sem suporte Symcloud Storage Sim Sim Operador de função de rede Sim Sem suporte SR-IOV Sim Sem suporte
Infraestrutura de nuvem distribuída
O Google fornece, implanta, opera e mantém o hardware dedicado que executa sua zona do Distributed Cloud. Os nós do Distributed Cloud que executam suas cargas de trabalho são executados exclusivamente nesse hardware.
O hardware executa vários nós agrupados em pools de nós, que podem ser atribuídos a clusters na sua zona do Distributed Cloud. Você pode configurar sua rede para que as cargas de trabalho executadas em clusters do Distributed Cloud estejam disponíveis apenas para seus usuários locais ou acessíveis pela Internet. Também é possível configurar sua rede para permitir que apenas nós do Distributed Cloud usem recursos locais ou se comuniquem com cargas de trabalho, como instâncias de máquina virtual (VM) do Compute Engine e pods do Kubernetes em execução em uma rede de nuvem privada virtual (VPC) por uma conexão de rede Cloud VPN segura com uma rede VPC.
Gerenciamento da nuvem distribuída
Os nós do Distributed Cloud não são recursos independentes e precisam permanecer conectados ao Google Cloud para fins de gerenciamento e monitoramento do plano de controle. Os nós do plano de controle do Distributed Cloud são hospedados na região Google Cloud designada. Os nós do Distributed Cloud locais exigem uma conexão de rede constante com Google Cloud.
O Google gerencia remotamente as máquinas físicas e os switches ToR que constituem sua instalação do Distributed Cloud. Isso inclui instalar atualizações de software e patches de segurança e resolver problemas de configuração. O administrador da rede também pode monitorar a integridade e o desempenho dos clusters e nós do Distributed Cloud e trabalhar com o Google para resolver problemas.
Depois que o Google implantar o hardware do Distributed Cloud no local designado, o administrador do cluster poderá começar a configurar o cluster do Distributed Cloud de uma maneira semelhante a um cluster convencional do Kubernetes. Eles podem atribuir máquinas a pools de nós e pools de nós a clusters, além de conceder acesso aos proprietários de aplicativos conforme exigido pelas funções. No entanto, o administrador do cluster precisa ter em mente as limitações de processamento e armazenamento das máquinas no rack do Distributed Cloud e planejar a configuração do cluster e da carga de trabalho de acordo.
O Distributed Cloud fornece uma API para configurar clusters e pools de nós.
Acesso à zona do Distributed Cloud
É possível configurar sua rede para permitir o nível de acesso desejado à sua zona do Distributed Cloud, tanto da rede local quanto da Internet.
Também é possível conceder à sua zona do Distributed Cloud acesso aos serviçosGoogle Cloud conectando-a à sua rede VPC. O Distributed Cloud usa o Cloud VPN para se conectar aos endpoints de serviço do Google. Seu administrador de rede precisa configurar a rede para permitir isso.
Personas da Distributed Cloud
As seguintes personas estão envolvidas na implantação e operação da sua zona do Distributed Cloud:
Técnico de campo do Google. Fornece, instala e ativa o hardware do Distributed Cloud no local designado. O administrador da rede trabalha com os técnicos do Google para conectar o hardware à fonte de energia e à rede.
Engenheiro de confiabilidade do site (SRE) do Google. Monitora e gerencia o hardware do Distributed Cloud. Isso inclui resolver problemas de configuração, instalar patches e atualizações e manter a segurança.
Administrador de rede. Configura e mantém a conectividade de rede e o controle de acesso entre o hardware do Distributed Cloud e sua rede local. Isso inclui configurar suas regras de roteamento e firewall para garantir que todos os tipos necessários de tráfego de rede possam fluir livremente entre o hardware do Distributed Cloud, Google Cloud, os clientes que consomem suas cargas de trabalho do Distributed Cloud, repositórios de dados internos e externos e assim por diante. O administrador de rede precisa ter acesso ao console do Google Cloud para monitorar o status das máquinas do Distributed Cloud. O administrador de rede também configura os recursos de rede do Distributed Cloud.
Administrador do cluster. Implanta e mantém clusters do Distributed Cloud na sua organização. Isso inclui configurar permissões, geração de registros e provisionamento de cargas de trabalho para cada cluster. O administrador do cluster atribui nós a pools de nós e pools de nós a clusters do Distributed Cloud. O administrador do cluster precisa entender as diferenças operacionais entre o cluster do Distributed Cloud e um cluster tradicional do Kubernetes, como os recursos de processamento e armazenamento do hardware do Distributed Cloud, para configurar e implantar corretamente as cargas de trabalho.
Proprietário do aplicativo. Um engenheiro de software responsável por desenvolver e/ou implantar e monitorar um aplicativo em execução em um cluster do Distributed Cloud. Os proprietários de aplicativos em um cluster da nuvem distribuída precisam entender as limitações de tamanho e local dos clusters, bem como as ramificações da implantação de um aplicativo na borda, como desempenho e latência.
Hardware do rack do Distributed Cloud
A Figura 1 mostra uma configuração típica de rack do Distributed Cloud.
Os componentes de uma instalação do Distributed Cloud são os seguintes:
Google Cloud. O tráfego entre a instalação do Distributed Cloud e Google Cloud inclui tráfego de gerenciamento de hardware, tráfego do plano de controle e tráfego do Cloud VPN para serviços do Google Cloud e cargas de trabalho em execução. Ele também pode incluir tráfego da VPC, se aplicável.
Internet. Tráfego criptografado de gerenciamento e plano de controle entre a instalação do Distributed Cloud e Google Cloud via Internet. O Distributed Cloud não é compatível com conexões de Internet por proxy.
Rede local. A rede local externa ao rack do Distributed Cloud que conecta os roteadores de borda de peering à Internet.
Roteadores de borda de peering. Os roteadores da sua rede local que fazem interface com os switches ToR do Distributed Cloud. Dependendo do local físico escolhido para a instalação do Distributed Cloud, os roteadores de borda de peering podem ser de propriedade e mantidos pela sua organização ou pelo seu data center. É preciso configurar esses roteadores para usar o protocolo de gateway de borda (BGP) para fazer peering com os switches ToR e anunciar uma rota padrão para o hardware do Distributed Cloud. Também é necessário configurar esses roteadores e os firewalls correspondentes para permitir o tráfego de gerenciamento de dispositivos do Google, o tráfego do plano de controle do Distributed Cloud e o tráfego do Cloud VPN, se aplicável.
Dependendo dos requisitos da sua empresa, você pode configurar esses roteadores da seguinte forma:
- Permita que os nós do Distributed Cloud acessem a Internet usando a conversão de endereços de rede (NAT) pública ou a exposição direta a endereços IP públicos.
- Permita uma conexão VPN com sua rede VPC e os serviçosGoogle Cloud desejados.
Switches de topo de rack (ToR, na sigla em inglês). Os switches de camada 3 que conectam as máquinas no rack e fazem interface com sua rede local. Esses switches são falantes de BGP e processam o tráfego de rede entre o rack do Distributed Cloud e seu equipamento de rede local. Eles se conectam aos roteadores de borda de peering usando pacotes do Link Aggregation Control Protocol (LACP).
Máquinas. As máquinas físicas que executam o software do Distributed Cloud e as cargas de trabalho. Cada máquina física é um nó no cluster do Distributed Cloud.
Hardware do servidor do Distributed Cloud
A Figura 2 mostra uma configuração típica do Distributed Cloud Server.
Os componentes de uma instalação do Distributed Cloud são os seguintes:
O tráfego entre a instalação do Distributed Cloud Google Cloud. e Google Cloud inclui gerenciamento de hardware e tráfego de registros de auditoria. Ele também pode incluir tráfego da VPC, se aplicável.
Internet. O tráfego criptografado de gerenciamento e registros de auditoria entre a instalação do Distributed Cloud e Google Cloud viaja pela Internet. O Distributed Cloud não é compatível com conexões de Internet por proxy.
Rede local. Sua rede local a que os servidores do Distributed Cloud se conectam por switches ToR da camada 2.
Switches da parte superior do rack (ToR). Seus switches da camada 2 que conectam as máquinas servidor e fazem interface com sua rede local. Cada máquina do Distributed Cloud Server requer, no mínimo, uma conexão na banda e uma fora da banda com um único switch ToR. O Google recomenda usar dois switches ToR e duas conexões no mesmo canal por máquina (uma por switch) para aumentar a confiabilidade. Cada máquina do Distributed Cloud Server se conecta aos switches ToR da seguinte maneira:
- Conectividade na banda. Cada máquina do Distributed Cloud Server se conecta a um ou aos dois switches ToR para conectividade na banda. Essas conexões transportam o tráfego da carga de trabalho. Configure-os como troncos 802.1q e a VLAN nativa correspondente como a rede a que as interfaces de rede de gerenciamento do Distributed Cloud pertencem. Se você precisar de mais conectividade de carga de trabalho, poderá fazer o trunking de outras VLANs identificadas para os servidores do Distributed Cloud.
- Conectividade fora da banda. Cada servidor do Distributed Cloud também se conecta a um switch ToR para conectividade fora da banda, o que permite que os servidores do Distributed Cloud se comuniquem entre si. Coloque as portas de switch fora da banda na mesma VLAN.
Máquinas. As máquinas físicas do Distributed Cloud Server que executam o software do Distributed Cloud e as cargas de trabalho. Cada máquina física é um nó no cluster do Distributed Cloud.
Serviço do Distributed Cloud
O serviço do Distributed Cloud é executado em Google Cloudpara clusters de plano de controle do Cloud ou diretamente no hardware do Distributed Cloud para clusters de plano de controle local. Ele serve como um plano de controle para os nós e clusters no hardware do Distributed Cloud.
Para clusters remotos do plano de controle, o Distributed Cloud precisa se conectar ao Google Cloud em todos os momentos e não pode funcionar sem essa conexão. Para clusters de plano de controle local, as cargas de trabalho continuam sendo executadas mesmo que o Distributed Cloud não consiga se conectar a Google Cloud por até 7 dias. Após esse período, o Distributed Cloud precisará se comunicar com Google Cloud para atualizar tokens de autenticação, chaves de criptografia de armazenamento e sincronizar dados de gerenciamento de hardware e registros de auditoria.
Esse plano de controle cria instâncias e configura sua zona do Distributed Cloud. O data center específico do Google a que o hardware do Distributed Cloud se conecta para gerenciamento é escolhido de acordo com a proximidade da instalação do Distributed Cloud.
Uma zona do Distributed Cloud consiste nas máquinas instaladas no seu rack do Distributed Cloud ou nas máquinas do servidor do Distributed Cloud implantadas no local. Com o Distributed Cloud Rack, é possível atribuir essas máquinas, instanciadas como nós do Kubernetes, a um pool de nós e o pool a um cluster do Distributed Cloud. Com o Distributed Cloud Servers, os pools de nós são preenchidos automaticamente e não podem ser configurados.
A Figura 3 mostra a organização lógica das entidades do Distributed Cloud.
As entidades são as seguintes:
Google Cloud region. A Google Cloud região da sua zona do Distributed Cloud é determinada pelo local do data center do Google mais próximo da sua instalação do Distributed Cloud.
Plano de controle do Kubernetes na nuvem. Por padrão, o plano de controle do Kubernetes para cada cluster do Distributed Cloud é executado remotamente em um data center do Google na região Google Cloud a que o cluster do Distributed Cloud está atribuído. Isso permite que a Distributed Cloud se beneficie de um plano de controle seguro e altamente disponível sem ocupar a capacidade de processamento nas máquinas físicas da Distributed Cloud. Os clusters do plano de controle do Cloud não estão disponíveis nos servidores do Distributed Cloud.
Plano de controle local do Kubernetes. A partir da versão 1.5.0 do Google Distributed Cloud, é possível configurar um cluster do Distributed Cloud para usar um plano de controle local em vez do plano de controle padrão da nuvem. Um cluster de plano de controle local pode entrar no modo de sobrevivência quando a conexão com Google Cloud é perdida temporariamente, permitindo que suas cargas de trabalho continuem sendo executadas até que a conexão seja restaurada. Esse é o único tipo de cluster disponível nos servidores do Distributed Cloud. Para mais informações, consulte Modo de capacidade de sobrevivência.
Zona do Distributed Cloud. Uma abstração lógica que representa o hardware do Distributed Cloud implantado nas suas instalações. Uma zona da nuvem distribuída abrange um único rack da nuvem distribuída ou todas as máquinas do servidor da nuvem distribuída implantadas no seu local. As máquinas físicas na zona são instanciadas como máquinas do Distributed Cloud no console Google Cloud . As máquinas em uma zona da Distributed Cloud compartilham uma única malha de rede ou um único domínio de falha. O Google cria suas máquinas antes de entregar o hardware do Distributed Cloud. Não é possível criar, excluir ou modificar máquinas do Distributed Cloud.
.Node. Um nó é um recurso do Kubernetes que cria uma máquina física do Distributed Cloud no ambiente do Kubernetes ao criar um pool de nós, disponibilizando-o para executar cargas de trabalho ao atribuir o pool de nós a um cluster do Distributed Cloud.
Pool de nós. Um agrupamento lógico de nós do Distributed Cloud em uma única zona do Distributed Cloud que permite atribuir nós do Distributed Cloud a clusters do Distributed Cloud. Para o Distributed Cloud Servers, os pools de nós são instanciados e preenchidos automaticamente.
Cluster. Um cluster do Distributed Cloud que consiste em um plano de controle e um ou mais pools de nós.
Conexão VPN. Um túnel VPN para uma rede VPC em execução em um projetoGoogle Cloud . Esse túnel permite que suas cargas de trabalho do Distributed Cloud acessem recursos do Compute Engine conectados a essa rede VPC. É necessário criar pelo menos um pool de nós na sua zona antes de criar uma conexão VPN. Os servidores do Distributed Cloud não são compatíveis com conexões VPN.
Armazenamento
O Distributed Cloud oferece 3,3 TiB de armazenamento utilizável por máquina física no rack do Distributed Cloud. Esse armazenamento é configurado como volumes lógicos do Linux. Ao criar um cluster, o Distributed Cloud cria um ou mais PersistentVolumes e os expõe como volumes de blocos que podem ser atribuídos a uma carga de trabalho usando PersistentVolumeClaims. Esses PersistentVolumes não oferecem durabilidade de dados e são adequados apenas para dados efêmeros. Para informações sobre como trabalhar com volumes de blocos, consulte PersistentVolumeClaim solicitando um volume de bloco bruto.
Para servidores do Distributed Cloud, o armazenamento é abstraído exclusivamente pelo Rakuten Symcloud Storage. Cada máquina do Distributed Cloud Server oferece 1 TB de armazenamento utilizável.
Segurança de armazenamento
O Distributed Cloud usa o LUKS para criptografar o armazenamento local da máquina e oferece suporte a chaves de criptografia gerenciadas pelo cliente (CMEK). Para mais informações, consulte Práticas recomendadas de segurança.
Integração do Symcloud Storage
Nos racks do Distributed Cloud, é possível configurar o Distributed Cloud para usar o Rakuten Symcloud Storage, que atua como uma camada de abstração de armazenamento local em cada nó do rack do Distributed Cloud e disponibiliza o armazenamento local para cargas de trabalho executadas em outros nós do Distributed Cloud. Nos servidores do Distributed Cloud, o Symcloud Storage é a opção de armazenamento padrão e única disponível. Os servidores do Distributed Cloud não expõem o armazenamento local como volumes lógicos do Linux.
Para mais informações, consulte Configurar o Distributed Cloud para o Symcloud Storage.
Rede
Esta seção descreve os requisitos e recursos de conectividade de rede do Distributed Cloud.
O Google pré-configura alguns dos componentes de rede virtual do Distributed Cloud para sua instalação antes de enviar o hardware do Distributed Cloud para você. Não é possível modificar as configurações pré-configuradas depois que o hardware é entregue.
A figura 3 mostra a topologia da rede virtual do Distributed Cloud.
Os componentes da rede virtual do Distributed Cloud são os seguintes:
Rede: Uma rede virtual com um espaço de endereço particular na sua zona do Distributed Cloud. Uma rede é isolada da camada 3 de outras redes virtuais na zona e pode conter uma ou mais sub-redes. A rede virtual abrange todas as máquinas físicas no rack do Distributed Cloud. Uma única zona do Distributed Cloud aceita no máximo 20 redes. Os servidores do Distributed Cloud só são compatíveis com uma única rede, a padrão criada quando um cluster do Distributed Cloud Server é instanciado.
Subrede. Uma sub-rede VLAN de camada 2 e camada 3 em uma rede do Distributed Cloud. Uma sub-rede tem seu próprio domínio de transmissão e um ou mais intervalos de endereços IPv4 de sua escolha. As sub-redes na mesma rede são isoladas na camada 2, mas podem se comunicar entre si na camada 3. Os nós em sub-redes diferentes na mesma rede podem se comunicar usando os endereços IP. No entanto, os nós em sub-redes dentro de redes diferentes não podem se comunicar entre si. Os servidores do Distributed Cloud só oferecem suporte ao gerenciamento de sub-redes usando IDs de VLAN.
Router. Uma instância de roteador virtual que controla o tráfego em uma rede do Distributed Cloud. O administrador de rede usa um roteador para configurar uma sessão de peering do BGP em uma conexão de interconexão entre uma rede do Distributed Cloud e sua rede local para que os pods do Distributed Cloud possam anunciar os prefixos de rede na sua rede local. Por padrão, os roteadores reanunciam as rotas recebidas das sub-redes do Distributed Cloud. O Distributed Cloud aceita um roteador por rede. Os servidores do Distributed Cloud não são compatíveis com roteadores.
Interconexão. Um link lógico agrupado entre uma rede do Distributed Cloud e sua rede local. Uma interconexão é composta de um ou mais links físicos. Durante a inicialização inicial, o Google cria as interconexões solicitadas quando você fez o pedido do Distributed Cloud. Não é possível criar, modificar ou remover interconexões depois que o rack do Distributed Cloud estiver funcionando. Por padrão, o Google cria quatro interconexões para oferecer alta disponibilidade à sua instalação. Os servidores do Distributed Cloud não são compatíveis com interconexões.
Anexo de interconexão. Um link virtual entre uma interconexão e um roteador que isola a rede do Distributed Cloud correspondente da sua rede local. O tráfego que flui por um anexo de interconexão pode ser sem tag ou com uma tag de ID da VLAN de sua escolha. Você cria anexos de interconexão com base nos requisitos da sua empresa. O Distributed Cloud não é compatível com anexos de interconexão.
Os componentes de rede do Distributed Cloud são semelhantes aos equivalentes do Google Cloud , mas com as seguintes diferenças:
Os componentes de rede da nuvem distribuída são locais da zona em que são instanciados.
Uma rede do Distributed Cloud não tem conectividade direta com uma rede VPC.
Por padrão, as redes do Distributed Cloud não têm conectividade entre si em diferentes zonas do Distributed Cloud. Você pode configurar explicitamente a rede entre zonas.
O administrador de rede configura os componentes de rede do Distributed Cloud, exceto as interconexões, que o Google configura antes de enviar o hardware do Distributed Cloud para você.
O administrador de rede precisa ter o papel de Administrador de rede de borda (roles/edgenetwork.admin) no projeto de destino Google Cloud , enquanto os desenvolvedores de aplicativos que implantam cargas de trabalho no Distributed Cloud precisam ter o papel de Leitor de rede de borda (roles/edgenetwork.viewer) no projeto de destino Google Cloud .
Conectividade com sua rede local
Para o tráfego de saída para recursos na sua rede local, os pods em um cluster do Distributed Cloud usam as rotas padrão anunciadas pelos roteadores de borda de peering. O Distributed Cloud usa o NAT integrado para conectar pods a esses recursos.
Para o tráfego de entrada de recursos na rede local, o administrador de rede precisa configurar políticas de roteamento que atendam aos requisitos da empresa para controlar o acesso aos pods em cada um dos clusters do Distributed Cloud. Isso significa, no mínimo, concluir as etapas em Configuração do firewall e configurar outras políticas conforme exigido pelas suas cargas de trabalho. Por exemplo, é possível configurar políticas de permissão/negação para sub-redes de nós individuais ou endereços IP virtuais expostos pelo balanceador de carga integrado no Distributed Cloud. Os blocos de CIDR do pod e do serviço da Distributed Cloud não são acessíveis diretamente.
Conectividade à Internet
Para o tráfego de saída para recursos na Internet, os pods em um cluster do Distributed Cloud usam a rota padrão anunciada pelos roteadores para os switches ToR do Distributed Cloud. Isso significa, no mínimo, concluir as etapas em Configuração do firewall e configurar outras políticas conforme exigido pelas suas cargas de trabalho. O Distributed Cloud usa o NAT integrado para conectar pods a esses recursos. Você pode configurar sua própria camada de NAT sobre a camada integrada na Distributed Cloud.
Para o tráfego de entrada, configure os roteadores WAN de acordo com os requisitos da sua empresa. Esses requisitos determinam o nível de acesso que você precisa fornecer da Internet pública aos pods nos clusters do Distributed Cloud. O Distributed Cloud usa o NAT integrado para blocos CIDR de pod e de gerenciamento de serviços. Portanto, esses blocos não podem ser acessados pela Internet.
Conectividade com uma rede VPC
O Distributed Cloud inclui uma solução de VPN integrada que permite conectar um cluster do Distributed Cloud diretamente a uma instância de VPC se ela estiver no mesmo projetoGoogle Cloud do cluster do Distributed Cloud.
Se você usar o Cloud Interconnect para conectar sua rede local a uma instância de VPC, os clusters do Distributed Cloud poderão acessar essa instância usando o peering eBGP padrão de sentido norte. Os roteadores de borda de peering precisam conseguir alcançar os prefixos de VPC adequados, e os roteadores do Cloud Interconnect precisam anunciar corretamente os prefixos do Distributed Cloud, como balanceador de carga, gerenciamento e sub-redes do sistema do Distributed Cloud.
Depois de estabelecer uma conexão VPN entre o cluster do Distributed Cloud e a rede VPC, as seguintes regras de conectividade serão aplicadas por padrão:
- Sua rede VPC pode acessar todos os pods no cluster do Distributed Cloud.
- Todos os pods no cluster do Distributed Cloud podem acessar todos os pods nos clusters nativo da VPC. Para clusters baseados em rotas, configure manualmente as rotas divulgadas personalizadas.
- Todos os pods no cluster do Distributed Cloud podem acessar sub-redes máquina virtual na sua rede VPC.
A funcionalidade descrita nesta seção não está disponível nos servidores do Distributed Cloud.
Conectividade com APIs e serviços do Google Cloud
Depois de configurar uma conexão VPN com sua rede VPC, as cargas de trabalho em execução na instalação do Distributed Cloud podem acessar APIs e serviços do Google Cloud .
Além disso, você pode configurar os seguintes recursos se os requisitos da sua empresa exigirem:
- Acesso privado do Google para acessar APIs e serviços do Google Cloud
- Private Service Connect para usar endpoints de serviço particulares e acessar Google Cloud APIs
A conectividade VPN não está disponível nos servidores do Distributed Cloud.
Segurança de rede
Os requisitos da sua empresa e a política de segurança de rede da sua organização determinam as etapas necessárias para proteger o tráfego de rede que entra e sai da instalação do Distributed Cloud. Para mais informações, consulte Práticas recomendadas de segurança.
Outros recursos de rede
O Distributed Cloud é compatível com os seguintes recursos de rede:
Suporte a redes de alto desempenho
Os racks do Distributed Cloud oferecem suporte à execução de cargas de trabalho que exigem o melhor desempenho de rede possível. Para isso, o Distributed Cloud vem com um operador de função de rede especializado e um conjunto de CustomResourceDefinitions (CRDs) do Kubernetes que implementam os recursos necessários para a execução de cargas de trabalho de alta performance.
Os racks do Distributed Cloud também oferecem suporte à virtualização de interfaces de rede usando SR-IOV.
Os recursos descritos nesta seção não estão disponíveis no Distributed Cloud Servers.
Suporte a cargas de trabalho de máquinas virtuais
O Distributed Cloud pode executar cargas de trabalho em máquinas virtuais e contêineres. Para mais informações, consulte Gerenciar máquinas virtuais.
Para saber como as máquinas virtuais são um componente essencial da plataforma Google Distributed Cloud, consulte Extensão do GKE Enterprise para gerenciar VMs de borda locais.
Suporte a cargas de trabalho de GPU
O Distributed Cloud pode executar cargas de trabalho baseadas em GPU nas GPUs NVIDIA Tesla T4. Você precisa especificar esse requisito ao pedir o hardware do Distributed Cloud. Para mais informações, consulte Gerenciar cargas de trabalho de GPU.
Essa funcionalidade não está disponível nos servidores do Distributed Cloud.