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 podem ser acessados por 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 em contêineres em um pod veem uma exibição do sistema de arquivos composta por:

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

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

Há 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 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
• Plug-ins para armazenar volumes do Kubernetes
  • NFS
  • CSI
• O que são Kubernetes volumeMounts?
• Criando um volume do Kubernetes implantando pods
• Gerenciamento de volumes do Kubernetes com NetApp Cloud Volumes ONTAP

5 tipos de volumes do Kubernetes

O Kubernetes dá suporte a vários volumes, permitindo que cada pod use vários tipos de volume simultaneamente. Os volumes efêmeros estão vinculados ao ciclo de vida do pod, enquanto os 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 não existe mais, 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. Os administradores podem provisionar PVs manualmente, e o Kubernetes pode usar classes de storage para provisionar PVs dinamicamente. Assim como os volumes, os PVs são plug-ins, 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 do storage, incluindo iSCSI, NFS e sistemas de storage de provedor 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 storage feita por um usuário. Ele funciona de forma semelhante a um pod, mas consome recursos PV em vez de recursos de nó. Um PVC pode solicitar recursos de storage específicos, especificando modos de acesso, como ReadWriteOnce, ReadWriteMany e ReadOnlyMany.

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

Conteúdo relacionado: leia nosso guia para Kubernetes PVC

Volumes efêmeros

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

Os volumes efêmeros são simples de implantar e gerenciar. Você pode especificá-los embutidos 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 caching.

Volumes EmptyDir

Um emptyDir volume é criado quando o Kubernetes atribui um pod a um nó. A vida útil desse volume está vinculada ao ciclo de vida de um pod existente nesse 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.

Depois de criar um volume emptyDir, você pode declarar o nome do tipo de volume como um campo no arquivo de manifesto do pod. Ele é exibido 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 para espaço temporário, como uma mesclagem baseada em disco.

Você pode armazenar volumes emptyDir na mídia que dá suporte ao nó. Por exemplo, você pode usar storage de rede ou SSD. Como alternativa, você pode definir "memória" no campo emptyDir.medium e o Kubernetes montará um sistema de arquivos com suporte de 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 os principais casos de uso para volumes hostPath:

• Use um /var/lib/dockerhostPath—para executar um contêiner que requer acesso aos componentes 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 que o pod comece a ser executado e se deve ser criado.
• Especifique um tipo para um volume hostPath—você pode configurar isso além da propriedade de caminho obrigatória.

HostPath volumes segurança
HostPath volumes apresentam muitos riscos de segurança. Evite usá-los sempre que possível. Se você precisar usar um HostPath volume, deve defini-lo apenas para o diretório ou arquivo necessário e montá-lo como ReadOnly.

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

• Credenciais expostas—HostPaths pode expor credenciais privilegiadas do sistema ou APIs privilegiadas. Agentes de ameaça podem usá-lo para atacar outras partes do cluster ou para escape de contêiner.
• Privilégios de root— quaisquer diretórios ou arquivos criados nos hosts subjacentes podem ser gravados apenas pelo root. Se você quiser gravar em um hostPath volume, você precisa modificar as permissões de arquivo no host ou executar o processo como root dentro de um contêiner privilegiado.

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

Volumes do Kubernetes ConfigMap

A 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 em contêineres que são executados em um pod. Você precisa fornecer o nome do ConfigMap no volume ao referenciar um ConfigMap. O Kubernetes permite personalizar o caminho para uma entrada específica no ConfigMap.

Plug-ins para armazenar volumes do Kubernetes

O Kubernetes fornece vários plug-ins de armazenamento que fornecem acesso a dispositivos de storage implantados em um cluster do Kubernetes. Estes são implementados usando o objeto StorageClass.

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

Vamos revisar dois plug-ins 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 geralmente acessa dados via NFS, esse plugin é muito útil para migrar workloads legados para Kubernetes.

Há 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 os orquestradores de contêineres exponham sistemas de storage aos contêineres que gerenciam. O 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 plug-ins fora da árvore baseados em CSI que são oferecidos diretamente pelos fornecedores de storage. O advento do CSI tornou muito mais fácil para as tecnologias de storage suportarem o Kubernetes.

Conteúdo relacionado: leia nosso guia para Container Storage Interface

O que são Kubernetes volumeMounts?

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

• Declará-lo na propriedade spec:volumes do template do pod e, em seguida, implantar o pod em alguns nós
• Montando o volume em um contêiner específico usando a propriedade spec:containers::volumeMounts

Essas etapas andam de mãos dadas. Ao criar um volume, você também deve montá-lo em um contêiner e não pode montar um volume sem declará-lo no template 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 anexa 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 de volume e a volumeMounts propriedade.

Criando um volume do Kubernetes implantando 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 containers 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 dessa Deployment é definido em pods-with-volumes—é assim que você se refere a ela no ambiente do Kubernetes.

Como vimos na seção anterior, este 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 esse arquivo YAML seja salvo com o nome my-deployment.yaml. Você pode criar a 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 funcionou corretamente, a saída mostrará que cada pod tem um contêiner chamado my-container com o ponto de montagem solicitado:

Montagens: / from my-volume (rw)

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

Volumes: my-volume: Type: 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 solução de gerenciamento de storage de nível empresarial líder do setor, oferece serviços de gerenciamento de storage seguros e comprovados na AWS, Azure e Google Cloud. A capacidade do Cloud Volumes ONTAP pode ser dimensionada para petabytes e oferece suporte a vários casos de uso, como serviços de arquivos, bancos de dados, DevOps ou qualquer outro workload empresarial, com um forte conjunto de recursos, incluindo alta disponibilidade, proteção de dados, eficiências de storage, integração com Kubernetes e muito mais.

Em particular, o Cloud Volumes ONTAP é compatível com provisionamento e gerenciamento de storage persistente do Kubernetes para workloads em contêineres.

Saiba mais sobre como o Cloud Volumes ONTAP ajuda a enfrentar os desafios das aplicações em contêineres nesses Kubernetes Workloads com estudos de caso do Cloud Volumes ONTAP.