Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Conéctese al recurso multi-clúster desde fuera de Kubernetes

El siguiente procedimiento describe cómo conectarse a un recurso MongoDBMultiCluster desplegado en Kubernetes desde fuera del clúster de Kubernetes.

Las bases de datos que ejecutan MongoDB 4.2.3 o versiones posteriores permiten el acceso fuera del clúster de Kubernetes.

Si creas servicios personalizados que requieren acceso externo a recursos personalizados de MongoDB implementados por el operador de Kubernetes y usas readiness probes en Kubernetes, configura el ajuste publishNotReadyAddresses en Kubernetes a true.

The publishNotReadyAddresses setting indicates that an agent that interacts with endpoints for this service should disregard the service's ready state. Setting publishNotReadyAddresses to true overrides the behavior of the readiness probe configured for the Pod hosting your service.

Por defecto, la configuración publishNotReadyAddresses está establecida en false. En este caso, cuando los Pods que alojan los recursos personalizados de MongoDB en Kubernetes Operator pierden conectividad con Cloud Manager u Ops Manager, las pruebas de disponibilidad configuradas para estos Pods fallan. Sin embargo, cuando se define el ajuste publishNotReadyAddresses a true:

  • Kubernetes no apaga el servicio cuya prueba de preparación falla.

  • Kubernetes considera que todos los endpoints están listos incluso si las pruebas de los Pods que alojan los servicios para estos endpoints indican que no están listos.

  • Los recursos personalizados de MongoDB aún están disponibles para operaciones de lectura y escritura.

Para conectarse a su conjunto de réplicas implementado por Kubernetes Operator con un recurso de MongoDBMultiCluster desde fuera del clúster de Kubernetes:

2

Proporcione valores para:

3

Para conectar a tu implementación de múltiples clústeres de Kubernetes desde un recurso externo, configura el spec.externalAccess entorno:

externalAccess: {}

Esta configuración indica al operador de Kubernetes que cree un servicio externo LoadBalancer para los pods de MongoDB en su implementación de múltiples clústeres de Kubernetes. El servicio externo proporciona un punto de entrada para conexiones externas. Agregar esta configuración sin valores crea un servicio externo con los siguientes valores por defecto:

Campo
Valor
Descripción

Name

<pod-name>-svc-external

Nombre del Servicio externo. No puedes cambiar este valor.

Type

LoadBalancer

Crea un servicio externo LoadBalancer.

Port

<Port Number>

A port for mongod.

publishNotReadyAddress

true

Specifies that DNS records are created even if the Pod isn't ready. Do not set to false for any database Pod.

Opcionalmente, si necesitas agregar valores al servicio o sobrescribir los valores por defecto, especifica:

Por ejemplo, los siguientes ajustes anulan los valores predeterminados del servicio externo para configurar la implementación de tu clúster multi-Kubernetes y crear servicios NodePort que expongan los Pods de MongoDB:

externalAccess:
externalService:
annotations:
# cloud-specific annotations for the service
spec:
type: NodePort # default is LoadBalancer
port: 27017
# you can specify other spec overrides if necessary

Tip

Para obtener más información, consulta anotaciones y ServiceSpec en la documentación de Kubernetes.

4

Si necesitas configurar los ajustes para un nodo específico del clúster, como cuando alojas nodos en diferentes proveedores de nube, puedes anular la configuración global spec.externalAccess configuraciones para un nodo específico utilizando el spec.clusterSpecList.externalAccess.externalService ajuste.

Para añadir valores al servicio o anular los valores por defecto para un nodo del clúster, especifique:

Por ejemplo, el siguiente archivo configura la implementación de MongoDB en múltiples clústeres de Kubernetes para crear servicios de balanceador de carga que exponen la implementación de MongoDB en múltiples clústeres de Kubernetes para los nodos del clúster implementados en GKE (Google Kubernetes Engine) y AWS EKS.

Nota

El siguiente ejemplo no configura anulaciones, por lo que los servicios externos usan los valores por defecto de la especificación. Acceso externo ajuste.

clusterSpecList:
- clusterName: gke-cluster-0.mongokubernetes.com
members: 2
externalAccess:
externalService:
annotations:
"cloud.google.com/l4-rbs": "enabled"
- clusterName: eks-cluster-1.mongokubernetes.com
members: 2
externalAccess:
externalService:
annotations:
"service.beta.kubernetes.io/aws-load-balancer-type": "external",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "instance",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing"
5

Agrega cada nombre externo de DNS al SAN del certificado.

6

En cada clúster, ejecute el siguiente comando para verificar que el operador de Kubernetes haya creado el servicio externo para su implementación.

$ kubectl get services

El comando devuelve una lista de servicios similar a la siguiente salida. Para cada Pod de base de datos en el clúster, el Operador de Kubernetes crea un servicio externo llamado <pod-name>-<cluster-idx>-<pod-idx>-svc-external. Este servicio está configurado de acuerdo con los valores y anulaciones que proporciones en la especificación del servicio externo.

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
<my-replica-set>-0-0-svc-external LoadBalancer 10.102.27.116 <lb-ip-or-fqdn> 27017:27017/TCP 8m30s

Dependiendo de la configuración de su clúster o proveedor de nube, la dirección IP del servicio LoadBalancer es una dirección IP accesible externamente o FQDN. Puedes utilizar la dirección IP o FQDN para enrutar el tráfico desde tu dominio externo.

7

Establece los nombres de host y puertos en spec.connectivity.replicaSetHorizons con los valores del servicio externo que creaste en el paso anterior.

Confirme que haya especificado los nombres de host externos correctos. Los nombres de host externos deben coincidir con los nombres DNS de los nodos de trabajo de Kubernetes. Estos pueden ser cualquier nodo en el clúster de Kubernetes. Si el pod se ejecuta en otro nodo, los nodos de Kubernetes utilizan enrutamiento interno.

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
name: multi-cluster-replica-set
namespace: mongodb
spec:
clusterSpecList:
- clusterName: e2e.cluster1.example.com
members: 1
- clusterName: e2e.cluster2.example.com
members: 1
- clusterName: e2e.cluster3.example.com
members: 1
connectivity:
replicaSetHorizons:
- sample-horizon: web1.example.com:30907
- sample-horizon: web2.example.com:30907
- sample-horizon: web3.example.com:30907
credentials: my-credentials
duplicateServiceObjects: false
opsManager:
configMapRef:
name: my-project
persistent: true
security:
certsSecretPrefix: clustercert
tls:
ca: ca-issuer
type: ReplicaSet
version: 8.0.0"
8

En cada clúster, ejecute este comando para aplicar el archivo de set de réplicas actualizado:

$ Kubectl apply -f <file_name.yaml>
9

En el entorno de desarrollo, en cada host de un set de réplicas, ejecuta el siguiente comando:

mongosh --host <my-replica-set>/web1.example.com \
--port 30907
--ssl \
--sslAllowInvalidCertificates

Nota

No utilices la bandera --sslAllowInvalidCertificates en producción.

En producción, para cada host de un set de réplicas, especifica el certificado TLS y la CA para conectar de manera segura a herramientas de clientes o aplicaciones:

mongosh --host <my-replica-set>/web1.example.com \
--port 30907 \
--tls \
--tlsCertificateKeyFile server.pem \
--tlsCAFile ca-pem

Si la conexión es exitosa, deberías ver:

Enterprise <my-replica-set> [primary]