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 finalidade da hierarquia de recursos do GDC é dupla:
- 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 da 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 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 sobre como organizar os serviços e as 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 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 projeto como pais.
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 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ç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 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 partilhados numa organização. A igualdade de espaço de nomes considera todos os espaços de nomes de um determinado nome como 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 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 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 do espaço de nomes aplica-se ao espaço de nomes do projeto nestes clusters partilhados. 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 partilhado
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.
Um cluster partilhado é uma configuração de cluster com âmbito organizacional e tem de ser anexado a um ou mais projetos. O cluster padrão é outra configuração de cluster que opera apenas num único projeto, mas é considerada um recurso de serviço na hierarquia de recursos. Estas configurações de cluster 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 da carga de trabalho do contentor, consulte o artigo Conceba a separação da carga de trabalho.
Para mais informações sobre os diferentes tipos de clusters no GDC, consulte as configurações de clusters do Kubernetes.
Os clusters partilhados 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 partilhados 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 contentorizadas. 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 o artigo Vista geral do cluster do Kubernetes.
Recurso de serviço
Os recursos de serviço incluem muitas entidades, como:
- VMs
- Clusters padrão do Kubernetes
- 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 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 por zona, 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.