Esta página explica a multilocatário de clusters no Google Kubernetes Engine (GKE). Isto inclui clusters partilhados por diferentes utilizadores numa única organização e clusters partilhados por instâncias por cliente de uma aplicação de software como serviço (SaaS). A multi-posse de clusters é uma alternativa à gestão de muitos clusters de posse única.
Esta página também resume as funcionalidades do Kubernetes e do GKE que podem ser usadas para gerir clusters multiinquilinos.
O que é a multi-posse?
Um cluster multi-inquilino é partilhado por vários utilizadores e/ou cargas de trabalho que são denominados "inquilinos". Os operadores de clusters multi-inquilinos têm de isolar os inquilinos uns dos outros para minimizar os danos que um inquilino comprometido ou malicioso pode causar ao cluster e a outros inquilinos. Além disso, os recursos do cluster têm de ser atribuídos de forma justa entre os inquilinos.
Quando planeia uma arquitetura multi-inquilino, deve considerar as camadas de isolamento de recursos no Kubernetes: cluster, espaço de nomes, nó, Pod e contentor. Também deve considerar as implicações de segurança da partilha de diferentes tipos de recursos entre inquilinos. Por exemplo, agendar pods de diferentes inquilinos no mesmo nó pode reduzir o número de máquinas necessárias no cluster. Por outro lado, pode ter de impedir a colocação conjunta de determinadas cargas de trabalho. Por exemplo, pode não permitir que código não fidedigno de fora da sua organização seja executado no mesmo nó que os contentores que processam informações confidenciais.
Embora o Kubernetes não possa garantir um isolamento perfeitamente seguro entre inquilinos, oferece funcionalidades que podem ser suficientes para exemplos de utilização específicos. Pode separar cada inquilino e os respetivos recursos do Kubernetes nos seus próprios namespaces. Em seguida, pode usar políticas para aplicar o isolamento de inquilinos. Normalmente, as políticas têm âmbito definido pelo espaço de nomes e podem ser usadas para restringir o acesso à API, limitar a utilização de recursos e restringir o que os contentores podem fazer.
Os inquilinos de um cluster com vários inquilinos partilham:
- Extensões, controladores, suplementos e definições de recursos personalizados (CRDs).
- O painel de controlo do cluster. Isto implica que as operações, a segurança e a auditoria do cluster estão centralizadas.
A gestão de um cluster multi-inquilino tem várias vantagens em relação à gestão de vários clusters de inquilino único:
- Despesas gerais de gestão reduzidas
- Redução da fragmentação de recursos
- Não é preciso esperar pela criação de clusters para novos inquilinos
Exemplos de utilização de multi-tenancy
Esta secção descreve como pode configurar um cluster para vários exemplos de utilização de multi-inquilinos.
Multi-inquilino empresarial
Num ambiente empresarial, os inquilinos de um cluster são equipas distintas na organização. Normalmente, cada inquilino tem um espaço de nomes correspondente. Os modelos alternativos de multi-tenancy com um inquilino por cluster ou um inquilino por Trusted Cloud projeto são mais difíceis de gerir. O tráfego de rede num espaço de nomes não tem restrições. O tráfego de rede entre espaços de nomes tem de ser explicitamente permitido. Estas políticas podem ser aplicadas através da política de rede do Kubernetes.
Os utilizadores do cluster estão divididos em três funções diferentes, consoante o respetivo privilégio:
- Administrador do cluster
- Esta função destina-se aos administradores de todo o cluster, que gerem todos os inquilinos. Os administradores de clusters podem criar, ler, atualizar e eliminar qualquer objeto de política. Podem criar espaços de nomes e atribuí-los a administradores de espaços de nomes.
- Administrador do espaço de nomes
- Esta função destina-se a administradores de inquilinos únicos específicos. Um administrador do espaço de nomes pode gerir os utilizadores no respetivo espaço de nomes.
- Programador
- Os membros desta função podem criar, ler, atualizar e eliminar objetos não relacionados com políticas com espaços de nomes, como pods, tarefas e entradas. Os programadores só têm estes privilégios nos espaços de nomes aos quais têm acesso.
Para informações sobre a configuração de vários clusters multi-inquilinos para uma organização empresarial, consulte o artigo Práticas recomendadas para multi-inquilinos empresariais.
Vários inquilinos do fornecedor de SaaS
Os inquilinos do cluster de um fornecedor de SaaS são as instâncias por cliente da aplicação e o plano de controlo do SaaS. Para tirar partido das políticas com âmbito de espaço de nomes, as instâncias da aplicação devem ser organizadas nos seus próprios espaços de nomes, tal como os componentes do plano de controlo do SaaS. Os utilizadores finais não podem interagir diretamente com o plano de controlo do Kubernetes. Em vez disso, usam a interface do SaaS, que, por sua vez, interage com o plano de controlo do Kubernetes.
Por exemplo, uma plataforma de blogues pode ser executada num cluster multi-inquilino. Neste caso, os inquilinos são a instância do blogue de cada cliente e o plano de controlo da própria plataforma. O plano de controlo da plataforma e cada blogue alojado seriam executados em namespaces separados. Os clientes criavam e eliminavam blogues, e atualizavam as versões do software de blogging através da interface da plataforma sem visibilidade sobre o funcionamento do cluster.
Aplicação da política de multi-tenancy
O GKE e o Kubernetes oferecem várias funcionalidades que podem ser usadas para gerir clusters multiinquilinos. As secções seguintes apresentam uma vista geral destas funcionalidades.
Controlo de acesso
O GKE tem dois sistemas de controlo de acesso: gestão de identidade e de acesso (IAM) e controlo de acesso baseado em funções (CABF). O IAM é o sistema de controlo de acesso da Trusted Cloud para gerir a autenticação e a autorização dos recursos Trusted Cloud. Usa o IAM para conceder aos utilizadores acesso ao GKE e aos recursos do Kubernetes. O RBAC está integrado no Kubernetes e concede autorizações detalhadas para recursos e operações específicos nos seus clusters.
Consulte a vista geral do controlo de acesso para mais informações acerca destas opções e quando usar cada uma.
Consulte o guia de instruções do CABF e o guia de instruções do IAM para saber como usar estes sistemas de controlo de acesso.
Pode usar as autorizações de IAM e CABF juntamente com os espaços de nomes para restringir as interações dos utilizadores com os recursos do cluster na Trusted Cloud consola. Para mais informações, consulte o artigo Ative o acesso e veja os recursos do cluster por espaço de nomes.Políticas de Rede
As políticas de rede dão-lhe o controlo sobre a comunicação entre os pods do seu cluster. As políticas especificam os espaços de nomes, as etiquetas e os intervalos de endereços IP com os quais um Pod pode comunicar.
Consulte o procedimento da política de rede para obter instruções sobre como ativar a aplicação da política de rede no GKE.
Siga o tutorial sobre a política de rede para saber como escrever políticas de rede.
Quotas de recursos
As quotas de recursos gerem a quantidade de recursos usados pelos objetos num espaço de nomes. Pode definir quotas em termos de utilização de CPU e memória ou em termos de contagens de objetos. As quotas de recursos permitem garantir que nenhum inquilino usa mais do que a respetiva parte atribuída dos recursos do cluster.
Consulte a documentação sobre as quotas de recursos para mais informações.
Controlo de acesso de Pods baseado em políticas
Para impedir que os pods que violam os seus limites de segurança sejam executados no cluster, use um controlador de admissão. Os controladores de admissão podem verificar as especificações dos pods em relação às políticas que definir e podem impedir que os pods que violem essas políticas sejam executados no seu cluster.
O GKE suporta os seguintes tipos de controlo de admissão:
- Policy Controller: Declare políticas predefinidas ou personalizadas e aplique-as em clusters em grande escala usando frotas. O Policy Controller é uma implementação do agente de políticas abertas Gatekeeper de código aberto e é uma funcionalidade do GKE Enterprise.
- Controlador de admissão PodSecurity: Aplique políticas predefinidas que correspondam às normas de segurança de pods em clusters individuais ou em espaços de nomes específicos.
Antiafinidade de agrupamentos
Pode usar a antiafinidade de pods
para impedir que os pods de diferentes inquilinos sejam agendados no mesmo nó.
As restrições de antiafinidade baseiam-se em etiquetas de pods.
Por exemplo, a especificação do Pod abaixo descreve um Pod com a etiqueta "team":
"billing" e uma regra de antiafinidade que impede que o Pod seja agendado juntamente com Pods sem a etiqueta.
apiVersion: v1
kind: Pod
metadata:
name: bar
labels:
team: "billing"
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: "kubernetes.io/hostname"
labelSelector:
matchExpressions:
- key: "team"
operator: NotIn
values: ["billing"]
A desvantagem desta técnica é que os utilizadores maliciosos podem contornar a regra aplicando a etiqueta team: billing a um pod arbitrário. A antiafinidade de pods, por si só, não pode aplicar a política de forma segura em clusters com inquilinos não fidedignos.
Consulte a documentação de antiafinidade de pods para mais informações.
Nós dedicados com taints e tolerations
As exclusões de nós são outra forma de controlar o agendamento de cargas de trabalho. Pode usar taints de nós para reservar nós especializados para utilização por determinados inquilinos. Por exemplo, pode dedicar nós equipados com GPU aos inquilinos específicos cujas cargas de trabalho requerem GPUs. Para clusters do Autopilot, as tolerâncias de nós só são suportadas para separação de cargas de trabalho. As exclusões de nós são adicionadas automaticamente pelo aprovisionamento automático de nós, conforme necessário.
Para dedicar um node pool a um determinado inquilino, aplique uma mancha com effect: "NoSchedule" ao node pool. Em seguida, apenas os pods com uma tolerância correspondente podem ser agendados para nós no conjunto de nós.
A desvantagem desta técnica é que os utilizadores maliciosos podem adicionar uma tolerância aos respetivos pods para obterem acesso ao conjunto de nós dedicado. As manchas e as tolerâncias de nós, por si só, não podem aplicar a política de forma segura em clusters com inquilinos não fidedignos.
Para mais informações, consulte o artigo Taints and Tolerations na documentação do Kubernetes.