Um Kubernetes Operator é uma extensão de software do Kubernetes que oferece suporte a recursos integrados para gerenciar seus aplicativos Kubernetes de forma automatizada e que segue os princípios do Kubernetes - especialmente o Loop de controle padrão.
Por que precisamos de um Operador de Kubernetes? Vamos lá Considere o exemplo do StatefulSets.
Os StatefulSets são ótimos para determinados casos de uso, mas não funcionam muito bem para executar softwares complexos, como bancos de dados, porque se concentram na criação e no gerenciamento de pods, e não no gerenciamento do software executado neles. Portanto, se você quisesse um cluster de quatro nós e implantasse Couchbase Usando o StatefulSets, você teria quatro pods do Couchbase não inicializados que não sabem uns dos outros. Caberia a você juntar os nós em um cluster, e isso significa tarefas operacionais adicionais.
Ao implantar Operador autônomo do Couchbase com um exclusivo personalizado Controlador do CouchbaseQuando um pod do Couchbase é implantado, o Kubernetes obtém conhecimento específico do Couchbase para que possa configurá-lo e uni-lo adequadamente a outros pods do Couchbase no cluster.
O provisionamento de cluster, a falha de nó, o dimensionamento ad-hoc e muitas outras tarefas de gerenciamento também exigem conhecimento específico do Couchbase no Kubernetes para serem automatizados adequadamente. Portanto, um operador do Kubernetes é a melhor maneira de tornar o banco de dados a principal escolha para o desenvolvimento nativo da nuvem no Kubernetes. No entanto, ao tentar descobrir qual banco de dados é realmente nativo da nuvem e mais adequado às metas da sua organização, você deve considerar vários fatores.
Neste artigo, comparo o Couchbase Autonomous Operator, uma parte essencial do Pilha nativa da nuvem do Couchbase contra o MongoDB Enterprise Kubernetes Operator sobre vários fatores que são fundamentais para tomar a decisão certa ao selecionar um banco de dados para desenvolvimentos nativos da nuvem.
Integrações nativas da nuvem
Figura 1: pilha nativa da nuvem do Couchbase
Conforme mostrado na Figura 1 acima, Operador autônomo do Couchbase tem integrações estreitas - e, em alguns casos, nativas - com ferramentas como o Prometheus Exporter, FluentBitHelm Chart, Service Broker, Operator Metering, Istio Service Mesh, CoreDNS, GlusterFS, Ceph, Portworx, CNI. Todos eles são totalmente certificados e compatíveis com o produto.
O MongoDB Enterprise Kubernetes Operator não oferece suporte nativo a todas essas integrações. O Service Broker e o Helm Chart são extensões do MongoDB Atlas, mas não do MongoDB Kubernetes Operator.
Arquitetura
Figura 2: Arquitetura do operador autônomo do Couchbase para Kubernetes
O Couchbase Autonomous Operator é verdadeiramente nativo da nuvem e se baseia na estrutura padrão nativa da nuvem do Operator. Como um produto completo, todas as operações são executadas pelo Couchbase Autonomous Operator, seja provisionamento de banco de dados, backup/restauração, alertas/monitoramento ou integrações nativas com projetos de código aberto, como Prometheus ou API OSB.
O Couchbase Autonomous Operator fornece uma rede de segurança para os clientes que estão implantando no Kubernetes e simplifica a implantação do Couchbase com um controlador de admissão com controle de acesso baseado em função (RBAC).
Figura 3: Arquitetura do operador do MongoDB Enterprise Kubernetes. Fonte
O MongoDB Enterprise Kubernetes Operator é um invólucro em torno do MongoDB Ops Manager que em si é um invólucro em torno do banco de dados MongoDB. Por outro lado, o Couchbase Autonomous Operator não é um invólucro, mas um produto utilitário completo que amplia os recursos de automação do Couchbase no nuvem para oferecer implementações totalmente gerenciadas.
A arquitetura do MongoDB Enterprise Kubernetes Operator não é nativa da nuvem. Cada operação Day-2 não é realizada diretamente pelo MongoDB Kubernetes Operator, mas por meio do MongoDB Ops Manager, incluindo provisionamento, backup/restauração, alertas/monitoramento etc. O MongoDB Enterprise Kubernetes Operator também não tem um controlador de admissão.
Nível de maturidade do operador
Há cinco níveis de maturidade de qualquer operador de Kubernetes:
-
- Instalação básica
- Upgrades contínuos
- Ciclo de vida completo
- Insights profundos
- Piloto automático
O Couchbase Autonomous Operator é certificado como um Operador Kubernetes de Nível 5 que atende aos critérios de cada nível até o Auto-piloto, o nível mais alto do Modelo de Maturidade da Capacidade do Operador. (Referência.)
O MongoDB Enterprise Kubernetes Operator não é um operador de nível 5. (Referência.)
Comparação de recursos: Operador autônomo do Couchbase vs. Operador de Kubernetes do MongoDB Enterprise
Categoria de recursos |
Operador autônomo do Couchbase (CAO) 2.2 para Kubernetes |
Operador de Kubernetes Empresarial MongoDB 1.10 |
Escala automática |
O Couchbase Autonomous Operator oferece suporte ao dimensionamento automático de todos os serviços do Couchbase.
Esse recurso é único no setor de bancos de dados, pois Você pode dimensionar horizontalmente e de forma automática um único serviço ou um grupo de serviços com base em limites totalmente personalizados e definidos pelo usuário para qualquer estatística do Couchbase, de acordo com as necessidades específicas de seu ambiente. |
O MongoDB Enterprise Kubernetes Operator não oferece suporte ao dimensionamento automático.
O MongoDB Atlas suporta apenas o dimensionamento automático vertical com estatísticas limitadas: utilização de memória e CPU. Essa flexibilidade limitada pode custar muito caro durante os horários de pico se outras operações não forem configuradas (ou priorizadas) adequadamente durante o dimensionamento automático. |
Hibernação do cluster |
O Couchbase Autonomous Operator oferece suporte à hibernação do cluster com um IMEDIATO estratégia de desligamento.
Os documentos que não são liberados podem morrer, mas ao definir um DURABILIDADE é possível obter melhor controle sobre o comportamento do desligamento. |
O MongoDB Enterprise Kubernetes Operator não oferece suporte à hibernação de cluster.
A hibernação do cluster é compatível apenas com o Atlas. A documentação do API DE PAUSA lista todas as propriedades de configuração do cluster que estão sendo pausadas, exceto a DURABILIDADE que é o parâmetro mais importante para que os clientes entendam o que acontece com as operações, consultas ou documentos em andamento. (Referência.) |
Configuração e implantação (CI/CD) |
O CAO oferece suporte a integrações nativas da nuvem com Helm Charts e API OSB.
O CAO pode ser implementado por meio do Couchbase Helm Chart e do Couchbase Service Broker. |
O MongoDB Enterprise Operator não oferece suporte a integrações nativas com Helm Charts e API OSB.
Observação: o MongoDB pode oferecer suporte à API Helm ou OSB com outros produtos, como o Atlas ou o MongoDB Ops Manager, mas o MongoDB Enterprise Kubernetes Operator não. |
Manutenção e upgrades |
As atualizações de cluster do Kubernetes, as atualizações de CAO e as atualizações de cluster do Couchbase são compatíveis com o Couchbase Autonomous Operator.
O CAO oferece suporte a upgrades em massa, juntamente com os tradicionais upgrades contínuos, sem tempo de inatividade. O Couchbase Autonomous Operator também oferece suporte a atualizações contínuas personalizadas, ou seja, você pode selecionar o número de pods ou uma porcentagem de pods em um cluster para atualizar, enquanto o restante dos pods continua a ser executado como está. |
A documentação do MongoDB Enterprise Kubernetes Operator não menciona a atualização das instâncias do banco de dados MongoDB por meio do MongoDB Enterprise Kubernetes Operator.
O MongoDB Enterprise Kubernetes Operator não oferece suporte a upgrades em massa. De acordo com as etapas mencionadas aquiSe o Operador do Kubernetes do MongoDB Enterprise não for excluído, o Operador poderá sempre gerar um erro e exigir a exclusão do Operador, o que envolve tempo de inatividade. (Referência.) |
Alta disponibilidade e recuperação de desastres |
O Couchbase Autonomous Operator oferece suporte a alta disponibilidade (HA), afinidade de nós, failover automático, tolerância a falhas e XDCR. | O MongoDB Enterprise Kubernetes Operator oferece suporte à tolerância a falhas e ao failover automático.
No entanto, ele depende internamente do MongoDB Ops Manager para operações de HA e XDCR, o que adiciona uma camada de serviço e pode afetar o desempenho em termos de taxa de transferência e latência. |
Gerenciamento de segurança |
O gerenciamento de segurança do Couchbase Autonomous Operator inclui suporte a RBAC, LDAP e TLS. | O MongoDB Enterprise Kubernetes Operator fornece segurança e também inclui suporte a RBAC, LDAP e TLS por meio do MongoDB Ops Manager. |
Gerenciamento de backup |
O backup e a restauração são totalmente gerenciados pelo Couchbase Autonomous Operator de forma nativa.
Também há suporte para backup no AWS S3. |
O backup/restauração não é gerenciado pelo MongoDB Enterprise Kubernetes Operator nativamente, mas pelo MongoDB Ops Manager. |
Análise de observabilidade |
O Couchbase Autonomous Operator tem integração nativa com o Prometheus, Grafana para monitoramento e alertas com FluentBit para encaminhamento centralizado de registros e registro de auditoria automatizado. | Os alertas e o monitoramento são compatíveis com o MongoDB Ops Manager.
O MongoDB Enterprise Kubernetes Operator não tem uma integração empresarial nativa com o Prometheus ou o FluentBit (Observação: a documentação do MongoDB Enterprise Kubernetes Operator não menciona essas integrações em nenhum lugar. Referência.) |
Trabalho em rede |
O Couchbase Autonomous Operator oferece suporte a integrações nativas da nuvem com CNI, CoreDNS e Istio Service Mesh. | O MongoDB Enterprise Kubernetes Operator não tem essas integrações nativas.
A documentação do MongoDB Enterprise Kubernetes Operator não menciona nenhuma dessas integrações nativas da nuvem. (Referência.) |
Armazenamento |
O Couchbase Autonomous Operator oferece suporte a integrações de armazenamento nativo da nuvem para GlusterFS, Ceph e Portworx.
O Couchbase Autonomous Operator também oferece suporte à expansão on-line de volumes persistentes, bem como ao dimensionamento de volumes de backup on-line Observação: a expansão de volume persistente on-line significa aumentar a escala de volumes persistentes sem precisar reiniciar os pods. |
A documentação do MongoDB Enterprise Kubernetes Operator não menciona nenhuma dessas integrações nativas da nuvem. (Referência.)
O MongoDB Enterprise Kubernetes Operator não oferece suporte ao dimensionamento de armazenamento on-line. Ele também não oferece suporte ao dimensionamento de volume de backup on-line. |
Conclusão
O MongoDB fornece a maioria de seus recursos avançados por meio do MongoDB Ops Manager ou do MongoDB Atlas, mas não oferece suporte a eles por meio do MongoDB Enterprise Kubernetes Operator. Essa camada adicional do Ops Manager aumenta o custo dos recursos, afeta o desempenho e acrescenta complexidades arquitetônicas desnecessárias.
Por outro lado, o Couchbase Autonomous Operator é um produto completo e oferece suporte a todos os serviços diretamente de uma forma verdadeiramente nativa da nuvem. O CAO é mais maduro do que qualquer outro operador Kubernetes no setor de banco de dados.
Referências
-
- https://docs.couchbase.com
- https://docs.couchbase.com/cloud-native-database/index.html
- https://docs.couchbase.com/operator/current/overview.html
- https://docs.mongodb.com
- https://medium.com/hackernoon/getting-started-with-mongodb-enterprise-operator-for-kubernetes-bb5d5205fe02
- https://www.couchbase.com/blog/couchbase-autonomous-operator-2-1-for-kubernetes-is-now-ga/
- https://info.couchbase.com/rs/302-GJY-034/images/CBvM_Scale_out%20_High_availability.pdf
- https://www.couchbase.com/blog/couchbase-better-scale-out-agility-and-high-availability-than-mongodb/
- https://connectondemand.couchbase.com/watch/wET3Bo88agGqFCTbMWXegJ
