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

Detalles y consideraciones del 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 reemplazarse por el dominio adecuado al que se pueda acceder 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 fragmentado deben emitirse para los siguientes componentes:

  • Cada conjunto de réplicas de fragmentos

  • 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 de cada componente debe contener todos los nombres de host de todos los procesos del conjunto de réplicas de dicho componente. Por ejemplo, el certificado emitido para el primer fragmento (índice 0) debe incluir en el campo SAN los siguientes nombres de host (para cada clúster en el que se implementa; 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

• Como 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 se deben usar para enrutar el tráfico externo) con los valores predeterminados:

  • type: LoadBalancer

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

• Según la configuración del clúster y el controlador del balanceador de carga en el clúster de Kubernetes, el uso del tipo LoadBalancer para servicios externos generará el aprovisionamiento de recursos del balanceador de carga para cada proceso en los clústeres fragmentados. Esto podría generar una gran cantidad de recursos del LoadBalancer asignados. En la implementación mínima (1 mongos, conjunto de réplicas del servidor de configuración de 3nodos, 1 fragmento del conjunto de réplicas de 3nodos), esto crea 7 servicios del LoadBalancer.

  Para minimizar la cantidad de recursos LoadBalancer que se crean, recomendamos configurar 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

• Dado que cada proceso (pod) tiene un servicio externo ClusterIP asociado, es necesario crear un componente proxy de "punto de entrada" externo al clúster de Kubernetes, que puede ser cualquier proxy (por ejemplo, HAProxy, Nginx) que admita el enrutamiento de paso TLS.

  • 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, fragmentos) definido para kind-e2e-cluster-3 usa externalDomain: externalDomain: kind-e2e-cluster-3.interconnected

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

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

      Vaina de fragmentos: mdb-sharded-0-2-0.kind-e2e-cluster-2.interconnected (mdb-sharded-<shardIdx>-<clusterIdx>-<podIdx>

  • El componente proxy debe configurarse de manera que todo el tráfico (en los puertos 27017 o 27018) se envíe mediante proxy (a nivel TCP, sin volver a cifrar el tráfico) al servicio externo respectivo.

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

• Tenga en cuenta que el externalDomain utilizado en el ejemplo es artificial. Debe reemplazarse por un nombre de dominio adecuado.

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

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

• Al usar dominios externos, toda la red (para la replicación y la conectividad entre el Agente de MongoDB y MongoDB) se enruta por defecto a través de un dominio externo, lo que podría resultar ineficiente. Una forma de mejorarlo es configurar la red o la resolución DNS dentro del clúster para que los nombres de host externos de los pods implementados en los mismos clústeres de Kubernetes se resuelvan a la dirección IP local del clúster de los servicios externos.