Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Notas de versão

Colaboradores RSS
PDFs

As Notas de versão fornecem informações sobre novos recursos, aprimoramentos e correções de bugs na versão mais recente do Astra Trident.

Aviso O tridentctl binário para Linux que é fornecido no arquivo zip do instalador é a versão testada e suportada. Esteja ciente de que o macos binário fornecido na /extras parte do arquivo zip não é testado ou suportado.

Novidades em 23.01.1

Correções

  • Operador Trident fixo para usar localhost IPv6 para instalação quando especificado na especificação.

  • Permissões fixas da função de cluster do operador do Trident para estar em sincronia com as permissões do pacote "Problema nº 799".

  • Adicionada uma correção para permitir que processos externos sejam executados até a conclusão.

  • Corrigido o problema com a inclusão de volume de bloco bruto em vários nós no modo RWX.

  • Suporte fixo à clonagem de FlexGroup e importação de volume para volumes SMB.

Mudanças em 23,01

Importante O Kubernetes 1,26 agora é compatível com o Trident. Atualize o Astra Trident antes de atualizar o Kubernetes.

Correções

  • Kubernetes: Adicionadas opções para excluir a criação da Diretiva de Segurança do Pod para corrigir instalações do Trident via Helm ("Problemas nº 783, nº 794").

Melhorias

Kubernetes

  • Adicionado suporte para Kubernetes 1,26.

  • Utilização geral aprimorada de recursos RBAC do Trident ("Problema nº 757").

  • Automação adicionada para detetar e corrigir sessões iSCSI quebradas ou obsoletas em nós de host.

  • Adicionado suporte para expandir volumes criptografados LUKS.

  • Kubernetes: Suporte à rotação de credenciais adicionado para volumes criptografados LUKS.

Astra Trident

  • Adicionado suporte para volumes SMB com o Amazon FSX for ONTAP para o driver de armazenamento ONTAP-nas.

  • Adicionado suporte para permissões NTFS ao usar volumes SMB.

  • Adicionado suporte a pools de storage para volumes do GCP com nível de serviço CVS.

  • Adicionado suporte para uso opcional do flexgroupAggregateList ao criar FlexGroups com o driver de armazenamento ONTAP-nas-FlexGroup.

  • Desempenho aprimorado para o driver de storage econômico ONTAP nas ao gerenciar vários FlexVols.

  • Atualizações de dataLIF habilitadas para todos os drivers de storage nas do ONTAP.

  • Atualização da convenção de nomenclatura Trident Deployment e DaemonSet para refletir o sistema operacional do nó host.

Desvalorizações

  • Kubernetes: Mínimo atualizado com suporte de Kubernetes para 1,21.

  • Os LIFs de dados não devem mais ser especificados ao configurar ontap-san ou ontap-san-economy drivers.

Mudanças em 22,10

Você deve ler as seguintes informações críticas antes de atualizar para o Astra Trident 22,10.

Aviso
<strong> informações críticas sobre o Astra Trident 22.10 </strong>

  • O Kubernetes 1,25 agora é compatível com o Trident. É necessário atualizar o Astra Trident para 22,10 antes da atualização para o Kubernetes 1,25.

  • O Astra Trident agora reforça estritamente o uso de configuração multipathing em ambientes SAN, com um valor recomendado de find_multipaths: no no arquivo multipath.conf.

    O uso de configuração não multipathing ou o uso find_multipaths: yes de ou find_multipaths: smart valor no arquivo multipath.conf resultará em falhas de montagem. A Trident recomenda o uso de find_multipaths: no desde a versão 21,07.

Correções

  • Corrigido um problema específico para o back-end do ONTAP criado usando credentials campo que não aparece on-line durante a atualização do 22.07.0 ("Problema nº 759" ).

  • Docker: corrigiu um problema que fazia com que o plugin de volume do Docker não iniciasse em alguns ambientes ("Problema nº 548" e "Problema nº 760").

  • Corrigido problema de SLM específico para backends de SAN ONTAP para garantir que apenas um subconjunto de LIFs de dados pertencentes a nós de relatório seja publicado.

  • Corrigido problema de desempenho em que verificações desnecessárias para iSCSI LUNs aconteceram ao anexar um volume.

  • Novas tentativas granulares removidas dentro do fluxo de trabalho iSCSI Astra Trident para falhar rapidamente e reduzir os intervalos de tentativas externas.

  • Corrigido o problema em que um erro foi retornado ao lavar um dispositivo iSCSI quando o dispositivo multipath correspondente já estava lavado.

Melhorias

  • Kubernetes:

    • Adicionado suporte para Kubernetes 1,25. É necessário atualizar o Astra Trident para 22,10 antes da atualização para o Kubernetes 1,25.

    • Adicionado um ServiceAccount separado, ClusterRole e ClusterRoleBinding para a implantação do Trident e DaemonSet para permitir melhorias futuras de permissões.

    • Adicionado suporte para "compartilhamento de volume entre namespace".

  • Todos os drivers de storage Trident ontap-* agora funcionam com a API REST do ONTAP.

  • Adicionado novo operador yaml (bundle_post_1_25.yaml) sem um PodSecurityPolicy para oferecer suporte ao Kubernetes 1,25.

  • Adicionado "Suporte para volumes criptografados com LUKS" para ontap-san e ontap-san-economy drivers de armazenamento.

  • Adicionado suporte para nós do Windows Server 2019.

  • Adicionado "Suporte para volumes SMB em nós do Windows" através do azure-netapp-files driver de armazenamento.

  • A deteção automática de comutação MetroCluster para controladores ONTAP está agora disponível em geral.

Desvalorizações

  • Kubernetes: atualizado com o mínimo de Kubernetes compatível para 1,20.

  • Driver do Astra Data Store (ADS) removido.

  • Removido o suporte yes e smart as opções para find_multipaths quando configurar multipathing de nó de trabalho para iSCSI.

Mudanças em 22,07

Correções

Kubernetes

  • Corrigido problema para lidar com valores booleanos e numéricos para o seletor de nó ao configurar o Trident com Helm ou o Operador Trident. ("GitHub Edição nº 700")

  • Corrigido problema no tratamento de erros do caminho não-CHAP, de modo que kubelet irá tentar novamente se falhar. "GitHub Edição nº 736")

Melhorias

  • Transição do k8s.gcr.io para o registry.k8s.io como Registro padrão para imagens CSI

  • Os volumes ONTAP-SAN agora usarão grupos por nó e mapearão apenas LUNs para grupos enquanto são publicados ativamente nesses nós para melhorar nossa postura de segurança. Os volumes existentes serão oportunisticamente comutados para o novo esquema de grupos quando o Trident determinar que é seguro fazê-lo sem afetar cargas de trabalho ativas.

  • Incluído um ResourceQuota com instalações Trident para garantir que o Trident DaemonSet seja programado quando o consumo de PriorityClass é limitado por padrão.

  • Adicionado suporte a recursos de rede ao driver do ANF. ("GitHub Edição nº 717")

  • Adicionada deteção automática de comutação MetroCluster de pré-visualização técnica aos drivers ONTAP. ("GitHub Edição nº 228")

Desvalorizações

  • Kubernetes: atualizado com o mínimo de Kubernetes compatível para 1,19.

  • A configuração de backend não permite mais vários tipos de autenticação em uma única configuração.

Remoções

  • O driver do AWS CVS (obsoleto desde 22,04) foi removido.

  • Kubernetes

    • Removido recurso SYS_ADMIN desnecessário dos pods de nós.

    • Reduz o nodeprep para informações simples de host e descoberta de serviço ativo para confirmar o melhor esforço de que os serviços NFS/iSCSI estão disponíveis nos nós de trabalho.

Documentação

Uma nova "Padrões de segurança do pod"seção (PSS) foi adicionada detalhando as permissões habilitadas pelo Astra Trident na instalação.

Mudanças em 22,04

A NetApp está continuamente melhorando e aprimorando seus produtos e serviços. Aqui estão alguns dos recursos mais recentes do Astra Trident. Para versões anteriores, "Versões anteriores da documentação"consulte .

Importante Se você estiver atualizando de qualquer versão anterior do Trident e usar o Azure NetApp Files, o location parâmetro config agora é um campo único obrigatório.

Correções

Melhorias

  • As conexões de entrada para os endpoints seguros da Trident agora exigem um mínimo de TLS 1,3. ("GitHub Edição nº 698")

  • O Trident agora adiciona cabeçalhos HSTS às respostas de seus endpoints seguros.

  • O Trident agora tenta ativar o recurso de permissões unix do Azure NetApp Files automaticamente.

  • Kubernetes: O daemonset do Trident agora é executado na classe de prioridade crítica do nó do sistema. ("GitHub Edição nº 694")

Remoções

O driver da série e (desativado desde 20,07) foi removido.

Mudanças em 22.01.1

Correções

  • Corrigido o problema com a remoção de volumes em nós excluídos. ("GitHub Edição nº 691")

  • Corrigido o pânico ao acessar campos nil para espaço agregado nas respostas da API do ONTAP.

Mudanças em 22.01.0

Correções

  • Kubernetes: aumente o tempo de repetição do backoff do Registro de nós para clusters grandes.

  • Corrigido problema em que o driver azure-NetApp-Files poderia ser confundido por vários recursos com o mesmo nome.

  • Os LIFs de dados SAN IPv6 da ONTAP agora funcionam se especificados com colchetes.

  • Corrigido o problema em que a tentativa de importar um volume já importado retorna EOF deixando PVC em estado pendente. ("GitHub Edição nº 489")

  • Corrigido o problema quando a performance do Astra Trident diminui quando são criados snapshots > 32 em um volume SolidFire.

  • Substituído SHA-1 por SHA-256 na criação de certificado SSL.

  • Driver do ANF fixo para permitir nomes duplicados de recursos e limitar operações a um único local.

  • Driver do ANF fixo para permitir nomes duplicados de recursos e limitar operações a um único local.

Melhorias

Desvalorizações

A interface REST do Trident pode ouvir e servir apenas em endereços 127.0.0.1 ou [::1]

Mudanças em 21.10.1

Aviso A versão v21.10.0 tem um problema que pode colocar o controlador Trident em um estado CrashLoopBackOff quando um nó é removido e depois adicionado de volta ao cluster do Kubernetes. Esse problema foi corrigido no v21,10.1 (GitHub Issue 669).

Correções

  • Condição de corrida potencial fixa ao importar um volume em um back-end CVS do GCP, resultando em falha na importação.

  • Corrigido um problema que pode colocar o controlador Trident em um estado CrashLoopBackOff quando um nó é removido e depois adicionado de volta ao cluster do Kubernetes (problema 669 do GitHub).

  • Corrigido o problema em que os SVMs não eram mais descobertos se nenhum nome SVM foi especificado (problema 612 do GitHub).

Mudanças em 21.10.0

Correções

  • Corrigido o problema em que clones de volumes XFS não podiam ser montados no mesmo nó que o volume de origem (problema 514 do GitHub).

  • Corrigido o problema em que o Astra Trident registrou um erro fatal no desligamento (problema 597 do GitHub).

  • Correções relacionadas ao Kubernetes:

    • Retorne o espaço usado de um volume como o mínimo restoresSize ao criar snapshots com ontap-nas drivers e ontap-nas-flexgroup (GitHub Issue 645).

    • Corrigido o problema em que Failed to expand filesystem o erro foi registrado após o redimensionamento de volume (GitHub problema 560).

    • Corrigido o problema em que um pod poderia ficar preso Terminating no estado (GitHub problema 572).

    • Corrigido o caso em que um ontap-san-economy FlexVol pode estar cheio de LUNs instantâneos (GitHub problema 533).

    • Corrigido o problema do instalador personalizado YAML com imagem diferente (problema 613 do GitHub).

    • Corrigido cálculo do tamanho do instantâneo (GitHub edição 611).

    • Corrigido o problema em que todos os instaladores do Astra Trident podiam identificar o Kubernetes simples como OpenShift (problema 639 do GitHub).

    • Corrigido o operador do Trident para parar a reconciliação se o servidor da API do Kubernetes não estiver acessível (problema 599 do GitHub).

Melhorias

  • Adicionado suporte à unixPermissions opção para volumes de performance do GCP-CVS.

  • Adicionado suporte para volumes CVS otimizados para escala no GCP na faixa de 600 GiB a 1 TIB.

  • Aprimoramentos relacionados ao Kubernetes:

    • Adicionado suporte para Kubernetes 1,22.

    • Habilitou o operador do Trident e o gráfico Helm para trabalhar com o Kubernetes 1,22 (GitHub Issue 628).

    • Adicionado a imagem do operador ao tridentctl comando imagens (GitHub Issue 570).

Melhorias experimentais

  • Adicionado suporte para replicação de volume no ontap-san driver.

  • Adicionado suporte REST Tech Preview para os ontap-nas-flexgroup drivers , ontap-san, e ontap-nas-economy .

Problemas conhecidos

Problemas conhecidos identificam problemas que podem impedi-lo de usar o produto com sucesso.

  • Ao atualizar um cluster do Kubernetes do 1,24 para o 1,25 ou posterior que tenha o Astra Trident instalado, você deve atualizar o Values.yaml para definir excludePodSecurityPolicy true ou adicionar --set excludePodSecurityPolicy=true helm upgrade ao comando antes de atualizar o cluster.

  • Agora, o Astra Trident aplica um espaço em fsType (fsType=""`branco ) para volumes que não têm o `fsType especificado em seu StorageClass. Ao trabalhar com o Kubernetes 1,17 ou posterior, a Trident dá suporte a fornecer um espaço em branco fsType para volumes NFS. Para volumes iSCSI, é necessário definir o fsType no StorageClass ao aplicar um fsGroup contexto de uso de segurança.

  • Ao usar um back-end em várias instâncias do Astra Trident, cada arquivo de configuração de back-end deve ter um valor diferente storagePrefix para backends do ONTAP ou usar um diferente TenantName para backends do SolidFire. O Astra Trident não consegue detectar volumes que outras instâncias do Astra Trident criaram. Tentar criar um volume existente em backends ONTAP ou SolidFire é bem-sucedido, porque o Astra Trident trata a criação de volume como uma operação idempotente. Se storagePrefix ou TenantName não forem diferentes, pode haver colisões de nomes para volumes criados no mesmo back-end.

  • Ao instalar o Astra Trident (usando tridentctl ou o Operador Trident) e usar tridentctl para gerenciar o Astra Trident, você deve garantir que a KUBECONFIG variável de ambiente esteja definida. Isso é necessário para indicar o cluster do Kubernetes com tridentctl quem trabalhar. Ao trabalhar com vários ambientes do Kubernetes, você deve garantir que o KUBECONFIG arquivo seja obtido com precisão.

  • Para executar a recuperação de espaço on-line para PVS iSCSI, o SO subjacente no nó de trabalho pode exigir que as opções de montagem sejam passadas para o volume. Isso é verdade para instâncias RHEL/RedHat CoreOS, que exigem o discard "opção de montagem"; Certifique-se de que a opção Descartar mountOption está incluída no seu[`StorageClass`site para suportar descarte de blocos online.

  • Se você tiver mais de uma instância do Astra Trident por cluster Kubernetes, o Astra Trident não poderá se comunicar com outras instâncias e não poderá descobrir outros volumes que eles criaram, o que leva a um comportamento inesperado e incorreto se mais de uma instância for executada em um cluster. Só deve haver uma instância do Astra Trident por cluster Kubernetes.

  • Se os objetos baseados no Astra Trident StorageClass forem excluídos do Kubernetes enquanto o Astra Trident estiver off-line, o Astra Trident não removerá as classes de storage correspondentes de seu banco de dados quando ele voltar on-line. Você deve excluir essas classes de armazenamento usando tridentctl ou a API REST.

  • Se um usuário excluir um PV provisionado pelo Astra Trident antes de excluir o PVC correspondente, o Astra Trident não excluirá automaticamente o volume de backup. Você deve remover o volume via tridentctl ou a API REST.

  • A ONTAP não pode provisionar simultaneamente mais de um FlexGroup de cada vez, a menos que o conjunto de agregados seja exclusivo para cada solicitação de provisionamento.

  • Ao usar o Astra Trident mais de IPv6 TB, você deve especificar managementLIF e dataLIF na definição de back-end entre colchetes. Por exemplo, [fd20:8b1e:b258:2000:f816:3eff:feec:0].

    Observação Não é possível especificar dataLIF em um back-end de SAN ONTAP. O Astra Trident descobre todas as LIFs iSCSI disponíveis e as usa para estabelecer a sessão multipath.

  • Se estiver usando solidfire-san o driver com OpenShift 4,5, certifique-se de que os nós de trabalho subjacentes usem MD5 como o algoritmo de autenticação CHAP. Os algoritmos CHAP seguros compatíveis com FIPS SHA1, SHA-256 e SHA3-256 estão disponíveis com o Element 12,7.

Encontre mais informações