Notas de versão
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.
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 22.01.1
A NetApp está continuamente melhorando e aprimorando seus produtos e serviços. Aqui estão alguns dos recursos mais recentes do Astra Trident.
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 (desde 22.10.1)
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
-
Melhorias do Kubernetes:
-
Adicionado suporte para Kubernetes 1,23.
-
Adicione opções de agendamento para pods Trident quando instalado via Operador Trident ou Helm. ("GitHub Edição nº 651")
-
-
Permitir volumes entre regiões no driver do GCP. ("GitHub Edição nº 633")
-
Adicionado suporte para a opção 'unixPermissions' aos volumes do ANF. ("GitHub Edição nº 666")
Desvalorizações
A interface REST do Trident pode ouvir e servir apenas em endereços 127.0.0.1 ou [::1]
Mudanças no Astra Trident 21.10.1
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 (desde Astra Trident 21,07)
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 eontap-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
, eontap-nas-economy
.
Problemas conhecidos
Problemas conhecidos identificam problemas que podem impedi-lo de usar o produto com sucesso.
-
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 brancofsType
para volumes NFS. Para volumes iSCSI, é necessário definir ofsType
no StorageClass ao aplicar umfsGroup
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 diferenteTenantName
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. SestoragePrefix
ouTenantName
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 usartridentctl
para gerenciar o Astra Trident, você deve garantir que aKUBECONFIG
variável de ambiente esteja definida. Isso é necessário para indicar o cluster do Kubernetes comtridentctl
quem trabalhar. Ao trabalhar com vários ambientes do Kubernetes, você deve garantir que oKUBECONFIG
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 usandotridentctl
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
edataLIF
na definição de back-end entre colchetes. Por exemplo,[fd20:8b1e:b258:2000:f816:3eff:feec:0]
. -
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.