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 AKS usando o Serviço 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 persista 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, você pode precisar 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
• Declarações de volume persistente (PVC)

Volumes

Os aplicativos geralmente 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 em pods e durante o 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 contêineres usarem. Alguns tipos de volume comuns do Kubernetes incluem:

• emptyDir - Este volume é comumente 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 neste tipo de volume persistem apenas durante a vida útil 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 exija, 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 do tmpfs do nó. Os segredos são armazenados dentro de um determinado namespace e só podem ser acessados por pods dentro do mesmo namespace.

• configMap - Este tipo de volume é usado para injetar propriedades de par chave-valor em 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-lo 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, você primeiro 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 dentro de 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 do pod só existem até que o pod seja excluído. Os pods geralmente esperam que seu armazenamento permaneça se um pod for reprogramado 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 AKS suportados por VHDX que são montados como ReadWriteOnce e são acessíveis a um único nó de cada vez. Ou, você pode usar volumes de arquivos AKS apoiados por 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 uma StorageClass para identificar o tipo de armazenamento que precisa ser criado.

Classes de armazenamento

Para definir diferentes níveis (e locais) de armazenamento, você pode criar um 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 backup 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 nenhuma StorageClass for especificada para um volume persistente, a StorageClass padrão será usada. Ao solicitar volumes persistentes, certifique-se de que eles usam o armazenamento apropriado. Você pode criar um StorageClass para necessidades adicionais.

Afirmações de volumes persistentes

Um PersistentVolumeClaim solicita armazenamento ReadWriteOnce ou ReadWriteMany de uma classe e tamanho de armazenamento específicos. 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 na StorageClass definida. A definição do pod inclui a montagem do volume uma vez que o volume tenha sido conectado ao pod.

Um PersistentVolume é vinculado 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 exemplo de manifesto YAML a seguir 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 

Ao criar uma definição de pod, você especifica a declaração de volume persistente para solicitar o armazenamento desejado. Em seguida, você também especifica o volumeMount para seus aplicativos lerem e gravarem dados. O exemplo de manifesto YAML 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 da unidade e o caminho:

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

Próximos passos

• Use os drivers AKS no Azure Stack HCI disk Container Storage Interface (CSI).