Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Storage

Nesta página, explicaremos os conceitos de armazenamento do Google Distributed Cloud (somente software) para VMware.

Resumo

O Google Distributed Cloud se integra a sistemas externos de armazenamento em blocos ou arquivos desta maneira:

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 Google Distributed Cloud, 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.
Verifica se o cluster pode executar uma carga de trabalho usando um volume de CSI provisionado pelo driver de 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 CSI do Kubernetes ativado por padrão na versão 1.15, o PersistentVolume com suporte do plug-in de volume do vSphere em árvore continua funcionando em um ambiente somente CSI, apenas redirecionando as chamadas de operação do 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 atributos do CSI, como expansão de volume e snapshot de volume, não está disponível para esses volumes. Para aproveitar esses recursos, as cargas de trabalho com estado precisam ser totalmente migradas para o CSI, recriando a especificação de recursos do Kubernetes com campos CSI. Desenvolvemos uma ferramenta automatizada para migrar cargas de trabalho com estado para o CSI sem inatividade do aplicativo, o que permite usar o conjunto completo de recursos do CSI.

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 os sistemas de armazenamento com o Google Distributed Cloud. 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 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.