5 tipos de volumes do Kubernetes e como trabalhar com eles

O que são volumes do Kubernetes?

Um volume do Kubernetes é um diretório que contém dados, que pode ser acessado pelos contêineres em um pod do Kubernetes. A localização do diretório, a mídia de storage que o suporta e seu conteúdo dependem do tipo específico de volume que está sendo usado.

Os processos em execução dentro de contêineres em um pod visualizam um sistema de arquivos composto por:

• Um sistema de arquivos raiz que corresponde ao conteúdo da imagem do contêiner.
• Volumes montados no contêiner (se definidos). Cada volume é montado em um caminho específico dentro do sistema de arquivos do contêiner.

Os volumes são definidos no campo .spec.containers[*].volumeMounts do template do pod. Para cada pod e cada imagem de contêiner dentro do pod, você precisa especificar quais volumes ele irá montar e em quais caminhos (os caminhos podem ser diferentes para cada contêiner).

Existem alguns tipos de volumes no Kubernetes. Os mais importantes são os volumes efêmeros, que são armazenados localmente no nó do Kubernetes e são excluídos quando um pod é reiniciado, e Kubernetes persistent volumes (PV), que retêm os dados mesmo após o desligamento de um pod.

Neste artigo:

• Tipos de volumes do Kubernetes
  • Volumes persistentes
  • Volumes efêmeros
  • Volumes EmptyDir
  • Volumes hostPath do Kubernetes
  • Volumes do Kubernetes ConfigMap
• Plugins para armazenar volumes do Kubernetes
  • NFS
  • CSI
• O que são Kubernetes volumeMounts?
• Criando um Volume do Kubernetes por meio da implantação de Pods
• Gerenciamento de volumes do Kubernetes com NetApp Cloud Volumes ONTAP

5 tipos de volumes do Kubernetes

O Kubernetes suporta vários volumes, permitindo que cada pod utilize vários tipos de volumes simultaneamente. Volumes efêmeros estão vinculados ao ciclo de vida do pod, enquanto volumes persistentes podem persistir além do ciclo de vida do pod. Isso significa que o Kubernetes destrói volumes efêmeros assim que o pod deixa de existir, enquanto mantém os dados dos volumes persistentes.

Volumes persistentes

O Kubernetes fornece um subsistema PersistentVolume com uma API que abstrai o provisionamento de storage e o consumo. Ele funciona com dois recursos de API—PersistentVolume (PV) e PersistentVolumeClaim (PVC).

PersistentVolume (PV)
Um PV é um recurso de storage localizado no cluster. Administradores podem provisionar PVs manualmente, e o Kubernetes pode usar classes de storage para provisionar PVs dinamicamente. Como volumes, os PVs são plugins, mas seu ciclo de vida é independente de qualquer pod que use o PV.

Um PV funciona como um objeto de API que captura os detalhes da implementação de storage, incluindo iSCSI, NFS e sistemas de storage de provedores de nuvem. Ele funciona de forma semelhante a um nó, mas oferece recursos de storage em vez de computação.

PersistentVolumeClaim (PVC)
Um PVC é uma solicitação de armazenamento feita por um usuário. Ele funciona de forma semelhante a um pod, mas consome recursos de PV em vez de recursos de nó. Um PVC pode solicitar recursos de storage, especificando modos de acesso, como ReadWriteOnce, ReadWriteMany e ReadOnlyMany.

Os PVCs permitem que os usuários consumam recursos de storage abstratos, mas normalmente os usuários precisam de PVs com propriedades variadas para diferentes problemas. É por isso que os administradores de clusters frequentemente precisam oferecer PVs variados que diferem em mais do que apenas tamanho e modos de acesso. Eles podem fazer isso sem expor os usuários aos detalhes de implementação por meio de recursos StorageClass.

Conteúdo relacionado: Leia nosso guia sobre Kubernetes PVC

Volumes Efêmeros

Os volumes efêmeros não armazenam dados de forma persistente entre reinicializações. Esses volumes estão vinculados ao ciclo de vida do pod, o que significa que são criados e excluídos juntamente com o pod. Isso permite parar e reiniciar pods sem limitá-los à disponibilidade de storage persistente.

Os volumes efêmeros são fáceis de implantar e gerenciar. Você pode especificá-los diretamente na especificação do pod. Os volumes efêmeros são ideais para aplicações que não exigem storage persistente, como serviços de armazenamento em cache.

Volumes EmptyDir

Um emptyDir volume é criado quando o Kubernetes atribui um pod a um nó. A duração desse volume está vinculada ao ciclo de vida do pod naquele nó específico. Um emptyDir volume é recriado quando os contêineres reiniciam ou falham. No entanto, os dados nesse volume são excluídos e perdidos quando o pod é removido do nó, falha ou morre.

Após criar um emptyDir volume, você pode declarar o nome do tipo de volume como um campo no arquivo de manifesto do pod. Ele aparece na seção de propriedades do volume com chaves vazias {} como valor. Volumes EmptyDir são adequados principalmente para storage temporário de dados. Por exemplo, você pode usá-lo como espaço temporário, como em uma mesclagem baseada em disco.

Você pode armazenar volumes emptyDir na mídia que suporta o nó. Por exemplo, você pode usar storage de rede ou SSD. Alternativamente, você pode definir "memory" no campo emptyDir.medium e o Kubernetes montará um sistema de arquivos baseado em RAM (tmpfs). Observe que o Kubernetes limpa o tmpfs ao reinicializar o nó.

Volumes hostPath do Kubernetes

Um volume hostPath monta um diretório ou arquivo do sistema de arquivos do nó host em seu pod.

Aqui estão casos de uso importantes para hostPath volumes:

• Use a /var/lib/dockerhostPath—para executar um contêiner que requer acesso aos recursos internos do Docker.
• Use um /sys hostPath—para executar cAdvisor em um contêiner.
• Permitir que um pod especifique um hostPath—para definir se um determinado hostPath deve existir antes do pod começar a ser executado e se ele deve ser criado.
• Especifique um tipo para um volume hostPath—você pode configurar isso além da propriedade de caminho obrigatória.

HostPath volumes security
HostPath volumes apresentam muitos riscos de segurança. Evite usá-los sempre que possível. Se precisar usar um volume HostPath, limite-o apenas ao diretório ou arquivo necessário e monte-o como ReadOnly.

Aqui estão os principais riscos de segurança:

• Credenciais expostas—HostPaths podem expor credenciais privilegiadas do sistema ou APIs privilegiadas. Atores maliciosos podem usá-las para atacar outras partes do cluster ou para escapar de contêineres.
• Privilégios de root—quaisquer diretórios ou arquivos criados nos hosts subjacentes só podem ser gravados pelo usuário root. Se você quiser gravar em um volume hostPath, é necessário modificar as permissões de arquivo no host ou executar o processo como root dentro de um contêiner privilegiado.

Você pode usar a AdmissionPolicy para restringir o acesso do HostPath a determinados diretórios. No entanto, a política só é eficaz se você exigir que volumeMounts usem pontos de montagem readOnly.

Volumes do Kubernetes ConfigMap

Um ConfigMap permite injetar dados de configuração em pods. Os dados armazenados em um ConfigMap podem ser referenciados em um volume do tipo configMap e, em seguida, consumidos por aplicativos conteinerizados que são executados em um pod. Você precisa fornecer o nome do ConfigMap no volume ao referenciar um ConfigMap. O Kubernetes permite que você personalize o caminho para uma entrada específica no ConfigMap.

Plugins para armazenar volumes do Kubernetes

O Kubernetes fornece vários plugins de storage que permitem o acesso a dispositivos de storage implantados em um cluster Kubernetes. Estes são implementados usando o objeto StorageClass.

Alguns dos principais plugins atualmente suportados pelo Kubernetes são GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS e iSCSI. Para mais detalhes sobre esses plugins, consulte a documentação de StorageClass.

Vamos analisar dois plugins de storage notáveis com mais detalhes.

NFS

Network File System (NFS) é um protocolo padrão para montar dispositivos de storage como unidades locais. Kubernetes permite montar um volume NFS como uma unidade local em um contêiner. Como o código legado frequentemente acessa dados via NFS, este plugin é muito útil para migrar cargas de trabalho legadas para Kubernetes.

Existem duas maneiras de acessar dados via NFS e Kubernetes:

• Volumes NFS efêmeros podem ser anexados ao storage NFS existente.
• PersistentVolumes com NFS—permite configurar recursos gerenciados em um cluster que são acessados via NFS.

CSI

A Container Storage Interface (CSI) é uma interface padrão que permite que orquestradores de contêineres exponham sistemas de storage aos contêineres que gerenciam. A CSI permite que fornecedores de storage criem plugins que são “out of tree”, ou seja, não precisam ser incluídos no repositório de código do Kubernetes e não são distribuídos com o Kubernetes.

Existem muitos plugins externos baseados em CSI que são oferecidos diretamente por fornecedores de storage. O surgimento do CSI tornou muito mais fácil para as tecnologias de storage suportarem o Kubernetes.

Conteúdo relacionado: Leia nosso guia sobre Container Storage Interface

O que são Kubernetes volumeMounts?

Existem duas etapas envolvidas na criação de um volume e em torná-lo acessível a um pod:

• Declarando-o na propriedade spec:volumes do modelo do pod e, em seguida, implantando o pod em alguns nós
• Montando o volume em um contêiner específico usando a propriedade spec:containers::volumeMounts

Esses passos são interdependentes. Ao criar um volume, você também deve montá-lo em um contêiner, e não é possível montar um volume sem declará-lo no modelo do pod.

Aqui está um exemplo que mostra tanto a criação quanto a montagem de um volume em uma configuração YAML de modelo de pod:

spec: containers: —name: my-app image: nginx volumeMounts: —name: my-volume mountPath: /app/config volumes: —name: my-volume 

Neste código:

• volumes (na parte inferior) cria um volume chamado my-volume e o conecta ao pod
• volumeMounts define como o volume é montado, incluindo o caminho do arquivo pelo qual o volume estará disponível de dentro do contêiner
• É essencial que o mesmo nome de volume seja usado em ambos os locais—a declaração do volume e a propriedade volumeMounts.

Criando um volume do Kubernetes através da implantação de pods

Para criar um volume do Kubernetes, você implanta um ou mais pods que declaram o volume. Uma maneira comum de fazer isso é por meio de um objeto Deployment. Aqui está um exemplo de um manifesto de Deployment que faz o seguinte:

• Implanta três pods, cada um com um contêiner NGINX
• Declara um volume emptyDir
• Monta o volume em cada um dos três recipientes na raiz

apiVersion: apps/v1 kind: Deployment metadata: name: pods-with-volumes spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: —name: my-container image: nginx:1.14.2 volumeMounts: —mountPath: / name: my-volume volumes: —name: my-volume emptyDir: {} 

Observe que o nome deste Deployment é definido em pods-with-volumes—é assim que você se refere a ele no ambiente Kubernetes.

Como vimos na seção anterior, esse objeto Deployment executa as duas ações necessárias para criar um volume:

• A propriedade spec:template:volumes declara o volume.
• A propriedade spec:containers::volumeMounts monta o volume nos contêineres.

Vamos supor que este arquivo YAML esteja salvo com o nome my-deployment.yaml. Você pode criar o Deployment no seu cluster Kubernetes usando este comando:

kubectl apply -f my-deployment.yaml

Para verificar se a Deployment está sendo executada corretamente com os volumes esperados, execute este comando:

kubectl describe pods pods-with-volumes

Se tudo funcionar corretamente, a saída mostrará que cada pod possui um contêiner chamado my-container com o ponto de montagem:

Montagens: / from my-volume (rw)

A saída também mostrará o volume em execução em cada pod:

Volumes: meu-volume: Tipo: EmptyDir (um diretório temporário que compartilha o ciclo de vida de um pod)

Gerenciamento de volumes do Kubernetes com NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, a principal solução de gerenciamento de storage de nível empresarial, oferece serviços de gerenciamento de storage seguros e comprovados na AWS, Azure e Google Cloud. A capacidade do Cloud Volumes ONTAP pode ser escalada para petabytes e suporta diversos casos de uso, como serviços de arquivos, bancos de dados, DevOps ou qualquer outra carga de trabalho empresarial, com um conjunto robusto de recursos, incluindo alta disponibilidade, proteção de dados, eficiências de storage, integração com Kubernetes e muito mais.

Em particular, Cloud Volumes ONTAP oferece suporte ao provisionamento e gerenciamento de Volumes Persistentes do Kubernetes  para os requisitos de cargas de trabalho conteinerizadas.

Saiba mais sobre como Cloud Volumes ONTAP ajuda a enfrentar os desafios de aplicações conteinerizadas nessas cargas de trabalho do Kubernetes com os estudos de caso do Cloud Volumes ONTAP.