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 trabalhando 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 de IdP e a sincronização de grupos de usuários, permitindo que usuários e grupos do IdP sejam importados para o cluster. Isso ajuda os administradores do cluster a segregar o acesso dos recursos do cluster dedicados a um projeto para um ou mais grupos de usuários que trabalham naquele 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 a documentação "aqui" .

É 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 ter diferentes SVMs para diferentes projetos criados no NetApp ONTAP, você deve mapear cada SVM para um backend Trident diferente. A configuração de backend no Trident direciona a alocação de armazenamento persistente para recursos de cluster OpenShift e requer que os detalhes do SVM sejam mapeados. Este deve ser o driver de protocolo para o backend, no mínimo. Opcionalmente, ele permite que você defina como os volumes são provisionados no armazenamento e defina limites para o tamanho dos volumes ou uso de agregados e assim por diante. Detalhes sobre a definição dos backends do Trident podem ser encontrados "aqui" .

Depois de configurar os backends do Trident , o próximo passo é configurar o StorageClasses. Configure tantas classes de armazenamento quantos forem os backends, fornecendo a cada classe de armazenamento acesso para iniciar volumes somente em um backend. Podemos mapear o StorageClass para um backend Trident específico usando o parâmetro storagePools ao definir a classe de armazenamento. Os detalhes para definir uma classe de armazenamento podem ser encontrados "aqui" . Portanto, há um mapeamento um-para-um do StorageClass para o backend Trident que aponta de volta para uma SVM. Isso garante que todas as reivindicações de armazenamento por meio do StorageClass atribuído a esse projeto sejam atendidas somente pelo SVM dedicado a esse projeto.

Como as classes de armazenamento não são recursos com namespace, como podemos garantir que as declarações de armazenamento para a classe de armazenamento de um projeto 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 o número e 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 as organizações a reduzir custos e interrupções devido ao excesso de provisionamento ou consumo excessivo de recursos. Consulte a documentação "aqui" para maiores 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.