Importante
No se recomienda configurar Ops Manager para usar el modo local en Kubernetes. Considere configurar Ops Manager para usar el modo remoto.
En una configuración predeterminada, los daemons de respaldo y del agente MongoDB acceden a los archivos de instalación de MongoDB a través de Internet desde MongoDB, Inc.
Puede configurar Ops Manager para que se ejecute en modo local con el operador de Kubernetes si los nodos de su clúster de Kubernetes no tienen acceso a Internet. Los daemons de respaldo y los recursos administrados de MongoDB descargan los archivos de instalación solo desde un volumen persistente. que crea para el StatefulSet de Ops Manager.
Este procedimiento cubre la carga de archivos de instalación en Ops Manager.
Si Ops Manager no tiene acceso a Internet,consulte Configurar la implementación para tener acceso a Internet limitado.
Para conocer la compatibilidad, consulte Compatibilidad de operadores de MongoDB Enterprise Kubernetes. Para ver todas las versiones disponibles de cada imagen, consulte Imágenes de contenedor.
Requisitos previos
Implemente un recurso de Ops Manager. El siguiente procedimiento le muestra cómo actualizar su objeto de Kubernetes de Ops Manager para habilitar el modo local.
Para evitar tiempos de inactividad cuando habilita el modo local, asegúrese de configurar
spec.replicasa un valor mayor que1en la definición de recurso de Ops Manager.Si actualizó su definición de recurso de Ops Manager para que Ops Manager tenga alta disponibilidad, aplique los cambios antes de comenzar este tutorial:
kubectl apply -f <opsmgr-resource>.yaml -n <metadata.namespace>
Procedimiento
Configure para kubectl que el valor predeterminado sea su espacio de nombres.
Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los kubectl comandos en el espacio de nombres que creó.
Nota
Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:
Establezca
contexten el nombre del clúster del operador, como por ejemplo:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".Establezca
--namespaceen el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb"ejemplo:.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
Elimina el StatefulSet que administra tus pods de Ops Manager.
En este tutorial, actualizas el StatefulSet que gestiona los Pods de Ops Manager en tu clúster de Kubernetes.
Primero tienes que borrar StatefulSet de Ops Manager para que Kubernetes pueda aplicar las actualizaciones que requiere el Modo Local.
Encuentra el nombre de tu StatefulSet de Ops Manager:
kubectl get statefulsets La entrada en la respuesta que coincide con el de
metadata.namesuTu StatefulSet de Ops Manager es la entrada en la respuesta que coincide con el
metadata.nameen la definición de tu recurso Ops Manager.kubectl get statefulsets -n mongodb NAME READY AGE ops-manager-localmode 2/2 2m31s ops-manager-localmode-db 3/3 4m46s Eliminar el StatefulSet de Ops Manager:
Advertencia
Asegúrate de incluir el indicador
--cascade=falseal eliminar tu StatefulSet de Ops Manager. Si no lo incluyes, Kubernetes también eliminará tus pods de Ops Manager.kubectl delete statefulset --cascade=false <ops-manager-statefulset>
Copie los campos de este recurso de Ops Manager.
Copiar las líneas 9-31 de este ejemplo a:
Utilice la configuración de Ops Manager
automation.versions.source: localen para habilitarspec.configurationel modo local.Defina un volumen persistente para el StatefulSet de Ops Manager para almacenar el archivo de instalación de MongoDB. Los agentes de MongoDB que se ejecutan en contenedores de recursos de base de datos de MongoDB creados con el operador de Kubernetes descargan los archivos de instalación de Ops Manager en lugar de hacerlo desde Internet.
1 apiVersion: mongodb.com/v1 2 kind: MongoDBOpsManager 3 metadata: 4 name: ops-manager-localmode 5 spec: 6 replicas: 2 7 version: "6.0.0" 8 adminCredentials: ops-manager-admin-secret 9 configuration: 10 # this enables local mode in Ops Manager 11 automation.versions.source: local 12 statefulSet: 13 spec: 14 # the Persistent Volume Claim will be created for each Ops Manager Pod 15 volumeClaimTemplates: 16 - metadata: 17 name: mongodb-versions 18 spec: 19 accessModes: [ "ReadWriteOnce" ] 20 resources: 21 requests: 22 storage: "20Gi" 23 template: 24 spec: 25 containers: 26 - name: mongodb-ops-manager 27 volumeMounts: 28 - name: mongodb-versions 29 # this is the directory in each Pod where all MongoDB 30 # archives must be put 31 mountPath: /mongodb-ops-manager/mongodb-releases 32 backup: 33 enabled: false 34 applicationDatabase: 35 members: 3
Pegue la sección de ejemplo copiada en su recurso de Ops Manager existente.
Abra su editor de texto preferido y pegue la especificación del objeto en la ubicación adecuada en su archivo de recursos.
Aplicar cambios a su implementación de Ops Manager.
Invoque el siguiente comando
kubectlen el nombre de archivo de la definición de recurso de Ops Manager:kubectl apply -f <opsmgr-resource>.yaml Kubernetes crea un nuevo conjunto de estado de Ops Manager al aplicar los cambios a la definición de recursos de Ops Manager. Antes de continuar, ejecute el siguiente comando para asegurarse de que el conjunto de estado de Ops Manager exista:
kubectl get statefulsets El nuevo StatefulSet de Ops Manager debería mostrar 0 miembros listos:
kubectl get statefulsets -n mongodb NAME READY AGE ops-manager-localmode 0/2 2m31s ops-manager-localmode-db 3/3 4m46s
De forma progresiva, elimine sus antiguos pods de Ops Manager.
Enumere los pods de Ops Manager en su clúster de Kubernetes:
kubectl get pods Eliminar un pod de Ops Manager:
kubectl delete pod <om-pod-0> Kubernetes vuelve a crear el Pod de Ops Manager que borraste. Continúa obteniendo el estado del nuevo Pod hasta que esté listo:
kubectl get pods Cuando se inicializa el nuevo Pod, la salida es similar al siguiente ejemplo:
NAME READY STATUS RESTARTS AGE mongodb-enterprise-operator-5648d4c86-k5brh 1/1 Running 0 5m24s ops-manager-localmode-0 0/1 Running 0 0m55s ops-manager-localmode-1 1/1 Running 0 5m45s ops-manager-localmode-db-0 1/1 Running 0 5m19s ops-manager-localmode-db-1 1/1 Running 0 4m54s ops-manager-localmode-db-2 1/1 Running 0 4m12s Cuando el nuevo Pod esté listo, la salida será similar al siguiente ejemplo:
NAME READY STATUS RESTARTS AGE mongodb-enterprise-operator-5648d4c86-k5brh 1/1 Running 0 5m24s ops-manager-localmode-0 1/1 Running 0 3m55s ops-manager-localmode-1 1/1 Running 0 5m45s ops-manager-localmode-db-0 1/1 Running 0 5m19s ops-manager-localmode-db-1 1/1 Running 0 4m54s ops-manager-localmode-db-2 1/1 Running 0 4m12s Repita los pasos b y c hasta que haya eliminado todos sus pods de Ops Manager y haya confirmado que todos los pods nuevos estén listos.
Realice un seguimiento del estado de su instancia de Ops Manager.
Para comprobar el estado de su recurso Ops Manager, invoque el siguiente comando:
kubectl get om -o yaml -w
Consulte Solucionar problemas del operador de Kubernetes para obtener información sobre los estados de implementación de recursos.
Una vez que el recurso Ops Manager completa la fase Pending, el comando devuelve un resultado similar al siguiente:
1 status: 2 applicationDatabase: 3 lastTransition: "2020-05-15T16:20:22Z" 4 members: 3 5 phase: Running 6 type: ReplicaSet 7 version: "4.4.5-ubi8" 8 backup: 9 phase: "" 10 opsManager: 11 lastTransition: "2020-05-15T16:20:26Z" 12 phase: Running 13 replicas: 1 14 url: http://ops-manager-localmode-svc.mongodb.svc.cluster.local:8080 15 version: "6.0.0"
Copia el valor del campo status.opsManager.url, que indica la conexión del recurso URL. Utilice este valor cuando cree un ConfigMap más adelante en el procedimiento.
Descargue el archivo de instalación de MongoDB en su máquina local.
Los instaladores que descargue dependerán del entorno en el que haya implementado el operador:
Nota
El siguiente ejemplo incluye un enlace que permite descargar la versión especificada de MongoDB Community Edition. Para descargar cualquier otra versión de MongoDB Community Edition, visite el Centro de descargas de MongoDB Community Edition. Para descargar MongoDB Enterprise Edition, visite el Centro de descargas de MongoDB Enterprise.
Descargue el archivo tarball de instalación de RHEL para la versión de MongoDB Server que desea que el operador de Kubernetes implemente. Por ejemplo, para descargar la versión 6.0.1:
curl -OL https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel80-6.0.1.tgz
Copie el archivo MongoDB al volumen persistente de Ops Manager.
Copie el archivo MongoDB para cada versión de MongoDB que desee implementar en el volumen persistente de Ops Manager.
Los comandos que utilice dependerán del entorno en el que haya implementado el operador de Kubernetes:
Nota
Si implementó más de un Ops Manager, copie solo replica los tarball paquetes de instalación de MongoDB a Replica 1 y más allá.
Para copiar el archivo de instalación de MongoDB al PersistentVolume de Ops Manager:
Copie el archivo tarball de instalación de MongoDB Server en el volumen persistente de Ops Manager. Por ejemplo, para copiar la versión 6.0.1:
kubectl cp mongodb-linux-x86_64-rhel80-6.0.1.tgz \ "ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz"
kubectl cp mongodb-linux-x86_64-rhel80-6.0.1.tgz \ "ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz"
Para copiar el archivo de instalación de MongoDB al Volumen Persistente de Ops Manager, copie la instalación del servidor MongoDB tarball al Volumen Persistente de Ops Manager. Por ejemplo, para copiar la versión 6.0.1:
oc rsync "ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz" \ mongodb-linux-x86_64-rhel80-6.0.1.tgz
oc rsync "ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz" \ mongodb-linux-x86_64-rhel80-6.0.1.tgz
Implementar un recurso de base de datos MongoDB.
Si aún no lo ha hecho, complete los siguientes requisitos previos:
Implemente un recurso de base de datos MongoDB en el mismo espacio de nombres donde implementó Ops Manager. Asegúrese de lo siguiente:
Haga coincidir el
spec.opsManager.configMapRef.namedel recurso con elmetadata.namede su ConfigMap.Haga coincidir el
spec.credentialsdel recurso con el nombre del secreto que creó y que contiene un par de claves API programáticas de Ops Manager.
El agente de MongoDB se ejecuta en contenedores de recursos de base de datos de MongoDB creados con el operador de Kubernetes. Descargue los archivos de instalación desde Ops Manager en lugar de descargarlos de internet.