Kubernetes Operator v1.3.0
Lançado em 04 de setembro 2025
Novas funcionalidades
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.
Correções de Bugs
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êinermongodb-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
eClusterRoleBinding
para incluir o namespace para que as instalações de vários operadores em namespaces diferentes não entrem em conflito entre si.
Outras alterações
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 ooperator.enablePVCResize
valorfalse
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 especificandofalse
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.
Kubernetes Operator v1.2.0
Lançado em 10 de julho 2025
Novas funcionalidades
- Autenticação de usuário do OpenID Connect (OIDC)
Adiciona suporte para autenticação de usuário OpenID Connect (OIDC).
Você pode configurar a autenticação OIDC com as configurações
spec.security.authentication.modes
espec.security.authentication.oidcProviderConfigs
.Exige MongoDB Enterprise Edition 7.0.11+ ou 8.0.0+.
- Para mais informações, veja:
- 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 despec.security.roles
espec.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
parafalse
. 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
comofalse
.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.
Correções de Bugs
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.
Kubernetes Operator v1.1.0
Lançado em 23 de maio 2025
Novas funcionalidades
- 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
emongod
está em texto simples por enquanto).
Kubernetes Operator v1.0.1
Lançado em 13 de maio 2025
Correções de Bugs
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.
Kubernetes Operator v1.0.0
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.
Licença
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 .
Migração
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.
Descontinuação do operador legado e EOL
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.
Notas de versão mais antigas
Para visualizar notas de versão antigas do Operador Kubernetes, consulte a Documentação legada.