O recurso MongoDBMultiCluster define sua implantação do MongoDB de clusters multi-Kubernetes e fornece ao MongoDB Enterprise Kubernetes Operator as informações necessárias para criar ou atualizar seus clusters, sistema do Ops Manager, statefulSets, serviços e outros recursos do Kubernetes.
Exemplo
O exemplo a seguir mostra uma especificação de recurso para uma implantação do MongoDB em cluster multi-Kubernetes:
1 # This example provides statefulSet overrides per cluster. 2 3 apiVersion: mongodb.com/v1 4 kind: MongoDBMultiCluster 5 metadata: 6   name: multi-replica-set 7 spec: 8   version: 6.0.0-ent 9   type: ReplicaSet 10   duplicateServiceObjects: false 11   credentials: my-credentials 12   opsManager: 13     configMapRef: 14       name: my-project 15   clusterSpecList: 16     - clusterName: cluster1.example.com 17       members: 2 18       statefulSet: 19         spec: 20           template: 21             spec: 22               containers: 23                 # Example of custom sidecar containers. Remove it before using the file in production. 24                 - name: sidecar1 25                   image: busybox 26                   command: [ "sleep" ] 27                   args: [ "infinity" ] 28           # Use the following settings to override the default storage size of the "data" Persistent Volume. 29           volumeClaimTemplates: 30             - metadata: 31                 name: data 32               spec: 33                 resources: 34                   requests: 35                     storage: 1Gi 36     - clusterName: cluster2.example.com 37       members: 1 38       statefulSet: 39         spec: 40           template: 41             spec: 42               containers: 43                 # Example of custom sidecar containers. Remove it before using the file in production. 44                 - name: sidecar2 45                   image: busybox 46                   command: [ "sleep" ] 47                   args: [ "infinity" ] 48           volumeClaimTemplates: 49             - metadata: 50                 name: data 51               spec: 52                 resources: 53                   requests: 54                     storage: 1Gi 55     - clusterName: cluster3.example.com 56       members: 1 57       statefulSet: 58         spec: 59           template: 60             spec: 61               containers: 62                 # Example of custom sidecar containers. Remove it before using the file in production. 63                 - name: sidecar3 64                   image: busybox 65                   command: [ "sleep" ] 66                   args: [ "infinity" ] 67           volumeClaimTemplates: 68             - metadata: 69                 name: data 70               spec: 71                 resources: 72                   requests: 73                     storage: 1Gi 74 75 ... 
Configurações de MongoDBMultiCluster recursos necessárias
Esta seção descreve as configurações que você deve utilizar para seu recurso MongoDBMultiCluster .
- apiVersion
- Tipo: string - Versão do esquema de recursos do MongoDB Kubernetes. 
- kind
- Tipo: string - Tipo de recurso MongoDB Kubernetes para criar. Defina isso como - MongoDBMultiCluster.
- metadata.name
- Tipo: string - Nome do recurso Kubernetes MongoDB que você está criando. - Os nomes de recursos devem ter 44 caracteres ou menos. 
- spec.credentials
- Tipo: string - Nome do segredo que você criou como credenciais de autenticação da API do Ops Manager para o Operador do Kubernetes se comunicar com o Ops Manager. - No Ops Manager, o secret do Kubernetes que contém as credenciais precisa existir no mesmo namespace que o recurso que você deseja criar. - Importante- O operador gerencia alterações no segredo- O Operador Kubernetes rastreia quaisquer alterações no Segredo e reconcilia o estado do recurso - MongoDB.
- spec.type
- Tipo: string - Tipo de recurso MongoDB Kubernetes para criar. O único valor aceito para uma implantação do MongoDB em cluster multi-Kubernetes é ReplicaSet. 
- spec.version
- Tipo: string - Versão do MongoDB instalada para este recurso do - MongoDBMultiCluster.- Importante- Certifique-se de escolher uma versão compatível do MongoDB Server. - Versões compatíveis diferem dependendo da imagem base que o recurso do banco de dados MongoDB utiliza. 
MongoDBMultiCluster Configurações de recursos opcionais
MongoDBMultiCluster recursos podem usar as seguintes configurações:
- spec.additionalMongodConfig
- Tipo: collection - Opções de configuração adicionais para iniciar processos no MongoDB. - O Kubernetes Operator aceita todas as opções de configuração que a versão do MongoDB que você distribui pelo MongoDB Agent aceita, exceto que o Kubernetes Operator substitui os valores que você fornece para qualquer uma das seguintes opções: - net.port
- net.tls.certificateKeyFile
- net.tls.clusterFile
- replication.replSetName
- security.clusterAuthMode
- sharding.clusterRole
- storage.dbPath
- systemLog.destination
- systemLog.path
 - Para saber mais sobre as opções de configuração que o operador Kubernetes possui, consulte Configurações exclusivas do operador Kubernetes do MongoDB. - Para saber quais opções de configuração você pode usar, consulte Opções avançadas para implantações do MongoDB na documentação do Ops Manager. 
- spec.agent
- Tipo: collection - Configurações do MongoDB Agent para o recurso do MongoDB database. 
- spec.agent.startupOptions
- Tipo: collection - Configurações do MongoDB Agent com as quais você deseja iniciar o recurso de reconhecimento de data center MongoDB. - Você deve fornecer as configurações do MongoDB Agent como pares de valor-chave. Os valores devem ser strings. Para obter uma lista das configurações do MongoDB Agent compatíveis, consulte: - Configurações do MongoDB Agent para projetos do Cloud Manager. 
- Configurações do MongoDB Agent para a versão do Ops Manager que você distribuiu com o Kubernetes Operator. 
 
- spec.backup
- Tipo: collection - O contêiner de coleta para spec.backup.mode, que permite backups contínuos para recursos MongoDB no Kubernetes Operator. 
- spec.backup.assignmentLabels
- Tipo: array - Uma lista de etiquetas de atribuição para os processos do Serviço de Backup Daemon . Use rótulos de atribuição para identificar se processos específicos de daemon de backup estão associados a projetos específicos. Se você definir rótulos de atribuição usando o operador Kubernetes , os valores definidos no arquivo de configuração do Kubernetes para rótulos de atribuição substituirão os valores definidos na UI do MongoDB Ops Manager . Os rótulos de atribuição que você não define usando o Kubernetes Operator continuam a usar os valores definidos na interface do usuário do MongoDB Ops Manager . 
- spec.backup.autoTerminateOnDeletion
- Tipo: booleano - Sinalizador que indica se o Kubernetes Operator interrompe e encerra o backup quando você exclui um recurso - MongoDBMultiCluster. O valor padrão é- false. Definir este sinalizador como- trueé recomendado se você deseja excluir o recurso- MongoDBMultiClusterenquanto a configuração spec.backup.mode está definida como- enabled.
- spec.backup.encryption
- Tipo: objeto - Objeto que contém as definições de configuração de criptografia de backup. 
- spec.backup.encryption.kmip
- Tipo: objeto - Objeto que contém as definições de configuração de criptografia de backup KMIP. Para saber mais, consulte Configurar o KMIP Backup Encryption para o Ops Manager. 
- spec.backup.encryption.kmip.client
- Tipo: objeto - Objeto que contém as definições de configuração do cliente de criptografia de backup KMIP. 
- spec.backup.mode
- Tipo: string - Habilita backups contínuos para um recurso do - MongoDBMultiCluster. Os valores possíveis são- enabled,- disablede- terminated.- Observação- A configuração spec.backup.mode depende do backup habilitado no MongoDB Ops Manager e exige que o - spec.backup.enabledvalor na MongoDB Ops Manager especificação de recursos do seja definido como- true.- Depois de ativar backups contínuos para seu recurso do MongoDB com spec.backup.mode, você pode verificar o status da cópia de segurança. 
- spec.backup.snapshotSchedule
- Tipo: collection - Container de collection para configurações de agendamento de snapshots para backups contínuos de recursos do MongoDB no Kubernetes Operator. 
- spec.backup.snapshotSchedule.dailySnapshotRetentionDays
- Tipo: número - Número de dias para manter snapshots diários. Você pode definir um valor entre - 1e- 365. Definir o valor em- 0desabilita esta regra.
- spec.backup.snapshotSchedule.fullIncrementalDayOfWeek
- Tipo: string - Dia da semana em que o Ops Manager tira um snapshot completo. Essa configuração garante um backup completo recente. O Ops Manager define o valor-padrão como - SUNDAY.
- spec.backup.snapshotSchedule.monthlySnapshotRetentionMonths
- Tipo: número - Número de meses para manter snapshots mensais. Você pode definir um valor entre - 1e- 36. Definir o valor em- 0desabilita esta regra.
- spec.backup.snapshotSchedule.pointInTimeWindowHours
- Tipo: número - Número de horas no passado para as quais você pode criar um snapshot de ponto no tempo. 
- spec.backup.snapshotSchedule.referenceHourOfDay
- Tipo: número - Hora do dia UTC para agendar snapshots usando um relógio em formato 24 horas. Você pode definir um valor entre - 0e- 23.
- spec.backup.snapshotSchedule.referenceMinuteOfHour
- Tipo: número - Minuto da hora UTC para agendar snapshots. Você pode definir um valor entre - 0e- 59.
- spec.backup.snapshotSchedule.snapshotIntervalHours
- Tipo: número - Número de horas entre snapshots. Você pode definir um valor de - 6,- 8,- 12ou- 24.
- spec.backup.snapshotSchedule.snapshotRetentionDays
- Tipo: número - Número de dias para manter snapshots recentes. Você pode definir um valor entre - 2e- 5.
- spec.backup.snapshotSchedule.weeklySnapshotRetentionWeeks
- Tipo: número - Número de semanas para manter snapshots semanais. Você pode definir um valor entre - 1e- 52. Definir o valor em- 0desabilita esta regra.
- spec.cloudManager.configMapRef.name
- Tipo: string - Alias para spec.opsManager.configMapRef.name. 
- spec.clusterSpecList
- Tipo: collection - Lista de especificações para cada cluster do Kubernetes em um recurso do - MongoDBMultiCluster.
- spec.clusterSpecList.clusterName
- Tipo: string - Nome do cluster onde o MongoDB Enterprise Kubernetes Operator agenda o StatefulSet. Quando o Operador Kubernetes implementa este recurso - MongoDBMultiCluster, ele cria uma conta de serviço. Esse nome é o que a conta de serviço no cluster do operador usa para se comunicar com os clusters de volume de trabalho.
- spec.clusterSpecList.externalAccess.externalDomain
- Tipo: string - Um domínio externo usado para expor externamente seu sistema de conjunto de réplicas. - Por padrão, cada nó do conjunto de réplicas utiliza o FQDN ( - *.svc.cluster.local) do Pod do Kubernetes como o nome de host padrão. No entanto, se você adicionar um domínio externo a esta configuração, o conjunto de réplicas usará um nome de host que é um subdomínio do domínio especificado. Este nome de host tem o seguinte formato:- <replica-set-name>-<cluster-idx>-<pod-idx>.<externalDomain>- Por exemplo: - multi-replica-set-0-1.cluster-0.example.com- Depois de implantar o conjunto de réplicas com essa configuração, o Kubernetes Operator usa o nome do host com domínio externo para substituir o - processes[n].hostnamecampo na MongoDB Ops Manager configuração de automação do . Em seguida, o MongoDB Agent utiliza este nome de host para se conectar ao- mongod.- Para especificar outros nomes de host para conectar ao conjunto de réplica, você pode utilizar a configuração do - spec.connectivity.replicaSetHorizons. No entanto, as seguintes conexões ainda usam o nome de host com o domínio externo:- AVISO: a especificação desse campo altera a forma como o MongoDB Ops Manager registra os processos - mongod. Você pode especificar esse campo somente para novas implantações de conjunto de réplicas começando no Kubernetes Operator versão 1.19. Você não pode alterar o valor desse campo ou de qualquer- processes[n].hostnamecampo na MongoDB Ops Manager automation configuration do para uma implantação de replica set em execução.- Importante- Use essa configuração somente ao implantar um conjunto de réplicas de sistema do MongoDB de cluster multi-Kubernetes sem uma interface de serviço. Consulte Implantar conjuntos de réplicas em um cluster multi-Kubernetes sem uma interface de serviço. 
- spec.clusterSpecList.externalAccess.externalService
- Tipo: collection - Configuração para expor externamente um cluster específico em sua implantação do MongoDB de cluster multi-Kubernetes. Essas configurações substituem o spec.externalAccess.externalService global configurações. - Ao definir o spec.externalAccess configuração, o Kubernetes Operator automaticamente cria um serviço de balanceador de carga externa com valores padrão. Você pode substituir determinados valores ou adicionar novos valores dependendo de suas necessidades. Por exemplo, se você deseja criar serviços NodePort e não precisa de um balanceador de carga , será necessário configurar substituições em sua especificação do Kubernetes: - externalAccess: - externalService: - annotations: - # cloud-specific annotations for the service - spec: - type: NodePort # default is LoadBalancer - # you can specify other spec overrides if necessary - Para obter mais informações sobre a especificação do Kubernetes, consulte ServiceSpec na documentação do Kubernetes. 
- spec.clusterSpecList.externalAccess.externalService.annotations
- Tipo: collection - Pares de valores-chave que permitem adicionar definições de configuração específicas do provedor de nuvem a um cluster específico em seu sistema do MongoDB de vários clusters Kubernetes. Esta configuração substitui a configuração global, spec.externalAccess.externalService.annotations. Para saber mais, consulte as anotações e a documentação do seu provedor de nuvem Kubernetes. - Você pode usar anotações para especificar valores de espaço reservado para serviços externos usados por sistemas do Kubernetes Operator. O operador Kubernetes substitui automaticamente estes valores pelos valores corretos, conforme descrito na tabela a seguir. O uso de espaços reservados permite fornecer anotações específicas em cada serviço para um Pod específico. ValorDescrição- {resourceName}- Igual a - metadata.name.- {namespace}- Igual a - metadata.namespace.- {podIndex}- Índice do Pod atribuído pelo StatefulSet e direcionado pelo serviço externo atual. - {podName}- Igual a - {resourceName}-{clusterIndex}-{podIndex}.- {clusterName}- O nome do cluster atual definido em spec.clusterSpecList.clusterName. - {clusterIndex}- O índice atribuído inicialmente pelo Operador Kubernetes para o nome do cluster atual definido em spec.clusterSpecList.clusterName. - Esse valor pode não refletir a ordem dos clusters de membros definidos em spec.clusterSpecList. Embora você possa alterar a ordem dos clusters de membros em spec.clusterSpecList, o Operador Kubernetes ainda usa o índice atribuído inicialmente para o nome do cluster atual. - {statefulSetName}- O StatefulSet. Igual a - {resourceName}-{clusterIndex}.- {externalServiceName}- Nome gerado do serviço externo, com base nos valores de espaço reservado que você especificou. Igual a - {resourceName}-{clusterIndex}-{podIndex}-svc-external.- {mongodProcessDomain}- O nome de domínio do servidor que está hospedando o processo mongod. Igual a spec.externalAccess.externalDomain se especificado. Caso contrário, igual ao domínio usado para o - mongodprocesso FQDN.- Por exemplo, para o nome de host do processo - mdb-rs-1.example.com,- example.comé o nome do domínio.- {mongodProcessFQDN}- O nome de host do processo - mongoddefinido na configuração de automação.- O nome do host do processo depende da sua configuração de sistema. Se você configurou seu sistema do MongoDB em clusters multi-Kubernetes para usar domínios externos, como para um sistema sem Service Mesh, o nome do host do processo usa o seguinte formato: - {resourceName}-{clusterIndex}-{podIndex}.{mongodProcessDomain}- Por exemplo: - mdb-rs-0-1.example.com- Se o seu sistema não utilizar domínios externos, o nome do host do processo utilizará o seguinte formato: - {resourceName}-{clusterIndex}-{podIndex}-svc.{namespace}.svc.cluster.local- Por exemplo: - mdb-rs-1-svc.ns.svc.cluster.local- Observação- Você deve usar apenas valores de espaço reservado conhecidos, conforme especificado na tabela, e garantir que seus espaços reservados não usem valores vazios ou nulos. Caso contrário, o Kubernetes Operator retorna um erro. Por exemplo, você pode encontrar a seguinte mensagem de erro: - error replacing placeholders in map with key=external-dns.alpha.kubernetes.io/hostname, value={resourceName}-{podIndex}-{unknownPlaceholder}.{clusterName}-{clusterIndex}.example.com: missing values for the following placeholders: {clusterName}, {clusterIndex}, {unknownPlaceholder}`` - Exemplo- O exemplo a seguir especifica os espaços reservados - {resourceName},- {podIndex}e- {namespace}:- apiVersion: mongodb.com/v1 - kind: MongoDB - metadata: - name: mdb-rs - namespace: ns - spec: - replicas: 3 - externalAccess: - externalService: - annotations: - external-dns.alpha.kubernetes.io/hostname: {resourceName}-{podIndex}-{namespace}.example.com - O Operador do Kubernetes preenche automaticamente as anotações para os serviços externos com base no valor apropriado para cada espaço reservado. Por exemplo: - mdb-rs-0-svc-external: - annotations: - external-dns.alpha.kubernetes.io/hostname: mdb-rs-0-ns.example.com - mdb-rs-1-svc-external: - annotations: - external-dns.alpha.kubernetes.io/hostname: mdb-rs-1-ns.example.com - mdb-rs-2-svc-external: - annotations: - external-dns.alpha.kubernetes.io/hostname: mdb-rs-2-ns.example.com 
- spec.clusterSpecList.externalAccess.externalService.spec
- Tipo: collection - Configuração do ServiceSpec. Para saber mais, consulte spec.clusterSpecList.externalAccess.externalService. 
- spec.clusterSpecList.memberConfig
- Tipo: collection - Especificação para cada conjunto de réplicas MongoDB e seus membros em sua implantação do MongoDB de multikubernetes cluster. - The order of the elements in the object for each replica set must reflect the order of members in the replica set. Por exemplo, o primeiro elemento afeta o Pod no índice - 0, o segundo elemento afeta o índice- 1, e assim por diante.- Exemplo- Considere o seguinte exemplo de especificação para um sistema MongoDB de cluster multi-Kubernetes com três conjuntos de réplicas: - apiVersion: mongodb.com/v1 - kind: MongoDBMultiCluster - metadata: - name: multi-replica-set - spec: - version: 6.0.0-ent - type: ReplicaSet - duplicateServiceObjects: false - credentials: my-credentials - opsManager: - configMapRef: - name: my-project - clusterSpecList: - - clusterName: cluster1.example.com - members: 2 - memberConfig: - - votes: 1 - priority: "0.5" - tags: - tag1: "value1" - environment: "prod" - - votes: 1 - priority: "1.5" - tags: - tag2: "value2" - environment: "prod" - - clusterName: cluster2.example.com - members: 1 - memberConfig: - - votes: 1 - priority: "0.5" - tags: - tag1: "value1" - environment: "prod" - - clusterName: cluster3.example.com - members: 1 - memberConfig: - - votes: 1 - priority: "0.5" - tags: - tag1: "value1" - environment: "prod" 
- spec.clusterSpecList.memberConfig.priority
- Tipo: string - Número que indica a probabilidade relativa de um nó do conjunto de réplicas do MongoDB se tornar o primário. - Para aumentar a probabilidade relativa de que um nó do conjunto de réplicas se torne o primary, especifique um valor de - prioritymais alto.
- Para diminuir a probabilidade relativa de que um nó do conjunto de réplicas se torne o primary, especifique um valor de - prioritymais baixo.
 - Por exemplo, um nó com uma - memberConfig.priorityde- 1.5tem mais probabilidade do que um nó com uma- memberConfig.priorityde- 0.5de se tornar o primary.- Um nó com um - memberConfig.priorityde- 0não está qualificado para se tornar o primary. Para saber mais, consulte Priority do nó.
- spec.clusterSpecList.memberConfig.tags
- Tipo: mapa - Mapa de tags de conjuntos de réplicas para direcionar operações de leitura e gravação para nós específicos do seu conjunto de réplicas MongoDB. 
- spec.clusterSpecList.memberConfig.votes
- Tipo: número - Determina se um nó do conjunto de réplicas do MongoDB pode votar em uma eleição. Defina como - 1para permitir que o membro vote. Defina como- 0para excluir o membro de uma eleição.
- spec.clusterSpecList.members
- Tipo: número - Número de membros no conjunto de réplicas MongoDB. 
- spec.clusterSpecList.service
- Tipo: string - Padrão: <resource_name>+"-service" - Nome do serviço Kubernetes que você deseja criar ou usar para um StatefulSet. Se um serviço com este nome já existir, o MongoDB Enterprise Kubernetes Operator não o excluirá nem recriará. Esta configuração permite que você crie seus próprios serviços personalizados e permite que o operador Kubernetes os reutilize. 
- spec.clusterSpecList.statefulSet.spec
- Tipo: collection - Fornece a configuração para a substituição do StatefulSet para cada um dos StatefulSets do cluster em um sistema MongoDB de cluster multi-Kubernetes. Para definir a configuração global que se aplica a todos os clusters em sua implantação do MongoDB de multi-Kubernetes cluster, consulte spec.statefulSet.spec. - Esta configuração se aplica somente a tipos de recurso de conjunto de réplicas em sistemas do MongoDB de clusters multikubernetes. 
- spec.connectivity.replicaSetHorizons
- Tipo: collection - Permite fornecer diferentes configurações de DNS para aplicativos de cliente e os MongoDB Agents. O Kubernetes Operator usa DNS de horizonte dividido para nós de conjuntos de réplicas. Esta funcionalidade permite uma comunicação dentro do cluster do Kubernetes e de fora do Kubernetes. - Você pode adicionar diversos mapeamentos externos por host. - Observação- Certifique-se de que cada valor nesta array é único. 
- Certifique-se de que o número de entradas nesta array corresponda ao valor fornecido em spec.clusterSpecList.members. 
- Forneça um valor para o spec.security.certsSecretPrefix configurando para habilitar o TLS. Este método para usar horizontes divididos requer a extensão MongoDB Server Name Indication do protocolo TLS . 
 - Neste exemplo, os clientes se comunicam com o conjunto de réplicas usando o horizonte de - example-website.- 15 - security: - 16 - tls: - 17 - enabled: true - 18 - connectivity: - 19 - replicaSetHorizons: - 20 - - "example-website": "web1.example.com:30907" - 21 - - "example-website": "web2.example.com:32350" - 22 - - "example-website": "web3.example.com:31185" - 23 - ... 
- spec.duplicateServiceObjects
- Tipo: booleano - Padrão: true - Especifica se o Operador Kubernetes duplica um objeto de rede de serviço do Pod em cada cluster para permitir a resolução de DNS. Defina como - falsese você configurar um proxy DNS para sua tela de serviço. Por exemplo, consulte Proxy de DNS na documentação do Istio.
- spec.externalAccess
- Tipo: collection - Especificação para expor sua implantação do MongoDB de cluster multi-Kubernetes para conexões externas. Para saber como se conectar ao MongoDB deployment de seu cluster multi-Kubernetes de fora do cluster Kubernetes, consulte Como conectar a recursos de vários clusters de fora do Kubernetes. - Essas configurações se aplicam a serviços em todos os clusters. Para substituir essas configurações globais em um cluster específico, use spec.clusterSpecList.externalAccess.externalService. - Se você adicionar - spec.externalAccess, o Kubernetes Operator criará um serviço externo para cada Pod em um conjunto de réplicas. Os serviços externos fornecem um ponto de entrada externo para cada Pod do banco de dados MongoDB em um cluster. Cada serviço externo tem seletores que relacionam o serviço externo a um Pod específico.- Se você adicionar esta configuração sem um valor, o Kubernetes Operator criará um serviço externo com os seguintes valores padrão: CampoValorDescriçã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 registros DNS são criados mesmo que o Pod não esteja pronto. Não defina como - falsepara nenhum pod de banco de dados .- Observação- Se você configurar spec.clusterSpecList.externalAccess.externalDomain, o serviço externo adicionará outra porta ( - Port Number + 1) para backups.
- spec.externalAccess.externalService
- Tipo: collection - Especificação para substituir os valores padrão em - spec.externalAccess.- Ao definir o spec.externalAccess configuração, o Kubernetes Operator automaticamente cria um serviço de balanceador de carga externa com valores padrão. Você pode substituir determinados valores ou adicionar novos valores dependendo de suas necessidades. Por exemplo, se você deseja criar serviços NodePort e não precisa de um balanceador de carga , será necessário configurar substituições em sua especificação do Kubernetes: - externalAccess: - externalService: - annotations: - # cloud-specific annotations for the service - spec: - type: NodePort # default is LoadBalancer - # you can specify other spec overrides if necessary - Para obter mais informações sobre a especificação do Kubernetes, consulte ServiceSpec na documentação do Kubernetes. 
- spec.externalAccess.externalService.annotations
- Tipo: collection - Pares de valores-chave que permitem adicionar definições de configuração específicas do provedor de nuvem a todos os clusters em seu sistema do MongoDB de vários clusters Kubernetes. Para substituições específicas do cluster, consulte spec.clusterSpecList.externalAccess.externalService.annotations. Para saber mais, consulte as anotações e a documentação do provedor de nuvem que você usa para os sistemas do Kubernetes. - Você pode usar anotações para especificar valores de espaço reservado para serviços externos usados por sistemas do Kubernetes Operator. O operador Kubernetes substitui automaticamente estes valores pelos valores corretos, conforme descrito na tabela a seguir. O uso de espaços reservados permite fornecer anotações específicas em cada serviço para um Pod específico. ValorDescrição- {resourceName}- Igual a - metadata.name.- {namespace}- Igual a - metadata.namespace.- {podIndex}- Índice do Pod atribuído pelo StatefulSet e direcionado pelo serviço externo atual. - {podName}- Igual a - {resourceName}-{clusterIndex}-{podIndex}.- {clusterName}- O nome do cluster atual definido em spec.clusterSpecList.clusterName. - {clusterIndex}- O índice atribuído inicialmente pelo Operador Kubernetes para o nome do cluster atual definido em spec.clusterSpecList.clusterName. - Esse valor pode não refletir a ordem dos clusters de membros definidos em spec.clusterSpecList. Embora você possa alterar a ordem dos clusters de membros em spec.clusterSpecList, o Operador Kubernetes ainda usa o índice atribuído inicialmente para o nome do cluster atual. - {statefulSetName}- O StatefulSet. Igual a - {resourceName}-{clusterIndex}.- {externalServiceName}- Nome gerado do serviço externo, com base nos valores de espaço reservado que você especificou. Igual a - {resourceName}-{clusterIndex}-{podIndex}-svc-external.- {mongodProcessDomain}- O nome de domínio do servidor que está hospedando o processo mongod. Igual a spec.externalAccess.externalDomain se especificado. Caso contrário, igual ao domínio usado para o - mongodprocesso FQDN.- Por exemplo, para o nome de host do processo - mdb-rs-1.example.com,- example.comé o nome do domínio.- {mongodProcessFQDN}- O nome de host do processo - mongoddefinido na configuração de automação.- O nome do host do processo depende da sua configuração de sistema. Se você configurou seu sistema do MongoDB em clusters multi-Kubernetes para usar domínios externos, como para um sistema sem Service Mesh, o nome do host do processo usa o seguinte formato: - {resourceName}-{clusterIndex}-{podIndex}.{mongodProcessDomain}- Por exemplo: - mdb-rs-0-1.example.com- Se o seu sistema não utilizar domínios externos, o nome do host do processo utilizará o seguinte formato: - {resourceName}-{clusterIndex}-{podIndex}-svc.{namespace}.svc.cluster.local- Por exemplo: - mdb-rs-1-svc.ns.svc.cluster.local- Observação- Você deve usar apenas valores de espaço reservado conhecidos, conforme especificado na tabela, e garantir que seus espaços reservados não usem valores vazios ou nulos. Caso contrário, o Kubernetes Operator retorna um erro. Por exemplo, você pode encontrar a seguinte mensagem de erro: - error replacing placeholders in map with key=external-dns.alpha.kubernetes.io/hostname, value={resourceName}-{podIndex}-{unknownPlaceholder}.{clusterName}-{clusterIndex}.example.com: missing values for the following placeholders: {clusterName}, {clusterIndex}, {unknownPlaceholder}`` - Exemplo- O exemplo a seguir especifica os espaços reservados - {resourceName},- {podIndex}e- {namespace}:- apiVersion: mongodb.com/v1 - kind: MongoDB - metadata: - name: mdb-rs - namespace: ns - spec: - replicas: 3 - externalAccess: - externalService: - annotations: - external-dns.alpha.kubernetes.io/hostname: {resourceName}-{podIndex}-{namespace}.example.com - O Operador do Kubernetes preenche automaticamente as anotações para os serviços externos com base no valor apropriado para cada espaço reservado. Por exemplo: - mdb-rs-0-svc-external: - annotations: - external-dns.alpha.kubernetes.io/hostname: mdb-rs-0-ns.example.com - mdb-rs-1-svc-external: - annotations: - external-dns.alpha.kubernetes.io/hostname: mdb-rs-1-ns.example.com - mdb-rs-2-svc-external: - annotations: - external-dns.alpha.kubernetes.io/hostname: mdb-rs-2-ns.example.com 
- spec.externalAccess.externalService.spec
- Tipo: collection - Configuração do ServiceSpec. Para saber mais, consulte spec.externalAccess.externalService. 
- spec.featureCompatibilityVersion
- Tipo: número - Limita as alterações aos dados que ocorrem com uma atualização para uma nova versão principal. Isso permite que você faça o downgrade para a versão principal anterior. Para saber mais sobre compatibilidade de funcionalidades, consulte - setFeatureCompatibilityVersionno Manual do MongoDB.
- spec.logLevel
- Tipo: string - Configura o nível de registro do agente de automação dentro do Pod. Os valores aceitos incluem: - DEBUG
- INFO
- WARN
- ERROR
- FATAL
 
- spec.opsManager.configMapRef.name
- Tipo: string - Nome do ConfigMap com a configuração de conexão do Cloud Manager ou Ops Manager. A configuração spec.cloudManager.configMapRef.name é um alias para essa configuração e pode ser usada em seu lugar. - Esse valor deve existir no mesmo namespace que o recurso que você deseja criar. - Importante- O operador gerencia alterações no ConfigMap- O Kubernetes Operator acompanha todas as alterações no ConfigMap e reconcilia o estado do recurso do - MongoDB.
- spec.persistent
- Tipo: booleano - Padrão: true - AVISO: conceda aos seus contêineres permissão para gravar no Volume Persistente. O Operador Kubernetes define - fsGroup = 2000,- runAsUser = 2000e- runAsNonRoot = trueem- securityContext. O Kubernetes Operator define- fsgroupcomo- runAsUserpara tornar o volume gravável para um usuário que executa o processo principal no container. Para saber mais, consulte Configurar um contexto de segurança para um Pod ou Contêiner e a discussão relacionada na documentação do Kubernetes. Se a reimplementação do recurso não corrigir os problemas com o Volume Persistente, entre em contato com o Suporte do MongoDB.- Se você não usar Volumes persistentes, os gráficos Disk Usage e Disk IOPS não poderão ser exibidos na guia Processes na página Deployment ou na página Metrics ao revisar os dados dessa implementação. 
- spec.security.authentication
- Tipo: collection - Especificações de autenticação para a implementação do MongoDB de clusters multikubernetes. 
- spec.security.authentication.agents
- Tipo: collection - Configuração de autenticação do MongoDB Agent para o projeto do Cloud Manager ou Ops Manager. 
- spec.security.authentication.agents.automationLdapGroupDN
- Tipo: string - O Nome Distinto (DN) do grupo LDAP ao qual o usuário do MongoDB Agent pertence. - Esta configuração é necessária se: - spec.security.authentication.ldap.authzQueryTemplate está presente, e 
- spec.security.authentication.agents.mode é - LDAPou- X509.
 
- spec.security.authentication.agents.automationPasswordSecretRef
- Tipo: collection - Detalhes do segredo que contém a senha para o spec.security.authentication.agents.automationUserName usuário. - Esta configuração é necessária se spec.security.authentication.agents.mode for - LDAP.
- spec.security.authentication.agents.automationPasswordSecretRef.key
- Tipo: string - Digite o spec.security.authentication.agents.automationPasswordSecretRef.name segredo que contém a senha do usuário em spec.security.authentication.agents.automationUserName. - Esta configuração é necessária se spec.security.authentication.agents.mode for - LDAP.
- spec.security.authentication.agents.automationPasswordSecretRef.name
- Tipo: string - Nome do segredo que contém a senha para o spec.security.authentication.agents.automationUserName usuário. Você deve criar este segredo no mesmo namespace para o qual distribuirá o operador Kubernetes: - kubectl create secret generic ldap-agent-user \ - --from-literal="password=<password>" -n <metadata.namespace> - Esse segredo deve conter uma chave cujo valor corresponda à senha do especificador.security.authentication.agents.automationUserName usuário em seu sistema de LDAP. - Esta configuração é necessária se spec.security.authentication.agents.mode for - LDAP.
- spec.security.authentication.agents.automationPasswordSecretRef.optional
- Tipo: booleano - Especifica se estas opções são obrigatórias ou opcionais: 
- spec.security.authentication.agents.automationUserName
- Tipo: string - Nome do usuário que os MongoDB Agents usam para interagir com sua deployment do MongoDB de vários Kubernetes clusters. O nome de usuário é mapeado para um Nome Distinto (DN) LDAP de acordo com spec.security.authentication.ldap.userToDNMapping. O DN resultante precisa existir em seu sistema de LDAP. - Esta configuração é necessária se spec.security.authentication.agents.mode for - LDAP.
- spec.security.authentication.agents.clientCertificateSecretRef.name
- Tipo: string - Padrão: agente-certs - Especifica o secreto que contém o certificado TLS do agente MongoDB. - Este segredo deve conter a chave - mms-automation-agent-pem. O valor dessa chave deve ser um certificado TLS que possa ser validado pelo servidor.- Você deve criar este segredo no mesmo namespace para o qual distribuirá o operador Kubernetes: - kubectl create secret generic agent-certs \ - --from-file=mms-automation-agent-pem=<automation-cert.pem> \ - --namespace=<metadata.namespace> 
- spec.security.authentication.enabled
- Tipo: booleano - Padrão: false - Especifica se a autenticação está habilitada no projeto do Cloud Manager ou MongoDB Ops Manager . Se configurado para , você deverá configurar um mecanismo de autenticação em - true.- Importante- O Kubernetes Operator managed a autenticação para esse recurso MongoDB se você incluir essa configuração, mesmo que ela esteja definida como - false. Você não pode configurar a autenticação para esse recurso usando a interface de usuário ou as API do Cloud Manager ou do Ops Manager enquanto essa configuração existir na especificação do recurso.- Omita esta configuração se quiser managed a autenticação usando a interface de usuário ou as API do Cloud Manager ou do Ops Manager. 
- spec.security.authentication.agents.mode
- Tipo: string - O mecanismo de autenticação que os MongoDB Agents de seu sistema do MongoDB de cluster multi-Kubernetes usam. Os valores válidos são - SCRAM,- SCRAM-SHA-1,- MONGODB-CR,- X509e- LDAP. O valor especificado também deve estar presente em spec.security.authentication.modes. Recomendamos- SCRAM-SHA-256 (SCRAM)em vez- SCRAM-SHA-1. Se você especificar- SCRAM-SHA-1, você também deverá especificar- MONGODB-CR.- Esta configuração é necessária se você especificou mais de um valor para spec.security.authentication.modes. 
- spec.security.authentication.ignoreUnknownUsers
- Tipo: booleano - Padrão: false - Determina se você pode modificar usuários de banco de dados que não foram configurados por meio do Kubernetes Operator nem da interface de usuário do Cloud Manager ou do Ops Manager. - Para gerenciar usuários do banco de dados diretamente pelo - mongodou- mongos, configure para- true.
- spec.security.authentication.internalCluster
- Tipo: string - Especifica se a autenticação interna do cluster X.509 está habilitada. - Para habilitar a autenticação de cluster interno X.509, defina como - "X509". Isso requer a especificação das seguintes configurações:- O operador Kubernetes aceita os seguintes valores: - ["X509"]: a autenticação interna do cluster X.509 está habilitada.
- ""ou omitida: a autenticação interna do cluster não está habilitada.
 - Importante- Depois de habilitar a autenticação interna do cluster, não será possível desabilitá-la. 
- spec.security.authentication.ldap
- Tipo: collection - Necessário para a autenticação LDAP. - Configura a autenticação LDAP para o projeto do Cloud Manager ou MongoDB Ops Manager . Para habilitar a autenticação LDAP , configure spec.security.authentication.modes para - ["LDAP"].
- spec.security.authentication.ldap.authzQueryTemplate
- Tipo: string - Necessário para a autorização LDAP. - Um modelo de URL de query com formatação LDAP RFC4515 e RFC4516 executado pelo MongoDB para obter os grupos LDAP aos quais o usuário pertence. A query é relativa ao host ou hosts especificados no - spec.security.authentication.ldap.servers. Você pode utilizar os seguintes tokens no modelo:- {USER}
- Substitui o nome de usuário autenticado, ou o nome de usuário transformed, na query LDAP.
 
- {PROVIDED_USER}
- Substitui o nome de usuário fornecido, antes da autenticação ou transformação LDAP, na query LDAP. (Available starting in MongoDB version 4.2).
 
 - Para obter mais detalhes, consulte Modelos de query LDAP no Manual do MongoDB. 
- spec.security.authentication.ldap.bindQueryPasswordSecretRef
- Tipo: collection - Necessário para a autenticação LDAP. - Especifica o secreto que contém a senha com a qual MongoDB se liga ao conectar ao servidor LDAP. 
- spec.security.authentication.ldap.bindQueryPasswordSecretRef.name
- Tipo: string - Necessário para a autenticação LDAP. - Nome do segredo que contém a senha com a qual o MongoDB se vincula ao se conectar ao servidor LDAP. - O segredo deve conter apenas um campo - password, que armazena a senha.
- spec.security.authentication.ldap.bindQueryUser
- Tipo: string - Necessário para a autenticação LDAP. - LDAP Nome distinto ao qual o MongoDB é associado ao conectar ao servidor LDAP. 
- spec.security.authentication.ldap.caConfigMapRef
- Tipo: collection - Necessário para a autenticação LDAP com TLS. - ConfigMap que contém um CA que valida o certificado LDAP do servidor TLS. 
- spec.security.authentication.ldap.caConfigMapRef.key
- Tipo: string - Necessário para a autenticação LDAP com TLS. - Nome do campo que armazena o CA que valida o certificado LDAP do servidor TLS. 
- spec.security.authentication.ldap.caConfigMapRef.name
- Tipo: string - Necessário para a autenticação LDAP com TLS. - Nome do ConfigMap que contém um CA que valida o certificado LDAP do servidor TLS. 
- spec.security.authentication.ldap.caConfigMapRef.optional
- Tipo: booleano - Especifica se estas opções são obrigatórias ou opcionais: 
- spec.security.authentication.ldap.servers
- Tipo: array de strings - Necessário para a autenticação LDAP. - Lista de nomes de hosts e portas dos servidores LDAP. Especifique os nomes de host com suas respectivas portas no seguinte formato: - spec: - security: - authentication: - ldap: - servers: - - "<hostname1>:<port1>" - - "<hostname2>:<port2>" 
- spec.security.authentication.ldap.timeoutMS
- Tipo: inteiro - Especifica quantos milissegundos uma solicitação de autenticação deve esperar antes de atingir o tempo limite. 
- spec.security.authentication.ldap.transportSecurity
- Tipo: string - Necessário para a autenticação LDAP. - Especifica se o servidor LDAP aceita TLS. - Se o servidor LDAP aceitar TLS, configure o valor para - tls. Se o servidor LDAP não aceitar TLS, deixe esse valor em branco ou defina o valor como- none.- Observação- Se você especificar uma string diferente de - noneou- tls, o Kubernetes Operator continuará definindo a configuração como- tls.
- spec.security.authentication.ldap.userCacheInvalidationInterval
- Tipo: inteiro - Especifica quantos segundos o MongoDB espera para limpar o cache do usuário LDAP . O padrão é 30 segundos. 
- spec.security.authentication.ldap.userToDNMapping
- Tipo: string - Mapeia o nome de usuário fornecido para - mongodou- mongospara autenticação em um Nome Distinto (DN) LDAP.- Para obter mais detalhes, consulte security.ldap.userToDNMapping no Manual do MongoDB. 
- spec.security.authentication.modes
- Tipo: array - Especifica o mecanismo de autenticação usado pelo sistema do MongoDB de clusters multikubernetes. Os valores válidos são - SCRAM,- SCRAM-SHA-1,- MONGODB-CR,- X509e- LDAP. Recomendamos- SCRAM-SHA-256 (SCRAM)em vez- SCRAM-SHA-1. Se você especificar- SCRAM-SHA-1, também deverá especificar- MONGODB-CR.- Observação- Para habilitar a autenticação de cluster interno X.509 para o projeto do Cloud Manager ou MongoDB Ops Manager , defina este valor como - ["X509"]e especifique as seguintes configurações:- forneça um valor para o spec.security.certsSecretPrefix configuração. 
 - Se você fornecer mais de um valor para - spec.security.authentication.modes, também deverá especificar um valor para spec.security.authentication.agents.mode.
- spec.security.authentication.requireClientTLSAuthentication
- Tipo: booleano - Padrão: false - Especifica se o host MongoDB exige que os clientes se conectem usando um certificado TLS. O padrão é - truese você habilitar a autenticação TLS.- Para habilitar a autenticação TLS , forneça um valor para o spec.security.certsSecretPrefix configuração. 
- spec.security.certsSecretPrefix
- Tipo: string - Texto para prefixo para os segredos do Kubernetes que você criou que contêm as chaves e certificados TLS do seu conjunto de réplicas. - É necessário prefixar os segredos com - <prefix>-<metadata.name>.- Por exemplo, se você chamar sua implantação - my-deploymentde e definir o prefixo como- mdb, deverá nomear o segredo TLS para as comunicações TLS do cliente- mdb-my-deployment-cert. Além disso, você deve nomear o segredo TLS para autenticação interna do cluster (se ativado) como- mdb-my-deployment-clusterfile.- Para saber mais sobre nomear os segredos que contêm seus certificados TLS , consulte o tópico em Início Rápido do Multi-Kubernetes-Cluster que se aplica à sua implantação. 
- spec.security.roles
- Tipo: array - Array que define funções definidas pelo usuário que oferecem controle de acesso refinado sobre seu sistema do MongoDB de vários clusters Kubernetes. - Para habilitar roles definidas pelo usuário, o spec.security.authentication.enabled deve ser - true.- Exemplo- Neste exemplo, um role definido pelo usuário denominado - customRolepermite aos usuários atribuídos a este role a:- Inserir documentos na collection - catsno banco de dados- petse
- Encontre e insira documentos na collection - dogsno banco de dados- pets.
 - 1 - security: - 2 - authentication: - 3 - enabled: true - 4 - modes: - 5 - - "SCRAM" - 6 - roles: - 7 - - role: "customRole" - 8 - db: admin - 9 - privileges: - 10 - - actions: - 11 - - insert - 12 - resource: - 13 - collection: cats - 14 - db: pets - 15 - - actions: - 16 - - insert - 17 - - find - 18 - resource: - 19 - collection: dogs - 20 - db: pets - 21 - ... 
- spec.security.roles.authenticationRestrictions
- Tipo: array - Array que define o endereço IP de e para o qual os usuários atribuídos a esta spec.security.roles.role podem se conectar. 
- spec.security.roles.authenticationRestrictions.clientSource
- Tipo: array - Array de endereços IP ou blocos CIDR a partir dos quais os usuários atribuídos a este spec.security.roles.role podem se conectar. - Os servidores MongoDB rejeitam solicitações de conexão de usuários com esse role se as solicitações vierem de um cliente que não esteja presente nessa array. 
- spec.security.roles.authenticationRestrictions.serverAddress
- Tipo: array - Array de endereços IP ou blocos CIDR aos quais os usuários atribuídos a este spec.security.roles.role podem se conectar. - Os servidores MongoDB rejeitam solicitações de conexão de usuários com esse role se o cliente solicitar a conexão a um servidor que não esteja presente nessa array. 
- spec.security.roles.db
- Tipo: string - O reconhecimento de data center no qual armazenar o role definido pelo usuário. - Exemplo- admin
- spec.security.roles.privileges
- Tipo: array - Array que descreve os privilégios dos usuários que concederam esse role. 
- spec.security.roles.privileges.actions
- Tipo: array - Lista de ações que os usuários que receberam essa função podem executar. Para obter uma lista de valores aceitos, consulte Ações de privilégio no Manual do MongoDB das versões do MongoDB que você implementa com o Kubernetes Operator. 
- spec.security.roles.privileges.resource
- Tipo: collection - Recursos para os quais o privilégio spec.security.roles.privilegios.actions se aplicam. - Essa collection deve incluir: - As configurações spec.security.roles.privilege.resource.db e spec.security.roles.privilege.resource.collection , ou 
- A configuração spec.security.roles.privilege.resource.cluster com um valor de - true.
 
- spec.security.roles.privileges.resource.cluster
- Tipo: booleano - Padrão: false - Sinalizador que indica que o privilégio spec.security.roles.privilegest.actions se aplica a todos os bancos de dados e collections no MongoDB deployment. - Se definido como verdadeiro, não forneça valores para spec.security.roles.privilege.resource.db e spec.security.roles.privilege.resource.collection. 
- spec.security.roles.privileges.resource.collection
- Tipo: string - Coleção no spec.security.roles.privilegest.resource.db para o qual o privilégio spec.security.roles.privilegest.actions se aplica. - Se você fornecer um valor para esta configuração, você também deverá fornecer um valor para spec.security.roles.privilegios.resource.db. 
- spec.security.roles.privileges.resource.db
- Tipo: string - Banco de dados ao qual o privilégio spec.security.roles.privilegios.actions se aplicam. - Se você fornecer um valor para esta configuração, você também deverá fornecer um valor para spec.security.roles.privilege.resource.collection. 
- spec.security.roles.role
- Tipo: string - Nome do role definido pelo usuário. 
- spec.security.tls.additionalCertificateDomains
- Tipo: collection - Lista de todos os domínios que devem ser adicionados aos certificados TLS para cada pod nesta implantação. Ao definir este parâmetro, cada CSR que o Kubernetes Operator transforma em um certificado TLS inclui um SAN no formato - <pod name>.<additional cert domain>.- Os recursos do conjunto de réplicas não precisam desse parâmetro. Use spec.connecttivity.replicaSetHorizons no lugar. - Observação- Se você adicionar esse parâmetro a um recurso habilitado para TLS, o Kubernetes exibirá um erro quando o recurso alcançar o estado - Pending. Este erro é exibido:- Please manually remove the |csr| in order to proceed.Para corrigir esse problema:- Remova todos os CSR existentes para que o Kubernetes possa gerar novos CSRs. Para saber como excluir um recurso, consulte a exclusão de recursos na documentação do Kubernetes. 
- Aprove os CSRs após o Kubernetes gerá-los. 
 
- spec.security.tls.ca
- Tipo: string - Forneça o nome do ConfigMap que armazena a CA. - Importante- Se você usar uma CA customizada para assinar seus certificados TLS para o recurso - MongoDBMultiCluster, deverá especificar esse parâmetro.- O Operador Kubernetes exige que você nomeie o certificado para o recurso do - MongoDBMultiCluster- ca-pemno ConfigMap.
- spec.security.tls.enabled
- Tipo: booleano - Importante- spec.security.tls.enabledestá obsoleto a partir da versão 1.19 do Kubernetes Operator e será removido em uma versão futura do Kubernetes Operator. Para habilitar o TLS, forneça um valor para o spec.security.certsSecretPrefix configuração.- Criptografa comunicações usando certificados TLS entre: - O MongoDB hospeda em um conjunto de réplicas ou configuração de cluster fragmentado 
- Clientes ( - mongoshell, drivers, MongoDB Compass e outros) e o deployment do MongoDB
 
- spec.statefulSet.spec
- Tipo: collection - Especificação global para o StatefulSet que o MongoDB Enterprise Kubernetes Operator cria para sua implantação do MongoDB de clusters multikubernetes. - Para revisar quais campos você pode adicionar aos aplicativos - spec.statefulSet.spec, consulte StatefulSetSpec v1 na documentação do Kubernetes.