Importante
No se recomienda configurar Ops Manager para usar el modo local en Kubernetes. Considerar configurar Ops Manager para utilizar el modo remoto en su lugar.
En una configuración predeterminada, el agente de MongoDB y los daemons de copias de seguridad acceden a los ficheros de instalación de MongoDB a través de Internet desde MongoDB, Inc.
Puedes configurar Ops Manager para que se ejecute en modo local con el Operador de Kubernetes si los nodos de tu clúster de Kubernetes no tienen acceso a Internet. Los daemons de copias de seguridad y los recursos de MongoDB gestionados descargan ficheros de instalación solo desde una Volumen persistente que crea para Ops Manager StatefulSet.
Este procedimiento cubre la carga de los ficheros de instalación en Ops Manager.
Si Ops Manager no tiene acceso a internet, consulta Configurar implementación para tener acceso limitado a Internet.
Para conocer la compatibilidad, consulta Controladores de MongoDB para la Compatibilidad del Operador de Kubernetes. Para ver todas las versiones disponibles de cada imagen, consulta Imágenes de contenedores.
Requisitos previos
Implementar un recurso de Ops Manager. El siguiente procedimiento te muestra cómo actualizar el Kubernetes de tu Ops Manager objeto 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
Configura kubectl para que se ajuste por defecto a tu espacio de nombres.
Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace 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:
Defina
contextcomo el nombre del clúster operador, por ejemplo:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".Establece el
--namespaceen el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo:kubectl config --namespace "mongodb".
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
Borre el StatefulSet que administra sus 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 la bandera
--cascade=falsecuando borres tu StatefulSet de Ops Manager. Si no incluyes este flag, Kubernetes también borrará 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 en:
Utiliza la configuración de Ops Manager
automation.versions.source: localenspec.configurationpara habilitar el 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: "8.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
Pega la sección de ejemplo copiada en tu recurso existente de Ops Manager.
Abra su editor de texto preferido y pegue la especificación del objeto en la ubicación adecuada en su archivo de recursos.
Aplica los cambios a tu implementación de Ops Manager.
Invoque el siguiente comando
kubectlen el nombre del archivo de la definición de recurso de Ops Manager:kubectl apply -f <opsmgr-resource>.yaml Kubernetes crea un nuevo StatefulSet de Ops Manager cuando aplicas los cambios a tu definición de recurso de Ops Manager. Antes de proceder al siguiente paso, ejecuta el siguiente comando para asegurarte de que el StatefulSet 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 manera progresiva, elimina tus Pods antiguos de Ops Manager.
Enumere los pods de Ops Manager en su clúster de Kubernetes:
kubectl get pods Borre 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 está iniciando el nuevo Pod, la salida es similar al siguiente ejemplo:
NAME READY STATUS RESTARTS AGE mongodb-kubernetes-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-kubernetes-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 confirmado que todos los nuevos Pods están listos.
Realice un seguimiento del estado de su instancia de Ops Manager.
Para comprobar el estado de tu recurso Ops Manager, ejecuta 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: "8.0.0-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: "8.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 fichero de instalación de MongoDB en su máquina local.
Los instaladores que descargues dependen del entorno en el que hayas implementado el operador:
Nota
El siguiente ejemplo incluye un enlace que te permite descargar la versión especificada de MongoDB Community Edition. Para descargar cualquier otra versión de MongoDB Community Edition, visita el Centro de Descargas de MongoDB Community Edition. Para descargar MongoDB Enterprise Edition, visita el Centro de Descargas de MongoDB Enterprise.
Descargue el archivo tarball de instalación de RHEL para la versión de MongoDB Server que desee que el Operador de Kubernetes implemente. Por ejemplo, para descargar el lanzamiento 8.0.0:
curl -OL https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel80-8.0.0.tgz
Copia el fichero de MongoDB al volumen persistente de Ops Manager.
Copie el fichero de MongoDB para cada versión de MongoDB que implementará en el volumen persistente Ops Manager.
Los comandos que se utilizan dependen del entorno en el que se desplegó 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 tar de instalación de MongoDB Server en el PersistentVolume de Ops Manager. Por ejemplo, para copiar la versión 8.0.0:
kubectl cp mongodb-linux-x86_64-rhel80-8.0.0.tgz \ "ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-8.0.0.tgz"
kubectl cp mongodb-linux-x86_64-rhel80-8.0.0.tgz \ "ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-8.0.0.tgz"
Para copiar el fichero de instalación de MongoDB en PersistentVolume de Ops Manager, copie la instalación de tarball de MongoDB Server en el PersistentVolume de Ops Manager. Por ejemplo, para copiar la versión 8.0.0:
oc rsync "ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-8.0.0.tgz" \ mongodb-linux-x86_64-rhel80-8.0.0.tgz
oc rsync "ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-8.0.0.tgz" \ mongodb-linux-x86_64-rhel80-8.0.0.tgz
Implementa 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 de MongoDB en el mismo namespace en el que implementó Ops Manager. Asegúrese de:
Haz coincidir el
spec.opsManager.configMapRef.namedel recurso con elmetadata.namede tu ConfigMap.Haga coincidir el
spec.credentialsdel recurso con el nombre del secreto que creó que contiene un par de claves API programáticas de Ops Manager.
Los MongoDB Agent se ejecutan en contenedores de recursos de la base de datos de MongoDB que se crean con el operador de Kubernetes. Descargue los ficheros de instalación desde Ops Manager en lugar de descargarlos de Internet.