O recurso "organização" representa uma unidade administrativa ou uma função comercial que compartilha o mesmo pool de recursos e políticas comuns. O Google Distributed Cloud (GDC) com isolamento físico oferece isolamento físico entre organizações usando recursos multitenancy no nível do hardware. Cada organização também tem os próprios componentes do plano de controle para os serviços, que não são compartilhados com outras organizações. Todos os recursos, como projetos, clusters e serviços, pertencem a uma organização, e não aos criadores deles. Portanto, os recursos não são excluídos se o usuário que os criou sair da organização. Em vez disso, todos os tipos de recursos seguem o ciclo de vida da organização. Para mais informações, consulte a hierarquia de recursos do GDC.
Conectividade de rede externa
Para ser útil, uma organização precisa de conectividade com redes externas. Isso permite que administradores da plataforma (PA) e operadores de aplicativos (AO) gerenciem a organização e os recursos dela, e que os usuários finais consumam os serviços implantados nela. No GDC, toda a conectividade externa é fornecida por interconexões.
Quando uma organização é criada, ela não é conectada automaticamente a nenhuma rede. Como operador, você precisa realizar mais etapas de configuração para anexar uma organização a uma interconexão existente ou provisionar uma nova e dedicada. Isso geralmente envolve:
- Adicionar a organização a um
AttachmentGroup. - Criação de recursos
Interconnectpara novas conexões físicas ou lógicas. - Definir recursos
RoutePolicypara anunciar as rotas de rede da organização para a rede externa.
As organizações oferecem recursos de rede aprimorados, incluindo a capacidade de organizações com interconexões dedicadas usarem endereços IP externo sobrepostos, o que simplifica o gerenciamento de IP.
Para conceitos detalhados e procedimentos de configuração, consulte a Visão geral da interconexão.
Modelos de conectividade do Interconnect
As interconexões do GDC oferecem suporte a duas configurações principais que se alinham a diferentes requisitos de segurança e gerenciamento de IP.
Conectividade de rede externa compartilhada
Esse modelo permite que várias organizações se conectem a uma zona do GDC por uma rede externa comum. Nessa configuração, o operador de infraestrutura (IO) gerencia a conexão física e o peering do BGP. Um requisito fundamental é que os endereços IP externo usados por cada organização sejam exclusivos em toda a rede compartilhada. Esse modelo é mais simples de gerenciar em ambientes com um domínio de confiança comum.
Conectividade de rede externa dedicada
Esse modelo é para organizações que exigem um grau maior de isolamento, conectando-se a uma rede externa distinta. Com a conectividade dedicada, o PA pode gerenciar o peering BGP, oferecendo mais controle.
Uma vantagem significativa desse modelo é a capacidade das organizações de usar endereços IP externo sobrepostos. Isso simplifica o gerenciamento de endereços IP, eliminando a necessidade de resolver conflitos de intervalos de IP em todos os locatários do universo do GDC.
Para conceitos e procedimentos de configuração detalhados, consulte a Visão geral da interconexão.
Arquiteturas de organização
O GDC oferece duas arquiteturas para organizações:
- Arquitetura da organização v1 do GDC com isolamento físico (organização v1)
- Arquitetura da organização v2 do GDC com isolamento físico (organização v2)
Na superfície, as organizações com qualquer uma das arquiteturas são provisionadas, usadas e operadas de maneira semelhante. Mas as arquiteturas de cluster, rede e armazenamento subjacentes são diferentes em cada tipo de organização.
Arquitetura da organização v1 do GDC com isolamento físico
Uma organização da v1 consiste em dois clusters:
- Cluster de administrador da organização: executa os componentes do plano de controle dos serviços gerenciados e do Marketplace para a organização. Ele também hospeda alguns serviços principais de infraestrutura.
- Cluster do sistema: executa cargas de trabalho de máquina virtual (VMs) e algumas cargas de trabalho do plano de dados de serviço gerenciado para a organização. O número de nós de trabalho depende da utilização do cluster.
O PA e o AO são necessários para acessar esses tipos de cluster às vezes para implantar cargas de trabalho e gerenciar o sistema.
O armazenamento para clusters virtuais é processado por um driver CSI específico do fornecedor dentro do cluster.
Arquitetura da organização v2 do GDC com isolamento físico
Uma organização v2 consiste em um cluster chamado de cluster de infraestrutura da organização, que executa os componentes do plano de controle e do plano de dados da organização. Esse cluster também hospeda o servidor da API de gerenciamento, em que todas as cargas de trabalho e serviços não contêineres são implantados. O servidor da API de gerenciamento fornece uma camada em que os PAs e os AOs podem implantar cargas de trabalho, mas não interagir diretamente com o cluster de infraestrutura da organização.
O armazenamento para clusters virtuais é processado por um driver CSI de proxy que permite que o driver CSI do cluster de infraestrutura da organização processe operações.
Os componentes de rede, incluindo gerenciamento de endereços IP, redirecionamento de entrada e saída e estrutura de VRF, oferecem melhorias em relação à arquitetura da organização v1 para segurança e usabilidade do sistema.
Quais são as novidades para as organizações da v2?
A arquitetura da organização v2 introduz mudanças em vários componentes em comparação com a arquitetura da organização v1.
Arquitetura de API e cluster
A arquitetura da organização v2 oferece apenas um cluster para a organização, em vez de dois clusters fornecidos na arquitetura anterior. A redução no número de clusters permite um uso mais elástico dos recursos de hardware.
Há também a separação de rede dos planos de controle e de dados, que não estava disponível para organizações da v1. O servidor da API de gerenciamento, ou plano de controle, agora pode ser exposto em uma rede do cliente diferente da rede em que o plano de dados está exposto. Essa separação oferece uma camada adicional opcional de isolamento entre o provisionamento e o consumo de recursos da nuvem. É esperado que seus administradores e desenvolvedores tenham conexões com as duas redes externas.
Armazenamento
A nova arquitetura da organização v2 remove as credenciais de armazenamento da NetApp do cluster de usuário implantando o driver CSI do KubeVirt em vez do driver CSI do NetApp Trident, que estava na arquitetura anterior. Essa atualização do driver CSI reduz ainda mais os privilégios diretos da matriz de armazenamento.
Rede
As seguintes melhorias de rede estão disponíveis para organizações da v2:
- Criptografia de nó para nó
- Cluster dedicado para processar o tráfego de rede
- Rede de VM simplificada
- Uso e gerenciamento mais eficientes de endereços IP
Criptografia entre nós
A arquitetura da organização v2 oferece criptografia entre os nós bare metal da organização para que todo o tráfego de rede do cliente seja criptografado ao sair do nó físico. Isso evita que os switches de rede tenham visibilidade do tráfego não criptografado.
Cluster dedicado para processar o tráfego de rede
O cluster de perímetro é um cluster virtual escalonável que processa todo o tráfego de entrada e saída (norte/sul) da organização. Esse cluster também permite que seu universo do GDC mude para opções mais escalonáveis de sistema virtual de detecção e prevenção de intrusão (IDPS) no futuro.
Rede de VM simplificada
A arquitetura da organização v2 converge duas interfaces por VM da arquitetura anterior para uma única interface. As VMs são movidas para um modelo de rede de nuvem privada virtual (VPC) padrão, o que significa que elas são conectadas à rede no nível da camada 3 (L3).
Os clientes também podem definir as próprias sub-redes, o que não é compatível com organizações da v1.
Uso e gerenciamento eficientes de endereços IP
A arquitetura da organização v2 permite endereços IP externo sobrepostos para organizações. Com o uso de endereços IP externos sobrepostos, as organizações podem se conectar diretamente às redes dos clientes, eliminando a necessidade de um único espaço de endereço IP externo grande alinhado em todas as organizações do universo do GDC.
Os endereços IP também são fornecidos por organização, em vez de serem ancorados em uma única sub-rede mãe com escopo zonal. Com esse recurso, os administradores podem especificar os próprios endereços IP, em vez de exigir que você, como operador, especifique um. Esse recurso oferece melhor elasticidade e isolamento para organizações que desejam um isolamento de rede forte sem compartilhar uma superrede mãe.
Para organizações da v1, os endereços IP do NAT de saída eram necessários um por projeto, por cluster de usuário e por organização. Para organizações v2, esse requisito foi muito melhorado para um por projeto e por organização. Essa mudança oferece mais eficiência no uso de endereços IP fornecidos pelo cliente.
Diferenças funcionais entre as organizações v1 e v2
Uma organização da v2 oferece todos os mesmos recursos de uma organização da v1. Os únicos recursos não disponíveis em uma organização v2 são:
- Vertex AI
- CLI do serviço de banco de dados
Qual arquitetura as organizações multizonais vão usar?
Em um universo do GDC multizona, se você estender uma organização para uma nova zona, a organização na nova zona precisará usar a mesma arquitetura da zona atual. Portanto, não é possível usar arquiteturas de organização diferentes por zona.
Como provisionar uma organização v2
Ao provisionar uma organização, as organizações v2 são criadas por padrão para clientes que não estão sujeitos a processos de acreditação.
No entanto, as organizações v2 oferecem uma mudança arquitetônica significativa. Para implantações de clientes sujeitas a acreditação, a arquitetura da organização v1 permanece como padrão até que a arquitetura da organização v2 conclua a acreditação.
O padrão da arquitetura da organização é controlado por uma flag de recurso configurada ao implantar uma zona.
Como forçar a arquitetura da organização
Em casos raros, talvez seja necessário substituir o comportamento de provisionamento padrão e forçar uma arquitetura de organização específica adicionando o campo spec.compatibilityOptions.architectureOverridePolicy ao recurso Organization durante o processo de provisionamento. Para mais informações, consulte a página Criar uma organização
do cliente.
Não é recomendável substituir a arquitetura padrão da organização, a menos que você tenha um bom motivo para forçar um comportamento específico.
Por exemplo, você pode forçar uma organização v1 se encontrar um problema significativo com uma organização v2 que bloqueia uma tarefa. Da mesma forma, você pode forçar uma organização v2 se precisar de acreditação e de uma única organização v2 para iniciar o processo. Essas flags de substituição precisam ser removidas quando não forem mais estritamente necessárias para evitar o provisionamento futuro da organização com a arquitetura errada.
O que acontece com as organizações da v1?
As organizações criadas antes do GDC air-gapped 1.14.2 permanecem na mesma arquitetura, mesmo que a zona do GDC seja atualizada para a versão 1.14.2 ou mais recente. Embora não haja um upgrade no local disponível para converter organizações da v1 para a v2, os recursos atuais das organizações da v1 vão continuar sendo compatíveis até a descontinuação futura da arquitetura da organização da v1.
Todos os novos recursos no futuro só poderão ser adicionados às organizações da v2. Portanto, recomendamos que você mova suas cargas de trabalho das organizações v1 para a nova arquitetura de organização v2 assim que possível. Um único universo isolado do GDC pode conter as duas arquiteturas de organização simultaneamente, o que facilita a transição.