Clúster fragmentado de varios clústeres sin malla de servicios

Detalles y consideraciones de ejemplo

El ejemplo anterior no está listo para producción. Tenga en cuenta los siguientes detalles y consideraciones:

• El dominio en el ejemplo (kind-e2e-cluster-3.interconnected) es artificial y debe ser reemplazado por el dominio correspondiente accesible externamente.

• La configuración utiliza TLS (no es posible exponer de forma segura los procesos externos de MongoDB sin TLS) y509 autenticación x. Esto se puede configurar arbitrariamente según las necesidades. Consulte la sección de Cifrado y Autenticación correspondiente para obtener más información.

• Los certificados TLS en el clúster segmentado deben emitirse para los siguientes componentes:

  • Cada set de réplicas de partición

  • Conjunto de réplicas del servidor de configuración

  • Mongos

• Cada certificado TLS (secretos -cert de tipo TLS, proporcionados manualmente o emitidos por cert-manager) debe proporcionarse en el clúster de Kubernetes donde se ejecuta el operador de Kubernetes. Desde allí, el operador de Kubernetes replica automáticamente los recursos necesarios (secretos -cert-pem generados) a los demás clústeres de Kubernetes.

• Cada certificado TLS para cada componente debe contener todos los nombres de host de todos los procesos del set de réplicas de ese componente. Por ejemplo, el certificado emitido para la primera partición (índice 0) debe tener en el campo SANs del certificado los siguientes nombres de host (para cada clúster en el que esté implementado; el nombre del pod sigue la convención mdb-sharded-<shardIdx>-<clusterIdx>-<podIdxInThisCluster>).

  • mdb-sharded-0-0-0.kind-e2e-cluster-1.interconnected

  • mdb-sharded-0-1-0.kind-e2e-cluster-2.interconnected

  • mdb-sharded-0-2-0.kind-e2e-cluster-3.interconnected

• Para referencia, todos los procesos del clúster fragmentado implementado con el ejemplo proporcionado están configurados con los siguientes nombres de host:

  mdb-sharded-0-0-0.kind-e2e-cluster-1.interconnected (shard-0)
  mdb-sharded-0-1-0.kind-e2e-cluster-2.interconnected (shard-0)
  mdb-sharded-0-2-0.kind-e2e-cluster-3.interconnected (shard-0)
  mdb-sharded-config-0-0.kind-e2e-cluster-1.interconnected (cs)
  mdb-sharded-config-1-0.kind-e2e-cluster-2.interconnected (cs)
  mdb-sharded-config-2-0.kind-e2e-cluster-3.interconnected (cs)
  mdb-sharded-mongos-0-0.kind-e2e-cluster-1.interconnected (mongos)
  mdb-sharded-mongos-1-0.kind-e2e-cluster-2.interconnected (mongos)
  mdb-sharded-mongos-2-0.kind-e2e-cluster-3.interconnected (mongos)

• Cada externalService: se define con un objeto predeterminado {}.

  Esto significa que el Operador de Kubernetes crea los Servicios Externos (servicios creados para cada pod que debería utilizarse para enrutar el tráfico externo a) con los valores por defecto:

  • type: LoadBalancer

  • ports: 27017, 27018 para fines de copia de seguridad

• Dependiendo de la configuración del clúster y del controlador del balanceador de carga en el clúster de Kubernetes, utilizar el tipo LoadBalancer para servicios externos provocará el provisionamineto de recursos de balanceador de carga para cada uno de los procesos en los clústeres fragmentados. Esto podría llevar a una gran cantidad de recursos LoadBalancer asignados. En la implementación mínima (1 mongos, set de réplicas del servidor de configuración de 3nodos, 1 partición de 3nodos en el set de réplicas) se crean 7 servicios LoadBalancer.

  Para minimizar la cantidad de recursos de LoadBalancer que se crean, recomendamos que configure el acceso externo con servicios ClusterIP, como se muestra en el siguiente ejemplo:

  - clusterName: kind-e2e-cluster-3
    externalAccess:
      externalDomain: kind-e2e-cluster-3.interconnected
      externalService:
        type: ClusterIP

• Con cada proceso (pod) teniendo un servicio externo ClusterIP asociado, necesitas crear un componente proxy de "punto de entrada" externo al clúster de Kubernetes, que puede ser cualquier proxy (por ejemplo, HAProxy, Nginx) que soporte enrutamiento TLS Passthrough.

  • El componente proxy debe implementarse en cada clúster de Kubernetes y exponerse externamente en un nombre de host definido para los componentes en cada clúster:

    • En el ejemplo anterior, cada componente (mongos, servidor de configuración, particiones) definido para kind-e2e-cluster-3 usa externalDomain: externalDomain: kind-e2e-cluster-3.interconnected

      Esto significa que el componente proxy debe estar configurado para recibir todas las conexiones a *.kind-e2e-cluster-3.interconnected.

      Cada conexión tendrá un nombre de host que siga la convención de nombres <pod-name>.<externalDomain>, por ejemplo:

      Partición pod: mdb-sharded-0-2-0.kind-e2e-cluster-2.interconnected (mdb-sharded-<shardIdx>-<clusterIdx>-<podIdx>

  • El componente proxy debe estar configurado de manera que cualquier tráfico (en los puertos 27017 o 27018) sea enrutado (a nivel TCP, sin re-encriptar el tráfico) al servicio externo respectivo.

    • Por ejemplo, para mdb-sharded-0-2-0-svc-external, puede utilizarse una regla genérica al configurar el envío como <pod-name>.kind-e2e-cluster-2.interconnected redirigido a <pod-name>-mdb-sharded-0-2-0-svc-external.

• Ten en cuenta que el externalDomain utilizado en el ejemplo es artificial. Debe ser reemplazado por un nombre de dominio apropiado.

• El operador implementa todos los procesos en los clústeres de Kubernetes junto con todos los servicios externos necesarios.

• Cada servicio externo en cada clúster debe recibir tráfico externo en los dominios externos definidos. Hasta que la red esté completamente configurada, el clúster no se configurará correctamente, porque para que el replicaset esté configurado, los procesos mongod deben poder conectarse entre sí para fines de replicación.

• Al utilizar dominios externos, toda la red (para replicación y para la conectividad de MongoDB Agent a MongoDB) se enruta por defecto a través del dominio externo, lo que puede no ser eficiente. Una de las formas de mejorarlo es configurar la red o la resolución de DNS dentro del clúster para que los nombres de host externos de los pods desplegados en los mismos clústeres de Kubernetes se resuelvan en la dirección IP local del clúster de los servicios externos.