Atualizar!. Nos comentários, um dos leitores sugeriu tentar (talvez ele mesmo esteja trabalhando nisso), então adicionei uma seção sobre esta solução. Eu também escrevi , porque o processo é muito diferente dos demais.
Para ser sincero, desisti e desisti (pelo menos por enquanto). usarei . Por que? Por causa do armazenamento! Quem diria que eu mexeria mais no armazenamento do que no próprio Kubernetes. eu uso porque é barato e o desempenho é bom e desde o início venho implantando clusters usando . Não experimentei os serviços gerenciados do Kubernetes do Google/Amazon/Microsoft/DigitalOcean, etc., etc., porque queria aprender tudo sozinho. Eu também sou frugal.
Então, sim, passei muito tempo tentando decidir qual armazenamento escolher quando estava avaliando uma possível pilha do Kubernetes. Prefiro soluções de código aberto, não só pelo preço, mas procurei algumas opções pagas por curiosidade, porque possuem versões gratuitas com limitações. Anotei alguns números de testes recentes quando comparei diferentes opções, e eles podem ser de interesse para quem está aprendendo sobre o armazenamento do Kubernetes. Embora eu pessoalmente tenha dito adeus ao Kubernetes por enquanto. Eu também quero mencionar , que pode provisionar diretamente volumes do Hetzner Cloud, mas ainda não tentei. Pesquisei o armazenamento definido por software em nuvem porque precisava de replicação e da capacidade de montar rapidamente volumes persistentes em qualquer nó, especialmente em caso de falhas de nó e outras situações semelhantes. Algumas soluções oferecem instantâneos pontuais e backups externos, o que é conveniente.
Testei de 6 a 7 soluções de armazenamento:
Como eu já disse Depois de testar a maioria das opções da lista, inicialmente optei pelo OpenEBS. OpenEBS é muito fácil de instalar e usar, mas para ser sincero, depois de testar com dados reais sob carga, fiquei decepcionado com seu desempenho. Este é um código aberto e os desenvolvedores estão por conta própria sempre muito prestativo quando precisei de ajuda. Infelizmente, ele tem um desempenho muito ruim em comparação com outras opções, então os testes tiveram que ser executados novamente. O OpenEBS possui atualmente 3 mecanismos de armazenamento, mas estou postando resultados de benchmark para cStor. Ainda não tenho números para Jiva e LocalPV.
Resumindo, o Jiva é um pouco mais rápido e o LocalPV geralmente é rápido, não pior do que o benchmark de disco diretamente. O problema do LocalPV é que o volume só pode ser acessado no nó onde foi preparado e não há replicação alguma. Tive alguns problemas ao restaurar um backup via em um novo cluster porque os nomes dos nós eram diferentes. Se falamos de backups, o cStor tem , com o qual você pode fazer backups externos de instantâneos em um determinado momento, o que é mais conveniente do que backups em nível de arquivo com Velero-Restic. escrevi , para facilitar o gerenciamento de backups e restaurações com este plugin. No geral, gosto muito do OpenEBS, mas seu desempenho...
Rook também é de código aberto e difere do restante das opções da lista por ser um orquestrador de armazenamento que executa tarefas complexas de gerenciamento de armazenamento com diferentes back-ends, por exemplo. , e outros, o que simplifica muito o trabalho. Tive problemas com o EfgeFS quando tentei há alguns meses, então testei principalmente com o Ceph. Ceph não oferece apenas armazenamento em blocos, mas também armazenamento de objetos compatível com S3/Swift e sistema de arquivos distribuído. O que eu gosto no Ceph é a capacidade de distribuir dados de volume por vários discos para que o volume possa usar mais espaço em disco do que cabe em um único disco. É confortável. Outro recurso interessante é que quando você adiciona discos a um cluster, ele redistribui automaticamente os dados entre todos os discos.
O Ceph possui snapshots, mas até onde eu sei, eles não podem ser usados diretamente no Rook/Kubernetes. É verdade que não me aprofundei nisso. Mas não há backups externos, então você terá que usar algo com Velero/Restic, mas existem apenas backups em nível de arquivo, não instantâneos pontuais. O que eu realmente gostei no Rook foi como é fácil trabalhar com o Ceph - ele esconde quase todas as coisas complicadas e oferece ferramentas para conversar diretamente com o Ceph para solucionar problemas. Infelizmente, durante o teste de estresse dos volumes do Ceph, continuei tendo problemas com , o que faz com que o Ceph fique instável. Ainda não está claro se isso é um bug no próprio Ceph ou um problema na forma como Rook gerencia o Ceph. Mexi nas configurações de memória e melhorou, mas o problema não foi totalmente resolvido. O Ceph tem um desempenho decente, como você pode ver nos benchmarks abaixo. Ele também tem um bom painel.
Eu gosto muito de Longhorn. Na minha opinião, esta é uma solução promissora. É verdade que os próprios desenvolvedores (Rancher Labs) admitem que ainda não é adequado para o ambiente de trabalho, e isso fica evidente. É de código aberto e tem desempenho decente (embora ainda não tenha sido otimizado), mas os volumes demoram muito para se conectar ao pod e, na pior das hipóteses, leva de 15 a 16 minutos, especialmente após a restauração de um backup grande ou atualizando a carga de trabalho. Ele possui snapshots e backups externos desses snapshots, mas eles só se aplicam a volumes, então você ainda precisará de algo como o Velero para fazer backup de outros recursos. Backups e restaurações são muito confiáveis, mas indecentemente lentos. Sério, incrivelmente lento. O uso da CPU e a carga do sistema geralmente aumentam ao trabalhar com uma quantidade média de dados no Longhorn. Existe um painel conveniente para gerenciar o Longhorn. Já disse que gosto do Longhorn, mas precisa de algum trabalho.
StorageOS é o primeiro produto pago da lista. Ele tem uma versão de desenvolvedor com tamanho de armazenamento gerenciado limitado de 500 GB, mas não acho que haja limite para o número de nós. O departamento de vendas me disse que o custo começa em US$ 125 por mês por 1 TB, se bem me lembro. Há um painel básico e uma CLI conveniente, mas algo estranho está acontecendo com o desempenho: em alguns benchmarks é bastante decente, mas no teste de estresse de volume não gostei nada da velocidade. Em geral, não sei o que dizer. Então eu realmente não entendi muito. Não há backups externos aqui e você também terá que usar 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.
Aprendi sobre Robin no Reddit com seu diretor técnico. Eu nunca tinha ouvido falar dele antes. Talvez porque procurasse soluções gratuitas, mas Robin é pago. Eles têm uma versão gratuita bastante generosa com 10 TB de armazenamento e três nós. No geral, o produto é bastante decente e possui recursos interessantes. Há uma CLI ótima, mas o mais legal é que você pode capturar instantâneos e fazer backup de todo o aplicativo (no seletor de recursos isso é chamado de versões do Helm ou “aplicativos flexíveis”), incluindo volumes e outros recursos, para que você possa fazer isso sem o Velero. E tudo seria maravilhoso se não fosse por um pequeno detalhe: se você restaurar (ou “importar”, como é chamado no Robin) um aplicativo em um novo cluster - por exemplo, em caso de recuperação de um desastre - a restauração, claro, funciona, mas é proibido continuar a fazer backup do aplicativo. Isto simplesmente não é possível nesta versão, como os desenvolvedores confirmaram. Isso é, para dizer o mínimo, estranho, especialmente considerando as outras vantagens (por exemplo, backups e restaurações incrivelmente rápidos). Os desenvolvedores prometem consertar tudo até o próximo lançamento. O desempenho geralmente é bom, mas notei uma estranheza: se eu executar o benchmark diretamente em um volume conectado ao host, a velocidade de leitura será muito mais rápida do que executar o mesmo volume dentro do pod. Todos os outros resultados são idênticos, mas em teoria não deveria haver diferença. Embora eles estejam trabalhando nisso, fiquei chateado com o problema de restauração e backup - pensei ter finalmente encontrado uma solução adequada e estava até disposto a pagar por isso quando precisasse de mais espaço ou mais servidores.
Não tenho muito a dizer aqui. Este é um produto pago, igualmente bacana e caro. O desempenho é simplesmente incrível. Este é o melhor indicador até agora. Slack me disse que o preço começa em US$ 205 por mês por nó, conforme listado no GKE Marketplace do Google. Não sei se será mais barato se você comprar diretamente. De qualquer maneira, não posso pagar por isso, então fiquei muito, muito desapontado porque a licença de desenvolvedor (até 1 TB e 3 nós) é praticamente inútil com o Kubernetes, a menos que você esteja satisfeito com o provisionamento estático. Eu esperava que a licença por volume fosse automaticamente rebaixada para desenvolvedor no final do período de teste, mas isso não aconteceu. A licença de desenvolvedor só pode ser usada diretamente com Docker, e a configuração no Kubernetes é muito complicada e limitada. Claro, prefiro código aberto, mas se eu tivesse dinheiro, com certeza 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 experimentei e gostei! Mas ainda precisamos cavar mais fundo. Agora posso dizer que o desempenho não é ruim (adicionei os resultados do benchmark abaixo). Essencialmente, obtive o mesmo desempenho do disco diretamente, sem qualquer sobrecarga. (Não pergunte por que o Portworx tem números melhores do que o benchmark do drive diretamente. Não tenho ideia. Mágica, eu acho.) Portanto, o Linstor parece muito eficaz até agora. Não é tão difícil de instalar, mas não é tão fácil quanto outras opções. Primeiro tive que instalar o Linstor (módulo do kernel e ferramentas/serviços) e configurar o LVM para provisionamento thin e suporte a snapshots fora do Kubernetes, diretamente no host, e então criar os recursos necessários para usar o armazenamento do Kubernetes. Não gostei que não funcionasse no CentOS e tive que usar o Ubuntu. Não é terrível, claro, mas um pouco chato, porque a documentação (que é excelente, aliás) menciona vários pacotes que não podem ser encontrados nos repositórios Epel especificados. Linstor tem snapshots, mas não backups externos, então aqui novamente tive que usar Velero com Restic para fazer backup de volumes. Eu preferiria instantâneos em vez de backups em nível de arquivo, mas isso pode ser tolerado se a solução tiver desempenho e for confiável. Linstor é de código aberto, mas tem suporte pago. Se bem entendi, pode ser utilizado sem restrições, mesmo que você não tenha contrato de suporte, mas isso precisa ser esclarecido. Não sei quão testado é o Linstor para Kubernetes, mas a camada 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 fará mudar de ideia e voltar para o Kubernetes? Não sei. Ainda precisamos nos aprofundar e 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 ter mais liberdade e aprender coisas novas. Como o Linstor não é tão fácil de instalar quanto os outros, escreverei um post sobre ele em breve.
Benchmarks
Infelizmente, não fiz muitas anotações sobre a comparação porque não pensei em escrever sobre isso. Só tenho resultados de benchmarks básicos de fio e apenas para clusters de nó único, portanto ainda não tenho números para configurações replicadas. Mas a partir desses resultados você pode ter uma ideia aproximada do que esperar de cada opção, pois comparei-as nos mesmos servidores em nuvem, 4 núcleos, 16 GB de RAM, com um disco adicional de 100 GB para os volumes testados. 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 se ter uma ideia geral. Em outros testes, copiei 38 GB de fotos e vídeos do volume para testar leitura e escrita, mas, infelizmente, não salvei os números. Resumindo: Portworkx foi muito mais rápido.
Para o benchmark de volume 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: 4Primeiro criei um volume com a classe de armazenamento apropriada e depois executei o trabalho com fio nos bastidores. Peguei 1 GB para estimar o desempenho e não esperar muito. Aqui estão os resultados:
Destaquei o melhor valor para cada métrica em verde e o pior em vermelho.
Conclusão
Como você pode ver, na maioria dos casos o Portworx teve um desempenho melhor que outros. Mas para mim é caro. Não sei quanto custa o Robin, mas eles têm uma ótima versão gratuita, então se você quiser um produto pago, pode experimentá-lo (espero que eles resolvam o problema de restauração e backups em breve). Dos três gratuitos, tive menos problemas com o OpenEBS, mas seu desempenho é péssimo. É uma pena não ter salvo mais resultados, mas espero que os números e meus comentários ajudem você.
Fonte: habr.com