Este documento apresenta as práticas recomendadas para a criação da hierarquia e da separação de cargas de trabalho no Google Distributed Cloud (GDC) air-gapped com organizações, projetos e clusters do Kubernetes. Estas orientações equilibram a utilização eficiente de recursos, o isolamento de cargas de trabalho e a facilidade de operações.
Crie organizações para o 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 granular 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 identidade e acesso 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 a rede, o armazenamento e outros serviços. Os utilizadores numa organização não têm acesso a recursos noutra organização, a menos que lhes seja concedido acesso explicitamente. A conectividade de rede de uma organização para outra não é permitida por predefinição, 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 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 requerem 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 conectividade entre cargas de trabalho ou uma ferramenta de monitorização partilhada.
- As cargas de trabalho podem partilhar uma raiz de confiança administrativa. O mesmo administrador pode ser fidedigno com 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 a responsabilidade pelos orçamentos das cargas de trabalho no agregado. Para ver detalhes sobre a visualização dos custos agregados da organização ou a análise granular por carga de trabalho, consulte a página Faturação.
- Os requisitos de disponibilidade das cargas de trabalho têm de seguir os requisitos de elevada disponibilidade para a distância entre zonas.
Crie projetos para o isolamento lógico entre cargas de trabalho
Numa organização, recomendamos que aprovisione vários projetos para criar uma separação lógica entre recursos. Os projetos na mesma organização podem partilhar a infraestrutura física subjacente, mas 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 criar limites de projetos, pense no maior conjunto de funcionalidades que podem ser partilhadas pelos recursos, como associações de funções, políticas de rede, ou requisitos de visibilidade. 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 numa organização. Embora um espaço de nomes esteja reservado em vários clusters, isso não significa que um pod seja agendado automaticamente em todos os clusters. Um pod agendado para um determinado cluster 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 quer os recursos sejam implementados ou não no mesmo cluster.
Também pode definir um recurso personalizado ProjectNetworkPolicy para 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
ProjectNetworkPolicy recurso personalizado 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 em 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 desenvolvimento de software é uma área no seu universo do 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 granular, 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 granular. Num projeto, concede associações de funções granulares para permitir que os programadores individuais acedam a alguns, mas não a todos os recursos no projeto. Por exemplo, uma equipa pode ter um administrador de base de dados que tem de gerir a base de dados, mas não modificar outros recursos, enquanto os programadores de software na 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, 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 abrange vários projetos.