Nota
En cualquier lugar de esta página donde diga Ops Manager, puedes sustituir Cloud Manager.
Importante
Puedes usar el Operador de Kubernetes para implementar recursos de MongoDB con Cloud Manager y con Ops Manager versión 6.0.x o posterior.
Puedes usar el Atlas Operator para implementar recursos de MongoDB en Atlas.
Puedes implementar una instancia de MongoDB autónoma para que un Ops Manager la gestione. Utiliza instancias autónomas para pruebas y desarrollo. No uses estas implementaciones para sistemas de producción, ya que carecen de replicación y alta disponibilidad. Para todas las implementaciones en producción, utiliza sets de réplicas. Para aprender sobre los sets de réplicas, consulte Implementar un set de réplicas.
Requisitos previos
Para implementar de forma autónomo utilizando un objeto, debes:
Tenga o cree una instancia de Ops Manager o una organización de Cloud Manager.
Tener o instalar el MongoDB Enterprise Kubernetes Operator.
Crea o genera un ConfigMap de Kubernetes Operator.
Crea credenciales para el Operador de Kubernetes o configura una herramienta diferente de almacenamiento de secretos.
Nota
Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.
Procedimiento
Configurar kubectl para establecer su namespace por defecto.
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ás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:
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>
Copia el siguiente objeto autónomo de ejemplo de Kubernetes objeto.
Esto es un YAML archivo que puedes modificar para cumplir con tu configuración deseada. Cambia la configuración resaltada para que se ajuste a la configuración autónoma que deseas.
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: <my-standalone> spec: version: "8.0.0" opsManager: configMapRef: name: <configMap.metadata.name> # Must match metadata.name in ConfigMap file credentials: <mycredentials> type: Standalone persistent: true ...
Abre tu editor de texto preferido y pega la especificación del objeto en un archivo de texto nuevo.
Configura los ajustes destacados en el paso anterior de la siguiente manera.
Clave | Tipo | Descripción | Ejemplo |
|---|---|---|---|
string | Etiqueta para este objeto de Kubernetes autónomo. Los nombres de recursos deben tener 44 caracteres o menos. Para aprender más, consulta |
| |
string | Versión de MongoDB que está instalada en este autónomo. El formato debe ser IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB. Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB. | Para obtener los mejores resultados, utilice la última versión disponible de MongoDB Enterprise que sea compatible con su versión de Ops Manager. | |
string | Nombre del ConfigMap con la configuración de conexión de Ops Manager. La configuración Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear. |
| |
string | Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el Operador Kubernetes se comunique con Ops Manager. El objeto secreto de Kubernetes de Ops Manager que contiene las credenciales debe estar en el mismo namespace que el recurso que se quiere crear. IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso |
| |
string | Tipo de recurso |
| |
string | Opcional. Si este valor es Para cambiar la <a class=\" \" target=\" \"href=\" \" rel=\"noopener noreferrer\"> Solicitud de volumen persistente <svg class=\" \" height=\" \" width=\" \" role=\" \" aria-hidden=\" \" alt=\" \" viewbox=\" \"><path d=\" \" fill=\" \"> <path d=\" \" fill=\" \"> configuración, configura las siguientes colecciones para cumplir con tus requisitos de implementación:
ADVERTENCIA: Otorga a tus contenedores permiso para guardar en tu volumen persistente. El operador de Kubernetes establece Si no usas volúmenes persistentes, el Disk Usage y Disk IOPS gráficas no pueden mostrarse ni en la pestaña Processes de la página Deployment ni en la página Metrics al revisar los datos de esta implementación. |
|
Agregar cualquier configuración aceptada adicional para una implementación autónomo.
También puedes añadir cualquiera de las siguientes configuraciones opcionales al archivo de especificación de objeto para una implementación autónoma:
Rastrea el estado de tu implementación autónoma.
Para verificar el estado de su MongoDB recurso, utilice el siguiente comando:
kubectl get mdb <resource-name> -o yaml -w
Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.
Para solucionar problemas de tu clúster fragmentado, consulta: