Notícias

UB CLOUD MANAGED HOST

DINAMICAMENTE COM KUBERNETES

Blog Single

O armazenamento no mundo do Kubernetes e do contêiner é tratado de maneira diferente do que acontece com máquinas virtuais (VMs) ou outros tipos de infraestrutura.

Os aplicativos em contêiner geralmente são dimensionados executando várias instâncias de contêineres em paralelo. Como resultado, você tem muito mais contêineres em execução ao mesmo tempo do que VMs, e a vida útil de qualquer instância de contêiner é geralmente muito menor: minutos ou horas. Uma VM em execução, em comparação, pode persistir por semanas ou meses. Enquanto um aplicativo está sendo executado em uma VM geralmente armazena dados na VM, isso não faz sentido, dada a natureza efêmera dos contêineres.

O que são volumes persistentes (PVs)?

Os aplicativos com estado exigem que os dados persistam além da vida útil de uma instância de contêiner. Os aplicativos geralmente armazenam informações para processamento posterior ou à medida que ocorrem alterações de registro ou transações. Os PVs permitem que os volumes de armazenamento sejam separados das instâncias de contêiner. Um PV é um volume de armazenamento alocado em um cluster que foi provisionado por um administrador ou provisionado dinamicamente usando classes de armazenamento.

O Kubernetes oferece suporte a vários tipos de volumes, incluindo armazenamento de arquivos e blocos. Os vários fornecedores de armazenamento e provedores de nuvem criaram drivers Container Storage Interface (CSI) que permitem que o Kubernetes aproveite os recursos de suas ofertas de armazenamento subjacentes. Decidir que tipo de armazenamento seu cluster consumirá é uma tarefa de gerenciamento importante, levando em consideração o provisionamento estático/dinâmico, a qualidade de serviço (QoS), a capacidade de expansão horizontal e muito mais.

Provisionando dinamicamente volumes persistentes com Kubernetes

Um PV é um recurso de cluster semelhante a outros recursos do Kubernetes, como um nó, memória (RAM), etc. Assim como qualquer recurso de cluster, ele pode ser criado por meio de um arquivo de configuração escrito em YAML.

Provisionamento de PV Estático e Reivindicações de Volume Persistente

Com o provisionamento estático, um administrador do Kubernetes precisa saber antecipadamente quais volumes persistentes os desenvolvedores precisarão, e criar esses volumes no armazenamento subjacente criando arquivos YAML, conforme mostrado acima. Depois que um PV é criado, ele fica acessível por meio da API do Kubernetes e disponível para consumo.

Uma reivindicação de volume persistente (PVC) é uma solicitação para um PV. As declarações descrevem o armazenamento necessário, incluindo um nome, tamanho e modos de acesso específicos. Um PVC pode especificar alguns ou todos os parâmetros de um PV adequado. Se o Kubernetes encontrar um PV disponível que corresponda à solicitação, o PVC será vinculado ao PV.

Em resumo, o provisionamento de PV estático requer estas etapas:

 O administrador do Kubernetes cria um PV.

 O desenvolvedor cria um PVC para solicitar armazenamento e reivindicar o PV.

 O desenvolvedor configura um pod para usar o PV com base na declaração satisfeita.

Provisionamento dinâmico

O provisionamento estático funciona bem até certo ponto, mas requer muita adivinhação por parte do administrador (para criar PVs que os aplicativos podem precisar) ou muito entre desenvolvedores e administradores. À medida que seu ambiente Kubernetes se expande, isso pode se tornar um gargalo.

O provisionamento dinâmico resolve esse problema. Em vez do administrador do Kubernetes criar PVs específicos, o administrador define as classes de armazenamento. Cada StorageClass tem um backend específico de armazenamento a partir do qual os PVs podem ser provisionados automaticamente para atender aos requisitos de um aplicativo. Por exemplo, você pode ter classes de armazenamento separadas para armazenamento em bloco e arquivo. As classes podem ser tão refinadas quanto você deseja que elas sejam. Você pode ter armazenamento em bloco lento, médio e rápido ou classes que são sempre submetidas a backup ou nunca.

Para criar um StorageClass, o administrador deve especificar um provisionador e parâmetros apropriados para esse provisionador. Por exemplo, o Kubernetes tem um provisionador interno para armazenamento (bloco) do AWS EBS: kubernetes.io/aws-ebs.

O Kubernetes fornece uma variedade de provisionadores internos, que são descritos na documentação do Kubernetes aqui. Provedores externos também estão disponíveis ou podem ser criados.

Com o provisionamento dinâmico, um desenvolvedor pode usar um PVC para solicitar um tipo de armazenamento específico e ter um novo PV provisionado automaticamente. O PVC deve solicitar um StorageClass que já foi criado e configurado no cluster de destino por um administrador para que o provisionamento dinâmico funcione.

Volumes Persistentes e Backup

Os ambientes Kubernetes exigem backups que acompanhem o estado do cluster e dos aplicativos para proteção contra desastres. Se seus backups são projetados para fazer backup apenas dos PVs que você conhece, mais cedo ou mais tarde, você pode perder alguns. Os backups do Kubernetes devem inspecionar o estado de seus clusters para encontrar todos os PVs. As soluções baseadas em políticas ajudam a garantir que você faça backup de todos os seus PVs nos intervalos certos para fornecer o nível de serviço desejado.

Notícias