Existem várias maneiras de configurar o armazenamento de dados para aplicativos em execução em um cluster Kubernetes. Alguns deles já estão desatualizados, outros surgiram recentemente. Neste artigo, veremos o conceito de três opções de conexão de sistemas de armazenamento, incluindo a mais recente - conexão via Container Storage Interface.
Método 1: especifique PV no manifesto do pod
Um manifesto típico que descreve um pod em um cluster Kubernetes:
As partes do manifesto que descrevem qual volume está conectado e onde são destacadas em cores.
Na seção volumeMontagens indique os pontos de montagem (mountPath) - em qual diretório dentro do container será montado o volume permanente, bem como o nome do volume.
Na seção x lista todos os volumes usados no pod. Especifique o nome de cada volume, bem como o tipo (no nosso caso: awsElasticBlockStore) e parâmetros de conexão. Quais parâmetros estão listados no manifesto dependem do tipo de volume.
O mesmo volume pode ser montado simultaneamente em vários contêineres de pod. Dessa forma, diferentes processos de aplicação podem acessar os mesmos dados.
Esse método de conexão foi inventado logo no início, quando o Kubernetes estava apenas em sua infância, e hoje o método está desatualizado.
Existem vários problemas ao usá-lo:
- todos os volumes devem ser criados manualmente; o Kubernetes não pode criar nada para nós;
- os parâmetros de acesso para cada volume são únicos e devem ser especificados nos manifestos de todos os pods que utilizam o volume;
- para alterar o sistema de armazenamento (por exemplo, mudar do AWS para o Google Cloud), você precisa alterar as configurações e o tipo de volumes montados em todos os manifestos.
Tudo isso é muito inconveniente, então na realidade este método é usado para conectar apenas alguns tipos especiais de volumes: configMap, secret, emptyDir, hostPath:
-
configMap e secret são volumes de serviço que permitem criar um volume com arquivos de manifestos do Kubernetes no contêiner.
-
vazioDir é um volume temporário, criado apenas durante a vida útil do pod. Conveniente para testar ou armazenar dados temporários. Quando um pod é excluído, o volume emptyDir também é excluído e todos os dados são perdidos.
-
hostPath - permite montar qualquer diretório no disco local do servidor no qual o aplicativo está sendo executado dentro do contêiner com o aplicativo, incluindo /etc/kubernetes. Este é um recurso inseguro, portanto as políticas de segurança normalmente proíbem o uso de volumes desse tipo. Caso contrário, o aplicativo do invasor poderá montar o diretório HTC Kubernetes dentro de seu contêiner e roubar todos os certificados do cluster. Normalmente, os volumes hostPath só podem ser usados por aplicativos do sistema executados no namespace kube-system.
são fornecidos na documentação.
Método 2. Conexão a lareiras SC/PVC/PV
Um método de conexão alternativo é o conceito de classe de armazenamento, PersistentVolumeClaim, PersistentVolume.
Classe de armazenamento armazena parâmetros de conexão ao sistema de armazenamento de dados.
Reivindicação de Volume Persistente descreve os requisitos para o que o aplicativo precisa.
Volume Persistente armazena parâmetros de acesso e status do volume.
A essência da ideia: no manifesto do pod eles indicam um volume do tipo PersistentVolumeClaim e indicam o nome desta entidade no parâmetro ClaimName.
O manifesto PersistentVolumeClaim descreve os requisitos para o volume de dados que o aplicativo requer. Incluindo:
- tamanho do disco;
- método de acesso: ReadWriteOnce ou ReadWriteMany;
- link para a classe Storage - em qual sistema de armazenamento de dados queremos criar o volume.
O manifesto da classe Storage armazena o tipo e os parâmetros da conexão com o sistema de armazenamento. O cubelet precisa deles para montar o volume em seu nó.
Os manifestos PersistentVolume indicam a classe de armazenamento e os parâmetros de acesso para um volume específico (ID do volume, caminho, etc.).
Ao criar um PVC, o Kubernetes analisa o tamanho do volume e qual classe de armazenamento é necessária e seleciona um PersistentVolume gratuito.
Se tais PVs não estiverem disponíveis, o Kubernetes pode lançar um programa especial - Provisioner (seu nome está indicado na classe Storage). Este programa se conecta ao sistema de armazenamento, cria um volume do tamanho necessário, recebe um identificador e cria um manifesto PersistentVolume no cluster Kubernetes, que está associado ao PersistentVolumeClaim.
Todo esse conjunto de abstrações permite remover informações sobre qual sistema de armazenamento o aplicativo está trabalhando, desde o nível de manifesto do aplicativo até o nível de administração.
Todos os parâmetros para conexão ao sistema de armazenamento de dados estão localizados na classe Storage, pela qual os administradores do cluster são responsáveis. Tudo o que você precisa fazer ao migrar da AWS para o Google Cloud é alterar o nome da classe Storage para PVC nos manifestos do aplicativo. O volume de persistência para armazenamento de dados será criado no cluster automaticamente usando o programa Provisioner.
Método 3: interface de armazenamento de contêiner
Todo o código que interage com vários sistemas de armazenamento faz parte do núcleo do Kubernetes. O lançamento de correções de bugs ou novas funcionalidades está vinculado a novos lançamentos; o código deve ser alterado para todas as versões suportadas do Kubernetes. Tudo isso é difícil de manter e adicionar novas funcionalidades.
Para resolver o problema, desenvolvedores do Cloud Foundry, Kubernetes, Mesos e Docker criaram o Container Storage Interface (CSI) - uma interface simples e unificada que descreve a interação do sistema de gerenciamento de contêineres e um driver especial (Driver CSI) que funciona com um específico sistema de armazenamento. Todo o código para interação com sistemas de armazenamento foi movido do núcleo do Kubernetes para um sistema separado.
.
Normalmente, o driver CSI consiste em dois componentes: Node Plugin e Controller plugin.
O Node Plugin é executado em cada nó e é responsável por montar volumes e realizar operações neles. O plugin Controller interage com o sistema de armazenamento: cria ou exclui volumes, atribui direitos de acesso, etc.
Por enquanto, os drivers antigos permanecem no kernel do Kubernetes, mas seu uso não é mais recomendado e todos são aconselhados a instalar o Driver CSI específico para o sistema com o qual irão trabalhar.
A inovação pode assustar quem já está acostumado a configurar o armazenamento de dados através da classe Storage, mas na verdade nada de terrível aconteceu. Para os programadores, nada muda realmente - eles trabalharam apenas com o nome classe Storage e continuarão a fazê-lo. Para administradores, a instalação do gráfico do leme foi adicionada e a estrutura das configurações foi alterada. Se anteriormente as configurações eram inseridas diretamente na classe Storage, agora elas devem ser definidas primeiro no gráfico do leme e depois na classe Storage. Se você olhar para isso, nada de ruim aconteceu.
Vamos dar um exemplo para ver os benefícios que você pode obter ao mudar para a conexão de sistemas de armazenamento Ceph usando o driver CSI.
Ao trabalhar com Ceph, o plug-in CSI oferece mais opções para trabalhar com sistemas de armazenamento do que drivers integrados.
- Criação de disco dinâmico. Normalmente, os discos RBD são usados apenas no modo RWO, mas o CSI para Ceph permite que eles sejam usados no modo RWX. Vários pods em nós diferentes podem montar o mesmo disco RDB em seus nós e trabalhar com eles em paralelo. Para ser justo, nem tudo é tão claro - este disco só pode ser conectado como um dispositivo de bloco, o que significa que você terá que adaptar o aplicativo para trabalhar com ele no modo de acesso múltiplo.
- Criando instantâneos. Em um cluster Kubernetes, você pode criar um manifesto com o requisito de criar um snapshot. O plugin CSI irá vê-lo e tirar um instantâneo do disco. Com base nisso, você pode fazer um backup ou uma cópia do PersistentVolume.
- Aumentando o tamanho do disco no armazenamento e PersistentVolume no cluster Kubernetes.
- Cotas. Os drivers CephFS integrados ao Kubernetes não oferecem suporte a cotas, mas novos plug-ins CSI com o Ceph Nautilus mais recente podem ativar cotas em partições CephFS.
- Métricas. O plugin CSI pode fornecer ao Prometheus uma variedade de métricas sobre quais volumes estão conectados, quais comunicações estão ocorrendo, etc.
- Com reconhecimento de topologia. Permite especificar em manifestos como o cluster está distribuído geograficamente e evitar conectar um sistema de armazenamento localizado em Amsterdã a pods em execução em Londres.
Como conectar o Ceph a um cluster Kubernetes via CSI, consulte . Você também pode assinar , que será lançado em 15 de outubro.
Autor do artigo: Sergey Bondarev, arquiteto praticante em Southbridge, administrador certificado do Kubernetes, um dos desenvolvedores do kubespray.
Um pequeno Post Scriptum não para publicidade, mas para benefício...
PS Sergey Bondarev ministra dois cursos intensivos: atualizado 28 a 30 de setembro e avançado 14 a 16 de outubro.
Fonte: habr.com