Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Armazenamento VMware vSphere

Para fornecer cargas de trabalho com estado com armazenamento VMware vSphere, recomendamos criar uma StorageClass vSphereVolume. Essa prática provisiona dinamicamente o armazenamento vSphere quando as cargas de trabalho solicitam volumes através de um PersistentVolumeClaim.

Para provisionar dinamicamente armazenamento no vSphere, o provedor vSphere deve estar habilitado. Veja as seguintes páginas para mais informações: vSphere fora da árvore e vSphere na árvore.

Pré-requisitos

Para provisionar volumes vSphere em um cluster criado com o RKE2, o provedor de nuvem vSphere deve ser explicitamente habilitado nas opções do cluster.

Criando uma StorageClass

Os seguintes passos também podem ser realizados usando a kubectl ferramenta de linha de comando. Veja documentação do Kubernetes sobre volumes persistentes para mais detalhes.

  1. Clique em ☰ > Gerenciamento de Cluster.

  2. Escolha o cluster ao qual você deseja fornecer armazenamento vSphere e clique em Explorar.

  3. Na barra de navegação à esquerda, selecione Armazenamento  Classes de Armazenamento.

  4. Clique em Criar.

  5. Digite um Nome para a StorageClass.

  6. Em Provisionador, selecione Volume VMware vSphere.

    vsphere storage class

  7. Opcionalmente, especifique propriedades adicionais para esta classe de armazenamento em Parâmetros. Consulte a documentação de armazenamento vSphere para mais detalhes.

  8. Clique em Criar.

Criando uma Carga de Trabalho com um Volume VMware vSphere

  1. Na barra de navegação à esquerda, clique em Carga de Trabalho.

  2. Clique em Criar.

  3. Clique em StatefulSet.

  4. Na aba Modelos de Reivindicação de Volume, clique em Adicionar Modelo de Reivindicação.

  5. Digite um nome para o volume persistente.

  6. No campo Classe de Armazenamento, selecione a vSphere StorageClass que você criou.

  7. Insira a Capacidade necessária para o volume. Em seguida, clique em Definir.

  8. Atribua um caminho no campo Ponto de Montagem. Este é o caminho completo onde o volume será montado no sistema de arquivos do contêiner, por exemplo, /persistent.

  9. Clique em Criar.

Verificando a Persistência do Volume

  1. Na barra de navegação à esquerda, clique em Carga de Trabalho  Pods.

  2. Vá para a carga de trabalho que você acabou de criar e clique em ⋮ > Executar Shell.

  3. Observe o caminho na raiz onde o volume foi montado (neste caso /persistent).

  4. Crie um arquivo no volume executando o comando touch /<volumeMountPoint>/data.txt.

  5. Feche a janela do shell.

  6. Clique no nome da carga de trabalho para revelar informações detalhadas.

  7. Clique em ⋮ > Excluir.

  8. Observe que o pod foi excluído. Em seguida, um novo pod é agendado para substituí-lo, de modo que a carga de trabalho mantenha sua escala configurada de um único pod stateful.

  9. Uma vez que o pod de substituição esteja em execução, clique em Executar Shell.

  10. Inspecione o conteúdo do diretório onde o volume está montado, digitando ls -l /<volumeMountPoint>. Observe que o arquivo que você criou anteriormente ainda está presente.

    workload-persistent-data

Por que usar StatefulSets em vez de Deployments

Você deve sempre usar StatefulSets para cargas de trabalho que consomem armazenamento vSphere, pois esse tipo de recurso é projetado para resolver uma limitação do armazenamento em blocos VMDK.

Como os volumes vSphere são suportados por armazenamento em blocos VMDK, eles suportam apenas um modo de acesso de ReadWriteOnce. Essa configuração restringe o volume para que ele possa ser montado apenas em um único pod por vez, a menos que todos os pods que consomem esse volume estejam co-localizados no mesmo nó. Esse comportamento torna um recurso de implantação inutilizável para escalonamento além de uma única réplica se consumir volumes vSphere.

Mesmo usar um recurso de implantação com apenas uma única réplica pode resultar em uma situação de deadlock durante a atualização da implantação. Se o pod atualizado for agendado para um nó diferente de onde o pod existente está, ele falhará ao iniciar porque o VMDK ainda está anexado ao outro nó.

Links relacionados