Nesta página, explicamos os conceitos de armazenamento do GKE no VMware.
Resumo
O GKE no VMware se integra a sistemas externos de armazenamento em blocos ou arquivos por meio de:
- Driver de Container Storage Interface (CSI) do vSphere
- Drivers de CSI de terceiros
- Plug-ins de volume do Kubernetes na árvore
Repositórios de dados do vSphere
Ao criar um cluster de administrador, você especifica um datastore atual do vSphere para os dados do etcd do cluster.
Ao criar um cluster de usuário, é possível usar o mesmo repositório de dados que o cluster de administrador ou especificar um diferente. Também é possível especificar repositórios de dados para pools de nós individuais.
Os repositórios 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.
StorageClasses
Ao criar uma PersistentVolumeClaim, é possível especificar uma StorageClass que fornece informações sobre como o armazenamento será provisionado. Se você não especificar uma StorageClass, a StorageClass padrão será usada.
StorageClass do cluster de administrador
Nos clusters de administrador, há uma StorageClass chamada standard, que
é designada como a StorageClass padrão. A StorageClass standard lista
o plug-in de volume em árvore do vSphere como o provisionador.
Para ver a StorageClass standard:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
standard --output yaml
Na saída, é possível ver que standard é a StorageClass padrão e
o provisionador é o plug-in de volume em árvore do vSphere,
kubernetes.io/vsphere-volume. Também é possível ver o nome de um repositório de dados
do vSphere.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
...
labels:
bundle.gke.io/component-name: admin-storage-class
name: standard
...
parameters:
datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...
StorageClasses do cluster de usuário
Nos clusters de usuário, há uma StorageClass chamada standard e outra
chamada standard-rwo.
A StorageClass standard-rwo é designada como a StorageClass padrão e
lista o driver de CSI do vSphere como provisionador.
Para ver a StorageClass standard-rwo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
standard-rwo --output yaml
Na saída, é possível ver que standard-rwo é a StorageClass padrão e
o provisionador é o driver de CSI do vSphere, csi.vsphere.vmware.com. Também é
possível ver o URL de um repositório de dados do vSphere:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
...
labels:
bundle.gke.io/component-name: user-vsphere-csi-driver-addon
...
name: standard-rwo
...
parameters:
datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...
Plug-ins de volume do Kubernetes na árvore
O Kubernetes é fornecido com vários plug-ins de volume em árvore. No entanto, a maioria desses plug-ins está descontinuada (incluindo o plug-in de volume em árvore do vSphere). Para mais informações, consulte o projeto de migração de CSI.
Migração de CSI para o driver de armazenamento do vSphere
No passado, o plug-in de volume em árvore do vSphere era o provisionador da StorageClass padrão nos clusters de usuário. Agora, esse plug-in está descontinuado e o driver de CSI do vSphere é o provisionador da StorageClass padrão nos clusters de usuário. Recomendamos que você use o driver de CSI do vSphere em vez do plug-in de volume em árvore.
A partir da versão 1.15 do GKE no VMware, o recurso de migração de CSI do Kubernetes é ativado por padrão para o plug-in de volume do vSphere em árvore. Isso significa que se uma carga de trabalho usar um volume em árvore do vSphere, todas as chamadas de operações de armazenamento interno serão redirecionadas automaticamente para o driver de CSI do vSphere.
Por exemplo, suponha que uma PersistentVolumeClaim especifique a StorageClass
standard, que lista o plug-in de volume em árvore do vSphere,
kubernetes.io/vsphere-volume, como o provisionador. Em seguida, qualquer carga de trabalho que use
essa PersistentVolumeClaim terá suas chamadas de operações de armazenamento redirecionadas para
o driver de CSI do vSphere. csi.vsphere.vmware.com.
Verificações de simulação
Quando você cria um novo cluster ou atualiza um atual, há verificações de simulação que garantem que o ambiente seja adequado para a migração de CSI.
Por exemplo, a simulação verifica o seguinte:
- Verifica se as versões do vCenter e do ESXI são apropriadas.
- Verifica se o driver de CSI do vSphere está ativado, caso haja PersistentVolumes em árvore do vSphere.
- Verifica se as StorageClasses do vSphere não têm determinados parâmetros que são ignorados após a migração de CSI.
- Verifica as anotações em PersistentVolumes e PersistentVolumeClaims criados de maneira estática para a migração de CSI.
- Verifique se o cluster pode executar uma carga de trabalho usando um volume CSI provisionado pelo driver CSI do vSphere.
Para mais informações, consulte Como executar verificações de simulação.
Problemas conhecidos
Há vários problemas conhecidos relacionados ao driver de CSI do vSphere. Para informações e soluções alternativas, consulte a seção "Problemas conhecidos" nas Notas de lançamento do driver de CSI do VMWare vSphere 3.0.
Concluir a migração para o CSI
Com o recurso de migração do CSI do Kubernetes ativado por padrão na versão 1.15, o
PersistentVolume apoiado pelo plug-in de volume do vSphere em árvore continua
funcionando em um ambiente somente CSI, apenas redireciona as chamadas de operação
de plug-in em árvore para o plug-in CSI. Como a especificação PersistentVolume é imutável,
ela será a mesma do plug-in de volume na árvore.
Por isso, o conjunto completo de recursos do CSI, como expansão de volume e recursos de snapshot de volume, não está disponível para esses volumes. Para aproveitar esses recursos, a carga de trabalho com estado precisa ser completamente migrada para o CSI, recriando a especificação do recurso do Kubernetes com campos CSI. Desenvolvemos um conjunto de ferramentas automatizadas para ajudar a migrar cargas de trabalho com estado para o CSI sem inatividade do aplicativo, permitindo que você use o conjunto de recursos CSI completo.
Como usar drivers de terceiros
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 a StorageClass como padrão do cluster ou configurar as cargas de trabalho usando a StorageClass (exemplo de StatefulSet).
Parceiros de armazenamento
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.
Expansão de volume
É possível expandir o tamanho de um volume persistente após ele ter sido provisionado editando a solicitação de capacidade na PersistentVolumeClaim. É 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 de CSI do vSphere, a expansão off-line está disponível nas versões do vSphere 7.0 e posteriores e a expansão on-line está disponível nas versões do vSphere 7.0 Atualização 2 e posteriores.
A StorageClass standard-rwo define allowVolumeExpansion como verdadeiro por padrão
para clusters recém-criados em execução nas versões do vSphere 7.0 ou posteriores. É possível usar a expansão on-line
e off-line para volumes usando essa StorageClass. No caso de um cluster
com upgrade, como StorageClasses não são modificadas em upgrades de cluster, quando
ele é atualizado da 1.7 para a 1.8, a configuração allowVolumeExpansion em
standard-rwo permanece não definida, o que significa que a expansão de volume 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.
Limpeza de volume
Quando você exclui um cluster de usuário, os volumes provisionados pelo driver de CSI do vSphere não são excluídos. Exclua todos os volumes, PersistentVolumeClaims e StatefulSets antes da exclusão do cluster.
Solução de problemas
Consulte Solução de problemas do armazenamento.