Conceitos de armazenamento para Kubernetes

10 minutos

O Kubernetes é uma plataforma aberta que gerencia aplicativos baseados em contêiner e seus componentes de rede e armazenamento associados. Ele fornece uma abordagem declarativa para implantações, apoiada por um conjunto robusto de APIs para operações de gerenciamento.

Você pode criar e executar aplicativos modernos, portáteis e baseados em microsserviços, usando o Kubernetes para orquestrar e gerenciar a disponibilidade dos componentes do aplicativo.

Gestão e orquestração de contentores

O gerenciamento de contêineres é o processo de organizar, adicionar, remover ou atualizar um número significativo de contêineres. Um orquestrador de contêineres é um sistema que implanta e gerencia automaticamente aplicativos em contêineres. Por exemplo, um orquestrador pode responder dinamicamente a alterações no ambiente para aumentar ou diminuir as instâncias implantadas do aplicativo gerenciado ou pode garantir que todas as instâncias de contêiner implantadas sejam atualizadas se uma nova versão de um serviço for lançada.

Arquitetura do Kubernetes

A arquitetura do Kubernetes é construída em clusters. Um cluster Kubernetes é dividido em dois componentes principais de infraestrutura:

Um plano de controle que fornece os principais serviços do Kubernetes e a orquestração das cargas de trabalho do seu aplicativo.
Nós que executam as cargas de trabalho do aplicativo. Cada cluster tem pelo menos um nó, mas você pode definir o número e o tamanho dos nós. Um pool de nós é um grupo de nós que compartilham a mesma configuração.

Os recursos para suas cargas de trabalho de aplicativo estão contidos em pods. Um pod no Kubernetes é um recurso efêmero que representa uma única instância do seu aplicativo. Ele consiste em um ou mais contêineres, com armazenamento compartilhado e recursos de rede, e uma especificação de como executar os contêineres. Os conteúdos de um Pod são sempre co-localizados e co-programados e executados num contexto partilhado.

Armazenamento persistente no Kubernetes

Na unidade anterior, aprendemos sobre os mecanismos de suporte em contêineres do Windows que permitem fornecer armazenamento persistente para seus aplicativos em um ambiente local por meio de montagens de ligação e volumes nomeados. No entanto, volumes e montagens de ligação têm algumas desvantagens quando usados em um ambiente distribuído como o Kubernetes.

Volumes e montagens de ligação são vinculados a uma máquina host específica, o que significa que eles não são portáteis entre nós em um cluster. Se um contêiner estiver agendado em um nó diferente daquele em que seus dados estão armazenados, ele não poderá acessá-lo. Além disso, os volumes e suportes de ligação não são escaláveis ou resilientes, pois dependem da disponibilidade e da capacidade de uma única máquina host.

O Kubernetes resolve os desafios de armazenamento de contêineres introduzindo duas abstrações: volumes persistentes e declarações de volume persistentes.

Volumes persistentes

Um volume persistente (PV) é um recurso de armazenamento no cluster, criado e gerenciado pela API do Kubernetes que pode existir além do tempo de vida de um pod individual. Um administrador de cluster pode criar estaticamente um PersistentVolume, ou o servidor de API do Kubernetes pode criá-lo dinamicamente usando classes de armazenamento. Um PV é um recurso no cluster assim como um nó é um recurso de cluster. Os PVs têm um ciclo de vida independente de qualquer Pod individual que use o PV.

Afirmações de volumes persistentes

Uma declaração de volume persistente (PVC) solicita armazenamento de um determinado StorageClassmodo de acesso e tamanho. O PVC funciona como uma verificação de reivindicação para o recurso de armazenamento. O servidor de API do Kubernetes pode provisionar dinamicamente o recurso de armazenamento subjacente se nenhum recurso existente puder atender à declaração com base na classe de armazenamento definida.

A StorageClass fornece uma maneira para os administradores descreverem as "classes" de armazenamento que oferecem. Classes diferentes podem ser mapeadas para níveis de qualidade de serviço, para políticas de backup ou para políticas arbitrárias determinadas pelos administradores de cluster. O próprio Kubernetes não tem opinião sobre o que as classes representam.