{"id":11228,"date":"2021-07-13T01:49:32","date_gmt":"2021-07-13T08:49:32","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=11228"},"modified":"2025-12-19T06:38:51","modified_gmt":"2025-12-19T14:38:51","slug":"couchbase-autonomous-operator-for-kubernetes-vs-mongodb-enterprise-kubernetes-operator","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/couchbase-autonomous-operator-for-kubernetes-vs-mongodb-enterprise-kubernetes-operator\/","title":{"rendered":"Operador aut\u00f4nomo do Couchbase vs. Operador de Kubernetes do MongoDB Enterprise"},"content":{"rendered":"

Um Kubernetes Operator \u00e9 uma extens\u00e3o de software do Kubernetes que<\/strong> oferece suporte a recursos integrados para gerenciar seus aplicativos Kubernetes de forma automatizada e que segue os princ\u00edpios do Kubernetes - especialmente o Loop de controle<\/a> padr\u00e3o.<\/p>\n

Por que precisamos de um Operador de Kubernetes<\/a>? Vamos l\u00e1 Considere o exemplo do StatefulSets<\/a>.<\/p>\n

Os StatefulSets s\u00e3o \u00f3timos para determinados casos de uso, mas n\u00e3o funcionam muito bem para executar softwares complexos, como bancos de dados, porque se concentram na cria\u00e7\u00e3o e no gerenciamento de pods, e n\u00e3o no gerenciamento do software executado neles. Portanto, se voc\u00ea quisesse um cluster de quatro n\u00f3s e implantasse Couchbase<\/a> Usando o StatefulSets, voc\u00ea teria quatro pods do Couchbase n\u00e3o inicializados que n\u00e3o sabem uns dos outros. Caberia a voc\u00ea juntar os n\u00f3s em um cluster, e isso significa tarefas operacionais adicionais.<\/p>\n

Ao implantar Operador aut\u00f4nomo do Couchbase<\/a> com um exclusivo personalizado Controlador do Couchbase<\/a>Quando um pod do Couchbase \u00e9 implantado, o Kubernetes obt\u00e9m conhecimento espec\u00edfico do Couchbase para que possa configur\u00e1-lo e uni-lo adequadamente a outros pods do Couchbase no cluster.<\/p>\n

O provisionamento de cluster, a falha de n\u00f3, o dimensionamento ad-hoc e muitas outras tarefas de gerenciamento tamb\u00e9m exigem conhecimento espec\u00edfico do Couchbase no Kubernetes para serem automatizados adequadamente. Portanto, um operador do Kubernetes \u00e9 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 \u00e9 realmente nativo da nuvem e mais adequado \u00e0s metas da sua organiza\u00e7\u00e3o, voc\u00ea deve considerar v\u00e1rios fatores.<\/p>\n

Neste artigo, comparo o Couchbase Autonomous Operator, uma parte essencial do Pilha nativa da nuvem do Couchbase<\/a> contra o MongoDB Enterprise Kubernetes Operator sobre v\u00e1rios fatores que s\u00e3o fundamentais para tomar a decis\u00e3o certa ao selecionar um banco de dados para desenvolvimentos nativos da nuvem.<\/p>\n

Integra\u00e7\u00f5es nativas da nuvem<\/h2>\n
<\/div>\n

\"An<\/p>\n

Figura 1: pilha nativa da nuvem do Couchbase<\/em><\/p>\n

Conforme mostrado na Figura 1 acima, Operador aut\u00f4nomo do Couchbase<\/a> tem integra\u00e7\u00f5es estreitas - e, em alguns casos, nativas - com ferramentas como o Prometheus Exporter, FluentBit<\/a>Helm Chart, Service Broker, Operator Metering, Istio Service Mesh, CoreDNS, GlusterFS, Ceph, Portworx, CNI. Todos eles s\u00e3o totalmente certificados e compat\u00edveis com o produto.<\/p>\n

O MongoDB Enterprise Kubernetes Operator n\u00e3o oferece suporte nativo a todas essas integra\u00e7\u00f5es. O Service Broker e o Helm Chart s\u00e3o extens\u00f5es do MongoDB Atlas, mas n\u00e3o do MongoDB Kubernetes Operator.<\/p>\n

Arquitetura<\/h2>\n
<\/div>\n

\"An<\/p>\n

Figura 2: Arquitetura do operador aut\u00f4nomo do Couchbase para Kubernetes<\/em><\/p>\n

O Couchbase Autonomous Operator \u00e9 verdadeiramente nativo da nuvem e se baseia na estrutura padr\u00e3o nativa da nuvem do Operator. Como um produto completo, todas as opera\u00e7\u00f5es s\u00e3o executadas pelo Couchbase Autonomous Operator, seja provisionamento de banco de dados, backup\/restaura\u00e7\u00e3o, alertas\/monitoramento ou integra\u00e7\u00f5es nativas com projetos de c\u00f3digo aberto, como Prometheus ou API OSB.<\/p>\n

O Couchbase Autonomous Operator fornece uma rede de seguran\u00e7a para os clientes que est\u00e3o implantando no Kubernetes e simplifica a implanta\u00e7\u00e3o do Couchbase com um controlador de admiss\u00e3o com controle de acesso baseado em fun\u00e7\u00e3o (RBAC)<\/a>.<\/p>\n

\"An<\/p>\n

Figura 3: Arquitetura do operador do MongoDB Enterprise Kubernetes. Fonte<\/a><\/em><\/p>\n

O MongoDB Enterprise Kubernetes Operator \u00e9 um inv\u00f3lucro em torno do MongoDB Ops Manager que em si<\/em> \u00e9 um inv\u00f3lucro em torno do banco de dados MongoDB. Por outro lado, o Couchbase Autonomous Operator n\u00e3o \u00e9 um inv\u00f3lucro, mas um produto utilit\u00e1rio completo que amplia os recursos de automa\u00e7\u00e3o do Couchbase no nuvem<\/a> para oferecer implementa\u00e7\u00f5es totalmente gerenciadas.<\/p>\n

A arquitetura do MongoDB Enterprise Kubernetes Operator n\u00e3o \u00e9 nativa da nuvem. Cada opera\u00e7\u00e3o Day-2 n\u00e3o \u00e9 realizada diretamente pelo MongoDB Kubernetes Operator, mas por meio do MongoDB Ops Manager, incluindo provisionamento, backup\/restaura\u00e7\u00e3o, alertas\/monitoramento etc. O MongoDB Enterprise Kubernetes Operator tamb\u00e9m n\u00e3o tem um controlador de admiss\u00e3o.<\/p>\n

N\u00edvel de maturidade do operador<\/h2>\n

H\u00e1 cinco n\u00edveis de maturidade de qualquer operador de Kubernetes:<\/p>\n