Opções de armazenamento para aplicações no AKS ativadas pelo Azure Arc

  • Artigo

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

As aplicações executadas em implementações do AKS com Azure Kubernetes Service ativadas pelo Azure Arc poderão ter de armazenar e obter dados. Para algumas cargas de trabalho da aplicação, os dados podem utilizar armazenamento local e rápido num nó desnecessário quando os pods são eliminados (o Kubernetes utiliza pods para executar uma instância de uma aplicação).

Outras cargas de trabalho podem exigir armazenamento que persista em volumes de dados mais regulares. Vários pods poderão ter de partilhar os mesmos volumes de dados ou voltar a ligar volumes de dados se o pod for reagendado num nó diferente. Além disso, poderá precisar de uma opção de armazenamento se os pods contiverem dados confidenciais ou informações de configuração da aplicação.

Imagem de armazenamento arquitectónico a mostrar um mestre de cluster e um nó.

Este artigo apresenta os principais conceitos que fornecem armazenamento às suas aplicações no AKS Arc, incluindo:

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

Volumes

Muitas vezes, as aplicações precisam de ser capazes de armazenar e obter dados. Uma vez que o Kubernetes trata normalmente os pods individuais como recursos temporários e descartáveis, estão disponíveis diferentes abordagens para que as aplicações utilizem e persistam dados. Um volume representa uma forma de armazenar, obter e manter dados entre pods e através do ciclo de vida da aplicação.

No Kubernetes, os volumes podem representar mais do que apenas um tradicional no qual as informações são armazenadas e obtidas. Os volumes do Kubernetes também podem ser utilizados como forma de inserir dados num pod para os contentores utilizarem. Alguns tipos de volume comuns do Kubernetes incluem:

  • emptyDir – este volume é normalmente utilizado como espaço temporário para um pod. Todos os contentores num pod podem aceder aos dados no volume. Os dados escritos neste tipo de volume persistem apenas durante o tempo de vida do pod – quando o pod é eliminado, o volume é eliminado. Normalmente, este volume utiliza o armazenamento de discos de nó local subjacente, embora também possa existir apenas na memória do nó.

  • secret - Este volume é utilizado para incluir dados confidenciais, como palavras-passe, em pods. Primeiro, vai criar um segredo com a API do Kubernetes. Quando define o pod ou a implementação, pode pedir um segredo específico. Os segredos só são fornecidos aos nós com um pod agendado que o requer e o segredo é armazenado em tmpfs e não escrito no disco. Quando o último pod num nó que requer um segredo é eliminado, o segredo é eliminado dos tmpfs do nó. Os segredos são armazenados num determinado espaço de nomes e só podem ser acedidos por pods no mesmo espaço de nomes.

  • configMap – este tipo de volume é utilizado para injetar propriedades do par chave-valor em pods, como informações de configuração da aplicação. Em vez de definir as informações de configuração da aplicação numa imagem de contentor, 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 implementados. Semelhante à utilização de um segredo, primeiro cria um ConfigMap com a API do Kubernetes. Este ConfigMap pode ser pedido quando define um pod ou implementação. Os ConfigMaps são armazenados num determinado espaço de nomes e só podem ser acedidos por pods no mesmo espaço de nomes.

Volumes persistentes

Os volumes que são definidos e criados como parte do ciclo de vida do pod só existem até que o pod seja eliminado. Muitas vezes, os pods esperam que o armazenamento permaneça se um pod for reagendado num anfitrião diferente durante um evento de manutenção, especialmente em StatefulSets. Um volume persistente é um recurso de armazenamento criado e gerido pela API do Kubernetes que pode existir para além da duração de um pod individual.

Pode utilizar volumes de disco do AKS suportados pelo VHDX montados como ReadWriteOnce e acessíveis a um único nó de cada vez. Em alternativa, pode utilizar volumes de ficheiros do AKS apoiados por partilhas de ficheiros SMB ou NFS. Estes são montados como ReadWriteMany e estão disponíveis para vários nós em simultâneo.

Um administrador de cluster pode criar estaticamente um volume persistente ou o volume pode ser criado dinamicamente pelo servidor da API do Kubernetes. Se um pod estiver agendado e pedir armazenamento que não esteja atualmente disponível, o Kubernetes pode criar o ficheiro VHDX subjacente e, em seguida, anexá-lo ao pod. O aprovisionamento dinâmico utiliza uma StorageClass para identificar que tipo de armazenamento precisa de ser criado.

Classes de armazenamento

Para definir diferentes camadas (e localização) de armazenamento, pode criar uma StorageClass. StorageClass também define a reclaimPolicy. Esta recuperaçãoPolítica controla o comportamento do recurso de armazenamento subjacente quando o pod é eliminado e o volume persistente poderá já não ser necessário. O recurso de armazenamento subjacente pode ser eliminado ou retido para utilização com um pod futuro.

No AKS Arc, a classe de armazenamento predefinida é criada automaticamente e utiliza CSV para criar volumes suportados por VHDX. A política de recuperação garante que o VHDX subjacente é eliminado quando o volume persistente que o utilizou é eliminado. A classe de armazenamento também configura os volumes persistentes para serem expansíveis, pelo que só precisa de editar a afirmação de volume persistente com o novo tamanho.

Se não for especificado StorageClass para um volume persistente, é utilizada a Classe de Armazenamento predefinida. Ao pedir volumes persistentes, certifique-se de que utilizam o armazenamento adequado. Pode criar uma StorageClass para necessidades adicionais.

Afirmações de volumes persistentes

Um PersistentVolumeClaim pede o armazenamento ReadWriteOnce ou ReadWriteMany de uma Classe de Armazenamento e tamanho específicos. O servidor da API do Kubernetes pode aprovisionar dinamicamente o recurso de armazenamento subjacente no AKS Arc se não existir nenhum recurso existente para satisfazer a afirmação com base no StorageClass definido. A definição do pod inclui a montagem do volume depois de o volume ter sido ligado ao pod.

Um PersistentVolume está vinculado a um PersistentVolumeClaim assim que um recurso de armazenamento disponível for atribuído ao pod que o pede. Existe um mapeamento 1:1 de volumes persistentes para afirmações.

O seguinte manifesto YAML de exemplo mostra uma afirmação de volume persistente que utiliza a StorageClass predefinida e pede um disco 5Gi:

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

Quando cria uma definição de pod, é especificada a afirmação de volume persistente para pedir o armazenamento pretendido. Em seguida, especifique o para as volumeMount suas aplicações lerem e escreverem dados. O seguinte manifesto YAML de exemplo mostra como a afirmação de volume persistente anterior pode ser utilizada 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 seguinte mostra como montar um volume num contentor do Windows e especificar a letra e o caminho da unidade:

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

Passos seguintes