Compartilhar 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 o Serviço de Kubernetes do Azure habilitado pelo Azure Arc talvez precisem armazenar e recuperar dados. Para algumas cargas de trabalho de aplicativo, os dados podem usar armazenamento rápido e local 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, 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 arquitetônico mostrando um mestre e um nó de cluster.

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 que os aplicativos usem e persistam 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 maneira de inserir dados em um pod para contêineres usarem. Alguns tipos de volume comuns 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 somente na memória do nó.

  • segredo - Esse 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 para nós com um pod agendado que o exija, e o segredo é armazenado no 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 implantadas. 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. 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 AKS apoiados 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 arquivo 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 esteja 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 que tipo de armazenamento precisa ser criado.

Classes de armazenamento

Para definir diferentes níveis (e locais) 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 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 uma StorageClass para necessidades adicionais.

Declarações de volume persistente

Um PersistentVolumeClaim solicita armazenamento ReadWriteOnce ou ReadWriteMany de uma classe de armazenamento e tamanho 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 de pod inclui a montagem de volume depois que o volume for conectado no 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 manifesto YAML de exemplo 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 que seus aplicativos leiam e gravem 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 e o caminho da unidade:

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

Próximas etapas