Cluster fragmentado de vários clusters sem malha de serviço

Detalhes e considerações de exemplo

O exemplo acima não está pronto para produção. Observe os seguintes detalhes e considerações:

• O domínio no exemplo (kind-e2e-cluster-3.interconnected) é artificial e deve ser substituído pelo domínio acessível externamente adequado.

• A configuração usa TLS (não é possível expor externamente processos do MongoDB com segurança sem TLS) e autenticação x509. Isso pode ser configurado arbitrariamente de acordo com as necessidades. Consulte Criptografia e Autenticação apropriadas para saber mais.

• Os certificados TLS em cluster fragmentado devem ser emitidos para os seguintes componentes:

  • Cada conjunto de réplicas de shard

  • Conjunto de réplicas do servidor de configuração

  • mongos

• Cada certificado TLS (-cert segredos do tipo TLS, fornecidos manualmente ou emitidos por cert-manager) deve ser fornecido no cluster Kubernetes onde o Operador Kubernetes está em execução. A partir daí, o Operador Kubernetes replica automaticamente os recursos necessários (segredos -cert-pem gerados) para os outros clusters Kubernetes.

• Cada certificado TLS para cada componente deve conter todos os nomes de host de todos os processos do conjunto de réplicas desse componente. Por exemplo, o certificado emitido para o primeiro shard (índice 0) deve ter no campo SANs do cert os seguintes nomes de host (para cada cluster em que é implantado; o nome do pod segue a convenção 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 referência, todos os processos do cluster fragmentado implementado com o exemplo fornecido são configurados com os seguintes nomes 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: é definido com um objeto padrão {}.

  Isso significa que o Kubernetes Operator cria os serviços externos (serviços criados para cada pod que devem ser usados para rotear o tráfego externo) com os valores padrão:

  • type: LoadBalancer

  • ports: 27017, 27018 para fins de backup

• Dependendo da configuração do cluster e do controlador do balanceador de carga no cluster Kubernetes, o uso do tipo LoadBalancer para serviços externos fará com que o provisionamento de recursos do balanceador de carga para cada um dos processos nos clusters fragmentados. Isso pode levar ao grande número de recursos do LoadBalancer alocados. Na implantação mínima (1 mongos, conjunto de réplica do servidor de configuração do 3nó, 1 fragmento do 3conjunto de réplicas do nó) isso cria 7 serviços LoadBalancer.

  Para minimizar o número de recursos LoadBalancer criados, recomendamos que você configure o acesso externo com serviços ClusterIP, conforme mostrado no exemplo a seguir:

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

• Com cada processo (pod) tendo um serviço externo ClusterIP associado, é necessário criar um componente proxy de " ponto de entrada" externo para o cluster Kubernetes, que pode ser qualquer proxy (por exemplo HAProxy, Nginx) que suporta roteamento de passagem TLS.

  • O componente proxy deve ser distribuído em cada cluster do Kubernetes e exposto externamente em um nome de host definido para os componentes em cada cluster:

    • No exemplo acima, cada componente (mongos, servidor de configuração, shards) definido para kind-e2e-cluster-3 utiliza externalDomain: externalDomain: kind-e2e-cluster-3.interconnected

      Isto significa que o componente proxy deve ser configurado para receber todas as conexões para *.kind-e2e-cluster-3.interconnected.

      Cada conexão deve ser um nome de host seguindo a convenção de nomenclatura <pod-name>.<externalDomain>, por exemplo:

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

  • O componente de proxy deve ser configurado de forma que qualquer tráfego (em portas 27017 ou 27018) seja proxy (em um nível TCP, sem criptografar novamente o tráfego) para o respectivo serviço externo.

    • Por exemplo, para mdb-sharded-0-2-0-svc-external uma regra genérica pode ser usada ao configurar o envio como <pod-name>.kind-e2e-cluster-2.interconnected encaminhado para <pod-name>-mdb-sharded-0-2-0-svc-external.

• Observe que o externalDomain utilizado no exemplo é artificial. Ele deve ser substituído por um nome de domínio adequado.

• O operador implementa todos os processos nos clusters Kubernetes junto com todos os serviços externos necessários.

• Cada serviço externo em cada cluster deve receber tráfego externo nos domínios externos definidos. Até que a rede esteja totalmente configurada, o cluster não está configurado corretamente, porque, para que o replicaset seja configurado, os processos mongod precisam ser capazes de se conectar uns aos outros para fins de replicação.

• Ao usar domínios externos, toda a rede (para replicação e conectividade do MongoDB Agent com o MongoDB ) é roteada por padrão por meio de domínio externo, o que pode não ser eficiente. Uma das maneiras de melhorá-lo é configurar a rede ou a resolução DNS dentro do cluster para que os nomes de host externos dos Pods distribuídos nos mesmos clusters Kubernetes sejam resolvidos para o endereço IP local do cluster dos serviços externos.