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

Aplica-se a: AKS no Azure Local

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 talvez precisem compartilhar os mesmo volumes de dados, ou anexar novamente os 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.

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 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 volume tradicional onde as informações são armazenadas e recuperadas. Volumes Kubernetes também podem ser usados como uma forma de inserir dados em um pod para uso pelos 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 durante o período de vida do pod; quando o pod é excluído, o volume é excluído. Este volume normalmente usa o armazenamento subjacente em disco do nó local, no entanto, ele também pode existir apenas na memória do nó.

• segredo: esse volume é usado para incluir dados confidenciais em pods, como senhas. Primeiro, você cria um segredo usando a API do Kubernetes. Quando você define seu pod ou implantação, pode solicitar um segredo específico. Os segredos são fornecidos apenas a nodos com um pod agendado que deles necessita, e o segredo é armazenado em tmpfs e não é gravado no disco. Quando o último pod em um nó que exige um segredo for 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 ao definir 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 do 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 a 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 as solicitações de armazenamento que não estiverem disponíveis no momento, o Kubernetes pode 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 é excluído quando o volume persistente que o usa é 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

Solicitações PersistentVolumeClaim em armazenamento ReadWriteOnce ou ReadWriteMany de um StorageClass específico 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 Windows e especificar a letra de unidade e caminho:

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

Garantir o acesso seguro do pod aos volumes montados

Para que seus aplicativos sejam executados corretamente, os pods devem ser executados como um usuário ou grupo definido e não como raiz. O securityContext para um pod ou contêiner permite definir configurações como fsGroup para assumir as permissões apropriadas nos volumes montados.

fsGroup é um campo dentro de securityContext uma especificação de pod do Kubernetes. Ele define uma ID de grupo suplementar que o Kubernetes atribui a todos os processos no pod e recursivamente aos arquivos em volumes montados. Isso garante que o pod tenha o acesso correto no nível do grupo aos volumes de armazenamento compartilhados.

Quando um volume é montado, o Kubernetes altera a propriedade do conteúdo do volume para corresponder ao valor fsGroup . Isso é particularmente útil quando os contêineres são executados como usuários sem privilégios de root e precisam ter permissão de gravação em volumes compartilhados.

O exemplo a seguir YAML mostra o valor do fsgroup :

securityContext:
  fsGroup: 2000

Neste exemplo, todos os arquivos em volumes montados são acessíveis pelo GID 2000.

Próximas etapas

• Use o AKS nos drivers de Interface de Armazenamento de Contêiner (CSI) do disco local do Azure.