Nesta página, explicamos os conceitos de armazenamento do GKE no VMware.
Resumo
O GKE no VMware integra-se a sistemas externos de armazenamento em blocos ou arquivos por meio do armazenamento VMware vSphere, plug-ins de volume em árvore do Kubernetes (ou "drivers") e drivers do Container Storage Interface (CSI).
O GKE no VMware usa um StorageClass padrão do Kubernetes para provisionar armazenamento de cargas de trabalho com estado em um repositório de dados do vSphere. Também é possível usar um StorageClass para provisionar diferentes volumes de armazenamento.
Armazenamento do vSphere
Por padrão, o GKE no VMware usa o armazenamento do vSphere. O cluster de administrador requer um armazenamento de dados do vSphere pré-provisionado para os dados etcd.
Quando você cria um cluster de usuário, o GKE no VMware usa o plug-in de volume do vSphere do Kubernetes para provisionar dinamicamente novos discos de máquina virtual (VMDKs, na sigla em inglês) em um repositório de dados do vSphere. Observação: antes da versão 1.2, os clusters de usuário usavam o mesmo armazenamento de dados que os clusters de administrador.
Os armazenamentos de dados do vSphere usados pelos clusters de administrador e de usuário podem receber um backup de NFS, vSAN ou VMFS em um dispositivo de bloco, como uma matriz de armazenamento externo. Em um ambiente de vários hosts, cada dispositivo de bloco precisa ser anexado a todos os hosts no ambiente, e o armazenamento de dados precisa ser configurado em cada host usando a opção Mount Datastore em outros hosts.
Armazenamento padrão
O GKE no VMware inclui um StorageClass padrão do Kubernetes, que determina como o Kubernetes precisa provisionar o armazenamento. Depois que o Kubernetes provisiona os volumes de armazenamento, eles são representados pelos PersistentVolumes do Kubernetes.
O StorageClass padrão de um cluster de usuário aponta para um armazenamento de dados do vSphere, que
é definido no campo datastore da configuração do StorageClass. Por padrão,
os PersistentVolumes do Kubernetes provisionados no cluster de usuário são VMDKs desse
armazenamento de dados. Esse não é necessariamente o mesmo armazenamento de dados usado pelo cluster de administrador.
No GKE no VMware, os StatefulSets do Kubernetes (cargas de trabalho com estado que normalmente exigem armazenamento permanente) usam PersistentVolumeClaims respaldados por StorageClasses que apontam para o armazenamento do vSphere por padrão.
Interface do Container Storage
A Container Storage Interface (CSI) é uma API aberta padrão que permite ao Kubernetes expor sistemas de armazenamento arbitrários a cargas de trabalho em contêineres. Quando você implanta um driver de volume compatível com CSI em clusters do GKE no VMware, as cargas de trabalho podem se conectar diretamente a um dispositivo de armazenamento compatível sem precisar passar pelo armazenamento do vSphere.
Para usar o CSI no cluster, você precisa implantar o driver CSI fornecido pelo fornecedor de armazenamento. Em seguida, é possível configurar cargas de trabalho para usar o StorageClass do driver ou defini-lo como o StorageClass padrão.
Fizemos parcerias com muitos fornecedores de armazenamento para qualificar seus sistemas de armazenamento com o GKE no VMware. Veja a lista completa de parceiros de armazenamento qualificados.
Driver CSI do vSphere
Por padrão, o GKE no VMware aproveita o plug-in do volume em árvore do VMware, que ativa automaticamente o suporte a repositórios de dados do VMware, incluindo o vSAN. O driver CSI do vSphere é a implementação do driver de volume do vSphere do Container Storage Interface e é um componente do VMware Cloud Native Storage. Ele é implantado automaticamente no GKE no VMware e está disponível a partir da versão 1.7 do GKE no VMware.
Expansão de volume
A expansão de volume é um recurso Beta no Kubernetes 1.20.
É possível expandir o tamanho de um volume persistente após ele ter sido provisionado editando a solicitação de capacidade no PersistentVolumeClaim (PVC). É possível fazer uma expansão on-line enquanto o volume está em uso por um pod ou uma expansão off-line em que o volume não está em uso.
Para o driver CSI do vSphere, a expansão off-line está disponível nas versões do vSphere >= 7.0 e a expansão on-line está disponível nas versões do vSphere >= 7.0, atualização 2.
O driver CSI do vSphere StorageClass standard-rwo, que é instalado automaticamente em clusters
de usuário, define allowVolumeExpansion como verdadeiro por padrão para clusters recém-criados em execução em >= vSphere 7.0. É possível usar a expansão on-line e off-line para volumes usando esse StorageClass. Para um cluster com upgrade, como
StorageClasses não são modificados em upgrades de cluster, quando um cluster é atualizado
de 1.7 para 1.8, a configuração allowVolumeExpansion em standard-rwo permanece não definida, o que significa volume expansão não é permitida.
Para mais informações sobre a expansão de volume, consulte Como usar a expansão de volume.
Snapshots de volume do CSI
É possível criar snapshots de armazenamento permanente usando os recursos VolumeSnapshot e VolumeSnapshotClass. Para usar esse recurso em um volume CSI, o driver CSI precisa ser compatível com snapshots de volume, e o contêiner de arquivo secundário external-snapshotter precisa ser incluído na implantação do driver CSI.
Para mais informações sobre snapshots de volume, consulte Como usar snapshots de volume.
Os controladores de snapshot do CSI são implantados automaticamente quando você cria um cluster.
A partir da versão 1.8 do GKE no VMware, estão disponíveis as versões v1 de objetos VolumeSnapshot,
VolumeSnapshotContent e VolumeSnapshotClass. As versões v1beta1 estão obsoletas e deixarão de ser exibidas a partir de uma versão posterior.
Limpeza de volume
Quando você exclui um cluster de usuário, os volumes provisionados pelo plug-in do volume em árvore da VMware podem não ser excluídos. No entanto, ao excluir um cluster de usuário, os volumes provisionados pelo driver CSI do vSphere não são excluídos. Você precisa confirmar se todos os volumes, PVCs e StatefulSets foram excluídos antes de excluir o cluster.
Plug-ins de volume do Kubernetes na árvore
O Kubernetes vem com vários plug-ins de volume na árvore. Você tem a opção de usar qualquer um deles para fornecer armazenamento em blocos ou em arquivos para suas cargas de trabalho com estado. Os plug-ins em árvore permitem que as cargas de trabalho se conectem diretamente ao armazenamento sem precisar passar pelo vSphere.
Enquanto o armazenamento do vSphere fornece automaticamente o provisionamento dinâmico de volumes dentro de um armazenamento de dados apoiado por qualquer dispositivo de armazenamento iSCSI, FC ou NFS, muitos dos plug-ins em árvore não são compatíveis com o provisionamento dinâmico. Elas exigem a criação manual de PersistentVolumes.
A tabela a seguir descreve vários plug-ins de volume na árvore:
| Plug-in de volume na árvore | Descrição | Modos de acesso compatíveis | Provisionamento dinâmico |
|---|---|---|---|
| Fibre Channel | Plug-in de armazenamento genérico | Leitura/gravação de pod único | Não |
| iSCSI | Plug-in de armazenamento genérico | Leitura/gravação de pod único | Não |
| NFS | Plug-in de armazenamento genérico | Ler/gravar vários pods | Não |
Como configurar o armazenamento de cluster
Se você quiser provisionar volumes de armazenamento diferentes de armazenamentos de dados do vSphere, poderá criar um novo StorageClass em um cluster que use um driver de armazenamento diferente. Em seguida, é possível definir o StorageClass como padrão do cluster ou configurar as cargas de trabalho usando o StorageClass (exemplo de StatefulSet).
Solução de problemas
Consulte Solução de problemas do armazenamento.