Share via

Opções de armazenamento para aplicativos no AKS habilitados pelo Azure Arc

  • Artigo

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Os aplicativos executados em implantações do AKS usando Serviço de Kubernetes do Azure habilitados pelo Azure Arc podem precisar armazenar e recuperar dados. Para algumas cargas de trabalho de aplicativo, os dados podem usar armazenamento local e rápido em um nó desnecessário quando os pods são excluídos (o Kubernetes usa pods para executar uma instância de um aplicativo).

Outras cargas de trabalho podem exigir armazenamento que persiste em volumes de dados mais regulares. Vários pods podem precisar compartilhar os mesmos volumes de dados ou reanexar volumes de dados se o pod for reagendado em um nó diferente. Além disso, talvez você precise de uma opção de armazenamento se os pods contiverem dados confidenciais ou informações de configuração do aplicativo.

Imagem de armazenamento de arquitetura mostrando um cluster master e um nó.

Este artigo apresenta os principais conceitos que fornecem armazenamento para seus aplicativos no AKS Arc, incluindo:

  • Volumes
  • Volumes persistentes
  • Classes de armazenamento
  • Declarações de volume persistente (PVC)

Volumes

Geralmente, os aplicativos precisam ser capazes de armazenar e recuperar dados. Como o Kubernetes normalmente trata pods individuais como recursos temporários e descartáveis, diferentes abordagens estão disponíveis para aplicativos usarem e persistirem dados. Um volume representa uma maneira de armazenar, recuperar e persistir dados entre os pods e por meio do ciclo de vida do aplicativo.

No Kubernetes, os volumes podem representar mais do que apenas um tradicional no qual as informações são armazenadas e recuperadas. Os volumes do Kubernetes também podem ser usados como uma maneira de inserir dados em um pod para os contêineres usarem. Alguns tipos comuns de volume do Kubernetes incluem:

  • emptyDir - este volume normalmente é usado como espaço temporário para um pod. Todos os contêineres dentro de um pod podem acessar os dados no volume. Os dados gravados para esse tipo de volume persistem somente para o tempo de vida do pod - quando o pod é excluído, o volume é excluído. Esse volume normalmente usa o armazenamento em disco do nó local subjacente, embora também possa existir apenas na memória do nó.

  • secret – esse volume é usado para incluir dados confidenciais, como senhas, em pods. Primeiro, você cria um segredo usando a API do Kubernetes. Ao definir o pod ou a implantação, você pode solicitar um segredo específico. Os segredos são fornecidos somente a nós com um pod agendado que o requer e o segredo é armazenado em tmpfs, não gravado em disco. Quando o último pod em um nó que requer um segredo é excluído, o segredo é excluído dos tmpfs do nó. Os segredos são armazenados dentro de um determinado namespace e só podem ser acessados pelo pods no mesmo namespace.

  • configMap - esse tipo de volume é usado para injetar as propriedades de par chave-valor no pods, como informações de configuração do aplicativo. Em vez de definir as informações de configuração do aplicativo em uma imagem de contêiner, você pode defini-la como um recurso do Kubernetes que pode ser facilmente atualizado e aplicado a novas instâncias de pods conforme eles são implantados. Semelhante ao uso de um segredo, primeiro você cria um ConfigMap usando a API do Kubernetes. Esse ConfigMap pode ser solicitado quando você define um pod ou implantação. ConfigMaps são armazenados em um determinado namespace e só podem ser acessados por pods no mesmo namespace.

Volumes persistentes

Os volumes definidos e criados como parte do ciclo de vida de pod existem somente até o pod ser excluído. Pods geralmente esperam que seu armazenamento permaneça se um pod ser reagendado em um host diferente durante um evento de manutenção, especialmente em StatefulSets. Um volume persistente é um recurso de armazenamento criado e gerenciado pela API do Kubernetes que pode existir além do tempo de vida de um pod individual.

Você pode usar volumes de disco do AKS com suporte do VHDX que são montados como ReadWriteOnce e são acessíveis a um único nó por vez. Ou você pode usar volumes de arquivos do AKS com o apoio de compartilhamentos de arquivos SMB ou NFS. Eles são montados como ReadWriteMany e estão disponíveis para vários nós simultaneamente.

Um administrador de cluster pode criar estaticamente um volume persistente ou o volume pode ser criado dinamicamente pelo servidor de API do Kubernetes. Se um pod for agendado e solicitar um armazenamento que não esteja disponível no momento, o Kubernetes poderá criar o arquivo VHDX subjacente e anexá-lo ao pod. O provisionamento dinâmico usa um StorageClass para identificar que tipo de armazenamento precisa ser criado.

Classes de armazenamento

Para definir diferentes camadas (e local) de armazenamento, você pode criar uma StorageClass. O StorageClass também define a reclaimPolicy. Essa reclaimPolicy controla o comportamento do recurso de armazenamento subjacente quando o pod é excluído e o volume persistente pode não ser mais necessário. O recurso de armazenamento subjacente pode ser excluído ou retido para uso com um pod futuro.

No AKS Arc, a classe de armazenamento padrão é criada automaticamente e usa CSV para criar volumes com suporte de VHDX. A política de recuperação garante que o VHDX subjacente seja excluído quando o volume persistente que a usou for excluído. A classe de armazenamento também configura os volumes persistentes para serem expansíveis, portanto, você só precisa editar a declaração de volume persistente com o novo tamanho.

Se nenhum StorageClass for especificado para um volume persistente, o StorageClass padrão será usado. Ao solicitar volumes persistentes, certifique-se de que eles usem o armazenamento apropriado. Você pode criar um StorageClass para necessidades adicionais.

Declarações de volume persistente

Um PersistentVolumeClaim solicita o armazenamento ReadWriteOnce ou ReadWriteMany de um StorageClass e tamanho específicos. O servidor de API do Kubernetes poderá provisionar dinamicamente o recurso de armazenamento subjacente no AKS Arc se não houver nenhum recurso existente para atender à declaração com base no StorageClass definido. A definição de pod inclui a montagem de volume depois que o volume for conectado no pod.

Um PersistentVolume é associado a um PersistentVolumeClaim depois que um recurso de armazenamento disponível é atribuído ao pod que o solicita. Há um mapeamento 1:1 de volumes persistentes para declarações.

O seguinte exemplo de manifesto YAML mostra uma declaração de volume persistente que usa o StorageClass padrão e solicita um disco 5Gi:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: aks-hci-vhdx 
spec: 
  accessModes: 
  - ReadWriteOnce 
  storageClassName: default 
  resources: 
    requests: 
      storage: 5Gi

Quando você cria uma definição de pod, a declaração de volume persistente é especificada para solicitar o armazenamento desejado. Em seguida, você também especifica o volumeMount para que seus aplicativos leiam e escrevam dados. O seguinte exemplo de manifesto YAML mostra como a declaração de volume persistente anterior pode ser usada para montar um volume em /mnt/aks-hci:

kind: Pod 
apiVersion: v1 
metadata: 
  name: nginx 
spec: 
  containers: 
    - name: myfrontend 
      image: k8s.gcr.io/nginx 
      volumeMounts: 
      - mountPath: "/mnt/aks-hci" 
        name: volume
  nodeSelector:
      kubernetes.io/os: linux
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: aks-hci-vhdx

O exemplo a seguir mostra como montar um volume em um contêiner do Windows e especificar a letra e o caminho da unidade:

volumeMounts: 
        - mountPath: "d:" 
          name: volume 
        - mountPath: "c:\k" 
          name: k-dir

Próximas etapas