Talvez a maneira mais fácil de entender os objetos, para que eles são e como eles interagem seja seguir uma única solicitação de armazenamento de um usuário do Kubernetes:

Um objeto Kubernetes PersistentVolumeClaim é uma solicitação de storage feita por um usuário de cluster do Kubernetes.

Além da especificação padrão, o Trident permite que os usuários especifiquem as seguintes anotações específicas de volume se quiserem substituir os padrões definidos na configuração de back-end:

Se o PV criado tiver a Delete política de recuperação, o Trident excluirá o PV e o volume de backup quando o PV for liberado (ou seja, quando o usuário exclui o PVC). Caso a ação de exclusão falhe, o Trident marca o PV como tal e periodicamente tenta novamente a operação até que seja bem-sucedida ou o PV seja excluído manualmente. Se o PV usar a Retain política, o Trident a ignora e assume que o administrador irá limpá-la do Kubernetes e do back-end, permitindo que o volume seja feito backup ou inspecionado antes de sua remoção. Observe que a exclusão do PV não faz com que o Trident exclua o volume de backup. Você deve removê-lo usando a API REST (tridentctl).

O Trident dá suporte à criação de snapshots de volume usando a especificação CSI: Você pode criar um instantâneo de volume e usá-lo como fonte de dados para clonar PVCs existentes. Dessa forma, cópias pontuais de PVS podem ser expostas ao Kubernetes na forma de snapshots. Os instantâneos podem então ser usados para criar novos PVS. Dê uma olhada On-Demand Volume Snapshots para ver como isso funcionaria.

O Trident também fornece as cloneFromPVC anotações e splitOnClone para a criação de clones. Você pode usar essas anotações para clonar um PVC sem precisar usar a implementação do CSI.

Aqui está um exemplo: Se um usuário já tem um PVC chamado mysql, o usuário pode criar um novo PVC chamado mysqlclone usando a anotação, como trident.netapp.io/cloneFromPVC: mysql . Com esse conjunto de anotações, o Trident clona o volume correspondente ao PVC mysql, em vez de provisionar um volume do zero.

Considere os seguintes pontos:

O sample-input diretório contém exemplos de definições de PVC para uso com Trident. Consulte a para obter uma descrição completa dos parâmetros e definições associados aos volumes Trident.

Um objeto Kubernetes PersistentVolume representa um storage disponibilizado para o cluster do Kubernetes. Ele tem um ciclo de vida que é independente do pod que o usa.

Quando você cria um PVC que se refere a um Trident-based StorageClass, o Trident provisiona um novo volume usando a classe de armazenamento correspondente e Registra um novo PV para esse volume. Ao configurar o volume provisionado e o PV correspondente, o Trident segue as seguintes regras:

Os objetos Kubernetes StorageClass são especificados por nome em PersistentVolumeClaims para provisionar o storage com um conjunto de propriedades. A própria classe de storage identifica o provisionador a ser usado e define esse conjunto de propriedades em termos que o provisionador entende.

É um dos dois objetos básicos que precisam ser criados e gerenciados pelo administrador. O outro é o objeto backend do Trident.

Um objeto do Kubernetes StorageClass que usa o Trident é parecido com este:

Esses parâmetros são específicos do Trident e informam à Trident como provisionar volumes para a classe.

Os parâmetros da classe de armazenamento são:

Os atributos de storage e seus possíveis valores podem ser classificados em atributos de seleção de pool de storage e atributos do Kubernetes.

Os objetos do Kubernetes VolumeSnapshotClass são análogos ao StorageClasses. Eles ajudam a definir várias classes de armazenamento e são referenciados por instantâneos de volume para associar o snapshot à classe de snapshot necessária. Cada snapshot de volume é associado a uma classe de snapshot de volume único.

A VolumeSnapshotClass deve ser definida por um administrador para criar instantâneos. Uma classe de instantâneo de volume é criada com a seguinte definição:

O driver especifica ao Kubernetes que as solicitações de snapshots de volume csi-snapclass da classe são tratadas pelo Trident. O deletionPolicy especifica a ação a ser tomada quando um instantâneo deve ser excluído. deletionPolicy`Quando está definido como `Delete, os objetos instantâneos de volume e o instantâneo subjacente no cluster de armazenamento são removidos quando um instantâneo é excluído. Alternativamente, configurá-lo para Retain significa que VolumeSnapshotContent e o instantâneo físico são retidos.

Um objeto Kubernetes VolumeSnapshot é uma solicitação para criar um snapshot de um volume. Assim como um PVC representa uma solicitação feita por um usuário para um volume, um instantâneo de volume é uma solicitação feita por um usuário para criar um instantâneo de um PVC existente.

Quando uma solicitação de snapshot de volume entra, o Trident gerencia automaticamente a criação do snapshot para o volume no back-end e expõe o snapshot criando um objeto exclusivo
VolumeSnapshotContent. Você pode criar snapshots a partir de PVCs existentes e usar os snapshots como DataSource ao criar novos PVCs.

Um objeto Kubernetes VolumeSnapshotContent representa um snapshot retirado de um volume já provisionado. Ele é análogo a PersistentVolume e significa um snapshot provisionado no cluster de storage. Semelhante aos PersistentVolumeClaim objetos e PersistentVolume, quando um snapshot é criado, o VolumeSnapshotContent objeto mantém um mapeamento um-para-um para o VolumeSnapshot objeto, que havia solicitado a criação do snapshot.

O VolumeSnapshotContent objeto contém detalhes que identificam exclusivamente o instantâneo, como o snapshotHandle. Esta snapshotHandle é uma combinação única do nome do PV e do nome do VolumeSnapshotContent objeto.

Quando uma solicitação de snapshot entra, o Trident cria o snapshot no back-end. Depois que o snapshot é criado, o Trident configura um VolumeSnapshotContent objeto e, portanto, expõe o snapshot à API do Kubernetes.

Os recursos personalizados do Kubernetes são endpoints na API do Kubernetes que são definidos pelo administrador e são usados para agrupar objetos semelhantes. O Kubernetes dá suporte à criação de recursos personalizados para armazenar uma coleção de objetos. Você pode obter essas definições de recursos executando `kubectl get crds`o .

As definições personalizadas de recursos (CRDs) e os metadados de objetos associados são armazenados pelo Kubernetes em seu armazenamento de metadados. Isso elimina a necessidade de uma loja separada para o Trident.

O Trident usa CustomResourceDefinition objetos para preservar a identidade de objetos do Trident, como backends Trident, classes de storage Trident e volumes Trident. Esses objetos são gerenciados pelo Trident. Além disso, a estrutura de snapshot do volume CSI introduz algumas CRDs que são necessárias para definir snapshots de volume.

CRDs são uma construção do Kubernetes. Os objetos dos recursos definidos acima são criados pelo Trident. Como um exemplo simples, quando um back-end é criado usando tridentctl`o , um objeto CRD correspondente `tridentbackends é criado para consumo pelo Kubernetes.

Aqui estão alguns pontos a ter em mente sobre os CRDs do Trident:

O Trident cria classes de storage correspondentes para objetos Kubernetes StorageClass que especificam csi.trident.netapp.io no campo do provisionador. O nome da classe de storage corresponde ao do objeto Kubernetes StorageClass que ele representa.

As classes de armazenamento compreendem um conjunto de requisitos para volumes. O Trident atende a esses requisitos com os atributos presentes em cada pool de storage. Se forem correspondentes, esse pool de storage será um destino válido para volumes de provisionamento que usam essa classe de storage.

Você pode criar configurações de classe de armazenamento para definir diretamente classes de armazenamento usando a API REST. No entanto, para implantações do Kubernetes, esperamos que elas sejam criadas ao Registrar novos objetos do Kubernetes StorageClass.

Os backends representam os fornecedores de storage em cima dos quais o Trident provisiona volumes. Uma única instância do Trident pode gerenciar qualquer número de backends.

Para obter mais informações sobre como construir esses objetos, "configurando backends"consulte .

Os pools de storage representam locais distintos disponíveis para provisionamento em cada back-end. Para ONTAP, eles correspondem a agregados em SVMs. Para NetApp HCI/SolidFire, estes correspondem a bandas de QoS especificadas pelo administrador. Para o Cloud Volumes Service, eles correspondem a regiões de provedores de nuvem. Cada pool de storage tem um conjunto de atributos de storage distintos, que definem suas características de performance e proteção de dados.

Ao contrário dos outros objetos aqui, os candidatos ao pool de armazenamento são sempre descobertos e gerenciados automaticamente.

Os volumes são a unidade básica de provisionamento, incluindo pontos de extremidade de back-end, como compartilhamentos NFS e iSCSI LUNs. No Kubernetes, eles correspondem diretamente PersistentVolumes ao . Ao criar um volume, certifique-se de que ele tenha uma classe de armazenamento, que determina onde esse volume pode ser provisionado, juntamente com um tamanho.

Uma configuração de volume define as propriedades que um volume provisionado deve ter.

O Trident gera internalName ao criar o volume. Isto consiste em duas etapas. Primeiro, ele prepende o prefixo de armazenamento (o padrão trident ou o prefixo na configuração de back-end) para o nome do volume, resultando em um nome do formulário <prefix>-<volume-name>. Em seguida, procede à higienização do nome, substituindo carateres não permitidos no backend. Para backends ONTAP, ele substitui hífens por sublinhados (assim, o nome interno se torna <prefix>_<volume-name>). Para backends de elemento, ele substitui sublinhados por hífens.

Você pode usar configurações de volume para provisionar volumes diretamente usando a API REST, mas nas implantações do Kubernetes, esperamos que a maioria dos usuários use o método padrão do Kubernetes PersistentVolumeClaim. O Trident cria esse objeto de volume automaticamente como parte do processo de provisionamento.

Os snapshots são uma cópia pontual de volumes, que pode ser usada para provisionar novos volumes ou restaurar o estado. No Kubernetes, eles correspondem diretamente a VolumeSnapshotContent objetos. Cada snapshot é associado a um volume, que é a origem dos dados do snapshot.

Cada Snapshot objeto inclui as propriedades listadas abaixo:

Quando uma solicitação de objeto Kubernetes VolumeSnapshot é criada, o Trident funciona criando um objeto snapshot no sistema de storage de backup. internalName`O deste objeto instantâneo é gerado combinando o prefixo `snapshot- com o UID do VolumeSnapshot objeto (por exemplo, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660 ). volumeName e volumeInternalName são preenchidos obtendo os detalhes do volume de apoio.

O deamonset do Trident consome uma system-node-critical classe de prioridade - a classe de prioridade mais alta disponível no Kubernetes - para garantir que o Trident possa identificar e limpar volumes durante o desligamento gracioso do nó e permitir que os pods do Trident daemonset pré-empt cargas de trabalho com prioridade mais baixa em clusters onde há alta pressão de recursos.

Para conseguir isso, o Trident emprega um ResourceQuota objeto para garantir que uma classe de prioridade "system-node-critical" no daemonset do Trident esteja satisfeita. Antes da implantação e criação do daemonset, o Trident procura o ResourceQuota objeto e, se não for descoberto, o aplica.

Se você precisar de mais controle sobre a cota de recurso padrão e Classe de prioridade, você pode gerar um custom.yaml ou configurar o ResourceQuota objeto usando o gráfico de Helm.

O seguinte é um exemplo de um objeto 'ResourceQuota' priorizando o daemonset do Trident.

Para obter mais informações sobre cotas de recursos, "Kubernetes: Cotas de recursos"consulte .