Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
/ / /

Conectarse a un recurso multiclúster desde fuera de Kubernetes

El siguiente procedimiento describe cómo conectarse a un MongoDBMultiCluster recurso implementado 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.

El ajuste publishNotReadyAddresses indica que un agente que interactúa con los endpoints de este servicio debe ignorar el ready estado. Establecer publishNotReadyAddresses en true anula el comportamiento de la sonda de preparación configurada para el pod que aloja tu servicio.

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 puntos finales están listos incluso si las sondas de los pods que alojan los servicios para estos puntos finales indican que no están listos.

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

Tip

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

1
2

Proporcione valores para:

  • La SecretoTLS spec.security.certsSecretPrefix en.

  • El CA certificado personalizado en spec.security.tls.ca.

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 LoadBalancer externo para los pods de MongoDB en su implementación multinube de 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>

Un puerto para mongod.

publishNotReadyAddress

true

Especifica que registros DNS se crean incluso si el Pod no está listo. No configures false para ningún Pod de base de datos.

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

Por ejemplo, la siguiente configuración anula los valores predeterminados del servicio externo para configurar tu implementación de varios clústeres de Kubernetes para crear servicios NodePort que exponen 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 agregar valores al servicio o anular los valores predeterminados para un miembro del clúster, especifique:

Por ejemplo, el siguiente archivo configura su implementación de MongoDB de múltiples clústeres Kubernetes para crear servicios de balanceador de carga que exponen la implementación de MongoDB de múltiples clústeres Kubernetes para los miembros 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 utilizan los valores predeterminados de la configuración spec.externalAccess.

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

Agregue cada nombre DNS externo al certificado SAN.

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 tu clúster o del proveedor de nube, la dirección IP del servicio LoadBalancer es una dirección accesible externamente o un FQDN. Puedes utilizar la dirección IP o un FQDN para dirigir el tráfico de 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 en un conjunto de réplicas, especifique el certificado TLS y la CA para conectarse de forma segura a las herramientas o aplicaciones del cliente:

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]

Volver

Acceder a los recursos

En esta página