Perguntas frequentes
Nesta página
- O que é um operador?
- Por que executar o MongoDB Enterprise Advanced no Kubernetes?
- Quão escalável é o MongoDB no Kubernetes?
- Existe alguma desvantagem em executar o MongoDB no Kubernetes?
- Quais plataformas Kubernetes são suportadas para MongoDB Server?
- Quantas implementações o MongoDB Enterprise Kubernetes Operator pode suportar?
- Devo executar o MongoDB Server no Kubernetes no mesmo cluster que a aplicação que o utiliza?
- Posso distribuir o servidor MongoDB em vários clusters Kubernetes?
- Qual é a diferença entre usar o Kubernetes Operator para gerenciar sistemas do MongoDB de vários clusters Kubernetes e gerenciar um único cluster Kubernetes?
- O MongoDB suporta a execução de mais de uma instância do Kubernetes Operator?
O que é um operador?
Um operador é um mecanismo padrão que estende o plano de controle do Kubernetes para gerenciar recursos personalizados do Kubernetes. Como cada operador é criado para seus próprios Recursos Personalizados (CRs), ele pode conter lógica que aborda o tipo de serviço para o qual o operador foi criado. Para o Operador Kubernetes, o operador inclui a lógica para a implantação de instâncias do MongoDB Server e do Ops Manager.
Cada CR usado pelo Operador Kubernetes representa um elemento de um MongoDB Server no Kubernetes e tem opções para personalizar essa parte do servidor. Depois de configurar esses objetos no sistema Kubernetes, o operador cria objetos nativos do Kubernetes, como Stateful Sets, que são necessários para criar Pods de acordo com os requisitos especificados para MongoDB Server. O Kubernetes Operator também facilita a configuração dos recursos do MongoDB Server, como reconhecimento de data center backups, por meio da interação com o MongoDB Cloud Manager ou Ops Manager.
Por que executar o MongoDB Enterprise Advanced no Kubernetes?
A execução do MongoDB no Kubernetes simplifica a configuração e o gerenciamento do MongoDB.
O Kubernetes Operator trabalha com o MongoDB e o MongoDB Ops Manager para automatizar a configuração utilizando arquivos de recursos personalizados que você cria para definir sua configuração. Isso permite que você gerencie a configuração usando quaisquer ferramentas que você já tenha para gerenciar aplicativos no Kubernetes, incluindo ferramentas que permitem um fluxo de trabalho GitOps em que a configuração é gerenciada em um repositório Git. O alto nível de automação e abstração da complexidade tornam o Kubernetes e o Kubernetes Operator especialmente adequados para executar o MongoDB como um serviço, seja para usuários internos ou clientes externos.
O Kubernetes permite que o MongoDB aproveite a escalabilidade e a resiliência automatizada que o Kubernetes oferece, como a substituição automatizada de um Pod perdido compondo um conjunto de réplicas ou um cluster fragmentado. Isso permite que o MongoDB seja altamente escalável e resiliente ao ser executado no Kubernetes.
Quão escalável é o MongoDB no Kubernetes?
O MongoDB no Kubernetes é tão escalável quanto o MongoDB em null ou VMs. Para muitos clientes, a escalabilidade é mais fácil de obter no Kubernetes. O Kubernetes Operator e o Kubernetes trabalham perfeitamente juntos para permitir um fácil dimensionamento horizontal, incluindo a capacidade de abranger implantações do MongoDB em vários clusters do Kubernetes para obter resiliência de vários clusters e locais.
O dimensionamento vertical é tão fácil quanto alterar os recursos de uma implementação no recurso personalizado que a define.
Tudo isso permite que o MongoDB seja dimensionado para atender a qualquer demanda.
Existe alguma desvantagem em executar o MongoDB no Kubernetes?
Não há desvantagens do ponto de vista técnico. O MongoDB no Kubernetes é tão eficiente e escalável quanto o MongoDB em execução em qualquer hardware ou infraestrutura.
Mas, como em qualquer infraestrutura, há um requisito inerente de que os clientes tenham familiaridade e experiência com a tecnologia, neste caso o Kubernetes. Embora o Kubernetes Operator simplifique e automatize a configuração do MongoDB dentro do Kubernetes, ainda há uma dependência dos recursos e capacidades subjacentes que fazem parte do cluster do Kubernetes, coisas como armazenamento com estado, redes, segurança e computação. Isso significa que os clientes ainda precisam garantir que esses serviços e recursos estejam disponíveis e configurados corretamente para oferecer suporte ao MongoDB, do que isso seria necessário se estivesse em execução em máquinas vazias ou virtuais.
Quais plataformas Kubernetes são suportadas para MongoDB Server?
O MongoDB Server oferece suporte a qualquer plataforma que se baseie no Kubernetes nativo sem alterar a lógica ou o comportamento padrão. Na prática, isso significa que o MongoDB Server suporta qualquer plataforma Kubernetes certificada pela Cloud Native Computing Federation. Para saber mais, consulte Compatibilidade do operador MongoDB Kubernetes.
Quantas implementações o MongoDB Enterprise Kubernetes Operator pode suportar?
O Kubernetes Operator pode suportar centenas de implementações. Para facilitar as operações de reconciliação paralelas e evitar tempos de reconciliação prolongados, aumente a contagem de threads da instância do Kubernetes Operator.
Devo executar o MongoDB Server no Kubernetes no mesmo cluster que a aplicação que o utiliza?
Para ajudar a minimizar a latência, considere colocar seu reconhecimento de data center e aplicação no mesmo cluster do Kubernetes se sua arquitetura de sistema permitir isso.
Posso distribuir o servidor MongoDB em vários clusters Kubernetes?
Sim. Para saber mais, consulte Implantar recursos do MongoDB em vários clusters Kubernetes. Para obter ajuda, entre em contato com o Suporte do MongoDB.
Qual é a diferença entre usar o Kubernetes Operator para gerenciar sistemas do MongoDB de vários clusters Kubernetes e gerenciar um único cluster Kubernetes?
Para usar o Operador Kubernetes para gerenciar um sistema MongoDB de cluster multi-Kubernetes, você deve configurar um conjunto específico de Roles do Kubernetes, ClusterRoles, RoleBindings, ClusterRoleBindings, e ServiceAccounts.
O Operador Kubernetes usado para uma implantação do MongoDB em cluster multi-Kubernetes também pode reconciliar um único recurso de cluster Kubernetes. Para saber mais, consulte O MongoDB suporta a execução de mais de uma instância do Kubernetes Operator?.
O MongoDB suporta a execução de mais de uma instância do Kubernetes Operator?
Se possível, recomendamos que você configure uma única instância do Kubernetes Operator para monitorar um, muitos ou todos os namespaces dentro do seu cluster Kubernetes. Por padrão, o Operador Kubernetes observa todos os recursos personalizados tipos que você escolhe implementar e não precisa configurá-los para observar tipos de recursos específicos.
No entanto, quando atingir um limite de desempenho para o número de implantações que uma única instância do Kubernetes Operator pode suportar, você poderá configurar uma instância adicional do Kubernetes Operator. Neste ponto, considere como você deseja dividir o gerenciamento de recursos no cluster do Kubernetes. Use as seguintes recomendações listadas em ordem de prioridade:
Certifique-se de que cada instância do Kubernetes Operator esteja observando namespaces diferentes e não sobrepostos dentro do cluster do Kubernetes.
Como alternativa, configure diferentes instâncias do Kubernetes Operator para observar diferentes tipos de recursos, seja em namespaces diferentes ou namespaces sobrepostos.
Se você optar por usar namespace sobrepostos, certifique-se de que cada instância do Kubernetes Operator observe diferentes tipos de recursos para evitar conflitos que resultariam em duas instâncias do Kubernetes Operator tentando managed os mesmos recursos.
Observação
Antes de configurar outra instância do Kubernetes Operator, verifique se nenhum de seus namespaces está incluído no subconjunto de namespaces para a instância existente do Kubernetes Operator.