Neste documento, descrevemos a hierarquia de recursos isolados do Google Distributed Cloud (GDC) e como os recursos são gerenciados em uma instância isolada. Para conceitos sobre gerenciamento de recursos em várias zonas, consulte a Visão geral multizona.
O objetivo da hierarquia de recursos do GDC é duplo:
- Fornecer uma hierarquia de propriedade, que vincula o ciclo de vida de um recurso ao próprio pai imediato na hierarquia.
- Fornecer pontos de conexão e herança para controle de acesso e políticas da organização.
A hierarquia de recursos do GDC se parece com o sistema de arquivos encontrado em sistemas operacionais como uma forma de organizar e gerenciar entidades hierarquicamente. Em geral, cada recurso tem exatamente um pai. Essa organização hierárquica de recursos permite definir políticas de controle de acesso, como o Identity and Access Management (IAM), que são herdadas pelos recursos filhos.
Para mais informações sobre práticas recomendadas para organizar seus limites de acesso, consulte Projetar limites de acesso entre recursos.
Estrutura de recursos em detalhes
As entidades a seguir são tipos de recursos reconhecidos na hierarquia de recursos do GDC:
Os recursos do GDC são organizados hierarquicamente. A maioria dos recursos na hierarquia tem exatamente um pai. A exceção se aplica apenas ao recurso de nível mais alto. 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 topo da hierarquia de recursos do GDC, e todos os recursos que pertencem a uma organização são agrupados no recurso da organização. Isso proporciona visibilidade e controle centralizados sobre todos os recursos dessa organização.
Os projetos e clusters têm escopo da organização. Eles podem ser anexados uns aos outros para organizar recursos de serviço. No entanto, projetos e clusters funcionam de forma independente. Essa flexibilidade oferece muitas opções diferentes de como organizar serviços e cargas de trabalho. Por exemplo, você 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 precisam pertencer a um projeto ou cluster e não podem ser compartilhadas entre projetos ou clusters. Exemplos de recursos de serviço incluem máquinas virtuais (VMs), bancos de dados, buckets de armazenamento e backups. A maioria desses recursos de nível inferior tem recursos de projeto como principais.
O diagrama a seguir representa um exemplo de hierarquia de recursos do GDC:
Para mais informações sobre práticas recomendadas para organizar sua hierarquia de recursos e otimizar o gerenciamento de carga de trabalho, consulte Projetar a separação de carga de trabalho do usuário.
Organização
O recurso de organização representa uma unidade administrativa ou uma função comercial, 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 recursos de infraestrutura a serem administrados juntos para que os usuários possam implantar cargas de trabalho de aplicativos. As organizações são globais e abrangem todas as zonas em um universo. Em uma 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, e não aos criadores deles. Isso significa que nenhum tipo de recurso de uma organização será excluído se o usuário que o criou sair da organização. Em vez disso, todos os tipos de recursos seguem o ciclo de vida da organização no GDC.
As políticas de controle de acesso do IAM aplicadas ao recurso organização são válidas para toda a hierarquia em todos os recursos da organização. Para mais informações sobre como conceder políticas e permissões em toda a organização, consulte as seções Políticas da organização e IAM.
Projeto
Um projeto é uma unidade de locação que todos os serviços precisam integrar. Os projetos oferecem agrupamento lógico de recursos de serviço. Os projetos são globais e abrangem todas as zonas de um universo.
Os projetos permitem a segmentação de recursos de serviço em uma organização e fornecem um ciclo de vida e um limite de política para gerenciar recursos. Os recursos de serviço em um projeto nunca podem sobreviver ao projeto em si nem ser movidos entre projetos, garantindo que o controle esteja disponível durante a vida útil de um recurso. Portanto, é necessário implantar recursos de qualquer tipo em um namespace do projeto.
Um projeto é considerado um namespace adequado do Kubernetes que abrange vários clusters em uma organização. A semelhança de namespace considera todos os namespaces de um determinado nome como o mesmo namespace para todos os clusters na mesma organização. O namespace único tem um proprietário consistente em todo o conjunto de clusters. Os provedores de serviços criam serviços no escopo do projeto criando componentes de plano de controle e plano de dados no namespace.
O namespace de um projeto hospeda o seguinte:
- APIs de serviço no escopo do projeto.
- Configurações de política no nível do projeto, como papéis e vinculações de papéis.
É possível anexar um projeto a apenas um subconjunto de clusters em uma organização. É possível implantar cargas de trabalho conteinerizadas nesses clusters em um namespace do projeto. O conceito de semelhança de namespace se aplica ao namespace do projeto nesses clusters. As políticas no escopo do namespace, como as de acesso baseado em papéis (RBAC), são aplicadas a todos esses namespaces.
Para mais informações sobre projetos, consulte a Visão geral de projetos.
Cluster do Kubernetes
Um cluster do Kubernetes é um conjunto de nós que executam cargas de trabalho em contêineres como parte do GKE no GDC. É possível provisionar clusters do Kubernetes para atender aos requisitos de computação dos seus aplicativos. Os clusters têm escopo de organização e precisam ser anexados a um ou mais projetos.
Os clusters subdividem os recursos de infraestrutura em pools isolados para serem consumidos por projetos em uma organização. Os clusters também são separados logicamente para oferecer diferentes domínios de falha e garantias de isolamento. A aplicação de políticas por organização garante que os clusters possam ser compartilhados entre equipes e usuários, mantendo o desempenho e as garantias de recursos. Além disso, as políticas da organização permitem que as cargas de trabalho de VM sejam executadas ao lado das cargas de trabalho de contêiner sem introduzir complexidade operacional.
Os clusters são úteis para instâncias em que é necessário implantar cargas de trabalho em contêiner. No entanto, com a opção de implantar cargas de trabalho baseadas em VM, 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 em uma implantação multizonal, é necessário implantar manualmente clusters em cada zona.
Para mais informações sobre clusters do Kubernetes, consulte a seção Gerenciar clusters do Kubernetes.
Recurso de serviço
Os recursos de serviço incluem muitas entidades, como:
- VMs
- Bancos de dados
- Buckets de armazenamento
- Cargas de trabalho em contêineres
- Backups
Os recursos de serviço precisam pertencer a um projeto ou, opcionalmente, a um cluster para cargas de trabalho em contêineres, e não podem ser compartilhados entre projetos. Isso significa que os recursos de serviço em um projeto nunca podem sobreviver ao próprio projeto, garantindo que o controle esteja disponível durante a vida útil do recurso.
Os recursos de serviço podem ser implantados globalmente ou por zona, dependendo do tipo. Consulte a documentação do serviço específico para informações sobre opções de implantação em várias zonas. Os recursos de serviço são ativados por padrão e podem ser desativados usando uma política da organização.