Este documento apresenta as práticas recomendadas para projetar a hierarquia e a separação de cargas de trabalho no Google Distributed Cloud (GDC) isolado usando organizações, projetos e clusters do Kubernetes. Estas orientações equilibram o uso eficiente de recursos, o isolamento de cargas de trabalho e a facilidade de operações.
Projetar organizações para isolamento físico e lógico entre clientes
O recurso Organization é a raiz de todos os recursos de um único cliente. O controle de acesso granular entre cargas de trabalho em uma organização pode
ser definido por vinculações de função e políticas de rede. Consulte
Gerenciamento de identidade e acesso para mais
informações.
Cada organização em uma zona do GDC oferece isolamento físico para a infraestrutura de computação e isolamento lógico para rede, armazenamento e outros serviços. Os usuários de uma organização não têm acesso aos recursos de outra, a menos que o acesso seja concedido explicitamente. Por padrão, não é permitida a conectividade de rede entre organizações, a menos que seja configurada explicitamente para permitir a transferência de dados de uma organização para outra.
Definir o escopo das cargas de trabalho que podem compartilhar uma organização
O escopo de uma organização no contexto da sua empresa pode variar de acordo com a definição de limites de confiança. Algumas empresas preferem 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 exigirem separação física e administrativa completa das cargas de trabalho.
Em geral, recomendamos que você agrupe várias cargas de trabalho em uma única organização com base nos seguintes indicadores:
- As cargas de trabalho podem compartilhar dependências. Por exemplo, pode ser uma fonte de dados compartilhada, conectividade entre cargas de trabalho ou uma ferramenta de monitoramento compartilhada.
- As cargas de trabalho podem compartilhar uma raiz administrativa de confiança. O mesmo administrador pode ter acesso privilegiado a todas as cargas de trabalho na organização.
- As cargas de trabalho podem compartilhar a infraestrutura física com outras cargas de trabalho na mesma organização, desde que haja separação lógica suficiente.
- O mesmo proprietário do orçamento é responsável pelos orçamentos de carga de trabalho agregados. Para detalhes sobre como ver os custos agregados da organização ou uma análise granular por carga de trabalho, consulte a página Faturamento.
- Os requisitos de disponibilidade de carga de trabalho precisam seguir os requisitos de alta disponibilidade para distância multizonal.
Projetar projetos para isolamento lógico entre cargas de trabalho
Em uma organização, recomendamos provisionar vários projetos para criar uma separação lógica entre os recursos. Projetos na mesma organização podem compartilhar a infraestrutura física subjacente, mas são usados para separar cargas de trabalho com um limite lógico com base em políticas do Identity and Access Management (IAM) e de rede.
Ao projetar limites de projetos, pense no maior conjunto de funcionalidades que podem ser compartilhadas por recursos, como vinculações de papéis, políticas de rede ou requisitos de observabilidade. Agrupe os recursos que podem compartilhar essa funcionalidade em um projeto e mova os recursos que não podem compartilhar essa funcionalidade para outro projeto.
Em termos do Kubernetes, um projeto é um namespace reservado em todos os clusters de uma organização. Embora um namespace seja reservado em vários clusters, isso não significa que um pod seja programado automaticamente em todos eles. Um pod programado para um cluster específico permanece programado para esse cluster.
O diagrama a seguir mostra como uma vinculação de função é aplicada a um projeto que abrange vários clusters.
As vinculações de função são definidas no nível do projeto para definir quem pode fazer o quê em cada tipo de recurso. As cargas de trabalho, como VMs ou pods, são implantadas em um projeto, e o acesso a elas é regido pela vinculação de função. A vinculação de função se aplica de forma consistente a cargas de trabalho baseadas em VM e em contêineres, independente do cluster em que são implantadas.
O diagrama a seguir mostra como as políticas de rede gerenciam o acesso entre projetos.
A comunicação entre projetos entre Backend Project, Frontend Project e Database Project está desativada. No entanto, os recursos em cada projeto podem se comunicar entre si.
As políticas de rede são definidas no nível do projeto para permitir seletivamente o acesso à rede entre os recursos. Por padrão, todos os recursos em um único projeto podem se comunicar entre si na rede interna, e um recurso em um projeto não pode se comunicar com um recurso em outro projeto. Esse comportamento das políticas de rede se aplica se os recursos são implantados no mesmo cluster ou não.
Também é possível definir um recurso personalizado ProjectNetworkPolicy para ativar
a comunicação entre projetos. Essa política é definida para cada projeto para permitir
o tráfego de entrada de outros projetos. O diagrama a seguir ilustra um recurso personalizado ProjectNetworkPolicy definido para o Backend Project para permitir a transferência de dados do Frontend Project e do Database Project.
Além disso, a pilha de monitoramento coleta métricas em toda a organização, mas você pode filtrar e consultar em vários níveis da hierarquia de recursos. É possível consultar métricas com entidades como um cluster ou namespace.
Criar projetos por ambiente de implantação
Para cada carga de trabalho, recomendamos criar projetos separados para produção, desenvolvimento e outros ambientes de implantação necessários. Ao separar os ambientes de implantação de produção e desenvolvimento, é possível definir vinculações de função e políticas de rede de maneira granular. Assim, as mudanças feitas em um projeto usado para desenvolvimento não afetam o ambiente de produção.
Conceder vinculações de papéis no nível do recurso em projetos
Dependendo da estrutura e dos requisitos da sua equipe, você pode permitir que os desenvolvedores modifiquem qualquer recurso no projeto que gerenciam ou exigir um controle de acesso mais granular. Em um projeto, você concede vinculações de papéis granulares para permitir que desenvolvedores individuais acessem alguns, mas não todos os recursos do projeto. Por exemplo, uma equipe pode ter um administrador de banco de dados que precisa gerenciar o banco de dados, mas não modificar outros recursos, enquanto os desenvolvedores de software da equipe não podem ter permissão para modificar o banco de dados.
Projetar clusters para isolamento lógico de operações do Kubernetes
Um cluster do Kubernetes não é um limite rígido de locatário porque as vinculações de função e as políticas de rede se aplicam a projetos, não a clusters do Kubernetes. Os clusters e projetos do Kubernetes têm uma relação de muitos para muitos. É possível ter vários clusters do Kubernetes em um único projeto ou um único cluster do Kubernetes que abrange vários projetos.