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 posterior le permiten acceder a ellas 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.

La configuración publishNotReadyAddresses indica que un agente que interactúa con puntos finales para este servicio debe ignorar la configuración del servicio. Estado listo. Establecer publishNotReadyAddresses de a true anula el comportamiento de la sonda de preparación configurada para el pod que aloja su 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 sonda 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 todavía están disponibles para operaciones de lectura y escritura.

Tip

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

1
2

Proporcionar valores para:

  • El SecretoTLS spec.security.certsSecretPrefix en.

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

3

Para conectarse a su implementación de múltiples clústeres de Kubernetes desde un recurso externo, configure el ajuste spec.externalAccess:

externalAccess: {}

Esta configuración indica al operador de Kubernetes que cree un servicio LoadBalancer externo para los pods de MongoDB en su implementación de varios clústeres de Kubernetes. Este servicio externo proporciona un punto de entrada para las conexiones externas. Al agregar esta configuración sin valores, se crea un servicio externo con los siguientes valores predeterminados:

Campo
Valor
Descripción

Name

<pod-name>-svc-external

Nombre del servicio externo. No se puede cambiar este valor.

Type

LoadBalancer

Crea un servicio LoadBalancer externo.

Port

<Port Number>

Un puerto mongod para.

publishNotReadyAddress

true

Especifica que los registros DNS se crean incluso si el pod no está listo. No se establece en false para ningún pod de base de datos.

Opcionalmente, si necesita agregar valores al servicio o anular los valores predeterminados, especifique:

Por ejemplo, las siguientes configuraciones anulan los valores predeterminados del servicio externo para configurar su implementación de múltiples clústeres de Kubernetes para 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, consulte las anotaciones y ServiceSpec en la documentación de Kubernetes.

4

Si necesita configurar ajustes para un miembro específico del clúster, como cuando aloja miembros en diferentes proveedores de nube, puede anular la configuración global spec.externalAccess para un miembro específico mediante la configuración spec.clusterSpecList.externalAccess.externalService.

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 del clúster, el operador de Kubernetes crea un servicio externo llamado <pod-name>-<cluster-idx>-<pod-idx>-svc-external. Este servicio se configura según los valores y las anulaciones que se proporcionan 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

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

7

Establezca los nombres de host y los puertos en spec.connectivity.replicaSetHorizons con los valores de servicio externo que creó en el paso anterior.

Confirme que especificó los nombres de host externos correctos. Estos nombres deben coincidir con los nombres DNS de los nodos de trabajo de Kubernetes. Estos pueden ser cualquier nodo del clúster de Kubernetes. Si el pod se ejecuta en otro nodo, los nodos de Kubernetes utilizan el 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 conjunto de réplicas actualizado:

$ Kubectl apply -f <file_name.yaml>
9

En el entorno de desarrollo, para cada host de un conjunto de réplicas, ejecute el siguiente comando:

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

Nota

No utilice 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 se realiza correctamente, debería ver:

Enterprise <my-replica-set> [primary]

Volver

Recursos de acceso

En esta página