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:
- Fornecer 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 da organização.
A hierarquia de recursos do 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 superior. Esta organização hierárquica de recursos permite-lhe definir políticas de controlo de acesso, como a Gestão de identidade e 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 dos 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 superior. 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 compõem todos os serviços do GDC.
Uma organização é o nível superior da hierarquia de recursos do GDC, e todos os recursos que pertencem a uma organização são agrupados no recurso da organização. Isto oferece visibilidade e controlo centralizados sobre todos os recursos que pertencem a uma organização.
Os projetos e os clusters do Kubernetes partilhados têm âmbito da organização. Podem ser anexados uns aos outros para organizar os recursos de serviço. No entanto, os projetos e os clusters partilhados 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 partilhado dedicado a um único projeto. Da mesma forma, um cluster partilhado pode abranger vários projetos.
Os recursos de serviço são entidades que têm de pertencer a um projeto e não podem ser partilhadas entre projetos. Exemplos de recursos de serviço incluem máquinas virtuais (VMs), clusters do Kubernetes padrão, bases de dados, contentores de armazenamento e cópias de segurança. A maioria destes recursos de nível inferior tem recursos de projetos como superiores.
O diagrama seguinte representa um exemplo de hierarquia de recursos do GDC:
Para mais informações sobre as práticas recomendadas para organizar a hierarquia de recursos para uma gestão ideal das cargas de trabalho, consulte o artigo Crie a separação das cargas de trabalho dos utilizadores.
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 inclui 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 de aos respetivos criadores. Isto significa que um 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 da IAM aplicadas ao recurso da organização aplicam-se em toda a hierarquia a 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ço. Os projetos são globais e abrangem todas as zonas num universo.
Os projetos permitem a segmentação de recursos de serviço numa organização e oferecem 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 conseguinte, 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 partilhados 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 partilhados na mesma organização. O espaço de nomes único tem um proprietário consistente no conjunto de clusters partilhados. Os fornecedores de serviços criam serviços com âmbito do projeto através da criação de 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 do projeto.
- Configurações de políticas ao nível do projeto, como funções e vinculações de funções.
Só pode anexar um projeto a um subconjunto de clusters partilhados numa organização. Pode implementar cargas de trabalho em contentores nestes clusters partilhados num espaço de nomes do projeto. O conceito de igualdade de espaços de nomes aplica-se ao espaço de nomes do projeto nestes clusters partilhados. As políticas com âmbito do espaço de nomes, como as políticas de acesso baseado 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 partilhado
Um cluster do Kubernetes é um conjunto de nós que executam cargas de trabalho em contentores como parte do GKE no GDC. Pode aprovisionar clusters do Kubernetes para suportar os requisitos de computação das suas aplicações.
Um cluster partilhado é uma configuração de cluster com âmbito da organização e tem de ser anexado a um ou mais projetos. O cluster padrão é outra configuração de cluster que funciona apenas num único projeto, mas é considerado um recurso de serviço na hierarquia de recursos. Estas configurações de clusters do Kubernetes foram concebidas para criar uma arquitetura do Kubernetes que oferece opções de gestão de contentores em ambientes de desenvolvimento de software, como para testes, desenvolvimento e produção. Para mais informações sobre as práticas recomendadas de separação de cargas de trabalho em contentores, consulte o artigo Crie a separação das cargas de trabalho.
Para mais informações sobre os diferentes tipos de clusters no GDC, consulte Configurações de clusters do Kubernetes.
Os clusters partilhados subdividem os recursos de infraestrutura em agrupamentos isolados a serem consumidos por projetos numa organização. Os clusters também estão logicamente separados uns dos outros para oferecerem diferentes domínios de falha e garantias de isolamento. A aplicação de políticas por organização garante que os clusters partilhados podem ser partilhados entre equipas e utilizadores, ao mesmo tempo que mantém as garantias de desempenho e 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 apenas 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 Vista geral dos clusters do Kubernetes.
Recurso de serviço
Os recursos de serviço incluem muitas entidades, como:
- VMs
- Clusters do Kubernetes padrão
- Bases de dados
- Contentores de armazenamento
- Cargas de trabalho em contentores
- Cópias de segurança
Os recursos de serviço têm de pertencer a um projeto e não podem ser partilhados entre projetos. Este ciclo de vida específico do projeto 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 zonalmente, consoante o tipo. Consulte a documentação do serviço específico para ver informações sobre as opções de implementação de 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.