Container Service for Kubernetes:Use dynamic volumes and cloud disks

Como funciona

Um StatefulSet utiliza discos em nuvem como volumes de armazenamento dinâmico por meio do seguinte processo:

Pré-requisitos

• Limitações de zona de disponibilidade: Exceto pelos discos em nuvem ESSD com redundância de zona, os demais tipos de disco só podem ser anexados a Pods na mesma zona de disponibilidade.

• Limitações de família de tipos de instância: Alguns tipos de disco em nuvem só podem ser anexados a famílias de tipos de instância específicas.

• Requisitos do componente CSI: Os componentes csi-plugin e csi-provisioner devem estar instalados.

  Os componentes CSI são instalados por padrão. Verifique a página Add-ons para garantir que eles ainda estejam instalados. Recomendamos atualizar os componentes CSI para a versão mais recente.

• Limitações de nó virtual: Para usar um disco em nuvem em um nó virtual, seu cluster e o kube-scheduler devem atender aos seguintes requisitos de versão.

  Requisitos de versão

  Versão do cluster	Versão do kube-scheduler
  1,28 ou posterior	6.9.3 ou posterior
  1,26	6.8.7
  1,24	6.4.7
  1,22	6.4.5

• Limitações do Lingjun Node: Para utilizar um disco em nuvem em um Lingjun Node, é necessário atender aos seguintes requisitos.

  Requisitos

  • Componente CSI: v1.34.3 ou posterior.

  • Autorizar funções do RAM: Adicione manualmente as permissões eflo:DescribeNode e eflo:DescribeNodeType à função do RAM AliyunCCCSIPluginRole.

  • Tag do disco em nuvem:

    1. Acesse Console do ECS - Block Storage - Disks.

    2. Ao criar um disco em nuvem, adicione a tag createdByProduct:eflo. Essa tag só pode ser adicionada durante a criação do disco.

       Exemplo:

       

       Se o erro OperationDenied.HpnZoneMismatch ocorrer durante a montagem, consulte O que fazer se um evento de Pod reportar o erro "OperationDenied.HpnZoneMismatch" ao montar um disco em nuvem em um nó Lingjun? .

    Após a criação, utilize esse disco em nuvem para criar manualmente um PV e vinculá-lo a um PVC. Esse disco em nuvem só pode ser agendado para nós Lingjun.

Etapa 3: Verificar o armazenamento persistente

Para verificar se os dados no disco em nuvem são persistentes, grave dados no disco, exclua o Pod e verifique se os dados persistem após a recriação do Pod.

1. Grave dados de teste no Pod.

   No Pod web-1, crie um arquivo chamado test no diretório /data, que é o ponto de montagem do disco em nuvem.

   kubectl exec web-1 -- touch /data/test
   kubectl exec web-1 -- ls /data

   Saída esperada:

   lost+found
   test

2. Simule uma falha de Pod excluindo-o.

   kubectl delete pod web-1

   Execute kubectl get pod -l app=nginx novamente. Um novo Pod com o mesmo nome, web-1, é criado automaticamente.

3. Verifique os dados no novo Pod.

   No novo Pod web-1, verifique o diretório /data novamente.

   kubectl exec web-1 -- ls /data

   A saída confirma que o arquivo test ainda existe. Isso demonstra que o armazenamento persistente preserva os dados, mesmo após a exclusão e recriação do Pod.

   lost+found
   test

Implantação em produção

• Alta disponibilidade

  • Seleção de disco em nuvem

    Avalie fatores como desempenho, faturamento, zonas de disponibilidade e famílias de tipos de instância para garantir que seus Pods sejam agendados em nós compatíveis.

    Ao selecionar um tipo de disco em nuvem, observe que os discos SSD e Ultra disks estão sendo descontinuados. Recomendamos o uso de discos ESSD PL0 ou ESSD Entry para substituir os Ultra disks, e discos ESSD AutoPL para substituir os discos SSD.

  • Recuperação de desastres entre zonas

    • Recuperação de desastres no nível da aplicação: Para cargas de trabalho críticas, como bancos de dados, implante instâncias da aplicação em várias zonas de disponibilidade e use o mecanismo nativo de sincronização de dados da aplicação para garantir alta disponibilidade.

    • Recuperação de desastres no nível de armazenamento: Escolha um tipo de disco em nuvem que suporte recuperação de desastres multizona. Esse recurso grava dados sincronizadamente em diferentes zonas de disponibilidade dentro da mesma região, permitindo failover entre zonas. Para mais informações, consulte Usar discos redundantes colocalizados ESSD.

• Segurança de dados e backup

  • Prevenção contra exclusão acidental de dados:

    Para evitar perda de dados, defina a reclaimPolicy da StorageClass como Retain. Isso garante que o disco em nuvem subjacente seja retido quando o PVC for excluído, simplificando a recuperação de dados.

  • Backups regulares

    Volumes dinâmicos simplificam o provisionamento de recursos, mas não substituem backups de dados. Para cargas de trabalho críticas, use o Backup Center para fazer backup e restaurar seus dados.

  • Criptografia em repouso: Para aplicações que lidam com dados sensíveis, configure encrypted: "true" na StorageClass para criptografar discos em nuvem.

• Otimização de desempenho e custos

  • Anexação paralela

    Para acelerar a inicialização do Pod, use anexação paralela para discos em nuvem.

  • Redimensionamento online de volumes

    Defina allowVolumeExpansion: true na StorageClass para redimensionar volumes de armazenamento de disco em nuvem online quando suas necessidades de armazenamento aumentarem.

  • Monitoramento e alertas de armazenamento

    Configure alertas com base no monitoramento de armazenamento de contêineres para detectar prontamente anomalias em volumes de armazenamento ou gargalos de desempenho.

Faturamento

Discos em nuvem provisionados dinamicamente por uma StorageClass utilizam o modelo de pagamento conforme o uso. Para mais informações, consulte faturamento do block storage e preços do block storage.

Limpar recursos

Para evitar cobranças inesperadas e garantir a segurança dos dados, siga estas etapas para liberar recursos não utilizados.

1. Exclua a carga de trabalho

   • Ação: Exclua todas as aplicações que usam o PersistentVolumeClaim (PVC) associado, como Deployments e StatefulSets. Isso interrompe os Pods em execução e desmonta os volumes associados.

     Comando de exemplo: kubectl delete deployment <your-deployment-name>

2. Exclua o PVC

   • Ação: Exclua o PVC associado à sua aplicação. A reclaimPolicy da StorageClass determina a liberação do PersistentVolume (PV) vinculado e do disco em nuvem subjacente.

     • Delete: Se a política for Delete, excluir o PVC também exclui o PV vinculado e o disco em nuvem subjacente. Esta ação é irreversível. Prossiga com cautela.

       Para evitar perda acidental de dados, você pode criar uma política de snapshot automático para fazer backup do disco em nuvem antes da exclusão.

     • Retain: Se a política for Retain, excluir o PVC altera o status do PV vinculado para Released, mas o objeto PV e o disco em nuvem subjacente são retidos. Se você não precisar mais do disco em nuvem e de seus dados, siga as instruções em Liberar um disco em nuvem para excluí-lo. Esta ação é irreversível. Prossiga com cautela.

     Comando de exemplo: kubectl delete pvc <your-pvc-name>

3. Exclua as definições de recursos de armazenamento do Kubernetes. Esta ação remove apenas as definições de recursos do cluster e não exclui o disco em nuvem subjacente.

   • Exclua o PV

     • Ação: Você pode excluir manualmente a definição de recurso para um PV no estado Released.

     • Comando de exemplo: kubectl delete pv <your-pv-name>

   • Exclua a StorageClass

     • Ação: Se você não precisar mais deste tipo de armazenamento, poderá excluir a StorageClass correspondente.

     • Comando de exemplo: kubectl delete sc <your-storageclass-name>

   Perguntas frequentes

   PVC preso no estado Pending ao ser agendado para um nó virtual

   Esse problema pode ocorrer se você usar uma StorageClass que não suporta agendamento para nós virtuais. Quando um Pod é agendado para um nó virtual usando rótulos ou anotações específicas, não é possível usar uma StorageClass configurada com volumeBindingMode: WaitForFirstConsumer.

   • Motivo:O modo WaitForFirstConsumer depende do kube-scheduler para selecionar um nó físico para um Pod. Essa seleção determina a zona de disponibilidade, e um disco em nuvem é então criado nessa zona. No entanto, o mecanismo de agendamento para nós virtuais não segue esse processo. Isso impede que o CSI obtenha as informações da zona de disponibilidade, o que, por sua vez, impede a criação do PV, deixando o PVC no estado Pending.

   • Se você encontrar esse problema, verifique se o seu Pod ou seu namespace possui alguma das seguintes configurações:

     • Rótulo:

       • alibabacloud.com/eci: "true": Agenda o Pod para execução no ECI.

       • alibabacloud.com/acs: "true": Agenda o Pod para um Pod ACS.

     • Fixação de nó:

       • Definir spec.nodeName como um nome de nó com o prefixo virtual-kubelet fixa o Pod nesse nó.

     • Anotação:

       • k8s.aliyun.com/eci-vswitch: Especifica o vSwitch para o Pod ECI.

       • k8s.aliyun.com/eci-fail-strategy: "fail-fast": Define a estratégia de falha para o Pod ECI como fail-fast.

   Montar um disco em nuvem para um único Pod ou Deployment de réplica única

   Para aplicações simples que não exigem dimensionamento de múltiplas réplicas ou identificadores de rede estáveis, você pode criar manualmente um PersistentVolumeClaim e montá-lo em um Pod ou Deployment para armazenamento persistente.

   O fluxo de trabalho é o seguinte: Escolher uma StorageClass -> Criar um PersistentVolumeClaim -> Montar o PersistentVolumeClaim na sua aplicação.

   1. Prepare uma StorageClass.

   2. Crie um PersistentVolumeClaim para solicitar recursos de armazenamento.

      kubectl

      1. Crie um arquivo chamado disk-pvc.yaml.

         apiVersion: v1
         kind: PersistentVolumeClaim
         metadata:
           name: disk-pvc
         spec:
           # Access mode
           accessModes:
           - ReadWriteOnce
           volumeMode: Filesystem
           resources:
             requests:
               # Requested storage capacity, which is the size of the cloud disk
               storage: 20Gi
           # Associate with the StorageClass created earlier
           storageClassName: alicloud-disk-topology-alltype 

         A tabela a seguir descreve os parâmetros.

         Parâmetro	Descrição
         accessModes	Os modos de acesso do volume. Valores válidos são ReadWriteOnce, ReadOnlyMany e ReadWriteMany. Os modos de acesso suportados dependem da configuração multiAttach na StorageClass e da configuração volumeMode no PersistentVolumeClaim. multiAttach especifica se o multi-attach de disco em nuvem deve ser ativado. O valor padrão é false, o que significa que o recurso está desativado. Quando multiAttach é false e volumeMode está definido como qualquer valor, o único modo de acesso suportado é ReadWriteOnce. Quando multiAttach é true e volumeMode é Filesystem, os modos de acesso suportados são ReadWriteOnce e ReadOnlyMany. Quando multiAttach está definido como true e volumeMode está definido como Block, todos os três modos de acesso são suportados. Importante Neste cenário, o modo de acesso é tipicamente ReadWriteOnce (RWO), o que significa que ele pode ser montado por apenas um Pod por vez. Portanto, o número de réplicas do Deployment não pode ser maior que 1. Se você tentar escalar horizontalmente, novos Pods permanecerão no estado Pending porque não conseguirão montar o disco em nuvem que já está em uso.
         volumeMode	O modo do volume. Valores válidos: Filesystem (padrão): O volume é formatado e montado como um diretório. Block: O volume é fornecido ao Pod como um dispositivo de bloco bruto e não formatado.
         storage	A capacidade de armazenamento solicitada. Diferentes tipos de disco em nuvem possuem diferentes faixas de capacidade. Certifique-se de que o valor de storage esteja dentro dos limites de capacidade do tipo de disco em nuvem correspondente à StorageClass referenciada para evitar falha na criação do disco.
         storageClassName	O nome da StorageClass a ser usada para esta solicitação.

      2. Crie o PersistentVolumeClaim.

         kubectl create -f disk-pvc.yaml

      3. Verifique o PersistentVolumeClaim.

         kubectl get pvc

         Na saída, como a StorageClass usa o modo WaitForFirstConsumer, o PVC permanece no estado Pending até que o primeiro Pod que o utiliza seja agendado com sucesso.

         NAME       STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS                            VOLUMEATTRIBUTESCLASS   AGE
         disk-pvc   Pending                                      alicloud-disk-wait-for-first-consumer   <unset>                 14s

      Console

      1. No painel de navegação à esquerda da página de gerenciamento do cluster, escolha Volumes > Persistent Volume Claims.

      2. Na página Persistent Volume Claims, clique em Create. Selecione Cloud Disk como PVC Type e configure os parâmetros conforme solicitado.

         Parâmetro	Descrição
         Allocation Mode	Selecione Use StorageClass.
         Existing Storage Class	Selecione uma StorageClass padrão ou criada manualmente.
         Capacity	A capacidade de armazenamento solicitada. Diferentes tipos de disco em nuvem possuem diferentes faixas de capacidade. Certifique-se de que o valor de storage esteja dentro dos limites de capacidade do tipo de disco em nuvem correspondente à StorageClass referenciada para evitar falha na criação do disco.
         Access Mode	Este cenário suporta apenas ReadWriteOnce, o que significa que um único Pod pode montar o volume com acesso de leitura e gravação.

         Após criar o PersistentVolumeClaim, você pode visualizá-lo na página Persistent Volume Claims.

   3. Monte o PersistentVolumeClaim na sua aplicação.

      1. Crie um arquivo chamado disk-deployment.yaml.

         Expandir para ver exemplo YAML

         apiVersion: apps/v1
         kind: Deployment
         metadata:
           name: single-pod-app
         spec:
           # Ensure the replica count is 1
           replicas: 1
           selector:
             matchLabels:
               app: nginx-single
           template:
             metadata:
               labels:
                 app: nginx-single
             spec:
               containers:
               - name: nginx
                 image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
                 ports:
                 - containerPort: 80
                 # Define the mount point in the container
                 volumeMounts:
                 - name: my-persistent-storage  # Must match the name defined in volumes below
                   mountPath: /data  # Mount to the /data directory in the container
               # Declare and reference the PVC at the pod level
               volumes:
               - name: my-persistent-storage # Volume to be referenced by the container
                 persistentVolumeClaim:
                   claimName: disk-pvc # Reference the PVC created earlier

      2. Implante o Deployment.

         kubectl create -f disk-deployment.yaml

   4. Verifique o resultado da montagem.

      1. Confirme se o Pod está em execução.

         kubectl get pods -l app=nginx-single

      2. Conecte-se ao Pod e verifique se o disco em nuvem está montado no diretório /data.

         # Get the pod name
         POD_NAME=$(kubectl get pods -l app=nginx-single -o jsonpath='{.items[0].metadata.name}')
         
         # Run the df -h command on the mount point
         kubectl exec $POD_NAME -- df -h /data

         A saída a seguir indica que o disco em nuvem de 20 GiB foi montado com sucesso.

         Filesystem      Size  Used Avail Use% Mounted on
         /dev/vdb         20G   24K   20G   1% /data

   Referências

   • Para recomendações sobre como configurar alta disponibilidade para volumes de disco em nuvem em uma implantação multizona, consulte Recomendações de configuração de alta disponibilidade para volumes de disco em nuvem.

   • Para saber mais sobre parâmetros de configuração de carga de trabalho, consulte Criar uma carga de trabalho com estado com StatefulSet e Criar uma carga de trabalho sem estado com Deployment.

   • Se você não precisar mais de um disco em nuvem e quiser parar de ser cobrado por ele, poderá Liberar um disco em nuvem. Liberar o disco o exclui permanentemente junto com todos os seus dados.

   • Se você encontrar problemas ao usar volumes de disco em nuvem, consulte Perguntas frequentes sobre volumes de disco em nuvem.

   • Se o seu cluster ainda estiver usando o componente obsoleto FlexVolume, consulte Migrar do FlexVolume para CSI.