Neste documento, apresentamos as práticas recomendadas para projetar a hierarquia e a separação de cargas de trabalho no Google Distributed Cloud (GDC) com isolamento físico usando organizações, projetos e clusters do Kubernetes. Essas 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 meio de vinculações de papéis e políticas de rede. Consulte
Gerenciamento de identidade e acesso para mais
informações.
Cada organização em uma zona do GDC fornece 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 explicitamente concedido. A conectividade de rede de uma organização para outra não é permitida por padrão, a menos que seja explicitamente configurada 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 forma como ela 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 exigirem uma 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 de confiança administrativa. O mesmo administrador pode receber acesso privilegiado a todas as cargas de trabalho na organização.
- As cargas de trabalho podem compartilhar a infraestrutura física subjacente com outras cargas de trabalho na mesma organização, desde que haja uma separação lógica suficiente.
- O mesmo titular do orçamento é responsável pelos orçamentos de carga de trabalho em conjunto. Para detalhes sobre como visualizar os custos agregados da organização ou uma análise granular por carga de trabalho, consulte a página Faturamento.
- Os requisitos de disponibilidade da carga de trabalho precisam seguir os requisitos de alta disponibilidade para distância entre várias zonas.
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. Os projetos na mesma organização podem compartilhar a infraestrutura física, mas são usados para separar as cargas de trabalho com um limite lógico baseado em políticas do Identity and Access Management (IAM) e políticas de rede.
Ao projetar limites de projeto, pense no maior conjunto de funcionalidades que pode ser compartilhado 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 do Kubernetes 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 os clusters. Um pod programado para um cluster específico permanece programado para esse cluster.
O diagrama a seguir mostra como uma vinculação de papel é aplicada a um projeto que abrange vários clusters.
As vinculações de papéis são definidas no nível do projeto para definir quem pode fazer o que em qual tipo de recurso. Cargas de trabalho como VMs ou pods são implantadas em um projeto, e o acesso a elas é regido pela vinculação de papéis. A vinculação de papel se aplica de maneira consistente a cargas de trabalho baseadas em VM e em contêineres, independentemente 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 os projetos 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 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 para 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 permitir
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 que o Backend Project permita 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 é possível 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 desenvolvimento de software
Para cada carga de trabalho, recomendamos criar projetos separados para cada ambiente de desenvolvimento de software. Um ambiente de desenvolvimento de software é uma área no universo do GDC destinada a todas as operações que correspondem a uma fase designada do ciclo de vida. Por exemplo, você pode ter ambientes de desenvolvimento de software para teste, desenvolvimento e produção. Ao separar seus ambientes de desenvolvimento de software, é possível definir vinculações de papéis e políticas de rede de maneira granular, para que as alterações feitas em um projeto usado para um ambiente que não seja de produção não afetem 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, é possível 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 de locatário rígido porque as vinculações de papéis 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.