Atualização! . Nos comentários, um dos leitores sugeriu experimentar o Linstor (talvez ele próprio trabalhe nele), então adicionei uma seção sobre essa solução. Também escrevi um post sobre como instalá-lo , porque o processo é muito diferente do resto.
Para ser sincero, desisti e abandonei o Kubernetes (pelo menos por enquanto). Vou usar o Heroku . Porque Por causa do armazenamento! Quem pensaria que eu iria mexer mais com o armazenamento do que com o próprio Kubernetes. Eu uso o Hetzner Cloud porque é barato e o desempenho é bom, e desde o início eu implantei clusters usando o Rancher . Não experimentei os serviços gerenciados pelo Kubernetes do Google / Amazon / Microsoft / DigitalOcean, etc., etc., porque queria aprender tudo sozinho. E eu sou econômico.
Então - sim, gastei muito tempo tentando decidir qual armazenamento escolher quando estava considerando uma possível pilha no Kubernetes. Prefiro soluções de código aberto, e não apenas por causa do preço, mas estudei algumas opções pagas por curiosidade, porque elas têm versões gratuitas com restrições. Anotei alguns números dos testes mais recentes quando comparava diferentes opções, e elas podem ser de interesse para quem estuda armazenamento no Kubernetes. Embora eu tenha me despedido pessoalmente de Kubernetes até agora. Também quero mencionar o driver CSI , no qual você pode preparar diretamente os volumes Hetzner Cloud, mas ainda não o tentei. Estudei o armazenamento definido por software baseado em nuvem porque precisava de replicação e capacidade de montar rapidamente volumes persistentes em qualquer nó, especialmente no caso de falha de um nó e outras situações semelhantes. Algumas soluções oferecem instantâneos em um determinado momento e backups externos, o que é conveniente.
Testei 6-7 soluções de armazenamento:
Como eu disse em um post anterior , depois de testar a maioria das opções da lista, eu inicialmente decidi pelo OpenEBS. O OpenEBS é muito fácil de instalar e usar, mas, para ser sincero, após o teste com dados reais sob carga, seu desempenho me decepcionou. Este é um código aberto, e os desenvolvedores do canal Slack sempre ajudaram muito quando eu precisei de ajuda. Infelizmente, ele tem um desempenho muito baixo em comparação com outras opções, então tive que executar os testes novamente. O OpenEBS agora tem três mecanismos de armazenamento, mas estou publicando os resultados de benchmark para o cStor. Até agora não tenho números para o Jiva e o LocalPV.
Em poucas palavras, o Jiva é um pouco mais rápido e o LocalPV geralmente é mais rápido, nada pior do que o benchmark do drive diretamente. O problema com o LocalPV é que o acesso ao volume só pode ser obtido no nó em que foi preparado e não há absolutamente nenhuma replicação. Tive alguns problemas para recuperar o backup via Velero em um novo cluster, porque os nomes dos nós eram diferentes. Se falamos de backups, o cStor possui um plug - in para o Velero , com o qual você pode fazer backups externos de instantâneos por vez, o que é mais conveniente do que os backups no nível do arquivo com o Velero-Restic. Escrevi vários scripts para facilitar o gerenciamento de backups e restaurações com este plugin. Em geral, eu realmente gosto do OpenEBS, mas seu desempenho ...
O Rook também possui código-fonte aberto e difere das outras opções da lista, pois é um orquestrador de armazenamento que executa tarefas complexas de gerenciamento de armazenamento com back- end diferentes, como Ceph , EdgeFS e outros, o que simplifica bastante o trabalho. Eu tive problemas com o EfgeFS quando tentei há alguns meses, então testei principalmente com o Ceph. O Ceph oferece não apenas armazenamento em bloco, mas também armazenamento em objetos compatível com o S3 / Swift e o sistema de arquivos distribuído. O que eu gosto no Ceph é a capacidade de distribuir dados de volume em vários discos, para que o volume possa usar mais espaço em disco do que caber em um único disco. Isso é conveniente. Outro recurso interessante é que, quando você adiciona discos a um cluster, ele redistribui automaticamente os dados em todos os discos.
Existem snapshots no Ceph, mas, tanto quanto eu sei, eles não podem ser usados diretamente no Rook / Kubernetes. É verdade que não entrei nisso. Porém, fora do local, não há backups; portanto, você precisa usar algo com o Velero / Restic, mas há apenas backups no nível do arquivo, e não instantâneos no momento. Mas no Rook, gostei muito do trabalho simples com o Ceph - ele oculta quase todas as coisas complexas e oferece ferramentas para se comunicar diretamente com o Ceph na solução de problemas. Infelizmente, no teste de estresse dos volumes Ceph, tive esse problema o tempo todo, devido ao qual o Ceph se tornou instável. Ainda não está claro se isso é um bug no Ceph em si ou um problema em como a Rook controla o Ceph. Eu conjurei com as configurações de memória, e ficou melhor, mas o problema não foi resolvido até o fim. O Ceph tem um bom desempenho, como você pode ver nos benchmarks abaixo. Ele também tem um bom painel.
Eu realmente gosto de Longhorn. Na minha opinião, esta é uma solução promissora. É verdade que os próprios desenvolvedores (Rancher Labs) reconhecem que não é adequado para o ambiente de trabalho, e isso pode ser visto. Possui código-fonte aberto e bom desempenho (embora ainda não o tenha otimizado), mas os volumes demoram muito tempo para se conectar à lareira e, nos piores casos, leva de 15 a 16 minutos, principalmente após a restauração de uma grande carga de trabalho de backup ou atualização. Ele possui instantâneos e backups externos, mas eles se aplicam apenas a volumes; portanto, você ainda precisa de algo como o Velero para fazer backup de outros recursos. Os backups e a recuperação são muito confiáveis, mas indecentemente lentos. Sério, apenas proibitivamente lento. A utilização da CPU e o carregamento do sistema geralmente saltam ao trabalhar com dados médios no Longhorn. Existe um painel conveniente para controlar o Longhorn. Eu já disse que gosto de Longhorn, mas precisa ser trabalhado.
O StorageOS é o primeiro produto pago na lista. Ele possui uma versão para desenvolvedores com um armazenamento gerenciado limitado de 500 GB, mas o número de nós, na minha opinião, não é limitado. O departamento de vendas me disse que o custo começa em US $ 125 por mês para 1 TB, se bem me lembro. Existe um painel básico e uma CLI conveniente, mas algo estranho está acontecendo com o desempenho: em alguns benchmarks é bastante decente, mas não gostei da velocidade no teste de estresse dos volumes. Em geral, eu não sei o que dizer. Portanto, eu não entendi particularmente. Não há backups externos, e você também precisará usar o Velero com Restic para fazer backup de volumes. É estranho, porque o produto é pago. E os desenvolvedores não estavam ansiosos para se comunicar no Slack.
Eu aprendi sobre Robin no Reddit com o diretor técnico. Eu nunca tinha ouvido falar dele antes. Talvez porque eu estivesse procurando soluções gratuitas, e Robin pagasse. Eles têm uma versão gratuita bastante generosa, com 10 TB de armazenamento e três nós. Em geral, o produto é bastante decente e com recursos agradáveis. Há uma excelente CLI lá, mas o mais interessante é que você pode capturar instantaneamente e fazer backup de todo o aplicativo (no seletor de recursos, isso é chamado de Helm releases ou "flex apps"), incluindo volumes e outros recursos, para que você possa ficar sem o Velero. E tudo seria maravilhoso se não fosse um pequeno detalhe: se você restaurar (ou "importar", como Robin chama) um aplicativo em um novo cluster - por exemplo, em caso de recuperação após um acidente - a recuperação, é claro, funciona, mas continua a fazer backup do aplicativo não é permitido Nesta versão, isso simplesmente não é possível, e os desenvolvedores confirmaram. Isso, para dizer o mínimo, é estranho, especialmente quando você considera as outras vantagens (por exemplo, backups e recuperação incrivelmente rápidos). Os desenvolvedores prometem consertar tudo para o próximo lançamento. O desempenho geralmente é bom, mas notei uma coisa estranha: se você executar o benchmark diretamente no volume conectado ao host, a velocidade de leitura será muito maior do que no mesmo volume, mas por dentro. Todos os outros resultados são idênticos, mas em teoria não deve haver diferença. Embora eles estejam trabalhando nisso, fiquei chateado por causa do problema de recuperação e backup - parecia-me que finalmente encontrei uma solução adequada e estava pronto para pagar quando precisava de mais espaço ou mais servidores.
Eu realmente não tenho nada a dizer aqui. Este é um produto pago, igualmente legal e caro. O desempenho é um milagre. Até agora, este é o melhor indicador. Slack me disse que o preço começa em US $ 205 por mês por nó, conforme indicado no Google GKE Marketplace. Eu não sei se será mais barato se você comprar diretamente. De qualquer forma, não posso pagar, então fiquei muito, muito decepcionado que a licença de desenvolvedor (até 1 TB e 3 nós) seja praticamente inútil com o Kubernetes, a menos que você esteja satisfeito com a preparação estática. Eu esperava que a licença de volume caísse automaticamente para o nível do desenvolvedor no final do período de avaliação, mas não caiu. A licença de desenvolvedor pode ser usada apenas diretamente com o Docker, e a configuração no Kubernetes é muito complicada e limitada. Claro, eu prefiro o código aberto, mas se eu tivesse dinheiro, eu definitivamente escolheria o Portworx. Até agora, seu desempenho simplesmente não se compara a outras opções.
Adicionei esta seção após a publicação do post, quando um leitor sugeriu experimentar o Linstor. Eu tentei e gostei! Mas você ainda tem que cavar. Agora posso dizer que o desempenho não é ruim (adicionei os resultados de benchmark abaixo). De fato, obtive o mesmo desempenho que o da unidade diretamente, sem absolutamente nenhuma sobrecarga. (Não pergunte por que o Portworx tem números melhores do que o benchmark do drive diretamente. Não faço ideia. Provavelmente é mágico.) Portanto, Linstor ainda parece muito eficaz. A instalação não é tão difícil, mas não tão fácil quanto as outras opções. Primeiro, tive que instalar o Linstor (o módulo do kernel e as ferramentas / serviços) e configurar o LVM para provisionamento dinâmico e snapshots de suporte fora do Kubernetes, diretamente no host, e depois criar os recursos necessários para usar o armazenamento do Kubernetes. Eu não gostei do fato de não funcionar no CentOS e ter que usar o Ubuntu. Não é assustador, é claro, mas um pouco chato, porque a documentação (que, aliás, é excelente) menciona vários pacotes que não podem ser encontrados nos repositórios Epel especificados. O Linstor possui snapshots, mas não backups externos, então aqui novamente tive que usar o Velero com o Restic para fazer backup de volumes. Eu preferiria capturas instantâneas em vez de backups em nível de arquivo, mas isso pode ser tolerado se a solução for produtiva e confiável. Linstor tem código aberto, mas há suporte pago. Se bem entendi, ele pode ser usado sem restrições, mesmo se você não tiver um contrato de suporte, mas isso precisa ser esclarecido. Não sei como o Linstor é testado para o Kubernetes, mas o nível de armazenamento em si está fora do Kubernetes e, aparentemente, a solução não apareceu ontem, então provavelmente já foi testada em condições reais. Existe uma solução aqui que me faça mudar de idéia e voltar ao Kubernetes? Não sei, não sei. Ainda é necessário aprofundar, estudar a replicação. Vamos ver Mas a primeira impressão é boa. Definitivamente, eu preferiria usar meus próprios clusters Kubernetes em vez do Heroku para ganhar mais liberdade e aprender coisas novas. Como o Linstor não é instalado tão facilmente quanto os outros, escreverei um post sobre isso em breve.
Benchmarks
Infelizmente, mantive poucos registros da comparação, porque não achei que escreveria sobre isso. Eu tenho apenas os resultados dos benchmarks de base de fio e apenas para clusters de nó único; portanto, para configurações replicadas, ainda não tenho números. Porém, com base nesses resultados, você pode ter uma idéia aproximada do que esperar de cada opção, porque eu os comparei nos mesmos servidores em nuvem, 4 núcleos, 16 GB de RAM, com um disco adicional de 100 GB para os volumes em teste. Executei os benchmarks três vezes para cada solução e calculei o resultado médio, além de redefinir as configurações do servidor para cada produto. Tudo isso é completamente não científico, apenas para fazer você entender em termos gerais. Em outros testes, copiei 38 GB de fotos e vídeos do volume e para testar leitura e gravação, mas, infelizmente, não salvei os números. Em resumo: o Portworkx foi muito mais rápido.
Para a referência de volumes, usei este manifesto:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: dbench spec: storageClassName: ... accessModes: - ReadWriteOnce resources: requests: storage: 5Gi --- apiVersion: batch/v1 kind: Job metadata: name: dbench spec: template: spec: containers: - name: dbench image: sotoaster/dbench:latest imagePullPolicy: IfNotPresent env: - name: DBENCH_MOUNTPOINT value: /data - name: FIO_SIZE value: 1G volumeMounts: - name: dbench-pv mountPath: /data restartPolicy: Never volumes: - name: dbench-pv persistentVolumeClaim: claimName: dbench backoffLimit: 4
Primeiro, criei um volume com a classe de armazenamento correspondente e, em seguida, iniciei a tarefa com fio nos bastidores. Levei 1 GB para estimar o desempenho e não esperar muito tempo. Aqui estão os resultados:
Destaquei o melhor valor para cada indicador em verde e o pior em vermelho.
Conclusão
Como você pode ver, na maioria dos casos, o Portworx teve um desempenho melhor do que outros. Mas para mim, ele é querido. Não sei quanto custa o Robin, mas há uma ótima versão gratuita. Portanto, se você precisar de um produto pago, poderá experimentá-lo (espero que eles resolvam o problema com recuperação e backups em breve). Dos três gratuitos, tive menos problemas com o OpenEBS, mas seu desempenho não é para o inferno. É uma pena, não salvei mais resultados, mas espero que os números fornecidos e meus comentários o ajudem.