Hierarquia de recursos

Este documento descreve a hierarquia de recursos isolada do Google Distributed Cloud (GDC) e como os recursos são geridos numa instância isolada. Para ver conceitos sobre a gestão de recursos em várias zonas, consulte a Vista geral de várias zonas.

A hierarquia de recursos do GDC tem dois objetivos:

  • Fornece uma hierarquia de propriedade que vincula o ciclo de vida de um recurso ao respetivo superior imediato na hierarquia.
  • Fornecer pontos de ligação e herança para controlo de acesso e políticas de organização.

A hierarquia de recursos da GDC assemelha-se ao sistema de ficheiros encontrado nos sistemas operativos como uma forma de organizar e gerir entidades hierarquicamente. Geralmente, cada recurso tem exatamente um recurso principal. Esta organização hierárquica de recursos permite-lhe definir políticas de controlo de acesso, como a gestão de identidade e de acesso (IAM), que são herdadas pelos recursos subordinados.

Para mais informações sobre as práticas recomendadas para organizar os limites de acesso, consulte o artigo Crie limites de acesso entre recursos.

Estrutura de recursos em detalhe

As seguintes entidades são tipos de recursos reconhecidos na hierarquia de recursos do GDC:

Os recursos do GDC estão organizados hierarquicamente. A maioria dos recursos na hierarquia de recursos tem exatamente um recurso principal. A exceção aplica-se apenas ao recurso de nível mais elevado. No nível mais baixo, os recursos de serviço são os componentes fundamentais que constituem todos os serviços da GDC.

Uma organização está no topo da hierarquia de recursos da GDC e todos os recursos que pertencem a uma organização estão agrupados no recurso da organização. Isto oferece visibilidade e controlo centralizados sobre todos os recursos pertencentes a uma organização.

Os projetos e os clusters têm âmbito organizacional. Podem ser anexados uns aos outros para organizar os recursos de serviço. No entanto, os projetos e os clusters funcionam de forma independente. Esta flexibilidade oferece muitas opções diferentes para organizar serviços e cargas de trabalho. Por exemplo, pode ter um cluster dedicado a um único projeto. Da mesma forma, um cluster pode abranger vários projetos.

Os recursos de serviço são entidades que têm de pertencer a um projeto ou a um cluster e não podem ser partilhados entre projetos ou clusters. Alguns exemplos de recursos de serviço incluem máquinas virtuais (VMs), bases de dados, contentores de armazenamento e cópias de segurança. A maioria destes recursos de nível inferior tem recursos de projeto como pais.

O diagrama seguinte representa um exemplo de hierarquia de recursos do GDC:

Hierarquia de recursos para organizações, projetos e recursos

Para mais informações sobre as práticas recomendadas para organizar a hierarquia de recursos para uma gestão ideal da carga de trabalho, consulte o artigo Conceba a separação da carga de trabalho do utilizador.

Organização

O recurso da organização representa uma unidade administrativa ou uma função empresarial, como uma empresa, e é o recurso de nível superior na hierarquia de recursos do GDC. Uma organização define um limite de segurança que envolve os recursos de infraestrutura a serem administrados em conjunto para que os utilizadores possam implementar cargas de trabalho de aplicações. As organizações são globais e abrangem todas as zonas num universo. Numa organização, os recursos de serviço, como VMs e volumes de armazenamento, são agrupados logicamente por projetos.

Todos os projetos, clusters e recursos de serviço pertencem à sua organização em vez dos respetivos criadores. Isto significa que qualquer tipo de recurso de uma organização não é eliminado se o utilizador que o criou sair da organização. Em alternativa, todos os tipos de recursos seguem o ciclo de vida da organização no GDC.

As políticas de controlo de acesso do IAM aplicadas ao recurso da organização aplicam-se a toda a hierarquia em todos os recursos da organização. Para mais informações sobre a concessão de políticas e autorizações ao nível da organização, consulte as secções Políticas da organização e IAM.

Projeto

Um projeto é uma unidade de arrendamento que todos os serviços têm de integrar. Os projetos oferecem um agrupamento lógico de recursos de serviços. Os projetos são globais e abrangem todas as zonas num universo.

Os projetos permitem a segmentação dos recursos de serviço numa organização e fornecem um ciclo de vida e um limite de políticas para a gestão de recursos. Os recursos de serviço num projeto nunca podem sobreviver ao próprio projeto nem mover-se entre projetos, o que garante que o controlo está disponível durante a vida útil de um recurso. Por isso, tem de implementar recursos de qualquer tipo num espaço de nomes do projeto.

Um projeto é considerado um espaço de nomes do Kubernetes adequado que abrange vários clusters numa organização. A igualdade de espaços de nomes considera todos os espaços de nomes de um determinado nome o mesmo espaço de nomes para todos os clusters na mesma organização. O único espaço de nomes tem um proprietário consistente no conjunto de clusters. Os fornecedores de serviços criam serviços com âmbito do projeto criando componentes do plano de controlo e do plano de dados no espaço de nomes.

O espaço de nomes de um projeto aloja o seguinte:

  • APIs de serviços com âmbito de projeto.
  • Configurações de políticas ao nível do projeto, como funções e associações de funções.

Só pode anexar um projeto a um subconjunto de clusters numa organização. Pode implementar cargas de trabalho em contentores nestes clusters num espaço de nomes do projeto. O conceito de igualdade do espaço de nomes aplica-se ao espaço de nomes do projeto nestes clusters. As políticas com âmbito de espaço de nomes, como as políticas de acesso baseadas em funções (RBAC), aplicam-se a todos esses espaços de nomes.

Para mais informações sobre projetos, consulte a Vista geral dos projetos.

Cluster do Kubernetes

Um cluster do Kubernetes é um conjunto de nós que executam cargas de trabalho contentorizadas como parte do GKE no GDC. Pode aprovisionar clusters do Kubernetes para suportar os requisitos de computação das suas aplicações. Os clusters têm âmbito organizacional e têm de estar anexados a um ou mais projetos.

Hierarquia de recursos com um cluster que abrange dois projetos

Os clusters subdividem os recursos de infraestrutura em pools isolados para serem consumidos por projetos numa organização. Os clusters também estão logicamente separados uns dos outros para oferecer diferentes domínios de falhas e garantias de isolamento. A aplicação de políticas por organização garante que os clusters podem ser partilhados entre equipas e utilizadores, ao mesmo tempo que mantém o desempenho e as garantias de recursos. Além disso, as políticas da organização permitem que as cargas de trabalho de VMs sejam executadas juntamente com as cargas de trabalho de contentores sem introduzir complexidade operacional.

Os clusters são benéficos para instâncias em que tem de implementar cargas de trabalho em contentores. No entanto, com a opção de implementar cargas de trabalho baseadas em VMs, a existência de um cluster do Kubernetes não é necessária no GDC.

Os clusters são um recurso zonal e não podem abranger várias zonas. Para operar clusters numa implementação de várias zonas, tem de implementar manualmente clusters em cada zona.

Para mais informações sobre clusters do Kubernetes, consulte a secção Faça a gestão de clusters do Kubernetes.

Recurso de serviço

Os recursos de serviço incluem muitas entidades, como:

  • VMs
  • Bases de dados
  • Contentores de armazenamento
  • Cargas de trabalho contentorizadas
  • Cópias de segurança

Os recursos de serviço têm de pertencer a um projeto ou, opcionalmente, a um cluster para cargas de trabalho em contentores e não podem ser partilhados entre projetos. Isto significa que os recursos de serviço num projeto nunca podem sobreviver ao próprio projeto, o que garante que o controlo está disponível durante a vida útil do recurso.

Os recursos de serviço podem ser implementados globalmente ou por zonas, consoante o tipo. Consulte a documentação do serviço específico para obter informações sobre as opções de implementação em várias zonas. Os recursos de serviço estão ativados por predefinição e podem ser desativados através de uma política da organização.