Melhores Práticas Multi-tenancy

Melhores Práticas: Use o Autorizador RBAC para acesso detalhado adicional

Recomendamos que você use o Autorizador do Kubernetes RBAC para impor o controle de acesso detalhado para usuários em clusters específicos por meio de atribuições e clusterroles do Kubernetes RBAC.

Uma função do Kubernetes RBAC é um conjunto de permissões. Por exemplo, uma atribuição pode incluir permissão de leitura em pods e permissão de lista para pods. Uma clusterrole do Kubernetes RBAC é exatamente como uma atribuição, mas pode ser usada em qualquer lugar no cluster. Um rolebinding do Kubernetes RBAC mapeia uma atribuição para um usuário ou grupo, concedendo permissões dessa atribuição ao usuário ou grupo para recursos nesse namespace. Da mesma forma, um clusterrolebinding do Kubernetes RBAC mapeia um clusterrole para um usuário ou grupo, concedendo permissões desse clusterrole para o usuário ou grupo em todo o cluster.

Consulte Sobre o Controle de Acesso e o Kubernetes Engine (OKE).

Melhor Prática: Use namespaces se vários clusters não forem uma opção

Recomendamos que você crie namespaces separados para cada equipe se um cluster do Kubernetes for grande (com centenas de nós) e houver várias equipes trabalhando no cluster. Por exemplo, normalmente você criará namespaces diferentes para equipes de desenvolvimento, teste e produção.

Um cluster do Kubernetes pode ser organizado em namespaces para dividir os recursos do cluster entre diversos usuários. Inicialmente, um cluster tem os seguintes namespaces:

• padrão, para recursos sem outro namespace
• kube-system, para recursos criados pelo sistema Kubernetes
• kube-node-lease, para um objeto de leasing por nó para ajudar a determinar a disponibilidade do nó
• kube-public, geralmente usado para recursos que precisam estar acessíveis no cluster

Namespaces desempenham um papel importante em manter um cluster seguro quando vários usuários e equipes estão trabalhando no mesmo cluster.

Consulte Namespaces na documentação do Kubernetes.

Melhores Práticas: Use uma convenção de nomenclatura de namespace para facilitar a implantação em vários ambientes

Recomendamos que você estabeleça e use uma convenção de nomenclatura de namespace que facilite a criação de implantações em vários ambientes e hospedadas em diferentes clusters.

Por exemplo, evite incluir nomes de ambiente em nomes de namespace. Em vez disso, use o mesmo nome de namespace em todos os ambientes. Usando o mesmo nome de namespace, você pode usar os mesmos arquivos de configuração em todos os ambientes e evitar a necessidade de criar um arquivo de configuração específico para cada ambiente.

Consulte Namespaces na documentação do Kubernetes.

Melhores Práticas: Isolar cargas de trabalho em pools de nós dedicados

Recomendamos que você implemente um forte isolamento de infraestrutura usando pools de nós dedicados para isolar tenants. Por exemplo, para um aplicativo com vários tenants que executa cada tenant em um recurso de computação dedicado, separado por pools de nós.

Muitos aplicativos SaaS com vários tenants exigem que os tenants sejam executados em recursos de computação dedicados e exijam a capacidade de controlar o tráfego de rede por meio de listas de segurança por tenant. As duas estratégias mais comuns para esse modelo de tenancy de aplicativo SaaS são:

• Aproveite namespaces e políticas de rede para isolar os tenants.
• Aproveite listas dedicadas de computação/segurança para isolar tenants.

Melhores Práticas: Impor cotas de recursos

Recomendamos que você crie e imponha cotas de recursos do Kubernetes para garantir que todos os tenants que compartilham um cluster tenham acesso justo aos recursos do cluster.

Crie uma cota de recursos para cada namespace, com base no número de pods implantados por cada tenant e na quantidade de memória e CPU exigidas por cada pod.

Por exemplo, a seguinte configuração ResourceQuota:

• permite que pods no namespace tenant-a solicitem até 16 CPUs e até 64 GB de memória
• limita o número máximo de CPUs a 32 e a memória máxima a 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

Consulte Cotas de Recursos na documentação do Kubernetes.

Melhores Práticas: Dimensionamento automático de nós de trabalho e pods

Recomendamos que você ative o dimensionamento automático para acomodar a demanda do tenant dimensionando automaticamente os pools de nós e pods em um cluster.

O dimensionamento automático garante que o sistema continue a parecer responsivo e íntegro, mesmo quando diferentes tenants implantam cargas de trabalho pesadas em seus próprios namespaces. O dimensionamento automático também ajuda o sistema a responder a interrupções.

Consulte Usando o Kubernetes Cluster Autoscaler, Usando o Kubernetes Horizontal Pod Autoscaler.

Melhores Práticas: Usar um balanceador de carga flexível

Recomendamos que você especifique uma forma flexível para balanceadores de carga do Oracle Cloud Infrastructure para acomodar a demanda do tenant.

O uso de uma forma flexível para balanceadores de carga do OCI que o Kubernetes Engine provisiona para serviços do Kubernetes do tipo LoadBalancer permite que você:

• Evite as restrições associadas às formas de balanceador de carga de largura de banda fixa, porque você pode especificar valores mínimos e máximos para criar uma faixa de tamanho superior e inferior para a forma de largura de banda do balanceador de carga.
• Evite as limitações associadas ao dimensionamento com base apenas nos padrões gerais de tráfego.

Consulte Especificando Formas Flexíveis de Balanceador de Carga.

Melhores Práticas: Centralize o controle de rede (Opcional)

Recomendamos que você mantenha controle centralizado sobre recursos de rede usando um gateway de roteamento dinâmico (DRG) e (opcionalmente) uma VCN hub.

O uso de um DRG permite que você roteie tráfego por meio de um appliance virtual de rede centralizado.

Opcionalmente, a criação de uma VCN hub permite configurar o roteamento principal e os firewalls. Os recursos em uma VCN hub podem se comunicar com outras VCNs de forma segura e eficiente usando IPs internos. O uso de uma VCN hub e do serviço IAM garante que apenas os administradores de rede tenham acesso à VCN centralizada. Essa separação ajuda a implementar o princípio do privilégio mínimo.

Por exemplo:

• A equipe de rede centralizada pode administrar a rede sem ter permissões para acessar clusters do Kubernetes (que residem em VCNs de spoke).
• Os administradores do Kubernetes Engine podem gerenciar clusters sem ter permissões para manipular a rede compartilhada.

Consulte Roteando tráfego por meio de um appliance virtual de rede central.