Do ponto de vista do cluster Red Hat OpenShift, o recurso de nível superior para começar é o projeto. Um projeto OpenShift pode ser visto como um recurso de cluster que divide todo o cluster OpenShift em vários clusters virtuais. Portanto, o isolamento no nível do projeto fornece uma base para configurar a multilocação.

O próximo passo é configurar o RBAC no cluster. A melhor prática é ter todos os desenvolvedores que trabalham em um único projeto ou carga de trabalho configurados em um único grupo de usuários no Provedor de Identidade (IdP). O Red Hat OpenShift permite a integração com o IdP e a sincronização de grupos de usuários, permitindo que os usuários e grupos do IdP sejam importados para o cluster. Isso ajuda os administradores do cluster a segregar o acesso aos recursos do cluster dedicados a um projeto para um grupo de usuários ou grupos que trabalham nesse projeto, restringindo assim o acesso não autorizado a quaisquer recursos do cluster. Para saber mais sobre a integração do IdP com o Red Hat OpenShift, consulte "Entendendo os provedores de identidade".

É importante isolar o armazenamento compartilhado que serve como um provedor de armazenamento persistente para um cluster Red Hat OpenShift para garantir que os volumes criados no armazenamento para cada projeto apareçam para os hosts como se tivessem sido criados em um armazenamento separado. Para fazer isso, crie tantas SVMs (máquinas virtuais de armazenamento) no NetApp ONTAP quantos projetos ou cargas de trabalho houver e dedique cada SVM a uma carga de trabalho.

Depois de criar diferentes SVMs para diferentes projetos no NetApp ONTAP, você deve mapear cada SVM para um backend do Trident diferente. A configuração do backend no Trident controla a alocação de storage persistente aos recursos do cluster OpenShift e requer os detalhes da SVM a ser mapeada. No mínimo, deve ser o driver de protocolo do backend. Opcionalmente, permite que você defina como os volumes são provisionados no storage e defina limites para o tamanho dos volumes ou uso de agregados, entre outras configurações. Detalhes sobre a definição dos backends do Trident podem ser encontrados em "Configurar backends".

Após configurar os back-ends do Trident, o próximo passo é configurar as StorageClasses. Configure tantas classes de armazenamento quanto houver back-ends, concedendo a cada classe de armazenamento acesso para criar volumes apenas em um back-end. Você pode mapear a StorageClass para um back-end específico do Trident usando o parâmetro storagePools ao definir a classe de armazenamento. Os detalhes para definir uma classe de armazenamento podem ser encontrados em "Criar uma classe de armazenamento". Assim, existe um mapeamento um-para-um da StorageClass para o back-end do Trident, que aponta de volta para uma SVM. Isso garante que todas as solicitações de storage por meio da StorageClass atribuída a esse projeto sejam atendidas somente pela SVM dedicada a esse projeto.

Como as classes de armazenamento não são recursos com namespace, como você pode garantir que as solicitações de armazenamento para a storage class de um projeto feitas por pods em outro namespace ou projeto sejam rejeitadas? A resposta é usar ResourceQuotas. ResourceQuotas são objetos que controlam o uso total de recursos por projeto. Ele pode limitar tanto o número quanto a quantidade total de recursos que podem ser consumidos por objetos no projeto. Quase todos os recursos de um projeto podem ser limitados usando ResourceQuotas, e usar isso de forma eficiente pode ajudar sua organização a reduzir custos e interrupções devido ao provisionamento excessivo ou ao consumo excessivo de recursos. Consulte "Definindo cotas de recursos por projeto" para obter mais informações.

Para este caso de uso, precisamos limitar os pods em um projeto específico de reivindicar armazenamento de classes de armazenamento que não são dedicadas ao projeto. Para fazer isso, precisamos limitar as reivindicações de volume persistentes para outras classes de armazenamento, definindo <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims para 0. Além disso, um administrador de cluster deve garantir que os desenvolvedores em um projeto não tenham acesso para modificar as ResourceQuotas.