O processo mongot armazena os índices de pesquisa do MongoDB Search e da pesquisa vetorial em um Persistent Volume dedicado. O Kubernetes operador não expande esse armazenamento automaticamente. No Kubernetes operador 1.9 ou posterior, você pode expandir os mongot Persistent Volume Claims e, em seguida, atualizar o recurso MongoDBSearch para refletir o tamanho do volume expandido. Para aumentar o armazenamento de outros recursos, consulte Aumentar o armazenamento para volumes persistentes.
Pré-requisitos
mongotDeclarações de volume persistente provisionadas usando um driver de interface de armazenamento de contêiner (CSI) que oferece suporte à expansão de volume enquanto o volume permanece conectado e uma StorageClass que representa esse driver e defineallowVolumeExpansioncomotrue. Confirme que o sistema de arquivos suporta expansão. Este procedimento não abrange os backends de armazenamento que exigem a desanexação do volume antes que o controlador possa expandi-lo.Um banco de dados de origem saudável e uma implantação do MongoDB Search e pesquisa vetorial, além de um plano de backup ou recuperação. Para configurar backups para o banco de dados de origem, consulte Configurar backups de banco de dados do MongoDB. Para aprender o que fazer backup para o Search, consulte Perguntas frequentes sobre a implantação do
mongot.Um período de manutenção sem dimensionamento simultâneo ou atualizações do Kubernetes operador ou do recurso MongoDBSearch. Pause a automação que pode restaurar réplicas do Kubernetes operador ou reverter a configuração de armazenamento do Search, por exemplo, uma sincronização do GitOps. Se você gerenciar o recurso MongoDBSearch no Git, confirme o novo tamanho antes de retomar a sincronização. Se você parar um operador, ele pausará a reconciliação de todos os recursos que ele gerencia.
Permissão para aplicar patch em Persistent Volume Claims, editar recursos do MongoDBSearch, dimensionar implantações do operador Kubernetes e excluir statefulSets e Pods.
Sistemas de vários clusters
Durante este procedimento, você executa comandos no recurso MongoDBSearch, nos mongot statefulSets e seus Persistent Volume Claims, e na implantação do operador Kubernetes. Em uma implantação de vários clusters, esses destinos podem residir em clusters diferentes. Use a tabela a seguir para determinar o contexto de cada comando e o operador a ser interrompido e retomado:
Implantação | contexto do recurso MongoDBSearch | contexto de StatefulSet e Persistent Volume Claim | Operador para parar e retomar |
|---|---|---|---|
Cluster único | Cluster de carga de trabalho | O mesmo cluster | Operador local |
Operador Kubernetes multi-cluster central | Cluster central | Cada cluster de nós afetado | Operador central |
Kubernetes operador por cluster de nó | Recurso de pesquisa local de cada cluster de nós | Mesmo cluster de nós | Operador de pesquisa de cada nó afetado |
Expandir armazenamento
O procedimento a seguir expande o armazenamento do Search do conjunto de réplicas de 1Gi para 2Gi. Corresponda cada StatefulSet ao name e index explícito da entrada do cluster, não à posição da entrada no array clusters.
Uma configuração shardOverrides[].persistence correspondente substitui a configuração persistence do cluster. Se você defini-lo, altere o tamanho lá. Se você substituir volumeClaimTemplates em spec.clusters[].statefulSet, altere o tamanho lá. Essa substituição tem precedência sobre persistence.
Aviso
Aumente apenas o armazenamento, mantendo o recurso MongoDBSearch existente e suas Persistent Volume Claims, e não dimensione mongot. Exclua apenas as definições de StatefulSet e certifique-se de usar a opção --cascade=orphan para que os Pods mongot e suas reivindicações permaneçam intactos enquanto o Kubernetes operador estiver parado.
Identifique os mongot StatefulSets e as declarações de dados.
Liste os mongot statefulSets para o recurso MongoDBSearch:
kubectl --context <member-context> -n <namespace> \ get sts -l mongodb.com/search-name=<search-name>
Com o modelo de declaração data padrão, cada réplica usa uma declaração chamada data-<statefulset-name>-<ordinal>. Para uma origem de cluster, cada cluster tem um StatefulSet para cada shard. Se você personalizou os modelos de declaração ou montagens de volume, verifique a declaração que cada Pod monta.
Expanda cada reivindicação de dados.
Execute o seguinte comando para cada reivindicação que você identificou na etapa anterior:
kubectl --context <member-context> -n <namespace> \ patch pvc <pvc-name> --type=merge \ -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'
Aguarde até que cada declaração relate pelo menos o tamanho solicitado (neste exemplo, 2Gi) em status.capacity.storage ou na condição FileSystemResizePending:
kubectl --context <member-context> -n <namespace> \ get pvc <pvc-name> -o yaml
Se a expansão demorar mais do que o tempo limite documentado do seu backend de armazenamento, investigue os eventos CSI antes de continuar:
kubectl --context <member-context> -n <namespace> \ describe pvc <pvc-name>
Interrompa as implantações do operador do Kubernetes responsáveis.
Registre a contagem original de réplicas de cada operador:
kubectl --context <operator-context> -n <operator-namespace> \ get deployment <operator-name> \ -o jsonpath='{.spec.replicas}{"\n"}'
Dimensione o operador para zero e aguarde que seus Pods sejam excluídos:
kubectl --context <operator-context> -n <operator-namespace> \ scale deployment <operator-name> --replicas=0 kubectl --context <operator-context> -n <operator-namespace> \ wait --for=delete pod --timeout=300s \ -l app.kubernetes.io/name=<operator-name>
Dimensione o operador, não mongot. O Helm gráfico nomeia a Implantação do operador mongodb-kubernetes-operator e define app.kubernetes.io/name: mongodb-kubernetes-operator em seus Pods. Se sua instalação for personalizada, use o seletor de pod real da Implantação em vez do rótulo do gráfico mostrado neste exemplo. Pare todos os Pods do operador responsável, incluindo Pods em terminação, antes de continuar. Parar um operador de banco de dados de origem separado não pausa os operadores de pesquisa de membros.
Remova apenas as definições do StatefulSet.
Execute o seguinte comando para cada StatefulSet que você identificou na etapa 1:
kubectl --context <member-context> -n <namespace> \ delete sts <statefulset-name> --cascade=orphan \ --timeout=300s
Confirme se cada StatefulSet está ausente enquanto seus mongot Pods e Persistent Volume Claims existentes permanecem intactos e sem carimbos de data/hora de exclusão. Não exclua o recurso MongoDBSearch nem dimensione mongot.
Atualize os recursos de pesquisa existentes.
kubectl --context <search-resource-context> -n <namespace> \ edit mongodbsearch <search-name>
Altere o valor persistence.single.storage da entrada do cluster afetado:
persistence: single: storage: 2Gi
Em uma implantação de cluster de nós pelo operador Kubernetes, atualize a configuração correspondente em cada recurso de pesquisa local.
Mantenha a classe de armazenamento, as entradas de cluster, os índices, as réplicas e outras configurações existentes. Remover uma entrada de cluster pode excluir os recursos e as reivindicações de Search desse cluster.
Leia os recurso de Search novamente para confirmar que os novos tamanhos efetivos persistiram. Os statefulSets direcionados devem permanecer ausentes até que você retome os operador.
Retome os operadores.
Restaure a contagem de réplicas registrada de cada operador:
kubectl --context <operator-context> -n <operator-namespace> \ scale deployment <operator-name> \ --replicas=<original-replicas> kubectl --context <operator-context> -n <operator-namespace> \ rollout status deployment/<operator-name> --timeout=600s
Aguarde até que cada StatefulSet reapareça com o modelo de reivindicação data expandido. O novo StatefulSet adota os Pods e reivindicações existentes.
Reinicie os pods mongot se o sistema de arquivos exigir.
Se a condição FileSystemResizePending persistir, exclua os mongot Pods afetados um de cada vez:
kubectl --context <member-context> -n <namespace> \ delete pod <mongot-pod-name> --timeout=300s kubectl --context <member-context> -n <namespace> \ wait --for=condition=Ready pod/<mongot-pod-name> \ --timeout=600s
Aguarde até que o Pod de substituição exista antes de executar o comando de prontidão. Reinicie o próximo Pod somente após a substituição estar pronta e a condição ser limpa. Ignore esta etapa se a expansão for concluída online.
Observação
Excluir um Pod ignora diretamente os PodDisruptionBudgets. Uma única réplica mongot não pode servir a solicitações enquanto é reiniciada. Este procedimento não oferece garantias de tempo de inatividade zero.
Verifique a prontidão do armazenamento e da Search.
Confirme se cada Persistent Volume Claim relata pelo menos a capacidade solicitada, que todos os mongot Pods esperados estão prontos e que cada recurso Search atinja a fase Running após a reconciliação.
Solucionar problemas de expansão
Se uma etapa falhar enquanto os operadores estiverem parados, mantenha os recursos do Search, seus Pods e declarações intactos. Corrija as configurações de armazenamento efetivas e, em seguida, restaure cada operador pausado para sua contagem de réplicas original. Se você retomar antes de corrigir a configuração, conclua o procedimento mais tarde, em vez de reduzir ou excluir uma declaração.
Se um Pod ou uma reivindicação começar a excluir, interrompa outras exclusões e entre em contato com seu administrador de Kubernetes ou de armazenamento. Não remova finalizadores nem edite PV.spec.capacity como uma solução alternativa.
Saiba mais
Para aumentar o armazenamento de outros recursos do Kubernetes operador, consulte Aumentar o armazenamento para volumes persistentes.
Para revisar as configurações de armazenamento do
mongot, consulte a spec.clusters[].persistence configuração.Para saber mais sobre as configurações de recurso do MongoDBSearch, consulte Configurações do MongoDB Search e pesquisa vetorial.