Solucionar problemas do Kubernetes Operator
Nesta página
- Obter o status de um recurso distribuído
- Revisar os registros
- Verifique as mensagens do webhook de validação
- Ver todas as especificações do recurso
MongoDB
- Restaurar StatefulSet que não foi distribuído
- Substituir um ConfigMap para refletir as alterações
- Remover componentes do Kubernetes
- Criar uma nova declaração de volume persistente depois de excluir um Pod
- Desativar controles de recursos do Ops Manager
- Remover recursos quando o operador Kubernetes falhar
- Depurar um container com falha
- Verificar se os nomes dos domínios em certificados TLS estão corretos
- Verificar a versão do MongoDB ao executar no modo local
- Falha na atualização ao usar
kubectl
ouoc
- Falha na atualização ao usar gráficos Helm
- Duas instâncias de operador após uma atualização
- Recuperar recurso devido a configuração de automação quebrada
Importante
Esta seção é somente para sistemas de cluster Kubernetes únicos. Para sistemas do MongoDB de vários clusters Kubernetes, consulte Solucionar problemas de sistemas de vários clusters Kubernetes.
Obter o status de um recurso distribuído
Para localizar o status de um recurso distribuído com o Kubernetes Operator, invoque um dos seguintes comandos:
Para sistemas de recursos do Ops Manager:
kubectl get <resource-name> -n <metadata.namespace> -o yaml O campo
status.applicationDatabase.phase
exibe o status do sistema do recurso do aplicativo de banco de dados.O
status.backup.phase
exibe o status da implantação de recurso do daemon da cópia de segurança.O campo
status.opsManager.phase
exibe o status do sistema do recurso do Ops Manager.
Observação
O controlador do Cloud Manager ou do Ops Manager observa os recursos do banco de dados definidos nas seguintes configurações:
spec.backup.s3Stores
Para implantações de recursos do MongoDB:
kubectl get mdb <resource-name> -n <metadata.namespace> -o yaml O campo
status.phase
exibe o status do sistema do recurso do MongoDB.
Os seguintes pares de valores-chave descrevem os status de implantação de recursos:
Chave | Valor | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
message | Mensagem explicando por que o recurso está em um estado Pending ou Failed . | ||||||||||
phase |
| ||||||||||
lastTransition | Carimbo 8601 de data/hora na ISO formato de data e hora em UTC quando a última reconciliação aconteceu. | ||||||||||
link | URL de implantação no Ops Manager. | ||||||||||
backup.statusName | Se você habilitou backups contínuos com spec.backup.mode no Kubernetes para seu recurso MongoDB, este campo indicará o status do backup, como backup.statusName:"STARTED" . Os valores possíveis são STARTED , STOPPED e TERMINATED . | ||||||||||
Campos específicos de recursos | Para obter descrições desses campos, consulte Especificação do recurso do banco de dados MongoDB. |
Exemplo
Para visualizar o status de um conjunto de réplicas denominado my-replica-set
no namespace developer
, execute:
kubectl get mdb my-replica-set -n developer -o yaml
Se o my-replica-set
estiver em execução, você verá:
status: lastTransition: "2019-01-30T10:51:40Z" link: http://ec2-3-84-128-187.compute-1.amazonaws.com:9080/v2/5c503a8a1b90141cbdc60a77 members: 1 phase: Running version: 4.2.2-ent
Se o my-replica-set
não estiver em execução, você deverá visualizar:
status: lastTransition: 2019-02-01T13:00:24Z link: http://ec2-34-204-36-217.compute-1.amazonaws.com:9080/v2/5c51c040d6853d1f50a51678 members: 1 message: 'Failed to create/update replica set in Ops Manager: Status: 400 (Bad Request), Detail: Something went wrong validating your Automation Config. Sorry!' phase: Failed version: 4.2.2-ent
Revisar os registros
Mantenha e faça a revisão de registros para depurar problemas e monitorar a atividade de clusters. Use a arquitetura de registro recomendada para reter Pod registros mesmo após a exclusão de um Pod.
Processo de registro
O Kubernetes Operator grava nos registros do Pod usando um encapsulador que converte os registros do MongoDB Agent e os componentes do mongod
no Pod do sistema de banco de dados em uma entrada de registro estruturada no seguinte formato JSON :
{ "logType": "<log-type>", "contents": "<log line from a log file>" }
O Kubernetes Operator é compatível com os seguintes tipos de registro:
automation-agent-verbose
automation-agent-stderr
mongodb
mongodb-audit
agent-launcher-script
automation-agent
monitoring-agent
backup-agent
Ao ler os logs de um container de banco de dados, o Kubernetes Operator gera a entrada JSON estruturada que contém registros de diferentes fontes.
Revisar os registros do Kubernetes Operator
Para analisar os registros do Kubernetes Operator, invoque este comando:
kubectl logs -f deployment/mongodb-enterprise-operator -n <metadata.namespace>
Você também pode verificar os logs do Ops Manager para ver se algum problema foi relatado ao Ops Manager.
Encontre um pod específico
Para ver quais pods estão disponíveis, primeiro invoque este comando:
kubectl get pods -n <metadata.namespace>
Revise os registros de um pod específico
Se você deseja restringir sua revisão a um Pod específico , você pode invocar este comando:
kubectl logs <podName> -n <metadata.namespace>
Exemplo
Se o seu conjunto de réplicas estiver rotulado como myrs
, execute:
kubectl logs myrs-0 -n <metadata.namespace>
Isso retorna o log do agente de automação para esse conjunto de réplicas.
Revisar um registro específico
Você pode restringir sua revisão a um tipo de registro específico. Por exemplo, o comando a seguir retorna os registros de auditoria dos registros do Kubernetes do Pod especificado, especificando o tipo de registro mongodb-audit
:
kubectl logs -c mongodb-enterprise-database replica-set-0 | jq -r 'select(.logType == "mongodb-audit") | .contents'
O comando gera uma entrada semelhante à seguinte saída:
{{{ "atype":"startup","ts":{"$date":"2023-08-30T20:43:54.649+00:00"},"uuid":{"$binary":"oDcPEY69R1yiUtpMupaXOQ==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0} {"atype":"startup","ts":{"$date":"2023-08-30T20:44:05.466+00:00"},"uuid":{"$binary":"OUbUWC1DQM6k/Ih4hKZq4g==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}}}
Registros de auditoria
Para incluir registros de auditoria nos registros do Pod do Kubernetes, adicione a seguinte configuração do additionalMongodConfig.auditLog
à sua definição de recurso. Você pode atualizar o nome do arquivo fornecido conforme necessário.
spec: additionalMongodConfig: auditLog: destination: file format: JSON path: /var/log/mongodb-mms-automation/mongodb-audit.log
Verifique as mensagens do webhook de validação
O operador Kubernetes usa um webhook de validação para evitar que os usuários apliquem definições de recursos inválidas. O webhook rejeita solicitações inválidas.
O ClusterRole e ClusterRoleBinding para o webhook estão incluídos nos arquivos de configuração padrão que você aplica durante a instalação. Para criar a função e a associação, é necessário ter privilégios de administrador do cluster.
Se você criar uma definição de recurso inválida, o webhook gera uma mensagem semelhante à seguinte que descreve o erro para a shell:
error when creating "my-ops-manager.yaml": admission webhook "ompolicy.mongodb.com" denied the request: shardPodSpec field is not configurable for application databases as it is for sharded clusters and appdb replica sets
Quando o Kubernetes Operator concilia cada recurso, ele também o valida. Ele não exige o webhook de validação para criar nem atualizar recursos.
Se você omitir o webhook de validação, ou se remover a função e a vinculação do webhook da configuração padrão, ou tiver privilégios insuficientes para executar a configuração, o Kubernetes Operator emitirá avisos, pois esses não são erros críticos. Se o Kubernetes Operator encontrar um erro crítico, ele marcará o recurso como Failed
.
Observação
Implementações do GKE (Google Kubernetes Engine)
GKE (Google Kubernetes Engine) tem um problema conhecido com o webhook ao distribuir em clusters privados. Para saber mais, veja Como atualizar regras de firewall do Google para corrigir problemas de webhook.
Ver todas MongoDB
as especificações do recurso
Para ver todas as especificações do recurso MongoDB
no namespace fornecido:
kubectl get mdb -n <metadata.namespace>
Exemplo
Para ler detalhes sobre o recurso standalone do dublin
, execute este comando:
kubectl get mdb dublin -n <metadata.namespace> -o yaml
Isso retorna a seguinte resposta:
apiVersion: mongodb.com/v1 kind: MongoDB metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"mongodb.com/v1","kind":"MongoDB","metadata":{"annotations":{},"name":"dublin","namespace":"mongodb"},"spec":{"credentials":"credentials","persistent":false,"podSpec":{"memory":"1Gi"},"project":"my-om-config","type":"Standalone","version":"4.0.0-ent"}} clusterDomain: "" creationTimestamp: 2018-09-12T17:15:32Z generation: 1 name: dublin namespace: mongodb resourceVersion: "337269" selfLink: /apis/mongodb.com/v1/namespaces/mongodb/mongodbstandalones/dublin uid: 7442095b-b6af-11e8-87df-0800271b001d spec: credentials: my-credentials type: Standalone persistent: false project: my-om-config version: 4.2.2-ent
Restaurar StatefulSet que não foi distribuído
Um pod StatefulSet pode travar com um status de se Pending
encontrar um erro durante o sistema.
Pending
Pods não encerram automaticamente, mesmo que você faça e aplique alterações de configuração para resolver o erro.
Para retornar o StatefulSet a um estado saudável, aplique as alterações de configuração ao recurso MongoDB no estado Pending
e, em seguida, exclua esses Pods.
Exemplo
Um sistema host tem diversos Pods em execução:
kubectl get pods my-replica-set-0 1/1 Running 2 2h my-replica-set-1 1/1 Running 2 2h my-replica-set-2 0/1 Pending 0 2h
my-replica-set-2
está preso no estágio Pending
. Para obter mais informações sobre o erro, execute:
kubectl describe pod my-replica-set-2 <describe output omitted> Warning FailedScheduling 15s (x3691 over 3h) default-scheduler 0/3 nodes are available: 1 node(s) had taints that the pod didn't tolerate, 2 Insufficient memory.
A saída indica um erro na alocação de memória.
Atualizar as alocações de memória no recurso do MongoDB é insuficiente, pois o pod não termina automaticamente depois de aplicar atualizações de configurações.
Para corrigir esse problema, atualize e aplique a configuração e, em seguida, exclua o pod suspenso:
vi <my-replica-set>.yaml kubectl apply -f <my-replica-set>.yaml kubectl delete pod my-replica-set-2
Depois que esse Pod suspenso for excluído, os outros Pods serão reiniciados com sua nova configuração como parte da atualização contínua do Statefulset.
Observação
Para saber mais sobre este problema, consulte Problema do Kubernetes 67250.
Substituir um ConfigMap para refletir as alterações
Se você não puder modificar nem reimplantar um arquivo de recurso ConfigMap
já implantado usando o comando kubectl apply, execute:
kubectl replace -f <my-config-map>.yaml
Isso exclui e recria o arquivo de recurso ConfigMap
.
Este comando é útil se você deseja fazer uma alteração recursiva e imediata, ou se precisa atualizar arquivos de recursos que não podem ser atualizados depois de inicializados.
Remover componentes do Kubernetes
Importante
Para remover qualquer componente, você precisa das seguintes permissões:
| |
|
Remover um MongoDB
recurso
Para remover quaisquer instâncias que o Kubernetes distribuiu, é necessário usar o Kubernetes.
Importante
Você pode usar somente o Kubernetes Operator para remover instâncias distribuídas do Kubernetes. Se você usar o MongoDB Ops Manager para remover a instância, o MongoDB Ops Manager lançará um erro.
Excluir um recurso do MongoDB não o remove da UI do MongoDB Ops Manager . É necessário remover o recurso do MongoDB Ops Manager manualmente. Para saber mais, veja Como remover um processo do monitoramento.
Excluir um recurso MongoDB para o qual você habilitou o backup não exclui os snapshots do recurso. É necessário excluir snapshots no MongoDB Ops Manager.
Exemplo
Para remover uma única instância do MongoDB que você criou usando o Kubernetes:
kubectl delete mdb <name> -n <metadata.namespace>
Para remover todas as instâncias do MongoDB que você criou usando o Kubernetes:
kubectl delete mdb --all -n <metadata.namespace>
Remover o Kubernetes Operator
Para remover o operador Kubernetes:
Remover todos os recursos do Kubernetes:
kubectl delete mdb --all -n <metadata.namespace> Remover o Kubernetes Operator:
kubectl delete deployment mongodb-enterprise-operator -n <metadata.namespace>
Remover o CustomResourceDefinitions
Para remover o CustomResourceDefinitions:
Remover todos os recursos do Kubernetes:
kubectl delete mdb --all -n <metadata.namespace> Remova CustomResourceDefinitions:
kubectl delete crd mongodb.mongodb.com kubectl delete crd mongodbusers.mongodb.com kubectl delete crd opsmanagers.mongodb.com
Remova o namespace
Para remover o namespace:
Remover todos os recursos do Kubernetes:
kubectl delete mdb --all -n <metadata.namespace> Remova namespace:
kubectl delete namespace <metadata.namespace>
Criar uma nova reivindicação de volume persistente depois de excluir um Pod
Se você excluir acidentalmente o Pod do conjunto de réplicas do MongoDB e sua Declaração de volume persistente, o operador Kubernetes não conseguirá reprogramar o Pod do MongoDB e emitirá a seguinte mensagem de erro:
scheduler error: pvc not found to schedule the pod
Para recuperar deste erro, você deve criar manualmente um novo PVC com o nome do objeto PVC que corresponde a esse Pod do conjunto de réplicas, como data-<replicaset-pod-name>
.
Desativar controles de recursos do Ops Manager
Quando você gerencia um projeto do MongoDB Ops Manager por meio do Kubernetes Operator, o Kubernetes Operator coloca a política de controle de recursos EXTERNALLY_MANAGED_LOCK
no projeto. Essa política desabilita determinados recursos no aplicativo MongoDB Ops Manager que podem comprometer a configuração do seu Kubernetes Operator. Se você precisar usar esses recursos bloqueados, poderá remover a política por meio da APIde controles de recursos, fazer alterações no aplicativo MongoDB Ops Manager e, em seguida, restaurar a política original por meio da API.
Aviso
O procedimento a seguir permite que você use recursos no aplicativo Ops Manager que, de outra forma, seriam bloqueados pelo Kubernetes Operator.
Recupere as políticas de controle de funcionalidades do seu projeto do Ops Manager.
curl --user "{USERNAME}:{APIKEY}" --digest \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --include \ --request GET "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" Salve a resposta que a API gera. Depois de fazer alterações no aplicativo de Ops Manager, adicione as políticas de volta ao projeto.
Importante
Observe os campos e valores destacados na seguinte resposta de amostra. Você deve enviar estes mesmos campos e valores em etapas posteriores ao remover e adicionar políticas de controle da funcionalidades.
O campo
externalManagementSystem.version
corresponde à versão do Kubernetes Operator. Você deve enviar o mesmo valor de campo exato em suas solicitações mais tarde nesta tarefa.Sua resposta deve ser semelhante a:
{ "created": "2020-02-25T04:09:42Z", "externalManagementSystem": { "name": "mongodb-enterprise-operator", "systemId": null, "version": "1.4.2" }, "policies": [ { "disabledParams": [], "policy": "EXTERNALLY_MANAGED_LOCK" }, { "disabledParams": [], "policy": "DISABLE_AUTHENTICATION_MECHANISMS" } ], "updated": "2020-02-25T04:10:12Z" } Atualize a array
policies
com uma lista vazia:Observação
Os valores fornecidos para o objeto
externalManagementSystem
, como o campoexternalManagementSystem.version
, devem corresponder aos valores recebidos na resposta na etapa 1.curl --user "{USERNAME}:{APIKEY}" --digest \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --include \ --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \ --data '{ "externalManagementSystem": { "name": "mongodb-enterprise-operator", "systemId": null, "version": "1.4.2" }, "policies": [] }' As funcionalidades anteriormente bloqueadas agora estão disponíveis no aplicativo de Ops Manager.
Faça suas alterações no aplicativo Ops Manager.
Atualize a array
policies
com as políticas de controle de funcionalidades originais:Observação
Os valores fornecidos para o objeto
externalManagementSystem
, como o campoexternalManagementSystem.version
, devem corresponder aos valores recebidos na resposta na etapa 1.curl --user "{USERNAME}:{APIKEY}" --digest \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --include \ --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \ --data '{ "externalManagementSystem": { "name": "mongodb-enterprise-operator", "systemId": null, "version": "1.4.2" }, "policies": [ { "disabledParams": [], "policy": "EXTERNALLY_MANAGED_LOCK" }, { "disabledParams": [], "policy": "DISABLE_AUTHENTICATION_MECHANISMS" } ] }' Os recursos agora estão bloqueados novamente, impedindo que você faça mais alterações por meio do aplicativo Ops Manager. No entanto, o operador Kubernetes retém todas as alterações feitas no aplicativo Ops Manager enquanto os recursos estavam disponíveis.
Remover recursos quando o operador Kubernetes falhar
Quando você exclui um recurso personalizado do MongoDB por meio do Kubernetes Operator, o Kubernetes Operator lida com a remoção da implantação no Cloud Manager ou no MongoDB Ops Manager. Para saber mais, consulte Remover um recurso MongoDB
.
No entanto, a remoção de recursos pode falhar no Kubernetes. Por exemplo, se o Kubernetes Operator falhar antes de excluir o recurso MongoDB , você deverá remover manualmente as implantações e excluir seus projetos no Cloud Manager ou MongoDB Ops Manager.
Para remover recursos do MongoDB Ops Manager ou Cloud Manager manualmente:
Remova uma implantação do MongoDB Ops Manager ou Cloud Manager no projeto usando a UI ou a API.
Remova um sistema na interface do usuário do MongoDB Ops Manager ou Cloud Manager . No MongoDB Ops Manager, remova uma implantação da Automação e remova uma implantação do Monitoramento.
No Cloud Manager, remova uma implantação da Automação e remova uma implantação do Monitoramento.
Como alternativa, remova uma implantação usando a API para atualizar a configuração de automação no MongoDB Ops Manager ou no Cloud Manager com uma configuração vazia usando a solicitação de MongoDB Ops Manager API API do ou a Cloud Manager API solicitação de do .
Execute o comando semelhante ao seguinte exemplo do MongoDB Ops Manager :
curl --user "{USERNAME}:{APIKEY}" --digest \ --header "Content-Type: application/json" \ --include \ --request PUT "https://{OPSMANAGER-HOST}/api/public/v1.0/groups/{PROJECT-ID}/automationConfig" \ --data '{}' Observação
Excluir um recurso MongoDB para o qual você habilitou o backup não exclui os snapshots do recurso. Você deve excluir snapshots no MongoDB Ops Manager ou excluir snapshots no Cloud Manager.
Exclua um projeto do MongoDB Ops Manager ou Cloud Manager usando a UI ou a API. Exclua um projeto no MongoDB Ops Manager ou exclua um projeto no Cloud Manager.
Como alternativa, exclua um projeto usando a MongoDB Ops Manager API solicitação da API do ou a Cloud Manager API solicitação da do .
Execute o comando semelhante ao seguinte exemplo do MongoDB Ops Manager :
curl --user "{USERNAME}:{APIKEY}" --digest \ --request DELETE "{OPSMANAGER-HOST}/api/public/v1.0/groups/${PROJECT-ID}"
Depurar um container com falha
Um container pode falhar com um erro que resulta em Kubernetes reiniciando o container em um loop.
Talvez seja necessário interagir com esse container para inspecionar arquivos ou executar comandos. Isso exige que você evite que o container seja reiniciado.
No editor de texto de sua preferência, abra o recurso MongoDB que você precisa reparar.
Para este recurso, adicione uma collection
podSpec
que se assemelha ao seguinte.podSpec: podTemplate: spec: containers: - name: mongodb-enterprise-database command: ['sh', '-c', 'echo "Hello!" && sleep 3600' ] O sono comando no
spec.podSpec.podTemplate.spec
instrui o container a aguardar pelo número de segundos que você especifica. Neste exemplo, o container aguardará 1 hora.Aplique esta alteração ao recurso.
kubectl apply -f <resource>.yaml Invoque a shell dentro do container.
kubectl exec -it <pod-name> bash
Verificar se os nomes dos domínios em certificados TLS estão corretos
Um conjunto de réplicas ou cluster fragmentado do MongoDB pode não atingir o estado READY
se o certificado TLS for inválido.
Ao configurar TLS para conjuntos de réplicas ou clusters fragmentados do MongoDB, certifique-se de especificar um certificado válido.
Se você não especificar o Nome de Domínio correto para cada certificado TLS , os logs do Operador Kubernetes poderão conter uma mensagem de erro semelhante à seguinte, em que foo.svc.local
é o Nome de Domínio especificado incorretamente para o Pod do membro do cluster:
TLS attempt failed : x509: certificate is valid for foo.svc.local, not mongo-0-0.mongo-0.mongodb.svc.cluster.local
Cada certificado deve incluir um nome de domínio válido.
Para cada conjunto de réplicas ou nó de cluster fragmentado, o nome comum, também conhecido como nome de domínio, do certificado desse nó deve corresponder ao FQDN do pod em que esse nó do cluster está distribuído.
O nome FQDN em cada certificado contém a seguinte sintaxe: pod-name.service-name.namespace.svc.cluster.local
. Este nome é diferente para cada Pod que hospeda um nó do conjunto de réplicas ou cluster fragmentado.
Por exemplo, para um nó de um conjunto de réplicas distribuído em um Pod com o nome rs-mongos-0-0
, no serviço do Kubernetes Operator denominado mongo-0
que é criado no namespace padrão do mongodb
, o FQDN é:
rs-mongos-0-0.mongo-0.mongodb.svc.cluster.local
Para verificar se você configurou corretamente os certificados TLS:
Executar:
kubectl logs -f <pod_name> Verifique se há mensagens relacionadas ao TLS nos arquivos de log do Kubernetes Operator.
Para saber mais sobre os requisitos do certificado TLS , consulte os pré-requisitos na aba TLS-Encrypted Connections em Distribuir um conjunto de réplicas ou em Distribuir um cluster fragmentado.
Verificar a versão do MongoDB ao executar no modo local
CustomResource
do MongoDB podem não atingir um estado de Running
se o Ops Manager estiver sendo executado no Modo Local e você especificar uma versão do MongoDB que não existe ou uma versão válida do MongoDB para a qual o Ops Manager distribuído no modo local não baixou um arquivo do MongoDB correspondente.
Se você especificar uma versão do MongoDB que não existe, ou uma versão válida do MongoDB para a qual o Ops Manager não pôde baixar um arquivo do MongoDB, mesmo que os Pods possam atingir o estado READY
, os logs do Kubernetes Operator conterão uma mensagem de erro semelhante à seguinte:
Failed to create/update (Ops Manager reconciliation phase): Status: 400 (Bad Request), Detail: Invalid config: MongoDB <version> is not available.
Isso pode significar que o MongoDB Agent não conseguiu baixar corretamente um binário do MongoDB correspondente para o diretório /var/lib/mongodb-mms-automation
. Nos casos em que o MongoDB Agent pode baixar o binário do MongoDB para a versão especificada do MongoDB corretamente, esse diretório conterá uma pasta de binários do MongoDB, como mongodb-linux-x86_64-4.4.0
.
Para conferir se uma pasta binária do MongoDB está presente:
Especifique o nome do Pod para este comando:
kubectl exec --stdin --tty $<pod_name> /bin/sh Verifique se uma pasta binária MongoDB está presente no diretório
/var/lib/mongodb-mms-automation
.Se você não conseguir localizar uma pasta binária do MongoDB, copie o arquivo MongoDB para o Volume persistente do Ops Manager para cada conjunto de réplicas do Ops Manager distribuído.
Falha na atualização usando kubectl
ou oc
Você poderá receber o seguinte erro ao atualizar o Kubernetes Operator:
Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden
Para solucionar este erro:
Remova a antiga implantação do operador Kubernetes.
kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace> Observação
Remover a implantação do operador Kubernetes não afeta o ciclo de vida de seus recursos MongoDB.
Repita o comando
kubectl apply
para atualizar para a nova versão do operador Kubernetes.
Falha na atualização ao usar gráficos Helm
Você poderá receber o seguinte erro ao atualizar o Kubernetes Operator:
Error: UPGRADE FAILED: cannot patch "mongodb-enterprise-operator" with kind Deployment: Deployment.apps "mongodb-enterprise-operator" is invalid: ... field is immutable
Para solucionar este erro:
Remova a antiga implantação do operador Kubernetes.
kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace> Observação
Remover a implantação do operador Kubernetes não afeta o ciclo de vida de seus recursos MongoDB.
Repita o comando
helm
para atualizar para a nova versão do operador Kubernetes.
Duas instâncias de operador após uma atualização
Depois de fazer a atualização da versão 1.10 ou anterior do Kubernetes Operator para a versão 1.11 ou posterior, o cluster do Kubernetes poderá ter duas instâncias distribuídas do Kubernetes Operator.
Use o comando get pods
para visualizar os pods do Kubernetes Operator:
Observação
Se você implantou o Kubernetes Operator no OpenShift, substitua os comandos do kubectl
nesta seção por comandos do oc
.
kubectl get pods
Se a resposta contiver um enterprise-operator
e um pod mongodb-enterprise-operator
, seu cluster terá duas instâncias do operador Kubernetes:
NAME READY STATUS RESTARTS AGE enterprise-operator-767884c9b4-ltkln 1/1 Running 0 122m mongodb-enterprise-operator-6d69686679-9fzs7 1/1 Running 0 68m
Você pode remover com segurança a implantação do enterprise-operator
. Execute o seguinte comando para removê-la:
kubectl delete deployment/enterprise-operator
Recuperar recurso devido a configuração de automação quebrada
Se um recurso personalizado permanecer em um estado Pending
ou Failed
por um longo período de tempo, Kubernetes Operator recuperará automaticamente seus recursos MongoDB
enviando a configuração de automação para o MongoDB Ops Manager. Isso evita um bloqueio quando o MongoDB Agent não consegue enviar uma alteração de configuração de automação atualizada porque o StatefulSet está preso em um estado Pending
devido a um envio anterior de uma configuração de automação inválida.
Para configurar a recuperação automática, defina as seguintes variáveis ambientais no seu arquivo mongodb-enterprise.yaml:
MDB_AUTOMATIC_RECOVERY_ENABLE para habilitar ou desabilitar a recuperação automática de recursos do
MongoDB
por Pod.MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S para definir o número de segundos em que um recurso personalizado pode permanecer em um estado
Pending
ouFailed
antes de o Kubernetes Operator recuperar automaticamente seus recursosMongoDB
.
Exemplo
1 spec: 2 template: 3 spec: 4 serviceAccountName: mongodb-enterprise-operator 5 containers: 6 - name: mongodb-enterprise-operator 7 image: <operatorVersionUrl> 8 imagePullPolicy: <policyChoice> 9 env: 10 - name: MDB_AUTOMATIC_RECOVERY_ENABLE 11 value: true 12 - name: MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S 13 value: 1200
Para aprender como definir variáveis de ambiente, consulte Como definir variáveis de ambiente para um contêiner.