A partir da versão 24.02, Trident é lançado a cada quatro meses: fevereiro, junho e outubro.

Trident geralmente não oferece suporte a recursos alfa no Kubernetes. Trident pode oferecer suporte a recursos beta nas duas versões do Trident subsequentes à versão beta do Kubernetes.

Trident não possui dependências de outros NetApp software products e funciona como um aplicativo independente. No entanto, você deve ter um NetApp backend storage device.

Utilize o tridentctl get comando para obter mais informações sobre a sua configuração do Trident.

Sim. Os endpoints do Prometheus podem ser usados para coletar informações sobre a operação do Trident, como o número de backends gerenciados, o número de volumes provisionados, bytes consumidos e assim por diante. Você também pode usar "Cloud Insights" para monitoramento e análise.

Não. Não há alterações em termos de experiência do usuário e funcionalidades. O nome do provisionador usado é csi.trident.netapp.io. Este método de instalação Trident é recomendado se você deseja usar todos os novos recursos oferecidos pelas versões atuais e futuras.

Sim, Trident pode ser instalado offline. Consulte "Saiba mais sobre a instalação do Trident".

Sim. Trident 18.10 e versões posteriores suportam a capacidade de instalação remota a partir de qualquer máquina que tenha kubectl acesso ao cluster. Após kubectl o acesso ser verificado (por exemplo, iniciar um kubectl get nodes comando a partir da máquina remota para verificar), siga as instruções de instalação.

Trident é instalado como um Deployment do Kubernetes (ReplicaSet) com uma instância, portanto, possui HA integrado. Você não deve aumentar o número de réplicas no deployment. Se o nó onde Trident está instalado for perdido ou o pod ficar inacessível, o Kubernetes reimplanta automaticamente o pod em um nó saudável no seu cluster. Trident é apenas plano de controle, então os pods atualmente montados não são afetados se Trident for reimplantado.

Trident lê do Kubernetes API Server para determinar quando os aplicativos solicitam novos PVCs, então ele precisa de acesso ao kube-system.

O instalador do Trident cria um Kubernetes ClusterRole, que tem acesso específico aos PersistentVolume, PersistentVolumeClaim, StorageClass e recursos Secret do cluster Kubernetes. Consulte "Personalize a instalação do tridentctl".

Você pode gerar e modificar localmente os arquivos de manifesto exatos que o Trident usa para instalação, se necessário. Consulte "Personalize a instalação do tridentctl".

Embora não seja recomendável, você pode usar o mesmo SVM de backend para duas instâncias do Trident. Especifique um nome de volume exclusivo para cada instância durante a instalação e/ou especifique um parâmetro exclusivo StoragePrefix no arquivo setup/backend.json. Isso é para garantir que o mesmo volume FlexVol não seja usado para ambas as instâncias.

Trident é simplesmente um pod do Kubernetes e pode ser instalado onde o Kubernetes está em execução.

Sim, Trident é compatível com AWS, Google Cloud e Azure.

Embora Trident seja de código aberto e fornecido gratuitamente, NetApp oferece suporte total, desde que seu backend NetApp seja compatível.

Para abrir um chamado de suporte, faça um dos seguintes:

Você pode criar um pacote de suporte executando tridentctl logs -a. Além dos logs capturados no pacote, capture o log do kubelet para diagnosticar os problemas de montagem no lado do Kubernetes. As instruções para obter o log do kubelet variam dependendo de como o Kubernetes está instalado.

Crie uma issue em "Trident Github" e mencione RFE no assunto e na descrição da issue.

Crie uma ocorrência em "Trident Github". Certifique-se de incluir todas as informações e registros necessários referentes ao problema.

Se você tiver alguma dúvida, problema ou solicitação, entre em contato conosco através do nosso Trident "Canal do Discord" ou GitHub.

Atualize a senha do backend com tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident. Substitua myBackend no exemplo pelo nome do seu backend, e `/path/to_new_backend.json pelo caminho para o arquivo backend.json correto.

Existem dois cenários prováveis para o Trident não conseguir encontrar um nó do Kubernetes. Isso pode ser devido a um problema de rede dentro do Kubernetes ou a um problema de DNS. O daemonset do nó Trident, que é executado em cada nó do Kubernetes, deve ser capaz de se comunicar com o controlador do Trident para registrar o nó no Trident. Se alterações de rede ocorreram após a instalação do Trident, você encontrará esse problema apenas com novos nós do Kubernetes adicionados ao cluster.

Os dados não serão perdidos se o pod do Trident for destruído. Os metadados do Trident são armazenados em objetos CRD. Todos os PVs que foram provisionados pelo Trident funcionarão normalmente.

NetApp oferece suporte à atualização do Trident de uma versão principal para a próxima versão principal imediata. Você pode atualizar da versão 18.xx para 19.xx, de 19.xx para 20.xx e assim por diante. Você deve testar a atualização em um laboratório antes da implantação em produção.

Se precisar corrigir erros observados após uma atualização, problemas de dependência ou uma atualização incompleta ou malsucedida, você deve "desinstalar Trident" e reinstalar a versão anterior seguindo as instruções específicas para essa versão. Esta é a única maneira recomendada de fazer o downgrade para uma versão anterior.

O gerenciamento do LIF é obrigatório. DataLIF varia:

Sim. Trident suporta CHAP bidirecional para backends ONTAP. Isso requer definir useCHAP=true na configuração do seu backend.

Trident pode criar e gerenciar políticas de exportação dinamicamente a partir da versão 20.04. Isso permite que o administrador de storage forneça um ou mais blocos CIDR em sua configuração de backend e que Trident adicione os IPs dos nós que se enquadram nesses intervalos a uma política de exportação que ele cria. Dessa forma, Trident gerencia automaticamente a adição e remoção de regras para nós com IPs dentro dos CIDRs fornecidos.

Trident suporta a definição de endereços IPv6 para:

Trident deve ser instalado usando a flag --use-ipv6 (para tridentctl instalação), IPv6 (para Trident operator), ou tridentTPv6 (para instalação via Helm) para que funcione sobre IPv6.

Sim, é possível atualizar o LIF de gerenciamento do backend usando o tridentctl update backend comando.

Você pode atualizar o DataLIF em ontap-nas e ontap-nas-economy apenas.

Trident pode suportar vários backends simultaneamente, seja com o mesmo driver ou com drivers diferentes.

Trident armazena as credenciais do backend como Kubernetes Secrets.

Caso os atributos de backend não possam ser usados para selecionar automaticamente os pools corretos para uma classe, os parâmetros storagePools e additionalStoragePools são usados para selecionar um conjunto específico de pools.

O `excludeStoragePools`parâmetro é usado para filtrar o conjunto de pools que Trident usa para provisionamento e removerá quaisquer pools que correspondam.

Se houver vários backends configurados do mesmo tipo, Trident seleciona o backend apropriado com base nos parâmetros presentes em StorageClass e PersistentVolumeClaim. Por exemplo, se houver vários backends do driver ontap-nas, Trident tenta combinar os parâmetros em StorageClass e PersistentVolumeClaim e encontrar um backend que possa atender aos requisitos listados em StorageClass e PersistentVolumeClaim. Se houver vários backends que correspondam à solicitação, Trident seleciona um deles aleatoriamente.

Sim.

O ontap-nas-economy driver cria até 200 Qtrees no mesmo FlexVol volume (configurável entre 50 e 300), 100.000 Qtrees por nó de cluster e 2,4M por cluster. Quando você insere uma nova PersistentVolumeClaim que é atendida pelo driver econômico, o driver verifica se já existe um volume FlexVol que possa atender à nova Qtree. Se o volume FlexVol que possa atender à Qtree não existir, um novo volume FlexVol será criado.

Você pode definir permissões Unix no volume provisionado pelo Trident definindo um parâmetro no arquivo de definição do backend.

Por padrão, Trident não define opções de montagem com nenhum valor no Kubernetes. Para especificar as opções de montagem na Kubernetes Storage Class, siga o exemplo fornecido "aqui".

Para permitir que os hosts apropriados acessem um volume, use o exportPolicy parâmetro configurado no arquivo de definição do backend.

Você pode configurar criptografia no volume provisionado pelo Trident usando o parâmetro encryption no arquivo de definição do backend. Para obter mais informações, consulte: "Como Trident funciona com NVE e NAE"

Use StorageClasses para implementar QoS para ONTAP.

Os drivers ONTAP suportam thin provisioning ou thick provisioning. Os drivers ONTAP utilizam thin provisioning por padrão. Se for desejado thick provisioning, você deve configurar o arquivo de definição de backend ou o StorageClass. Se ambos estiverem configurados, StorageClass terá precedência. Configure o seguinte para ONTAP:

A proteção de PVC é ativada automaticamente no Kubernetes a partir da versão 1.10.

Sim. Você pode expandir um PVC criado pelo Trident. Observe que volume com crescimento automático é um recurso do ONTAP que não se aplica ao Trident.

A importação do volume falha se o volume externo estiver no modo DP ou estiver offline. Você recebe a seguinte mensagem de erro:

A cota de recursos de armazenamento do Kubernetes deve funcionar enquanto o armazenamento NetApp tiver capacidade. Quando o armazenamento NetApp não consegue respeitar as configurações de cota do Kubernetes devido à falta de capacidade, Trident tenta provisionar, mas ocorre um erro.

Sim. A criação de snapshots de volume sob demanda e Volumes Persistentes a partir de Snapshots são suportados pelo Trident. Para criar PVs a partir de snapshots, certifique-se de que o VolumeSnapshotDataSource feature gate foi habilitado.

A partir de hoje, o suporte a snapshots sob demanda está disponível para nossos ontap-nas, ontap-nas-flexgroup, ontap-san, ontap-san-economy, solidfire-san e azure-netapp-files drivers de backend.

Isso está disponível nos ontap-nas, ontap-san e ontap-nas-flexgroup drivers. Você também pode especificar um snapshotPolicy para o ontap-san-economy driver no nível de FlexVol.

Isso também está disponível nos ontap-nas-economy drivers, mas na granularidade do nível de FlexVol volume e não na granularidade do nível de qtree. Para habilitar a capacidade de criar snapshots de volumes provisionados pelo Trident, defina a opção de parâmetro de backend snapshotPolicy para a política de snapshot desejada, conforme definida no backend do ONTAP. Quaisquer snapshots criados pelo controlador de armazenamento não são conhecidos pelo Trident.

Sim, você pode reservar uma porcentagem específica de espaço de disco para armazenar as cópias de snapshots por meio do Trident, definindo o snapshotReserve atributo no arquivo de definição do backend. Se você configurou snapshotPolicy e snapshotReserve no arquivo de definição do backend, a porcentagem de reserva de snapshots será definida de acordo com a porcentagem de snapshotReserve mencionada no arquivo do backend. Se o número percentual de snapshotReserve não for mencionado, o ONTAP, por padrão, considera a porcentagem de reserva de snapshots como 5. Se a opção snapshotPolicy estiver definida como none, a porcentagem de reserva de snapshots será definida como 0.

Sim, você pode acessar o diretório de snapshots no volume provisionado pelo Trident definindo o parâmetro snapshotDir no arquivo de definição do backend.

Atualmente, SnapMirror precisa ser configurado externamente usando a CLI do ONTAP ou o OnCommand System Manager.

Para restaurar um volume para um snapshot do ONTAP, execute as seguintes etapas:

É possível criar espelhos de balanceamento de carga para volumes raiz de SVMs que fornecem dados via NFS. ONTAP atualiza automaticamente os espelhos de balanceamento de carga para volumes que foram criados pelo Trident. Isso pode resultar em atrasos na montagem dos volumes. Quando vários volumes são criados usando Trident, o provisionamento de um volume depende da atualização do espelho de balanceamento de carga pelo ONTAP.

O Kubernetes não permite classes de armazenamento em namespaces. No entanto, você pode usar o Kubernetes para limitar o uso de uma classe de armazenamento específica por namespace usando cotas de recursos de armazenamento, que são por namespace. Para negar a um namespace específico o acesso a um armazenamento específico, defina a cota de recursos como 0 para essa classe de armazenamento.