Volumes

Autopilot Padrão

Nesta página, você encontra uma visão geral dos volumes no Kubernetes e do uso deles com o Google Kubernetes Engine (GKE).

Visão geral

Arquivos em disco em um contêiner são o local mais simples para um aplicativo gravar dados, mas essa abordagem tem desvantagens. Os arquivos são perdidos quando o contêiner falha ou é interrompido por qualquer outro motivo. Além disso, os arquivos contidos em um contêiner ficam inacessíveis a outros contêineres em execução no mesmo pod. A abstração de volumes do Kubernetes trata desses dois problemas.

Conceitualmente, um volume é um diretório acessível a todos os contêineres de um pod. A fonte do volume declarada na especificação do pod determina como o diretório é criado, o meio de armazenamento usado e o conteúdo inicial do diretório. Um pod especifica quais volumes ele contém e o caminho no qual os contêineres montam o volume.

Os tipos de volumes temporários têm os mesmos tempos de vida que os respectivos pods de fechamento. Esses volumes são criados quando o pod é criado e eles permanecem após as reinicializações do contêiner. Quando o pod é encerrado ou é excluído, os respectivos volumes vão com ele.

Outros tipos de volumes são interfaces para armazenamento durável que existem independentemente de um pod. Ao contrário dos volumes temporários, os dados em um volume respaldado por armazenamento durável são preservados quando o pod é removido. O volume é simplesmente desconectado e os dados podem ser transferidos para outro pod. Você precisa usar recursos PersistentVolume para gerenciar o ciclo de vida de tipos de armazenamento duráveis, em vez de especificá-los diretamente.

Tipos de volumes

Volumes diferem em sua implementação de armazenamento e seu conteúdo inicial. É possível escolher a fonte do volume que melhor se adapta ao seu caso de uso. Várias origens de volume comuns estão descritas nas seções a seguir. Para uma lista completa dos tipos de volumes, consulte a documentação dos volumes do Kubernetes.

emptyDir

Um volume emptyDir fornece um diretório vazio em que os contêineres no pod podem fazer leituras e gravações. Quando o pod é removido de um nó por qualquer motivo, os dados no emptyDir são excluídos definitivamente. Um volume emptyDir é armazenado em qualquer mídia que esteja sendo usada para o nó, que pode ser um disco, um SSD ou um armazenamento de rede, dependendo do seu ambiente. Os volumes emptyDir são úteis para liberar espaço e compartilhar dados entre vários contêineres em um pod.

Todas as montagens de emptyDir fazem parte do armazenamento temporário do nó, que também inclui os registros e a camada graváveis do contêiner. Por padrão, o GKE Autopilot define o armazenamento temporário como 1 GiB para dar ao aplicativo um pouco de espaço para criar alguns arquivos. Se você precisar de mais ou menos espaço, ajuste o armazenamento temporário na implantação. Para isso, basta definir uma solicitação de recurso para ephemeral-storage.

Se você usa contêineres com pools de nós do Linux, defina o campo emptyDir.medium como Memory para instruir o Kubernetes a ativar um tmpfs (sistema de arquivos ativado por RAM). No entanto, isso não é permitido em contêineres do Windows Server.

ConfigMap

Um recurso ConfigMap fornece uma maneira de injetar dados de configuração em pods. Os dados armazenados em um objeto ConfigMap podem ser referenciados em um volume do tipo ConfigMap e consumidos por meio de arquivos executados em um pod. Os arquivos em um volume ConfigMap são especificados por um recurso ConfigMap.

Secret

Um volume Secret é usado para disponibilizar dados confidenciais, como senhas, tokens OAuth e chaves SSH, aos aplicativos. Os dados armazenados em um objeto Secret podem ser referenciados em um volume do tipo Secret e consumidos por meio de arquivos executados em um pod.

downwardAPI

Um volume downwardAPI disponibiliza dados da API Downward para aplicativos. Esses dados incluem informações sobre o pod e o contêiner em que um aplicativo é executado. Por exemplo, um pod pode ser configurado para expor um DownwardAPIVolumeFile a aplicativos que incluem o namespace e o endereço IP do pod. Para conferir uma lista completa dos tipos de dados que é possível adicionar, consulte Recursos da API Downward (em inglês).

PersistentVolumeClaim

Um volume PersistentVolumeClaim pode ser usado por operadores de cluster para provisionar armazenamento durável para uso dos aplicativos. Um pod usa um PersistentVolumeClaim para montar um volume que é respaldado por esse armazenamento durável.