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

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

Os aplicativos executados em implantações do AKS usando o Serviço de Kubernetes do Azure habilitado pelo Azure Arc podem precisar armazenar e recuperar dados. Para algumas cargas de trabalho de aplicativos, 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 reprogramado 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.

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

• Volumes
• Volumes persistentes
• Classes de armazenamento
• Solicitaçõ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 os aplicativos usarem e persistirem dados. Um volume representa uma maneira de armazenar, recuperar e persistir dados entre 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 forma de inserir dados em um pod para uso dos contêineres. 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 - Este volume é usado para incluir dados confidenciais, como senhas, em pods. Primeiro, você cria um segredo usando a API do Kubernetes. Ao definir seu pod ou implantação, você pode solicitar um segredo específico. Os segredos são fornecidos apenas a nós com um pod agendado que o exige, e o segredo é armazenado em tmpfs, não gravado no disco. Quando o último pod em um nó que requer um segredo é excluído, o segredo é excluído do 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 informações de configuração do aplicativo em uma imagem de contêiner, você pode defini-las como um recurso do Kubernetes que pode ser facilmente atualizado e aplicado a novas instâncias de pods à medida que 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 uma implantação. Os ConfigMaps são armazenados em um determinado namespace e só podem ser acessados por pods dentro do 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 podem ser acessados por um único nó por vez. Ou você pode usar volumes de arquivo do AKS com suporte 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 estiver agendado e solicitar armazenamento que não está 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 um StorageClass. O StorageClass também define o 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 o 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 determinado StorageClass e tamanho. O servidor de API do Kubernetes pode 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 quando 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 manifesto YAML de exemplo a seguir mostra uma declaração de volume persistente que usa o StorageClass padrão e solicita um disco de 5 Gi:

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

Ao criar uma definição de pod, você especifica a declaração de volume persistente para solicitar o armazenamento desejado. Você também especifica o volumeMount para que seus aplicativos leiam e gravem dados. O manifesto YAML de exemplo a seguir 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

• Use o AKS no Azure Drivers de Interface de Armazenamento em Contêiner (CSI) de disco local.