Este documento apresenta as práticas recomendadas para conceber a hierarquia e a separação de cargas de trabalho no Google Distributed Cloud (GDC) air-gapped através de organizações, projetos e clusters do Kubernetes. Estas orientações equilibram a utilização eficiente de recursos, o isolamento das cargas de trabalho e a facilidade de operações.
Conceber organizações para isolamento físico e lógico entre clientes
O recurso Organization é a raiz de todos os recursos pertencentes a um único cliente. O controlo de acesso detalhado entre cargas de trabalho numa organização pode ser definido através de associações de funções e políticas de rede. Consulte o artigo
Gestão de identidades e acessos para mais
informações.
Cada organização numa zona do GDC oferece isolamento físico para a infraestrutura de computação e isolamento lógico para redes, armazenamento e outros serviços. Os utilizadores de uma organização não têm acesso aos recursos de outra organização, a menos que lhes seja concedido acesso explicitamente. Por predefinição, a conetividade de rede de uma organização para outra não é permitida, a menos que seja configurada explicitamente para permitir a transferência de dados de uma organização e a transferência de dados para outra.
Defina o âmbito das cargas de trabalho que podem partilhar uma organização
O âmbito de uma organização no contexto da sua empresa pode variar consoante a forma como a sua empresa define os limites de confiança. Algumas empresas podem preferir criar vários recursos de organização para diferentes entidades na empresa. Por exemplo, cada departamento da empresa pode ser um cliente independente do GDC com uma organização independente se os departamentos precisarem de uma separação física e administrativa completa das respetivas cargas de trabalho.
Em geral, recomendamos que agrupe várias cargas de trabalho numa única organização com base nos seguintes sinais:
- As cargas de trabalho podem partilhar dependências. Por exemplo, pode ser uma origem de dados partilhada, a conetividade entre cargas de trabalho ou uma ferramenta de monitorização partilhada.
- As cargas de trabalho podem partilhar uma raiz de fidedignidade administrativa. O mesmo administrador pode ter acesso privilegiado a todas as cargas de trabalho na organização.
- As cargas de trabalho podem partilhar a infraestrutura física subjacente com outras cargas de trabalho na mesma organização, desde que exista uma separação lógica suficiente.
- O mesmo titular do orçamento tem responsabilidade pelos orçamentos de carga de trabalho de forma agregada. Para ver detalhes sobre a visualização dos custos agregados da organização ou a análise detalhada por carga de trabalho, consulte a página Faturação.
- Os requisitos de disponibilidade da carga de trabalho têm de seguir os requisitos de alta disponibilidade para a distância entre várias zonas.
Crie projetos para isolamento lógico entre cargas de trabalho
Dentro de uma organização, recomendamos o aprovisionamento de vários projetos para criar uma separação lógica entre os recursos. Os projetos na mesma organização podem partilhar a infraestrutura física subjacente, mas os projetos são usados para separar cargas de trabalho com um limite lógico com base nas políticas de gestão de identidade e de acesso (IAM) e nas políticas de rede.
Ao conceber limites de projetos, pense no maior conjunto de funcionalidades que podem ser partilhadas por recursos, como associações de funções, políticas de rede ou requisitos de observabilidade. Agrupe os recursos que podem partilhar esta funcionalidade num projeto e mova os recursos que não podem partilhar esta funcionalidade para outro projeto.
Em termos do Kubernetes, um projeto é um espaço de nomes do Kubernetes reservado em todos os clusters de uma organização. Embora um espaço de nomes esteja reservado em vários clusters, isso não significa que um pod seja automaticamente agendado em todos os clusters. Um pod agendado para um cluster específico permanece agendado para esse cluster específico.
O diagrama seguinte mostra como uma associação de funções é aplicada a um projeto que abrange vários clusters.
As associações de funções são definidas ao nível do projeto para definir quem pode fazer o quê a que tipo de recurso. As cargas de trabalho, como VMs ou pods, são implementadas num projeto e o acesso a estas cargas de trabalho é regido pela associação de funções. A associação de funções aplica-se de forma consistente a cargas de trabalho baseadas em VMs e cargas de trabalho baseadas em contentores, independentemente do cluster no qual são implementadas.
O diagrama seguinte mostra como as políticas de rede gerem o acesso entre projetos.
A comunicação entre projetos entre o Backend Project, o Frontend Project e o Database Project está desativada. No entanto, os recursos em cada projeto podem comunicar entre si.
As políticas de rede são definidas ao nível do projeto para permitir seletivamente o acesso à rede entre recursos. Por predefinição, todos os recursos num único projeto podem comunicar entre si na rede interna, e um recurso num projeto não pode comunicar com um recurso noutro projeto. Este comportamento das políticas de rede aplica-se independentemente de os recursos serem implementados no mesmo cluster ou não.
Também pode definir um recurso personalizado ProjectNetworkPolicypara ativar a comunicação entre projetos. Esta política é definida para cada projeto para permitir o tráfego de entrada de outros projetos. O diagrama seguinte ilustra um recurso personalizado ProjectNetworkPolicy definido para o Backend Project para
ativar a transferência de dados do Frontend Project e do Database Project.
Além disso, a pilha de monitorização recolhe métricas em toda a organização, mas pode filtrar e consultar a vários níveis da hierarquia de recursos. Pode consultar métricas com entidades, como um cluster ou um espaço de nomes.
Crie projetos por ambiente de desenvolvimento de software
Para cada carga de trabalho, recomendamos que crie projetos separados para cada ambiente de desenvolvimento de software. Um ambiente de programação de software é uma área no seu universo da GDC destinada a todas as operações que correspondem a uma fase do ciclo de vida designada. Por exemplo, pode ter ambientes de desenvolvimento de software para testes, desenvolvimento e produção. A separação dos ambientes de desenvolvimento de software permite-lhe definir associações de funções e políticas de rede de forma detalhada, para que as alterações feitas num projeto usado para um ambiente de não produção não afetem o ambiente de produção.
Conceda associações de funções ao nível do recurso nos projetos
Consoante a estrutura e os requisitos da sua equipa, pode permitir que os programadores modifiquem qualquer recurso no projeto que gerem ou pode exigir um controlo de acesso mais detalhado. Num projeto, concede associações de funções detalhadas para permitir que programadores individuais acedam a alguns, mas não a todos os recursos no projeto. Por exemplo, uma equipa pode ter um administrador da base de dados que tem de gerir a base de dados, mas não modificar outros recursos, enquanto os programadores de software da equipa não podem ter autorização para modificar a base de dados.
Crie clusters para o isolamento lógico das operações do Kubernetes
Um cluster do Kubernetes não é um limite de inquilino rígido porque as associações de funções e as políticas de rede aplicam-se a projetos e não a clusters do Kubernetes. Os clusters e os projetos do Kubernetes têm uma relação de muitos-para-muitos. Pode ter vários clusters do Kubernetes num único projeto ou um único cluster do Kubernetes que abranja vários projetos.