Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/ /

Conectar ao recurso Multi-Cluster de fora do Kubernetes

Nesta página

  • Pré-requisitos
  • Considerações
  • Procedimento

O procedimento a seguir descreve como conectar-se a um recurso do MongoDBMultiCluster distribuído no Kubernetes a partir de fora do cluster do Kubernetes.

Bancos de dados que executam o MongoDB 4.2.3 ou posterior permitem acessá-los fora do cluster Kubernetes.

Se você criar serviços personalizados que exijam acesso externo aos recursos personalizados do MongoDB implantados pelo Kubernetes Operator, e usar testes de prontidão no Kubernetes, defina a configuração publishNotReadyAddresses no Kubernetes como true.

A publishNotReadyAddresses configuração indica que um agente que interage com endpoints para este serviço deve desconsiderar o pronto do serviço estado. A publishNotReadyAddresses definição true como substitui o comportamento do teste de preparação configurado para o Pod que hospeda seu serviço.

Por padrão, a configuração publishNotReadyAddresses é definida como false. Nesse caso, quando os Pods que hospedam os recursos personalizados do MongoDB no Operador de Kubernetes perdem a conectividade com o Cloud Manager ou o Ops Manager, os testes de preparação configurados para esses Pods falham. No entanto, quando você define a configuração publishNotReadyAddresses como true:

  • O Kubernetes não desliga o serviço cuja análise de prontidão falha.

  • O Kubernetes considera todos os endpoints como prontos, mesmo que os testes dos Pods que hospedam os serviços desses endpoints indiquem que eles não estão prontos.

  • Os recursos personalizados do MongoDB ainda estão disponíveis para operações de leitura e gravação.

Dica

Veja também:

Para conectar-se ao seu conjunto de réplicas implantado pelo Kubernetes Operator com um recurso MongoDBMultiCluster de fora do cluster do Kubernetes:

1
2

Forneça valores para:

  • O segredoTLS em spec.security.certsSecretPrefix.

  • O certificado CA personalizado em spec.security.tls.ca.

3

Para se conectar à sua implantação de vários clusters Kubernetes a partir de um recurso externo, configure o spec.externalAccess configuração:

externalAccess: {}

Esta configuração instrui o Kubernetes Operador do a criar um LoadBalancer externo serviço para os MongoDB pods em suaKubernetesimplantação de -cluster. O serviço externo fornece um ponto de entrada para conexões externas. Adicionar esta configuração sem valores cria um serviço externo com os seguintes valores-padrão:

Campo
Valor
Descrição
Name
<pod-name>-svc-external
Nome do serviço externo. Não é possível alterar este valor.
Type
LoadBalancer
Cria um serviço LoadBalancer externo.
Port
<Port Number>
Uma porta para o mongod.
publishNotReadyAddress
true
Especifica que os registros DNS são criados mesmo que o Pod não esteja pronto. Não defina como false para nenhum pod de banco de dados.

Como opção, para adicionar valores ao serviço ou substituir os valores padrão, especifique:

Por exemplo, as configurações a seguir substituem os valores padrão do serviço externo para configurar seu sistema de clusters multikubernetes para criar serviços NodePort que expõem os pods 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

Dica

Para saber mais, consulte Anotações e ServiceSpec na documentação do Kubernetes.

4

Se você precisar definir as configurações de um membro específico do cluster, como quando estiver hospedando membros em diferentes fornecedor de nuvem, poderá substituir a especificação global.externalAccess configurações para um membro específico usando o spec.clusterSpecList.externalAccess.externalService configuração.

Para adicionar valores ao serviço ou substituir os valores padrão para um membro do cluster, especifique:

Por exemplo, o arquivo a seguir configura seu sistema deKubernetes cluster multi- MongoDB para criar serviços de balanceador de carga que expõem o sistema deKubernetes cluster multi- MongoDB para membros do cluster implantado no GKE (Google Kubernetes Engine) e Amazon Web Services EKS.

Observação

O exemplo a seguir não configura substituições, portanto, os serviços externos usam os valores padrão do spec.externalAccess configuração.

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

Adicione cada nome de DNS externo ao certificado SAN.

6

Em cada cluster, execute o seguinte comando para verificar se o Kubernetes Operator criou o serviço externo para sua implantação.

$ kubectl get services

O comando retorna uma lista de serviços semelhantes à seguinte saída. Para cada Pod de reconhecimento de data center no cluster, o Kubernetes cria um serviço externo chamado <pod-name>-<cluster-idx>-<pod-idx>-svc-external. Esse serviço é configurado de acordo com os valores e substituições que você fornece na especificação de serviço 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

Dependendo da configuração do cluster ou do fornecedor de serviços em nuvem, o endereço IP do serviço LoadBalancer é um endereço IP ou FQDN externamente acessível. Você pode usar o endereço IP ou FQDN para rotear o tráfego do seu domínio externo.

7

Configure os nomes de host e portas no spec.connectivity.replicaSetHorizons para os valores de serviço externo que você criou na etapa anterior.

Confirme se você especificou os nomes de host externos corretos. Os nomes de host externos devem corresponder aos nomes DNS dos nós de trabalho do Kubernetes. Eles podem ser quaisquer nós no cluster Kubernetes. Se o Pod for executado em outro nó, os nós do Kubernetes usarão roteamento 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: 6.0.0-ent"
8

Em cada cluster, execute este comando para aplicar o arquivo de conjunto de réplicas atualizado:

$ Kubectl apply -f <file_name.yaml>
9

No ambiente de desenvolvimento, para cada host em um conjunto de réplicas, execute o seguinte comando:

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

Observação

Não use o sinalizador --sslAllowInvalidCertificates em produção.

Na produção, para cada host em um conjunto de réplicas, especifique o certificado TLS e o CA para se conectar com segurança às ferramentas ou aplicativos do cliente:

mongosh --host <my-replica-set>/web1.example.com \
--port 30907 \
--tls \
--tlsCertificateKeyFile server.pem \
--tlsCAFile ca-pem

Se a conexão for bem-sucedida, você deverá ver:

Enterprise <my-replica-set> [primary]

Voltar

Acessar recursos