Atualização!. Um dos leitores nos comentários sugeriu tentar (talvez ele esteja trabalhando nisso), então adicionei uma seção sobre essa solução. Também escrevi , pois o processo é bastante diferente dos outros.
Para ser sincero, desisti e abandonei (pelo menos por enquanto). Vou usar . Por quê? Por causa do armazenamento! Quem diria que eu ia gastar mais tempo lidando com armazenamento do que com Kubernetes em si. Estou usando , porque é barato e a performance é boa, e desde o início venho implantando clusters usando . Não experimentei serviços gerenciados de Kubernetes do Google/Amazon/Microsoft/DigitalOcean e por aí vai, porque queria aprender tudo por conta própria. E também sou econômico.
Então, sim, passei uma boa quantidade de tempo tentando decidir qual armazenamento escolher ao planejar a pilha possível no Kubernetes. Prefiro soluções de código aberto, não apenas pelo preço, mas também explorei algumas opções pagas por curiosidade, pois têm versões gratuitas com limitações. Anotei alguns números dos últimos testes ao comparar diferentes opções, e eles podem interessar àqueles que estão estudando armazenamento no Kubernetes. Embora, pessoalmente, eu tenha me afastado do Kubernetes por enquanto. Quero também mencionar , que permite preparar volumes do Hetzner Cloud diretamente, mas ainda não o experimentei. Estudei armazenamentos definidos por software em nuvem, porque precisava de replicação e da capacidade de conectar volumes permanentes rapidamente em qualquer nó, especialmente em caso de falha de nó e outras situações semelhantes. Algumas soluções oferecem snapshots no tempo e backups off-site, o que é conveniente.
Teste seis a sete soluções de armazenamento:
Como mencionei , após testar a maioria das opções da lista, inicialmente me decidi pelo OpenEBS. OpenEBS é muito fácil de instalar e usar, mas, para ser honesto, após os testes com dados reais sob carga, seu desempenho me decepcionou. É de código aberto, e os desenvolvedores têm seu sempre foram muito úteis quando precisei de ajuda. Infelizmente, sua performance é muito baixa em comparação com outras opções, então precisei realizar os testes novamente. Atualmente, o OpenEBS possui 3 motores de armazenamento, mas estou publicando os resultados do benchmark para o cStor. Até agora, não tenho números para Jiva e LocalPV.
Em poucas palavras, Jiva é um pouco mais rápido, e LocalPV é realmente rápido, não pior do que o benchmark do disco direto. O problema com LocalPV é que o acesso pode ser obtido apenas no nó onde foi preparado, e não há replicação. Tive alguns problemas para restaurar o backup através de num novo cluster, porque os nomes dos nós eram diferentes. Falando em backups, o cStor tem , que permite fazer backups off-site de snapshots em momentos específicos, o que é mais conveniente do que backups a nível de arquivos com Velero-Restic. Eu escrevi , para facilitar o gerenciamento de backups e restaurações com esse plugin. No geral, gostei muito do OpenEBS, mas sua performance…
O Rook também é de código aberto, e se diferencia das outras opções na lista por ser um orquestrador de armazenamento que executa tarefas complexas de gerenciamento de armazenamento com diferentes backends, como , e outros, o que simplifica bastante o trabalho. Tive problemas com o EdgeFS quando o testei há alguns meses, então fiz a maior parte dos meus testes com Ceph. O Ceph oferece não apenas armazenamento em bloco, mas também armazenamento de objetos compatível com S3/Swift e um sistema de arquivos distribuído. O que gosto no Ceph é a capacidade de espalhar os dados de uma volume por vários discos, permitindo que o volume use mais espaço de disco do que cabe em um único disco. Isso é prático. Outra função interessante é que, ao adicionar discos ao cluster, ele redistribui automaticamente os dados entre todos os discos.
No Ceph, há snapshots, mas, até onde eu sei, eles não podem ser usados diretamente no Rook/Kubernetes. Honestamente, não investiguei a fundo. Além disso, não há backups off-site, então teremos que usar algo como Velero/Restic, mas isso apenas faz backups ao nível de arquivos e não snapshots de um ponto no tempo. Por outro lado, gostei muito da facilidade de uso do Ceph no Rook — ele esconde quase todas as complexidades e oferece ferramentas para interagir diretamente com o Ceph para solução de problemas. Infelizmente, eu sempre enfrentava , que torna o Ceph instável. Ainda não está claro se é um bug no próprio Ceph ou um problema na forma como o Rook gerencia o Ceph. Eu brinquei com as configurações de memória, e melhorou um pouco, mas o problema não foi completamente resolvido. O Ceph tem um bom desempenho, como pode ser visto nos benchmarks abaixo. Além disso, possui um bom painel de monitoramento.
Gosto bastante do Longhorn. A meu ver, é uma solução promissora. Contudo, os próprios desenvolvedores (Rancher Labs) admitem que ainda não é adequado para ambientes de produção, e isso é evidente. Ele é de código aberto e tem um desempenho razoável (embora ainda não tenham otimizado), mas as volumes demoram muito para se conectar aos pods, tendo, em piores cenários, um tempo de 15 a 16 minutos, especialmente após a restauração de um grande backup ou a atualização da carga de trabalho. Ele possui snapshots e backups off-site para esses snapshots, mas eles só se aplicam às volumes, então você ainda precisará de algo como o Velero para fazer backup dos outros recursos. Os backups e restaurações são muito confiáveis, mas excessivamente lentos. Sério, são incrivelmente lentos. O uso de CPU e a carga do sistema frequentemente disparam ao trabalhar com volumes medianos de dados no Longhorn. Há um painel de monitoramento conveniente para gerenciar o Longhorn. Já mencionei que gosto do Longhorn, mas é necessário trabalhar melhor nele.
StorageOS é o primeiro produto pago na lista. Ele tem uma versão para desenvolvedores com um tamanho limitado de armazenamento gerenciado de 500 GB, mas o número de nós, me parece, não é limitado. No departamento de vendas, disseram-me que o custo começa em $125 por mês por 1 TB, se eu me lembro corretamente. Há um painel de monitoramento básico e um CLI conveniente, mas a performance está um pouco estranha: em alguns benchmarks é bastante razoável, mas nos testes de estresse dos volumes, a velocidade não me agradou. No geral, não sei o que dizer. Portanto, não investiguei muito. Aqui não há backups off-site e também será necessário usar o Velero com Restic para o backup dos volumes. É estranho, já que o produto é pago. Além disso, os desenvolvedores não estavam muito entusiasmados em se comunicar no Slack.
Eu descobri sobre o Robin no Reddit através do seu diretor técnico. Antes disso, nunca tinha ouvido falar. Pode ser porque estava em busca de soluções gratuitas, enquanto o Robin é pago. Eles oferecem uma versão gratuita bastante generosa, com armazenamento de 10 TB e três nós. No geral, o produto é bastante respeitável e possui recursos agradáveis. Tem um CLI excelente, mas o mais impressionante é que é possível fazer snapshots e backups de toda a aplicação (no seletor de recursos, isso é chamado de releases do Helm ou 'flex apps'), incluindo volumes e outros recursos, permitindo que você não precise do Velero. E tudo seria maravilhoso, se não fosse por um pequeno detalhe: ao restaurar (ou 'importar', como é chamado no Robin) uma aplicação em um novo cluster — por exemplo, em caso de recuperação de desastre — a restauração, claro, funciona, mas não é possível continuar o backup da aplicação. Neste release, isso é simplesmente impossível, e os desenvolvedores confirmaram. Isso é, para dizer o mínimo, estranho, especialmente considerando as outras vantagens (como backups e restaurações incrivelmente rápidas). Os desenvolvedores prometem corrigir tudo na próxima versão. O desempenho, no geral, é bom, mas notei uma estranheza: ao rodar um benchmark diretamente no volume conectado ao host, a velocidade de leitura é muito maior do que no mesmo volume, mas de dentro do pod. Todos os outros resultados são idênticos, mas teoricamente não deveria haver diferença. Mesmo que estejam trabalhando nisso, fiquei desapontado com o problema de restauração e backup — parecia que finalmente havia encontrado uma solução adequada, e eu estava até disposto a pagar por ela, quando precisasse de mais espaço ou mais servidores.
Aqui eu não tenho muito a dizer. Este é um produto pago, igualmente excelente e caro. O desempenho é simplesmente incrível. Até agora, este é o melhor resultado. No Slack, me disseram que o preço começa em $205 por mês por nó, conforme indicado no Marketplace do GKE do Google. Não sei se será mais barato comprando diretamente. De qualquer forma, não posso me permitir isso, então fiquei muito e muito desapontado que a licença de desenvolvedor (até 1 TB e 3 nós) é praticamente inútil com Kubernetes, a menos que você se contente com uma configuração estática. Eu esperava que a licença corporativa automaticamente diminuísse para o nível de desenvolvedor ao final do período de teste, mas isso não aconteceu. A licença de desenvolvedor só pode ser utilizada diretamente com o Docker, e a configuração no Kubernetes é muito complexa e limitada. Eu, claro, prefiro soluções de código aberto, mas se eu tivesse dinheiro, 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 ainda preciso investigar mais. Atualmente, posso dizer que o desempenho é bom (os resultados do benchmark estão adicionados abaixo). Essencialmente, consegui o mesmo desempenho que teria com o disco diretamente, sem nenhuma penalização. (Não pergunte por que os números do Portworx são melhores do que o benchmark do disco diretamente. Não tenho ideia. Deve ser mágica.) Então, o Linstor parece ser muito eficiente por enquanto. Instalá-lo não é tão difícil, mas também não é tão fácil quanto as outras opções. Primeiro, tive que instalar o Linstor (módulo do kernel e ferramentas/serviços) e configurar o LVM para thin provisioning e suporte a snapshots fora do Kubernetes, diretamente no host, e depois criar os recursos necessários para usar o armazenamento a partir do Kubernetes. Não gostei de o Linstor não ter funcionado no CentOS e ter que usar o Ubuntu. Não é um problema, claro, mas é um pouco irritante, porque na documentação (que, por sinal, é excelente) são mencionados vários pacotes que não podem ser encontrados nos repositórios Epel indicados. O Linstor possui snapshots, mas não backups off-site, então novamente precisei usar o Velero com Restic para fazer backup dos volumes. Eu preferiria snapshots em vez de backups a nível de arquivos, mas isso pode ser aceitável se a solução for eficiente e confiável. O Linstor é de código aberto, mas há suporte pago disponível. Se eu entendi corretamente, ele pode ser usado sem restrições, mesmo que você não tenha um contrato de suporte, mas isso precisa ser confirmado. Não sei quão testado o Linstor é para Kubernetes, mas o próprio nível de armazenamento está fora do Kubernetes e, pelo que parece, a solução não surgiu ontem, então provavelmente já foi testada em condições reais. Existe alguma solução aqui que me faça reconsiderar e voltar ao Kubernetes? Não sei, não sei. Preciso investigar mais, estudar a replicação. Vamos ver. Mas a primeira impressão é boa. Eu definitivamente preferiria usar meus próprios clusters Kubernetes em vez do Heroku, para ter mais liberdade e aprender algo novo. Como o Linstor não é tão simples de instalar quanto os outros, em breve escrevi sobre isso.
Benchmarks
Infelizmente, eu salvei poucas anotações sobre as comparações, porque não imaginei que escreveria sobre isso. Eu só tenho os resultados de benchmarks básicos fio e apenas para clusters com um único nó, então não tenho números ainda para configurações replicadas. Mas com esses resultados, é possível ter uma ideia aproximada do que esperar de cada opção, pois eu os comparei em servidores em nuvem iguais, com 4 núcleos, 16 GB de RAM, e um disco adicional de 100 GB para os volumes testados. Executei os benchmarks três vezes para cada solução e calculei a média, além de reiniciar as configurações do servidor para cada produto. Tudo isso não é científico, apenas para que você tenha uma noção geral. Em outros testes, copiei 38 GB de fotos e vídeos de um volume e para um volume, para testar leitura e gravação, mas, infelizmente, não salvei os números. Resumindo: o Portworx foi muito mais rápido.
Para o benchmark dos volumes, eu 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, eu criei um volume com a classe de armazenamento apropriada e, em seguida, executei a tarefa com fio em segundo plano. Eu usei 1 GB para estimar o desempenho e não esperar muito tempo. Aqui estão os resultados:
Eu 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 se destacou em relação aos outros. Mas para mim, é caro. Não sei quanto custa o Robin, mas ele tem uma ótima versão gratuita, então, se você precisar de um produto pago, pode experimentar (espero que eles resolvam em breve o problema com restaurações e backups). Dos três gratuitos, tive menos problemas com o OpenEBS, mas o desempenho dele é péssimo. É uma pena que eu não tenha salvo mais resultados, mas espero que os números apresentados e meus comentários ajudem você.
Fonte: habr.com
