/ /

Implementar

Docs Home

/ /

Implementar recursos de la base de datos

Implementar

Docs Home

Gestión

Controladores para el Operador de Kubernetes

Implementar recursos de la base de datos

Implementar

Implementar una instancia autónoma de MongoDB

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 los Controladores MongoDB para el Operador de Kubernetes.
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

Configura `kubectl` para que sea por defecto en tu namespace.

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 context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".
Establece el --namespace en 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 ejemplo autónomo de Kubernetes.

Este es un archivo YAML que puedes modificar para cumplir con la configuración que desees. Cambia los ajustes resaltados para que coincidan con la configuración autónoma deseada.

---
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 nuevo archivo de texto.

Configura los ajustes destacados en el paso anterior de la siguiente manera.

Clave	Tipo	Descripción	Ejemplo
`metadata.name`	string	Etiqueta para este objeto de Kubernetes autónomo. Los nombres de recursos deben tener 44 caracteres o menos. Para aprender más, consulta `metadata.name` y la documentación de Kubernetes sobre nombres.	`my-project`
`spec.version`	string	Versión de MongoDB que está instalada en este autónomo. El formato debe ser `X.Y.Z` para la Community Edition y `X.Y.Z-ent` para la edición Enterprise. 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.
`spec.opsManager` `.configMapRef.name`	string	Nombre del ConfigMap con la configuración de conexión de Ops Manager. La `spec.cloudManager.configMapRef.name` configuración es un alias para esta configuración y puede usarse en su lugar. Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.	`<myproject>`
`spec.credentials`	string	Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el operador de Kubernetes pueda comunicarse con Ops Manager. The Ops Manager Kubernetes Secret object holding the Credentials must exist on the same Namespace as the resource you want to create. IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso `MongoDB`.	`<mycredentials>`
`spec.type`	string	Tipo de recurso `MongoDB` que se va a crear.	`Standalone`
`spec.persistent`	string	Opcional. Si este valor es `true`, entonces `spec.podSpec.persistence.single` se establece en su valor por defecto de `16Gi`. Para cambiar la configuración de tu claim de volumen persistente, configura las siguientes colecciones para cumplir con los requisitos de tu implementación: Si desea un volumen persistente para cada Pod, configure la `spec.podSpec.persistence.single` colección. Si quieres Volúmenes Persistentes separados para datos, diarios y registros para cada Pod, configura las siguientes colecciones: `spec.podSpec.persistence.multiple.data` `spec.podSpec.persistence.multiple.journal` `spec.podSpec.persistence.multiple.logs` ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su Volumen Persistente. El Operador de Kubernetes `fsGroup = 2000` `runAsUser = 2000`establece, y `runAsNonRoot = true` en. El `securityContext` Operador de Kubernetes establece `fsgroup` igual a `runAsUser` para que el volumen sea escribible para un usuario que ejecuta el proceso principal en el contenedor. Para obtener más información, consulte Configurar un Contexto de Seguridad para un Pod o Contenedor y la discusión relacionada en la documentación de Kubernetes. Si la redistribución del recurso no soluciona los problemas con su Volumen Persistente, comuníquese con el Soporte de MongoDB. If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.	`true`

Agregar cualquier configuración aceptada adicional para una implementación autónomo.

También puedes agregar cualquiera de las siguientes configuraciones opcionales al archivo de especificación del objeto para una implementación autónoma:

Guarde este archivo con una extensión de archivo `.yaml`.

Inicia tu implementación autónoma.

Invoca el siguiente comando de Kubernetes para crear tu autónomo:

kubectl apply -f <standalone-conf>.yaml

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:

Volver

Implementar

Set de réplicas