Esta página explica os conceitos de armazenamento do Google Distributed Cloud (apenas software) para VMware.
Resumo
O Google Distributed Cloud integra-se com sistemas de armazenamento de blocos ou ficheiros externos através do seguinte:
- O controlador da interface de armazenamento de contentores (CSI) do vSphere
- Controladores CSI de terceiros
- Plug-ins de volume no Kubernetes
Armazenamentos de dados do vSphere
Quando cria um cluster de administrador, especifica um repositório de dados do vSphere existente para os dados etcd do cluster.
Quando cria um cluster de utilizadores, pode usar o mesmo repositório de dados que o cluster de administrador ou pode especificar um repositório de dados diferente. Também pode especificar armazenamentos de dados para pools de nós individuais.
Os arquivos de dados do vSphere usados pelos clusters de administrador e de utilizador podem ser suportados por NFS, vSAN ou VMFS num dispositivo de blocos, como uma matriz de armazenamento externo. Num ambiente com vários anfitriões, cada dispositivo de blocos tem de estar associado a todos os anfitriões no ambiente, e o repositório de dados tem de ser configurado em cada anfitrião através da opção Montar repositório de dados em anfitriões adicionais.
StorageClasses
Quando cria um PersistentVolumeClaim, pode especificar uma StorageClass que faculte informações sobre como o armazenamento vai ser aprovisionado. Se não especificar uma StorageClass, é usada a StorageClass predefinida.
StorageClass do cluster de administrador
Nos clusters de administrador, existe uma StorageClass denominada standard e está designada como a StorageClass predefinida. A standard StorageClass lista
o plugin de volume integrado do vSphere como o aprovisionador.
Para ver a standard StorageClass:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
standard --output yaml
No resultado, pode ver que standard é a StorageClass predefinida e que o aprovisionador é o plug-in de volume na árvore do vSphere, kubernetes.io/vsphere-volume. Também pode ver o nome de um arquivo 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 utilizadores
Nos clusters de utilizadores, existe uma StorageClass denominada standard e outra StorageClass denominada standard-rwo.
O standard-rwo StorageClass é designado como o StorageClass predefinido e
apresenta o controlador CSI do vSphere como o aprovisionador.
Para ver a standard-rwo StorageClass:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
standard-rwo --output yaml
Na saída, pode ver que standard-rwo é a StorageClass predefinida e que o aprovisionador é o controlador CSI do vSphere, csi.vsphere.vmware.com. Também pode ver o URL de um arquivo 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 no Kubernetes
O Kubernetes é fornecido com vários plug-ins de volume no sistema. No entanto, a maioria destes plug-ins de volume na árvore estão descontinuados (incluindo o plug-in de volume na árvore do vSphere). Para mais informações, consulte o projeto de migração do CSI.
Migração de CSI para o controlador de armazenamento do vSphere
Anteriormente, o plug-in de volume do vSphere na árvore era o aprovisionador para a StorageClass predefinida nos clusters de utilizadores. No entanto, o plug-in de volume do vSphere integrado foi descontinuado e o controlador CSI do vSphere é o fornecedor da StorageClass predefinida nos clusters de utilizadores. Recomendamos que use o controlador CSI do vSphere em vez do plug-in de volume na árvore.
A partir da versão 1.15 do Google Distributed Cloud, a funcionalidade de migração do CSI do Kubernetes está ativada por predefinição para o plug-in de volume do vSphere no kernel. Isto significa que, se uma carga de trabalho usar um volume do vSphere na árvore, todas as chamadas de operações de armazenamento internas são automaticamente redirecionadas para o controlador CSI do vSphere.
Por exemplo, suponha que um PersistentVolumeClaim especifica a standardStorageClass, que lista o plug-in de volume na árvore do vSphere,kubernetes.io/vsphere-volume como o aprovisionador. Em seguida, qualquer carga de trabalho que use
esse PersistentVolumeClaim terá as respetivas chamadas de operações de armazenamento redirecionadas para
o controlador CSI do vSphere, csi.vsphere.vmware.com.
Verificações prévias
Quando cria um novo cluster ou atualiza um cluster, existem verificações prévias que garantem que o seu ambiente é adequado para a migração de CSI.
Por exemplo, as verificações prévias:
- Verifique se as versões do vCenter e ESXI são adequadas.
- Verifique se o controlador CSI do vSphere está ativado se existirem PersistentVolumes do vSphere no kernel.
- Verifique se as StorageClasses do vSphere não têm determinados parâmetros que são ignorados após a migração do CSI.
- Valide as anotações nos PersistentVolumes e PersistentVolumeClaims criados estaticamente na árvore necessários para a migração de CSI.
- Verifique se o cluster consegue executar com êxito uma carga de trabalho através de um volume de CSI aprovisionado pelo controlador de CSI do vSphere.
Para mais informações, consulte o artigo Executar verificações pré-voo.
Problemas conhecidos
Existem vários problemas conhecidos relacionados com o controlador CSI do vSphere. Para obter informações e soluções, consulte a secção Problemas conhecidos nas notas de lançamento do controlador CSI do VMWare vSphere 3.0.
Conclua a migração para a CSI
Com a funcionalidade de migração do CSI do Kubernetes ativada por predefinição na versão 1.15, o
PersistentVolume suportado pelo plug-in de volume do vSphere integrado continua
a funcionar num ambiente apenas de CSI. Apenas redireciona as chamadas de operação do plug-in integrado para o plug-in CSI. Uma vez que a especificação PersistentVolume é imutável, a especificação é igual à do plug-in de volume na árvore.
Devido a isto, o conjunto completo de funcionalidades do CSI, como a expansão de volume e as funcionalidades de instantâneo de volume, não está disponível para esses volumes. Para tirar partido destas funcionalidades, a carga de trabalho com estado tem de ser totalmente migrada para o CSI através da recriação da especificação de recursos do Kubernetes com campos CSI. Desenvolvemos um conjunto de ferramentas automatizadas para ajudar a migrar a carga de trabalho com estado para o CSI sem tempo de inatividade da aplicação, o que lhe permite usar o conjunto completo de funcionalidades do CSI.
Usar controladores de terceiros
Se quiser aprovisionar volumes de armazenamento que não sejam datastores do vSphere, pode criar uma nova StorageClass num cluster que use um controlador de armazenamento diferente. Em seguida, pode definir StorageClass como predefinição do cluster ou configurar as suas cargas de trabalho para usar StorageClass (exemplo de StatefulSet).
Parceiros de armazenamento
Estabelecemos parcerias com muitos fornecedores de armazenamento para qualificar os respetivos sistemas de armazenamento com o Google Distributed Cloud. Consulte a lista completa de parceiros de armazenamento qualificados.
Expansão do volume
Pode expandir o tamanho de um volume persistente depois de ter sido aprovisionado editando o pedido de capacidade na PersistentVolumeClaim. Pode fazer uma expansão online enquanto o volume está a ser usado por um Pod ou uma expansão offline quando o volume não está a ser usado.
Para o controlador CSI do vSphere, a expansão offline está disponível nas versões do vSphere >= 7.0 e a expansão online está disponível nas versões do vSphere >= 7.0 Update 2.
A standard-rwo StorageClass define allowVolumeExpansion como verdadeiro por predefinição
para clusters criados recentemente que são executados no >= vSphere 7.0. Pode usar a expansão online e offline para volumes que usam esta StorageClass. Para um cluster atualizado, uma vez que as StorageClasses não são modificadas nas atualizações de clusters, quando um cluster é atualizado da versão 1.7 para a 1.8, a definição allowVolumeExpansion em standard-rwo permanece não definida, o que significa que a expansão do volume não é permitida.
Para mais informações sobre a expansão do volume, consulte o artigo Usar a expansão do volume.
Instantâneos de volumes CSI
Pode criar instantâneos do armazenamento persistente através dos recursos
VolumeSnapshot
e
VolumeSnapshotClass. Para usar esta funcionalidade num volume de CSI, o controlador de CSI tem de suportar
cópias instantâneas de volumes e o contentor external-snapshotter sidecar tem de estar
incluído na implementação do controlador de CSI.
Para mais informações sobre os instantâneos de volume, consulte o artigo Usar instantâneos de volume.
Os controladores de instantâneos da CSI são implementados automaticamente quando cria um cluster.
Limpeza de volume
Quando elimina um cluster de utilizadores, os volumes aprovisionados pelo controlador CSI do vSphere não são eliminados. Deve eliminar todos os volumes, PersistentVolumeClaims e StatefulSets antes de eliminar o cluster.
Resolução de problemas
Consulte o artigo Resolução de problemas de armazenamento.