Práticas recomendadas para a multilocação empresarial

A multi-tenancy no Google Kubernetes Engine (GKE) refere-se a um ou mais clusters que são partilhados entre inquilinos. No Kubernetes, um inquilino pode ser definido como qualquer uma das seguintes opções:

• Uma equipa responsável pelo desenvolvimento e funcionamento de uma ou mais cargas de trabalho.
• Um conjunto de cargas de trabalho relacionadas, quer sejam operadas por uma ou mais equipas.
• Uma única carga de trabalho, como uma implementação.

A multi-posse de clusters é frequentemente implementada para reduzir os custos ou aplicar de forma consistente as políticas de administração em todos os inquilinos. No entanto, a configuração incorreta de um cluster do GKE ou dos respetivos recursos do GKE associados pode resultar em poupanças de custos não alcançadas, aplicação incorreta de políticas ou interações destrutivas entre as cargas de trabalho de diferentes inquilinos.

Este guia fornece práticas recomendadas para configurar de forma segura e eficiente vários clusters multi-inquilinos para uma organização empresarial.

Pressupostos e requisitos

As práticas recomendadas neste guia baseiam-se num exemplo de utilização multi-inquilino para um ambiente empresarial, que tem as seguintes pressuposições e requisitos:

• A organização é uma única empresa que tem vários inquilinos (duas ou mais equipas de aplicações/serviços) que usam o Kubernetes e gostariam de partilhar recursos de computação e administrativos.
• Cada inquilino é uma única equipa que desenvolve uma única carga de trabalho.
• Além das equipas de aplicações/serviços, existem outras equipas que também utilizam e gerem clusters, incluindo membros da equipa da plataforma, administradores de clusters, auditores, etc.
• A equipa da plataforma é proprietária dos clusters e define a quantidade de recursos que cada equipa de inquilino pode usar. Cada inquilino pode pedir mais.
• Cada equipa de inquilinos deve poder implementar a respetiva aplicação através da API Kubernetes sem ter de comunicar com a equipa da plataforma.
• Cada inquilino não deve poder afetar outros inquilinos no cluster partilhado, exceto através de decisões de design explícitas, como chamadas API, origens de dados partilhadas, etc.

Esta configuração vai servir como modelo a partir do qual podemos demonstrar as práticas recomendadas de multi-inquilino. Embora esta configuração possa não descrever perfeitamente todas as organizações empresariais, pode ser facilmente expandida para abranger cenários semelhantes.

Configurar pastas, projetos e clusters

Para as organizações empresariais que implementam clusters multi-inquilinos no GKE, é necessária uma configuração adicional noutrosTrusted Cloud sistemas para gerir a complexidade que não existe em implementações do Kubernetes mais simples de uma única aplicação e uma única equipa. Isto inclui a configuração do projeto para isolar as preocupações administrativas, bem como o mapeamento da estrutura da organização para identidades e contas na nuvem, e a gestão de Trusted Cloud recursos adicionais, como bases de dados, registo e monitorização, armazenamento e redes.

Estabeleça uma hierarquia de pastas e projetos

Para captar a forma como a sua organização gere os Trusted Cloud recursos e para aplicar uma separação de responsabilidades, use pastas e projetos. As pastas permitem que diferentes equipas definam políticas que se aplicam em cascata a vários projetos, enquanto os projetos podem ser usados para segregar ambientes (por exemplo, produção vs. preparação) e equipas entre si. Por exemplo, a maioria das organizações tem uma equipa para gerir a infraestrutura de rede e uma equipa diferente para gerir clusters. Cada tecnologia é considerada uma parte separada da pilha que requer o seu próprio nível de conhecimentos, resolução de problemas e acesso.

Uma pasta principal pode conter até 300 pastas, e pode aninhar pastas até 10 níveis de profundidade. Se tiver mais de 300 inquilinos, pode organizá-los em hierarquias aninhadas para se manter dentro do limite. Para mais informações sobre pastas, consulte o artigo Criar e gerir pastas.

Atribua funções através da IAM

Pode controlar o acesso aos Trusted Cloud recursos através de políticas de IAM. Comece por identificar os grupos necessários para a sua organização e o respetivo âmbito de operações. Em seguida, atribua a função do IAM adequada ao grupo.

Centralize o controlo da rede

Para manter o controlo centralizado sobre os recursos de rede, como sub-redes, trajetos e firewalls, use redes VPC partilhadas. Os recursos numa VPC partilhada podem comunicar entre si de forma segura e eficiente nos limites do projeto através de IPs internos. Cada rede de VPC partilhada é definida e detida por um projeto anfitrião centralizado e pode ser usada por um ou mais projetos de serviço.

Com a VPC partilhada e a IAM, pode separar a administração da rede da administração do projeto. Esta separação ajuda a implementar o princípio do menor privilégio. Por exemplo, uma equipa de rede centralizada pode administrar a rede sem ter autorizações nos projetos participantes. Da mesma forma, os administradores do projeto podem gerir os recursos do respetivo projeto sem autorizações para manipular a rede partilhada.

Quando configura uma VPC partilhada, tem de configurar as sub-redes e os respetivos intervalos de IP secundários na VPC. Para determinar o tamanho da sub-rede, tem de saber o número esperado de inquilinos, o número de pods e serviços que se espera que executem, bem como o tamanho máximo e médio dos pods. O cálculo da capacidade total do cluster necessária permite compreender o tamanho da instância desejado e fornece o número total de nós. Com o número total de nós, é possível calcular o espaço de IP total consumido, o que pode fornecer o tamanho da sub-rede desejado.

Seguem-se alguns fatores que também deve ter em conta ao configurar a sua rede:

• O número máximo de projetos de serviço que podem ser anexados a um projeto anfitrião é 1000 e o número máximo de projetos anfitriões de VPC partilhada numa única organização é 100.
• Os intervalos de IPs dos nós, dos pods e dos serviços têm de ser únicos. Não é possível criar uma sub-rede cujos intervalos de endereços IP principal e secundário se sobreponham.
• O número máximo de pods e serviços para um determinado cluster do GKE é limitado pelo tamanho dos intervalos secundários do cluster.
• O número máximo de nós no cluster é limitado pelo tamanho do intervalo de endereços IP principal da sub-rede do cluster e do intervalo de endereços do pod do cluster.
• Para ter flexibilidade e mais controlo sobre a gestão de endereços IP, pode configurar o número máximo de pods que podem ser executados num nó. Ao reduzir o número de agrupamentos por nó, também reduz o intervalo CIDR atribuído por nó, o que requer menos endereços IP.

Para obter informações sobre os intervalos de rede num cluster de VPC, consulte o artigo Criar um cluster nativo de VPC.

Os inquilinos que requerem um maior isolamento para recursos executados fora dos clusters partilhados (como VMs do Compute Engine dedicadas) podem usar a sua própria VPC, que está interligada à VPC partilhada executada pela equipa de rede. Isto oferece segurança adicional à custa de uma maior complexidade e várias outras limitações. Para mais informações sobre o intercâmbio, consulte o artigo Usar o intercâmbio da rede da VPC. No exemplo abaixo, todos os inquilinos optaram por partilhar uma única VPC de inquilino (por ambiente).

Criar clusters fiáveis e de alta disponibilidade

Crie a arquitetura do cluster em função da alta disponibilidade e fiabilidade implementando as seguintes recomendações:

• Crie um projeto de administrador de cluster por cluster para reduzir o risco de as configurações ao nível do projeto (por exemplo, associações da IAM) afetarem negativamente muitos clusters e para ajudar a fornecer separação para a quota e a faturação. Os projetos de administrador do cluster estão separados dos projetos de inquilino, que os inquilinos individuais usam para gerir, por exemplo, os respetivos Trusted Cloud recursos.
• Configure o isolamento da rede para desativar o acesso aos nós e gerir o acesso ao plano de controlo. Também recomendamos que configure o isolamento da rede para ambientes de desenvolvimento e de preparação.
• Certifique-se de que o plano de controlo do cluster é regional para oferecer elevada disponibilidade para multi-posse. Quaisquer interrupções no plano de controlo afetam os inquilinos. Tenha em atenção que existem implicações de custos com a apresentação de clusters regionais. Os clusters do Autopilot estão pré-configurados como clusters regionais.
• Certifique-se de que os nós no seu cluster abrangem, pelo menos, três zonas para alcançar a fiabilidade zonal. Para ver informações sobre o custo de saída entre zonas na mesma região, consulte a documentação de preços de rede.

Aumente/diminua automaticamente os recursos e os nós do cluster

Para dar resposta às exigências dos seus inquilinos, dimensione automaticamente os nós no seu cluster ativando a autoscaling.

O dimensionamento automático ajuda os sistemas a parecerem responsivos e em bom estado quando cargas de trabalho pesadas são implementadas por vários inquilinos nos respetivos espaços de nomes ou a responder a interrupções zonais.

Com os clusters do Autopilot, os conjuntos de nós são dimensionados automaticamente para cumprir os requisitos das suas cargas de trabalho.

Quando ativa o dimensionamento automático, especifica o número mínimo e máximo de nós num cluster com base nos tamanhos de carga de trabalho esperados. Ao especificar o número máximo de nós, pode garantir que existe espaço suficiente para todos os pods no cluster, independentemente do espaço de nomes em que são executados. A escala automática do cluster redimensiona os conjuntos de nós com base no limite mínimo/máximo, o que ajuda a reduzir os custos operacionais quando a carga do sistema diminui e evita que os pods entrem num estado pendente quando não existem recursos de cluster disponíveis suficientes. Para determinar o número máximo de nós, identifique a quantidade máxima de CPU e memória que cada inquilino requer e some essas quantidades para obter a capacidade total que o cluster deve conseguir processar se todos os inquilinos estiverem no limite. Com o número máximo de nós, pode escolher os tamanhos e as quantidades de instâncias, tendo em consideração o espaço de sub-rede de IP disponibilizado ao cluster.

Use a escala automática de pods para dimensionar automaticamente os pods com base nas exigências de recursos. O redimensionador automático horizontal de pods (HPA) dimensiona o número de réplicas de pods com base na utilização de CPU/memória ou em métricas personalizadas. A escala automática vertical de pods (VPA) pode ser usada para dimensionar automaticamente as exigências de recursos dos pods. Não deve ser usado com o HPA, a menos que as métricas personalizadas estejam disponíveis, uma vez que os dois escaladores automáticos podem competir entre si. Por este motivo, comece com o HPA e só use o VPA mais tarde quando necessário.

Determine o tamanho do seu cluster

Ao determinar o tamanho do seu cluster, seguem-se alguns fatores importantes a ter em conta:

• O dimensionamento do cluster depende do tipo de cargas de trabalho que planeia executar. Se as suas cargas de trabalho tiverem uma densidade maior, a rentabilidade é mais elevada, mas também existe uma maior probabilidade de contenção de recursos.
• O tamanho mínimo de um cluster é definido pelo número de zonas que abrange: um nó para um cluster zonal e três nós para um cluster regional.
• Por projeto, existe um máximo de 50 clusters por zona, mais 50 clusters regionais por região.

• Por cluster, aplicam-se os seguintes valores máximos aos nós:

  • 1000 nós por node pool
  • 1000 nós por cluster (se usar o controlador GKE Ingress)
  • 5000 nós por cluster por predefinição. Pode aumentar este limite para 15 000 ou 65 000 nós. Para saber mais, consulte o artigo Clusters com mais de 5000 nós.
  • 256 pods por nó
  • 150 000 pods por cluster e 300 000 contentores por cluster

  Consulte a página Quotas e limites para ver informações adicionais.

Agende períodos de manutenção

Para reduzir os períodos de inatividade durante as atualizações e a manutenção de clusters/nós, agende períodos de manutenção para ocorrerem durante as horas de menor atividade. Durante as atualizações, podem ocorrer interrupções temporárias quando as cargas de trabalho são movidas para recriar nós. Para garantir um impacto mínimo de tais interrupções, agende atualizações para horas de menor atividade e crie as implementações das suas aplicações para processar interrupções parciais sem problemas, se possível.

Configure um balanceador de carga de aplicações externo com a entrada

Para ajudar na gestão dos serviços publicados dos seus inquilinos e na gestão do tráfego recebido para esses serviços, crie um balanceador de carga HTTP(s) para permitir uma única entrada por cluster, onde os serviços de cada inquilino estão registados no recurso Ingress do cluster. Pode criar e configurar um balanceador de carga HTTP(S) criando um recurso de entrada do Kubernetes, que define como o tráfego chega aos seus serviços e como é encaminhado para a aplicação do seu inquilino. Ao registar serviços com o recurso Ingress, a convenção de nomenclatura dos serviços torna-se consistente, mostrando um único Ingress, como tenanta.example.com e tenantb.example.com.

Proteger o cluster para multi-tenancy

Controlar a comunicação do pod com políticas de rede

Para controlar a comunicação de rede entre os pods em cada um dos espaços de nomes do cluster, crie políticas de rede com base nos requisitos dos seus inquilinos. Como recomendação inicial, deve bloquear o tráfego entre espaços de nomes que alojam as aplicações de diferentes inquilinos. O administrador do cluster pode aplicar uma deny-allpolítica de rede para negar todo o tráfego de entrada e evitar que os pods de um espaço de nomes enviem acidentalmente tráfego para serviços ou bases de dados noutros espaços de nomes.

Por exemplo, segue-se uma política de rede que restringe a entrada de todos os outros namespaces para o namespace tenant-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Execute cargas de trabalho com o GKE Sandbox

Os clusters que executam cargas de trabalho não fidedignas estão mais expostos a vulnerabilidades de segurança do que outros clusters. Com o GKE Sandbox, pode reforçar os limites de isolamento entre cargas de trabalho para o seu ambiente multi-inquilino. Para a gestão de segurança, recomendamos que comece com o GKE Sandbox e, em seguida, use controlos de admissão baseados em políticas para preencher eventuais lacunas.

O GKE Sandbox baseia-se no gVisor, um projeto de sandbox de contentores de código aberto, e oferece isolamento adicional para cargas de trabalho multi-inquilino adicionando uma camada adicional entre os contentores e o SO anfitrião. Os tempos de execução de contentores são frequentemente executados como um utilizador com privilégios no nó e têm acesso à maioria das chamadas do sistema para o kernel do anfitrião. Num cluster multi-inquilino, um inquilino malicioso pode obter acesso ao kernel do anfitrião e aos dados de outros inquilinos. O GKE Sandbox mitiga estas ameaças reduzindo a necessidade de os contentores interagirem com o anfitrião, diminuindo a superfície de ataque do anfitrião e restringindo o movimento de autores maliciosos.

O GKE Sandbox oferece dois limites de isolamento entre o contentor e o SO anfitrião:

• Um kernel de espaço do utilizador, escrito em Go, que processa chamadas do sistema e limita a interação com o kernel do anfitrião. Cada pod tem o seu próprio kernel de espaço do utilizador isolado.
• O kernel do espaço do utilizador também é executado em espaços de nomes e chamadas do sistema de filtragem seccomp.

Configure controlos de admissão baseados 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.

Use a federação de identidades da carga de trabalho para o GKE para conceder acesso a Trusted Cloud serviços

Para conceder acesso em segurança a cargas de trabalho a Trusted Cloud serviços, ative a federação de identidades da carga de trabalho para o GKE no cluster. A federação de identidades da carga de trabalho para o GKE ajuda os administradores a gerir contas de serviço do Kubernetes que as cargas de trabalho do Kubernetes usam para aceder a Trusted Cloud serviços. Quando cria um cluster com a federação de identidade da carga de trabalho para o GKE ativada, é estabelecido um espaço de nomes de identidade para o projeto no qual o cluster está alojado. O espaço de nomes de identidade permite que o cluster autentique automaticamente as contas de serviço para aplicações do GKE mapeando o nome da conta de serviço do Kubernetes para um identificador de conta de serviço Google virtual, que é usado para a associação do IAM de contas de serviço do Kubernetes de inquilinos.

Restrinja o acesso à rede ao plano de controlo

Para proteger o seu plano de controlo, restrinja o acesso a redes autorizadas. No GKE, quando ativa as redes autorizadas, pode autorizar até 50 intervalos CIDR e permitir que apenas os endereços IP nesses intervalos acedam ao seu plano de controlo. O GKE já usa o Transport Layer Security (TLS) e a autenticação para fornecer acesso seguro ao seu ponto final do plano de controlo a partir da Internet pública. Ao usar redes autorizadas, pode restringir ainda mais o acesso a conjuntos especificados de endereços IP.

Aprovisionamento de inquilinos

Crie projetos de inquilinos

Para alojar os recursos não pertencentes a clusters de um inquilino, crie um projeto de serviço para cada inquilino. Estes projetos de serviço contêm recursos lógicos específicos das aplicações do inquilino (por exemplo, registos, monitorização, contentores de armazenamento, contas de serviço, etc.). Todos os projetos de serviço de inquilino estão ligados à VPC partilhada no projeto anfitrião do inquilino.

Use o RBAC para refinar o acesso do inquilino

Defina um acesso mais detalhado aos recursos do cluster para os seus inquilinos através do CABF do Kubernetes. Além do acesso só de leitura inicialmente concedido com a IAM aos grupos de inquilinos, defina funções e associações do CABF do Kubernetes ao nível do espaço de nomes para cada grupo de inquilinos.

Anteriormente, identificámos dois grupos de inquilinos: administradores de inquilinos e programadores de inquilinos. Para esses grupos, definimos as seguintes funções e acesso RBAC:

Além de criar funções e associações de RBAC que atribuem várias autorizações a grupos do Google Workspace ou do Cloud Identity no respetivo espaço de nomes, os administradores de inquilinos precisam frequentemente da capacidade de gerir utilizadores em cada um desses grupos. Com base nos requisitos da sua organização, isto pode ser processado através da delegação de autorizações do Google Workspace ou Cloud ID ao administrador do inquilino para gerir a respetiva associação ao grupo ou através da interação do administrador do inquilino com uma equipa na sua organização que tenha autorizações do Google Workspace ou Cloud ID para processar essas alterações.

Use os Grupos Google para associar autorizações

Para gerir eficientemente as autorizações de inquilinos num cluster, pode associar autorizações de RBAC aos seus Grupos Google. A associação desses grupos é mantida pelos administradores do Google Workspace, pelo que os administradores do cluster não precisam de informações detalhadas acerca dos seus utilizadores.

Por exemplo, temos um Grupo Google denominado tenant-admins@mydomain.com e um utilizador denominado admin1@mydomain.com é membro desse grupo. A seguinte associação concede ao utilizador acesso de administrador ao espaço de nomes tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Crie espaços de nomes

Para fornecer um isolamento lógico entre inquilinos que estão no mesmo cluster, implemente namespaces. Como parte do processo RBAC do Kubernetes, o administrador do cluster cria espaços de nomes para cada grupo de inquilinos. O administrador do inquilino gere os utilizadores (programadores do inquilino) no respetivo espaço de nomes do inquilino. Os programadores de inquilinos podem, então, usar recursos específicos do cluster e do inquilino para implementar as respetivas aplicações.

Evite atingir os limites do espaço de nomes

O número máximo teórico de espaços de nomes num cluster é de 10 000, embora, na prática, existam muitos fatores que podem impedir que atinja este limite. Por exemplo, pode atingir o número máximo de pods (150 000) e nós (5000) ao nível do cluster antes de atingir o número máximo de espaços de nomes. Outros fatores (como o número de segredos) podem reduzir ainda mais os limites efetivos. Como resultado, uma boa regra geral inicial é tentar aproximar-se apenas do limite teórico de uma restrição de cada vez e manter-se aproximadamente uma ordem de magnitude afastado dos outros limites, a menos que a experimentação mostre que os seus exemplos de utilização funcionam bem. Se precisar de mais recursos do que os que podem ser suportados por um único cluster, deve criar mais clusters. Para ver informações sobre a escalabilidade do Kubernetes, consulte o artigo Limites de escalabilidade do Kubernetes.

Padronize a nomenclatura do espaço de nomes

Para facilitar as implementações em vários ambientes alojados em diferentes clusters, standardize a convenção de nomenclatura do espaço de nomes que usa. Por exemplo, evite associar o nome do ambiente (desenvolvimento, teste e produção) ao nome do espaço de nomes e, em alternativa, use o mesmo nome em todos os ambientes. Ao usar o mesmo nome, evita ter de alterar os ficheiros de configuração em todos os ambientes.

Crie contas de serviço para cargas de trabalho de inquilinos

Crie uma conta de serviço Google específica do inquilino para cada carga de trabalho distinta num namespace do inquilino. Isto oferece uma forma de segurança, garantindo que os inquilinos podem gerir contas de serviço para as cargas de trabalho que detêm/implementam nos respetivos espaços de nomes. A conta de serviço do Kubernetes para cada espaço de nomes é mapeada para uma conta de serviço Google através da federação de identidades da carga de trabalho para o GKE.

Aplique quotas de recursos

Para garantir que todos os inquilinos que partilham um cluster têm acesso justo aos recursos do cluster, aplique quotas de recursos. Crie uma quota de recursos para cada espaço de nomes com base no número de pods implementados por cada inquilino e na quantidade de memória e CPU exigida por cada pod.

O exemplo seguinte define uma quota de recursos em que os pods no espaço de nomes tenant-a podem pedir até 16 CPUs e 64 GB de memória, e a CPU máxima é 32 e a memória máxima é 72 GB.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Monitorização, registo e utilização

Acompanhe as métricas de utilização

Para obter discriminações de custos em espaços de nomes e etiquetas individuais num cluster, pode ativar a atribuição de custos do GKE. A atribuição de custos do GKE acompanha as informações sobre os pedidos de recursos e a utilização de recursos das cargas de trabalho de um cluster, que pode detalhar ainda mais por espaços de nomes e etiquetas. Com a atribuição de custos do GKE, pode aproximar a discriminação de custos para departamentos/equipas que partilham um cluster, compreender os padrões de utilização de aplicações individuais (ou mesmo componentes de uma única aplicação), ajudar os administradores de clusters a resolver picos de utilização e oferecer um melhor planeamento de capacidade e orçamentação.

Quando ativa a atribuição de custos do GKE, o nome do cluster e o espaço de nomes das suas cargas de trabalho do GKE aparecem no campo de etiquetas da exportação da faturação para o BigQuery.

Forneça registos específicos do inquilino

Para fornecer aos inquilinos dados de registo específicos das respetivas cargas de trabalho de projetos, use o Log Router do Cloud Logging. Para criar registos específicos do inquilino, o administrador do cluster cria um destinatário para exportar entradas de registo para um contentor de registos criado no projeto Trusted Cloud by S3NS do inquilino.

Para ver detalhes sobre como configurar estes tipos de registos, consulte o artigo Registo multi-inquilino no GKE.

Resumo da lista de verificação

A tabela seguinte resume as tarefas recomendadas para criar clusters multi-inquilinos numa organização empresarial:

O que se segue?

• Para mais informações sobre segurança, consulte o artigo Reforçar a segurança do cluster.
• Para mais informações sobre redes VPC, consulte o artigo Práticas recomendadas e arquiteturas de referência para o design de VPC.
• Para mais práticas recomendadas empresariais, consulte o Trusted Cloud by S3NS Well-Architected Framework.