Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Menu Docs
Página inicial do Docs
/
Controladores MongoDB para operador Kubernetes

Notas de versão para Controladores MongoDB para Operador Kubernetes

Lançado em 04 de setembro 2025

  • Suporte para várias arquiteturas

    • Adiciona suporte abrangente de várias arquiteturas para o Kubernetes Operator.

    • Suporta a implantação em arquiteturas IBM Power (ppc64le) e IBM Z (s390x) juntamente com o suporte x86_64 existente.

    • Imagens principais (operador, agente, contêineres de inicialização, banco de dados, teste de preparação) agora suportam múltiplas arquiteturas. Mas esta versão não adiciona suporte IBM e ARM para o Ops Manager e as imagens mongodb-kubernetes-init-ops-manager.

      Observação

      Esta versão migra as imagens do MongoDB Agent para um novo repositório de containers, quay.io/mongodb/mongodb-agent.

      • Os agentes no novo repositório suportam as arquiteturas x86-,64 ARM,64 s390x e ppc64le. Para saber mais, consulte Imagens de container.

      • O operador Kubernetes executando a versão maior ou igual a 1.3.0 e estático não pode usar as imagens do agente do repositório de contêiner antigo, quay.io/mongodb/mongodb-agent-ubi.

      Não use quay.io/mongodb/mongodb-agent-ubi, pois ele foi disponibilizado somente para compatibilidade com versões anteriores.

  • Corrige a arquitetura atual dos contêineres do conjunto com estado, que depende de uma "matriz de agente " para mapear as versões do operador e do agente . O novo design elimina a array operator-version/agent-version, mas adiciona um container adicional contendo todos os binários necessários. Esta arquitetura mapeia para o contêiner mongodb-database.

  • Corrige um problema em que a sonda de prontidão relatava o nó como pronto mesmo quando seu mecanismo de autenticação não estava sincronizado com os outros nós, às vezes resultando em reinicializações prematuras.

  • Corrige um problema onde os MongoDB Agents não aderiram à variável de ambiente do NO_PROXY configurada no operador.

  • Altera os nomes padrão do webhook ClusterRole e ClusterRoleBinding para incluir o namespace para que as instalações de vários operadores em namespaces diferentes não entrem em conflito entre si.

  • Move permissões opcionais de PersistentVolumeClaim para uma função separada.

    Ao gerenciar o operador com Helm, você pode desativar permissões para PersistentVolumeClaim recursos definindo o operator.enablePVCResize valor false como, que é true por padrão. Se habilitadas, essas permissões fazem parte da role de operador primary. Com essa alteração, as permissões têm um papel separado.

  • Remove do subresourceEnabled valor de Helm.

    Esta configuração era true por padrão. Você pode excluir permissões de subrecurso da função de operador especificando false como o valor. Essa configuração foi introduzida como uma solução temporária para o problema do OpenShift (Bug 1803171). O problema foi resolvido e a configuração não é mais necessária. Portanto, essa alteração remove essa opção de configuração, fazendo com que as funções de operador sempre tenham permissões de subrecurso.

  • Não inclui imagens de contêiner para as versões 7.0.16, 8.0.8, 8.0.9 e 8 do Ops Manager.0.10 devido a um bug no Ops Manager que impede que os usuários do Kubernetes Operator atualizem seu Ops Manager sistemas destas versões.

Lançado em 10 de julho 2025

  • Autenticação de usuário do OpenID Connect (OIDC)
  • Novo CRD do ClusterMongoDBRole
    • Adiciona o novo ClusterMongoDBRole CRD para dar suporte a roles reutilizáveis em vários clusters MongoDB. Isso permite que os usuários definam funções uma vez e as reutilizem em vários recursos do MongoDB ou MongoDBMultiCluster.

    • Você pode fazer referência a esta role usando o campo spec.security.roleRefs. Observe que somente um de spec.security.roles e spec.security.roleRefs pode ser usado de cada vez.

    • O operador trata os recursos ClusterMongoDBRole como modelos de função personalizada que são usados somente quando referenciados pelos recursos do banco de dados .

    • O operador observa o novo recurso por padrão. Isso significa que o operador exige que você crie um novo ClusterRole e ClusterRoleBinding. O gráfico Helm ou o plugin-in kubectl mongodb criam esses ClusterRole e ClusterRoleBinding por padrão. Você deve criá-los manualmente se usar um método de instalação diferente.

    • Para desabilitar este comportamento no gráfico do capacete, defina o valor operator.enableClusterMongoDBRoles para false. Isso desabilita a criação dos recursos RBAC necessários para o recurso ClusterMongoDBRole, bem como desabilita a observação desse recurso.

    • Para ignorar a instalação do ClusterRole e ClusterRoleBinding necessários com o plugin-in kubectl mongodb, defina --create-mongodb-roles-cluster-role como false.

    • O novo recurso ClusterMongoDBRole foi projetado para ser somente leitura, o que significa que pode ser usado por sistemas do MongoDB gerenciadas por diferentes operadoras.

    • Você pode excluir o recurso ClusterMongoDBRole a qualquer momento, mas o operador não exclui nenhuma função que foi criada usando esse recurso. Para remover adequadamente o acesso, você deve remover manualmente a referência ao ClusterMongoDBRole nos recursos MongoDB ou MongoDBMultiCluster.

    • A documentação de referência desse recurso pode ser encontrada na Especificação de recursos do ClusterMongoDBRole.

  • Corrige um problema em que mover um recurso MongoDBMultiCluster para um novo projeto (ou uma nova instância do Ops Manager) deixaria a implantação em um estado de falha.

Lançado em 23 de maio 2025

  • MongoDBSearch (visualização privada da comunidade)
    • Adiciona suporte para a implementação do MongoDB Search (Community Private Preview Edition).

    • Habilita recursos de pesquisa vetorial e de texto completo para sistemas do MongoDBCommunity.

    • Adiciona novo CRD MongoDB que é assistido por padrão pelo Operador Kubernetes. Para mais informações, consulte o Início Rápido.

    • A fase de visualização privada do MongoDBSearch vem com as seguintes limitações
      • Versão mínima do MongoDB Community : 8.0.

      • O TLS deve ser desabilitado no MongoDB (a comunicação entre mongot e mongod está em texto simples por enquanto).

Lançado em 13 de maio 2025

  • Adiciona imagens ausentes do MongoDB Agent no pacote Kubernetes Operator no catálogo OpenShift e no catálogo operatorhub.io.

  • Adiciona o mongodbcommunity CRD ausente da lista assistida no gráfico Helm.

Lançado em 9 de maio 2025

O MongoDB está unificando suas ofertas de Kubernetes com a introdução do Kubernetes Operator. Esse novo operador é um projeto de código aberto e representa uma fusão do MongoDB Community Operator anterior e do MongoDB Enterprise Kubernetes Operator. Isso torna mais fácil gerenciar, dimensionar e atualizar seus sistemas. Mudanças futuras se basearão nisso para alinhar mais de perto a forma como a Community e o Enterprise são gerenciados no Kubernetes, a fim de oferecer uma experiência ainda mais integrada e simplificada.

Como um projeto de código aberto , ele agora permite contribuições da comunidade, o que ajuda a gerar correções de bugs mais rápidas e a otimização contínua.

Os usuários com contratos que permitiram o uso do Enterprise Operator ainda podem aproveitar a nova substituição, permitindo que os clientes a adotem sem alterações no contrato. O próprio Kubernetes Operator é licenciada sob a 2.0 licença Apache, e um arquivo de licença incluído no repositório fornece mais detalhes.

Os direitos de licença para todos os outros produtos MongoDB e FERRAMENTAS, como MongoDB Enterprise Edition e Ops Manager, permanecem inalterados. Se você tiver dúvidas de licenciamento em relação a esses produtos ou à FERRAMENTAS, entre em contato com a equipe de contas do MongoDB .

A migração do Community Kubernetes Operator e do Enterprise Kubernetes Operator para o Kubernetes Operator é perfeita: suas implementações do MongoDB não são afetadas pela atualização e não exigem alterações. Basta seguir as instruções no guia de migração.

Continuaremos com o suporte da melhor maneira possível do Community Kubernetes Operator por 6 meses, até 2025 de novembro de . Cada versão do Enterprise Kubernetes Operator permanecerá suportada de acordo com a orientaçãoatual.

Todas as futuras correções de bugs e melhorias serão lançadas em novas versões do Kubernetes Operator. Recomendamos todos os usuários a planejar sua migração para o Kubernetes Operator dentro desses cronogramas.

Para visualizar notas de versão antigas do Operador Kubernetes, consulte a Documentação legada.

Nesta página