Especificação do recurso do banco de dados MongoDB
Nesta página
- Configurações de recursos comuns
- Obrigatório
- Condicional
- Opcional
- Configurações de recursos específicos de implementação
- Configurações standalone
- Configurações de conjunto de réplicas
- Configurações de cluster fragmentado
- Configurações do Prometheus
- Configurações de segurança
- Exemplos
- Configurações do StatefulSet
Observação
Em qualquer lugar nesta página que diz Gerente de Operações, você pode substituir o Gerenciador de Nuvem.
O Operador MongoDB Enterprise Kubernetes cria o Kubernetes statefulSets dos arquivos de especificação que você escreve.
O Kubernetes Operator cria recursos específicos do MongoDB no Kubernetes como recursos personalizados.
Para gerenciar esses recursos personalizados, use o seguinte processo:
Crie ou atualize uma especificação de recurso do
MongoDB
.Oriente o MongoDB Enterprise Kubernetes Operator para aplicá-lo ao seu ambiente Kubernetes. Como resultado, o Kubernetes Operator executa estas ações:
Cria os StatefulSets, serviços e outros recursos definidos do Kubernetes.
Atualiza a configuração de implantação do Ops Manager para refletir as alterações.
Tipo de implementação | StatefulSets | Tamanho do StatefulSet |
---|---|---|
Autônomo | 1 | 1 Pod |
Conjunto de réplicas | 1 | 1 Pod por membro |
Cluster fragmentado | <numberOfShards> + 2 |
Cada recurso do MongoDB
utiliza uma especificação de objeto no YAML para definir as características e configurações do objeto MongoDB: autônoma, conjunto de réplicas e cluster fragmentado.
Configurações de recursos comuns
Cada tipo de recurso deve usar as seguintes configurações:
Obrigatório
metadata.name
Tipo: string
Nome do recurso
MongoDB
que você cria.Os nomes de recursos devem ter 44 caracteres ou menos.
spec.credentials
Tipo: string
Obrigatório. Nome do Kubernetes segredo MongoDB Ops Manager API do Kubernetes você criou como credenciais de autenticação Cloud Manager MongoDB Ops Managerda para o Operator se comunicar com o ou .
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.persistent
Tipo: booleano
Padrão: Verdadeiro
AVISO: conceda aos contêineres permissão para gravar no Volume Persistente. O Operador Kubernetes define
fsGroup = 2000
,runAsUser = 2000
erunAsNonRoot = true
emsecurityContext
. O Kubernetes Operator definefsgroup
comorunAsUser
para 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 Disk Usage e Disk IOPS Atlas Charts não poderão ser exibidos na Processes guia da Deployment página ou na Metrics página ao revisar os dados dessa implementação.
spec.type
Tipo: string
Tipo de recurso
MongoDB
para criar. Os valores aceitos são:Standalone
ReplicaSet
ShardedCluster
spec.version
Tipo: string
Versão do MongoDB que você instalou nesse recurso do
MongoDB
.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.
Observação
Se você atualizar esse valor para uma versão posterior do MongoDB para seus recursos de banco de dados de dados, a versão de versão de compatibilidade do recurso permanecerá na versão do MongoDB da qual você está atualizando para lhe dar a opção de fazer o downgrade, se necessário. Se quiser que a versão de compatibilidade do recurso corresponda à nova versão do MongoDB , defina manualmente
spec.featureCompatibilityVersion
para a nova versão ou paraAlwaysMatchVersion
. Para saber mais, consultespec.featureCompatibilityVersion
.
Condicional
Cada recurso deve usar uma das seguintes configurações:
spec.opsManager.configMapRef.name
Tipo: string
Nome do ConfigMap com a configuração de conexão do Cloud Manager ou MongoDB Ops Manager . A configuração
spec.cloudManager.configMapRef.name
é um nome alternativo para essa configuração e pode ser usada como substituto.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.cloudManager.configMapRef.name
Tipo: string
Alias para
spec.opsManager.configMapRef.name
.
Opcional
Cada tipo de recurso pode usar as seguintes configurações:
metadata.annotations.mongodb.com/v1.architecture
Tipo: string
Determina a arquitetura do container usada por um sistema específico:
Os contêineres não estáticos padrão que baixam o binário MongoDB no tempo de execução, ou
Containers estáticos (visualização pública) que são imutáveis no tempo de execução.
Os valores aceitos são:
static
non-static
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: my-project annotations: mongodb.com/v1.architecture: "static"
spec.agent.backupAgent.logRotate
Tipo: objeto
Limites após os quais o MongoDB Agent gira o log de backup.
spec.agent.backupAgent.logRotate.sizeThresholdMB
Tipo: inteiro
Tamanho máximo, em MB, de um arquivo de log de backup antes que o MongoDB Agent gire os registros.
spec.agent.backupAgent.logRotate.timeThresholdHrs
Tipo: inteiro
Número de horas após as quais o MongoDB Agent gira o arquivo de log de backup .
spec.agent.mongod.auditlogRotate
Tipo: objeto
Objeto que contém a configuração de rotação do registro de auditar para os processos MongoDB .
spec.agent.mongod.auditlogRotate.sizeThresholdMB
Tipo: número
Tamanho máximo, em MB, de um arquivo de log de auditar antes de o MongoDB Agent girar os registros.
spec.agent.mongod.auditlogRotate.timeThresholdHrs
Tipo: inteiro
Número de horas após as quais o MongoDB Agent gira o arquivo de log de auditar .
spec.agent.mongod.auditlogRotate.numUncompressed
Tipo: inteiro
Número máximo de arquivos de log de auditar totais para deixar descompactados, incluindo o arquivo de log atual.
spec.agent.mongod.auditlogRotate.numTotal
Tipo: inteiro
Número total de arquivos de log de auditar que o MongoDB Ops Manager mantém. Se você não definir esse valor, o número total de arquivos de log de auditar será padronizado como 0.
spec.agent.mongod.auditlogRotate.percentOfDiskspace
Tipo: número
Porcentagem máxima de espaço total em disco que o Ops Manager pode usar para armazenar os arquivos de log expressos como decimal. Se esse limite for excedido, o Ops Manager excluirá os arquivos de log compactados até atingir esse limite. O Ops Manager exclui primeiro os arquivos de log mais antigos.
O padrão é 0,02.
spec.agent.mongod.logRotate
Tipo: objeto
Limites após os quais o MongoDB Ops Manager gira os registros MongoDB de um processo.
spec.agent.mongod.logRotate.sizeThresholdMB
Tipo: inteiro
Tamanho máximo em MB para um arquivo de log individual antes que o MongoDB Ops Manager o gire. O MongoDB Ops Manager gira o arquivo de log imediatamente se ele atender ao valor fornecido neste
sizeThresholdMB
ou nospec.agent.mongod.logRotate.timeThresholdHrs
.
spec.agent.mongod.logRotate.timeThresholdHrs
Tipo: inteiro
Duração máxima em horas para um arquivo de log individual antes da próxima rotação. O tempo é desde a última rotação.
O MongoDB Ops Manager gira o arquivo de log quando o arquivo encontra este
timeThresholdHrs
ouspec.agent.mongod.logRotate.sizeThresholdMB
.
spec.agent.monitoringAgent.logRotate
Tipo: objeto
Limites após os quais o MongoDB Agent gira o registro de monitoramento.
spec.agent.monitoringAgent.logRotate.sizeThresholdMB
Tipo: inteiro
Tamanho máximo em MB para um arquivo de log individual antes que o MongoDB Agent gire o registro de monitoramento.
spec.agent.monitoringAgent.logRotate.timeThresholdHrs
Tipo: inteiro
Número de horas após as quais o MongoDB Agent gira o registro de monitoramento.
spec.agent.readinessProbe.environmentVariables
Tipo: objeto
Configura as seguintes variáveis de ambiente usadas para controlar os arquivos de log do teste de preparação:
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: my-project spec: agent: readinessProbe: environmentVariables: READINESS_PROBE_LOGGER_BACKUPS: 1 READINESS_PROBE_LOGGER_MAX_SIZE: 10 READINESS_PROBE_LOGGER_MAX_AGE: 3 READINESS_PROBE_LOGGER_COMPRESS: true MDB_WITH_AGENT_FILE_LOGGING: false LOG_FILE_PATH: /var/log/mongodb-mms-automation/readiness.log
spec.featureCompatibilityVersion
Tipo: string
O padrão é a versão principal anterior do MongoDB após a atualização do MongoDB .
Limita as alterações aos dados que ocorrem com uma atualização para uma nova versão principal. Por exemplo, se você atualizar do MongoDB 5.0 para o MongoDB 6.0, a versão de compatibilidade do recurso permanecerá em 5.0 para lhe dar a opção de fazer o downgrade, se necessário.
Se quiser que a versão de compatibilidade do recurso corresponda à nova versão do MongoDB , você deve definir manualmente
featureCompatibilityVersion
para a nova versão. Por exemplo,featureCompatibilityVersion: 6.0
.Como alternativa, você pode habilitar a opção
AlwaysMatchVersion
para atualizar automaticamente a versão de compatibilidade do recurso para corresponder à versão do MongoDB durante as atualizações. Por exemplo,featureCompatibilityVersion: AlwaysMatchVersion
.Para saber mais sobre compatibilidade de funcionalidades, consulte
setFeatureCompatibilityVersion
no Manual do MongoDB .
spec.clusterDomain
Tipo: string
Padrão: cluster.local
Nome de domínio do cluster Kubernetes onde você implementa o Operador Kubernetes. Quando o Kubernetes cria um StatefulSet, o Kubernetes atribui a cada Pod um FQDN. Para atualizar o Cloud Manager ou o Ops Manager, o Kubernetes Operator calcula o FQDN para cada Pod usando um nome de cluster fornecido. O Kubernetes não fornece uma API para consultar esses nomes de host.
Aviso
Você deve definir se o seu
spec.clusterDomain
cluster Kubernetes tiver um domínio padrão diferente docluster.local
padrão. Se você não usar o padrão nem definir a opçãospec.clusterDomain
, o operador Kubernetes pode não funcionar conforme o esperado.
spec.clusterName
Tipo: string
Padrão: cluster.local
Nome de domínio do cluster Kubernetes onde você implementa o Operador Kubernetes. Quando o Kubernetes cria um StatefulSet, o Kubernetes atribui a cada Pod um FQDN. Para atualizar o Cloud Manager ou o Ops Manager, o Kubernetes Operator calcula o FQDN para cada Pod usando um nome de cluster fornecido. O Kubernetes não fornece uma API para consultar esses nomes de host.
Aviso
Você deve definir se o seu
spec.clusterDomain
cluster Kubernetes tiver um domínio padrão diferente docluster.local
padrão. Se você não usar o padrão nem definir a opçãospec.clusterDomain
, o operador Kubernetes pode não funcionar conforme o esperado.
metadata.namespace
Tipo: string
Namespace Kubernetes onde você cria este
MongoDB
recurso e outros objetos.
spec.service
Tipo: string
Padrão: <resource_name>+"-svc" and <resource_name>+"-svc-external"
Nome do serviço Kubernetes a ser criado ou utilizado para um StatefulSet. Se o serviço com este nome já existir, o MongoDB Enterprise Kubernetes Operator não o excluirá nem recriará. Essa configuração permite que você crie seus próprios serviços personalizados e que o Kubernetes Operator os reutilize.
spec.logLevel
Tipo: string
Padrão: INFO
Configura o nível de registro do agente de automação dentro do Pod. Os valores aceitos incluem:
DEBUG
INFO
WARN
ERROR
FATAL
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 de banco de dados diretamente pelo
mongod
oumongos
, defina essa configuração comotrue
.
Configurações de recursos específicos de implementação
Outras configurações que você pode e deve usar em uma especificação de recurso do MongoDB
dependem de qual item do deployment do MongoDB você deseja criar:
Configurações standalone
Observação
Todas as configurações autônomas também se aplicam aos recursos do conjunto de réplicas.
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:
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.startupOptions
Tipo: collection
Configurações do MongoDB Agent com as quais você deseja iniciar o recurso do banco de dados 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.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: my-standalone 6 spec: 7 version: "6.0.0-ent" 8 service: my-service 9 10 opsManager: 11 configMapRef: 12 name: my-project 13 credentials: my-credentials 14 type: Standalone 15 16 persistent: true 17 agent: 18 startupOptions: 19 maxLogFiles: "30" 20 dialTimeoutSeconds: "40" 21 ...
spec.podSpec
Tipo: objeto
Objeto que contém as especificações da CustomResourceDefinition do MongoDB Pods.
spec.externalAccess
Tipo: collection
Especificação para expor seu cluster para conexões externas. Para saber como se conectar ao seu recurso do MongoDB de fora do cluster Kubernetes, consulte Como conectar a um recurso de banco de dados MongoDB de fora do Kubernetes.
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 MongoDB database em um cluster. Cada serviço externo tem seletores que correspondem ao 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çãoName
<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 omongod
.publishNotReadyAddress
true
Especifica que os registros DNS são criados mesmo que o Pod não esteja pronto. Não defina comofalse
para nenhum pod de banco de dados.Observação
Se você configurar o
spec.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
.Quando você configura a configuração do
spec.externalAccess
, o Operador Kubernetes cria automaticamente um serviço de balanceador de carga externo com valores padrão. Você pode substituir determinados valores ou adicionar novos valores dependendo de suas necessidades. Por exemplo, se você pretende criar serviços NodePort e não precisa de um balancer de carga, você deve configurar substituições na 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 configurações específicas do fornecedor de nuvem a todos os clusters em seu sistema. Para saber mais,consulte anotações e a documentação do seu fornecedor 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 ametadata.name
.{namespace}
Igual ametadata.namespace
.{podIndex}
Índice do Pod atribuído pelo StatefulSet e direcionadas pelo serviço externo atual.{podName}
Igual a{resourceName}-{podIndex}
.{statefulSetName}
O StatefulSet. Igual a{resourceName}
.{externalServiceName}
Nome gerado do serviço externo, com base nos valores de espaço reservado que você especificou. Igual a{resourceName}-{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 processomongod
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
mongod
definido na configuração de automação.O nome do host do processo depende da sua configuração de sistema. Se você configurou seu sistema para utilizar
external domains
, o nome do host do processo utilizará o seguinte formato:{resourceName}-{podIndex}.{mongodProcessDomain}
Por exemplo:
mdb-rs-1.example.com
Se o seu sistema não utilizar domínios externos, o nome do host do processo utilizará o seguinte formato:
{resourceName}-{podIndex}.{resourceName}-{podIndex}-svc.{namespace}.svc.cluster.local
Por exemplo:
mdb-rs-1.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. Você também não pode usar um espaço reservado específico para sistemas de vários clusters Kubernetes para um único sistema de recursos do MongoDB .
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.podSpec.persistence.single
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monte todos os três diretórios para dados, diário e registros no mesmo Volume persistente .
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou as collections
persistence.multiple
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringTamanho mínimo do volume persistente que deve ser montado. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 16Gi.
Por exemplo, se o sistema autônomo exigir 60 gigabytes de espaço de armazenamento, defina esse valor em
60Gi
.storageClass
stringTipo de armazenamento especificado em uma declaração de volume persistente. Você pode criar esse tipo de armazenamento como um objeto StorageClass antes de usá-lo nesta especificação de objeto.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.podSpec.persistence.multiple.data
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para dados em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade de armazenamento mínima que deve estar disponível em um nó do Kubernetes para hospedar implantação autônoma no Kubernetes. Este valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 16Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para sistema standalone. Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.podSpec.persistence.multiple.journal
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para diários em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade de armazenamento mínima que deve estar disponível em um nó do Kubernetes para hospedar implantação autônoma no Kubernetes. Este valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 1Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para sistema standalone. Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.podSpec.persistence.multiple.logs
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para logs em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade de armazenamento mínima que deve estar disponível em um nó do Kubernetes para hospedar implantação autônoma no Kubernetes. Este valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 3Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para sistema standalone. Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.podSpec.podTemplate.affinity.nodeAffinity
Tipo: Estrutura
Regra do Kubernetes para colocar Pods para conjunto de réplicas em uma faixa específica de nós .
Para desempenho otimizado de leitura e gravação, use regras de afinidade de nós que restringem Pods para executar em nós específicos ou preferir executar em nós específicos .
spec.podSpec.podTemplate.affinity.podAffinity
Tipo: Estrutura
Regra
MongoDB
do Kubernetes para determinar se vários Pods de recursos deve ser colocalizado com outros Pods . Para saber mais sobre os casos de uso, consulte Afinidade e Antiafinidade na documentação do Kubernetes.
spec.podSpec.podTemplate.affinity.podAntiAffinity
Tipo: Estrutura
Default: kubernetes.io/hostname
Define uma regra para distribuir Pods hospedar
MongoDB
recursos em locais diferentes. Um local pode ser um único nó, rack ou região. Por padrão, o Kubernetes Operator tenta espalhar Pods em diferentes nós.
spec.podSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
Tipo: Estrutura
Default: kubernetes.io/hostname
Esta chave define qual etiqueta é usado para determinar qual domínio de topologia um nó pertence.
spec.podSpec.podTemplate
Tipo: collection
Modelo para os Pods Kubernetes que o Enterprise Kubernetes Operator MongoDB cria para os recursos de banco de dados MongoDB.
Os valores do modelo têm precedência sobre os valores especificados no
spec.podSpec
.Observação
O Kubernetes Operator não valida os campos que você fornece no
spec.podSpec.podTemplate
.
spec.podSpec.podTemplate.metadata
Tipo: collection
Metadados para os Pods Kubernetes que o Enterprise Kubernetes Operator MongoDB cria para os recursos de banco de dados MongoDB.
Para revisar quais campos você pode adicionar a
spec.podSpec.podTemplate.metadata
, consulte a documentação do Kubernetes.
spec.podSpec.podTemplate.spec
Tipo: collection
Especificações dos Pods Kubernetes que o Enterprise Kubernetes Operator MongoDB cria para os recursos de banco de dados MongoDB.
Para analisar quais campos você pode adicionar ao
spec.podSpec.podTemplate.spec
, consulte a Kubernetes API principal do v1 Core API.Observação
Quando você adiciona containers ao
spec.podSpec.podTemplate.spec.containers
, o Kubernetes Operator os adiciona ao pod do Kubernetes. Estes containers são anexados aos containers de recursos de banco de dados MongoDB no pod.Use essa configuração para especificar as alocações de CPU e RAM de cada Pod. Por exemplo, consulte as amostras no Github.
Configurações de conjunto de réplicas
Observação
Todas as configurações autônomas também se aplicam aos recursos do conjunto de réplicas.
As seguintes configurações se aplicam a tipos de recurso de conjunto de réplicas:
spec.backup
Tipo: collection
O contêiner de coleta para
spec.backup.mode
, que permite backups contínuos para recursos do MongoDB no Kubernetes Operator.
spec.backup.assignmentLabels
Tipo: array
Uma lista de rótulos separados por vírgulas para atribuir backup daemons, armazéns de oplog, blockstores, S3 snapshot stores e armazenamento do sistema de arquivos a projetos ou grupos específicos. Use rótulos de atribuição para identificar se armazéns de backup específicos 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 IU do Ops Manager . Os rótulos de atribuição que você não define usando o operador Kubernetes continuam a usar os valores definidos na IU do Ops Manager .
Observação
Se você definir este parâmetro, a chave de API vinculada ao valor de
spec.credentials
deverá ter um roleGlobal Owner
.
spec.backup.mode
Tipo: string
Permite backups contínuos para um recurso do MongoDB. Os valores possíveis são
enabled
,disabled
eterminated
.Observação
A configuração
spec.backup.mode
depende do backup habilitado no MongoDB Ops Manager e exige quespec.backup.enabled
o valor na MongoDB Ops Manager especificação de recursos do seja definidotrue
como .Depois de habilitar backups contínuos para seu recurso do MongoDB com
spec.backup.mode
, você pode conferir o status do backup.
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.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.snapshotIntervalHours
Tipo: número
Número de horas entre snapshots. Você pode definir um valor de
6
,8
,12
ou24
.
spec.backup.snapshotSchedule.snapshotRetentionDays
Tipo: número
Número de dias para manter snapshots recentes. Você pode definir um valor entre
2
e5
.
spec.backup.snapshotSchedule.dailySnapshotRetentionDays
Tipo: número
Número de dias para manter snapshots diários. Você pode definir um valor entre
1
e365
. Definir o valor em0
desabilita esta regra.
spec.backup.snapshotSchedule.weeklySnapshotRetentionWeeks
Tipo: número
Número de semanas para manter snapshots semanais. Você pode definir um valor entre
1
e52
. Definir o valor em0
desabilita esta regra.
spec.backup.snapshotSchedule.monthlySnapshotRetentionMonths
Tipo: número
Número de meses para manter snapshots mensais. Você pode definir um valor entre
1
e36
. Definir o valor em0
desabilita 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
0
e23
.
spec.backup.snapshotSchedule.referenceMinuteOfHour
Tipo: número
Minuto da hora UTC para agendar snapshots. Você pode definir um valor entre
0
e59
.
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.clusterName
Tipo: string
Padrão: cluster.local
Nome de domínio do cluster Kubernetes onde você implementa o Operador Kubernetes. Quando o Kubernetes cria um StatefulSet, o Kubernetes atribui a cada Pod um FQDN. Para atualizar o Cloud Manager ou o Ops Manager, o Kubernetes Operator calcula o FQDN para cada Pod usando um nome de cluster fornecido. O Kubernetes não fornece uma API para consultar esses nomes de host.
Aviso
Você deve definir se o seu
spec.clusterDomain
cluster Kubernetes tiver um domínio padrão diferente docluster.local
padrão. Se você não usar o padrão nem definir a opçãospec.clusterDomain
, o operador Kubernetes pode não funcionar conforme o esperado.
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.
Requisitos de horizonte dividido:
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.members
.Forneça um valor para a configuração do
spec.security.certsSecretPrefix
para habilitar o TLS. Este método para usar horizontes divididos requer a extensão MongoDB Server Name Indication do protocolo TLS .
Exemplo
Neste exemplo, os nós do conjunto de réplicas se comunicam entre si no horizonte de
example-localhost
. Os clientes se comunicam com o conjunto de réplicas usando o horizonte deexample-website
.1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-replica-set> 6 spec: 7 members: 3 8 version: "4.2.2-ent" 9 type: ReplicaSet 10 opsManager: 11 configMapRef: 12 name: <configMap.metadata.name> 13 credentials: <mycredentials> 14 persistent: true 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.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>-<pod-idx>.<externalDomain>
Por exemplo:
replica-set-1.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].hostname
campo na MongoDB Ops Manager configuração de automação do . Em seguida, o MongoDB Agent utiliza este nome de host para se conectar aomongod
.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 conexões abaixo continuam usando 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 qualquerprocesses[n].hostname
campo na MongoDB Ops Manager automation configuration do para uma implantação de replica set em execução.
spec.memberConfig
Tipo: collection
Especificação para cada conjunto de réplicas MongoDB distribuído a partir do recurso
MongoDB
.A ordem dos elementos na array deve refletir a ordem dos nós no conjunto de réplicas. Por exemplo, o primeiro elemento da array afeta o Pod no índice
0
, o segundo elemento afeta o índice1
, e assim por diante.Exemplo
Considere o seguinte exemplo de especificação para um conjunto de réplicas de três nós:
spec: memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod" - votes: 1 priority: "1.5" tags: tag2: "value2" environment: "prod" - votes: 0 priority: "0.5" tags: tag2: "value2" environment: "prod"
spec.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
priority
mais alto.Para diminuir a probabilidade relativa de que um nó do conjunto de réplicas se torne o primary, especifique um valor de
priority
mais baixo.
Por exemplo, um nó com uma
memberConfig.priority
de1.5
tem mais probabilidade do que um nó com umamemberConfig.priority
de0.5
de se tornar o primary.Um nó com um
memberConfig.priority
de0
não está qualificado para se tornar o primary. Para saber mais, consulte Priority do nó.
spec.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.memberConfig.votes
Tipo: número
Determina se um nó do conjunto de réplicas do MongoDB pode votar em uma eleição. Defina como
1
para permitir que o membro vote. Defina como0
para excluir o membro de uma eleição.
As seguintes configurações se aplicam somente a tipos de recurso de conjunto de réplicas:
spec.backup.autoTerminateOnDeletion
Tipo: booleano
Sinalizador que controla se o Kubernetes Operator interrompe e encerra o backup quando você exclui um recurso do MongoDB. Se omitido, o valor padrão é
false
. Definir este sinalizador comotrue
é recomendado se você deseja excluir o recurso customizado do MongoDB enquanto a configuraçãospec.backup.mode
está definida comoenabled
.
Configurações de cluster fragmentado
Importante
Os sistemas de cluster fragmentado de vários clusters estão atualmente em visualização pública.
Observação
Todas as Configurações de conjuntos de réplicas também se aplicam aos recursos do cluster fragmentado, a menos que especificado de outra forma.
As configurações a seguir se aplicam somente aos tipos de recursos de cluster fragmentado:
spec.backup.snapshotSchedule.clusterCheckpointIntervalMin
Tipo: número
Número de minutos entre checkpoints sucessivos de clusters. Esta configuração se aplica apenas a clusters fragmentados que executam MongoDB com uma versão de compatibilidade do recurso do 4.0 ou anterior. Este número determina a granularidade das restaurações point-in-time para clusters fragmentados. Você pode definir um valor de
15
,30
ou60
.
spec.configServerCount
Tipo: inteiro
Obrigatório. Número de membros no servidor de configuração.
spec.configSrv.additionalMongodConfig
Tipo: collection
Opções de configurações adicionais recomendadas para iniciar cada nó do servidor de configuração .
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:
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.configSrv.agent
Tipo: collection
Definições de configuração do MongoDB Agent para cada nó do servidor de configuração .
spec.configSrv.agent.startupOptions
Tipo: collection
Configurações do MongoDB Agent para iniciar cada nó do servidor de configuração .
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.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: my-sharded-cluster-options 6 spec: 7 version: "6.0.0-ent" 8 type: ShardedCluster 9 opsManager: 10 configMapRef: 11 name: my-project 12 credentials: my-credentials 13 persistent: true 14 shardCount: 2 15 mongodsPerShardCount: 3 16 mongosCount: 2 17 configServerCount: 1 18 19 mongos: 20 agent: 21 startupOptions: 22 maxLogFiles: "30" 23 24 configSrv: 25 agent: 26 startupOptions: 27 dialTimeoutSeconds: "40" 28 shard: 29 agent: 30 startupOptions: 31 serverSelectionTimeoutSeconds: "20" 32 ...
spec.configSrvPodSpec
Tipo: objeto
Objeto que contém as especificações da CustomResourceDefinition do MongoDB Pods do servidor de configuração .
spec.configSrvPodSpec.persistence.single
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monte todos os três diretórios para dados, diário e registros no mesmo Volume persistente .
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou as collections
persistence.multiple
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringTamanho mínimo do volume persistente que deve ser montado. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 5Gi.
Por exemplo, se cada servidor de configuração exigir 60 gigabytes de espaço de armazenamento, defina esse valor como
60Gi
.storageClass
stringTipo de armazenamento especificado em uma declaração de volume persistente. Você pode criar esse tipo de armazenamento como um objeto StorageClass antes de usá-lo nesta especificação de objeto.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.configSrvPodSpec.persistence.multiple.data
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para dados em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade mínima de armazenamento que deve estar disponível em um nó do Kubernetes para hospedar cada membro do servidor de configuração no Kubernetes. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 16Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para cada nó do servidor de configuração . Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.configSrvPodSpec.persistence.multiple.journal
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para diários em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade mínima de armazenamento que deve estar disponível em um nó do Kubernetes para hospedar cada membro do servidor de configuração no Kubernetes. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 1Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para cada nó do servidor de configuração . Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.configSrvPodSpec.persistence.multiple.logs
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para logs em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade mínima de armazenamento que deve estar disponível em um nó do Kubernetes para hospedar cada membro do servidor de configuração no Kubernetes. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 3Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para cada nó do servidor de configuração . Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.configSrvPodSpec.podTemplate
Tipo: collection
Modelo para os Pods do Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada nó do servidor de configuração.
Os valores do modelo têm precedência sobre os valores especificados no
spec.configSrvPodSpec
.Observação
O Kubernetes Operator não valida os campos que você fornece no
spec.configSrvPodSpec.podTemplate
.
spec.configSrvPodSpec.podTemplate.affinity.podAffinity
Tipo: collection
Regra
MongoDB
do Kubernetes para determinar se vários Pods de recursos deve ser colocalizado com outros Pods . Para saber mais sobre os casos de uso, consulte Afinidade e Antiafinidade na documentação do Kubernetes.
spec.configSrvPodSpec.podTemplate.affinity.nodeAffinity
Tipo: collection
Regra do Kubernetes para colocar Pods para conjunto de réplicas em uma faixa específica de nós .
Para desempenho otimizado de leitura e gravação, use regras de afinidade de nós que restringem Pods para executar em nós específicos ou preferir executar em nós específicos .
spec.configSrvPodSpec.podTemplate.affinity.podAntiAffinity
Tipo: string
Default: kubernetes.io/hostname
Define uma regra para distribuir Pods hospedar
MongoDB
recursos em locais diferentes. Um local pode ser um único nó, rack ou região. Por padrão, o Kubernetes Operator tenta espalhar Pods em diferentes nós.
spec.configSrvPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
Tipo: string
Default: kubernetes.io/hostname
Esta chave define qual etiqueta é usado para determinar qual domínio de topologia um nó pertence.
spec.configSrvPodSpec.podTemplate.metadata
Tipo: collection
Metadados para os pods do Kubernetes que o Enterprise Kubernetes Operator MongoDB cria para cada nó do servidor de configuração.
Para revisar quais campos você pode adicionar a
spec.configSrvPodSpec.podTemplate.metadata
, consulte a documentação do Kubernetes.
spec.configSrvPodSpec.podTemplate.spec
Tipo: collection
Especificações dos pods do Kubernetes que o Enterprise Kubernetes Operator MongoDB cria para cada nó do servidor de configuração.
Para analisar quais campos você pode adicionar ao
spec.configSrvPodSpec.podTemplate.spec
, consulte a Kubernetes API principal do v1 Core API.Observação
Quando você adiciona containers ao
spec.configSrvPodSpec.podTemplate.spec.containers
, o operador Kubernetes os adiciona ao pod do Kubernetes. Esses containers são anexados a cada container-membro do servidor de configuração no Pod.Use essa configuração para especificar as alocações de CPU e RAM de cada Pod. Por exemplo, consulte as amostras no Github.
spec.mongodsPerShardCount
Tipo: inteiro
Obrigatório. Número de membros por shard.
spec.mongosCount
Tipo: inteiro
Obrigatório. Número de instâncias do
mongos
no cluster fragmentado.
spec.mongos.additionalMongodConfig
Tipo: collection
Opções de configurações adicionais recomendadas para iniciar cada instância de mongos .
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:
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.mongos.agent
Tipo: collection
Definições de configuração do MongoDB Agent para cada instância
mongos
.
spec.mongos.agent.startupOptions
Tipo: collection
Configurações do MongoDB Agent com as quais você deseja iniciar cada instância do
mongos
.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.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: my-sharded-cluster-options 6 spec: 7 version: "6.0.0-ent" 8 type: ShardedCluster 9 opsManager: 10 configMapRef: 11 name: my-project 12 credentials: my-credentials 13 persistent: true 14 shardCount: 2 15 mongodsPerShardCount: 3 16 mongosCount: 2 17 configServerCount: 1 18 19 mongos: 20 agent: 21 startupOptions: 22 maxLogFiles: "30" 23 24 configSrv: 25 agent: 26 startupOptions: 27 dialTimeoutSeconds: "40" 28 shard: 29 agent: 30 startupOptions: 31 serverSelectionTimeoutSeconds: "20" 32 ...
spec.mongosPodSpec
Tipo: objeto
Objeto que contém as especificações da CustomResourceDefinition do MongoDB mongos Pods.
spec.mongosPodSpec.podTemplate
Tipo: collection
Modelo para os Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada instância do
mongos
.Os valores do modelo têm precedência sobre os valores especificados no
spec.mongosPodSpec
.Observação
O Kubernetes Operator não valida os campos que você fornece no
spec.mongosPodSpec.podTemplate
.
spec.mongosPodSpec.podTemplate.affinity.podAffinity
Tipo: collection
Opcional. Regra
MongoDB
do Kubernetes para determinar se vários Pods de recursos deve ser colocalizado com outros Pods .
spec.mongosPodSpec.podTemplate.affinity.nodeAffinity
Tipo: collection
Regra do Kubernetes para colocar Pods para conjunto de réplicas em uma faixa específica de nós .
Para desempenho otimizado de leitura e gravação, use regras de afinidade de nós que restringem Pods para executar em nós específicos ou preferir executar em nós específicos .
spec.mongosPodSpec.podTemplate.affinity.podAntiAffinity
Tipo: string
Default: kubernetes.io/hostname
Define uma regra para distribuir Pods hospedar
MongoDB
recursos em locais diferentes. Um local pode ser um único nó, rack ou região. Por padrão, o Kubernetes Operator tenta espalhar Pods em diferentes nós.
spec.mongosPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
Tipo: string
Default: kubernetes.io/hostname
Esta chave define qual etiqueta é usado para determinar qual domínio de topologia um nó pertence.
spec.mongosPodSpec.podTemplate.metadata
Tipo: collection
Metadados para os Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada instância do
mongos
.Para revisar quais campos você pode adicionar a
spec.mongosPodSpec.podTemplate.metadata
, consulte a documentação do Kubernetes.
spec.mongosPodSpec.podTemplate.spec
Tipo: collection
Especificações dos Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada instância do
mongos
.Para analisar quais campos você pode adicionar ao
spec.mongosPodSpec.podTemplate.spec
, consulte a Kubernetes API principal do v1 Core API.Observação
Quando você adiciona containers ao
spec.mongosPodSpec.podTemplate.spec.containers
, o operador Kubernetes os adiciona ao pod do Kubernetes. Esses contêineres são anexados a cada container de instânciamongos
no pod.Use essa configuração para especificar as alocações de CPU e RAM de cada Pod. Por exemplo, consulte as amostras no Github.
spec.shardCount
Tipo: inteiro
Obrigatório. Número de shards no cluster fragmentado.
spec.shard.additionalMongodConfig
Tipo: collection
Opções de configuração adicionais com as quais você deseja iniciar cada nó shard de cluster fragmentado .
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:
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.shard.agent
Tipo: collection
Configurações do MongoDB Agent para cada nó fragmento de cluster fragmentado.
spec.shard.agent.startupOptions
Tipo: collection
Configurações do MongoDB Agent para iniciar cada nó de fragmento do cluster fragmentado.
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.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: my-sharded-cluster-options 6 spec: 7 version: "6.0.0-ent" 8 type: ShardedCluster 9 opsManager: 10 configMapRef: 11 name: my-project 12 credentials: my-credentials 13 persistent: true 14 shardCount: 2 15 mongodsPerShardCount: 3 16 mongosCount: 2 17 configServerCount: 1 18 19 mongos: 20 agent: 21 startupOptions: 22 maxLogFiles: "30" 23 24 configSrv: 25 agent: 26 startupOptions: 27 dialTimeoutSeconds: "40" 28 shard: 29 agent: 30 startupOptions: 31 serverSelectionTimeoutSeconds: "20" 32 ...
spec.shardPodSpec
Tipo: objeto
Objeto que contém as especificações da CustomResourceDefinition do MongoDB pods de fragmentos.
spec.shardPodSpec.persistence.multiple.data
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para dados em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade mínima de armazenamento que deve estar disponível em um nó do Kubernetes para hospedar cada nó de fragmento do cluster fragmentado no Kubernetes. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 16Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para cada nó de shard do cluster fragmentado. Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.shardPodSpec.persistence.multiple.journal
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para diários em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade mínima de armazenamento que deve estar disponível em um nó do Kubernetes para hospedar cada nó de fragmento do cluster fragmentado no Kubernetes. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 1Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para cada nó de shard do cluster fragmentado. Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.shardPodSpec.persistence.multiple.logs
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monta um diretório para logs em seu próprio volume persistente.
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou a collection
persistence.single
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringCapacidade mínima de armazenamento que deve estar disponível em um nó do Kubernetes para hospedar cada nó de fragmento do cluster fragmentado no Kubernetes. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 3Gi.
Por exemplo, se esse recurso
MongoDB
exigir 60 gigabytes de espaço de armazenamento, defina esse valor como60Gi
.storageClass
stringTipo de armazenamento necessário para cada nó de shard do cluster fragmentado. Você pode criar este tipo de armazenamento como uma StorageClass objeto antes de usá-lo neste objeto especificação.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
spec.shardPodSpec.podTemplate
Tipo: collection
Modelo para os Pods do Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada membro de fragmento do cluster fragmentado.
Os valores do modelo têm precedência sobre os valores especificados no
spec.shardPodSpec
.Observação
O Kubernetes Operator não valida os campos que você fornece no
spec.shardPodSpec.podTemplate
.
spec.shardPodSpec.podTemplate.affinity.podAffinity
Tipo: string
Regra
MongoDB
do Kubernetes para determinar se vários Pods de recursos deve ser colocalizado com outros Pods . Para saber mais sobre os casos de uso, consulte Afinidade e Antiafinidade na documentação do Kubernetes.
spec.shardPodSpec.podTemplate.affinity.nodeAffinity
Tipo: string
Regra do Kubernetes para colocar Pods para conjunto de réplicas em uma faixa específica de nós .
Para desempenho otimizado de leitura e gravação, use regras de afinidade de nós que restringem Pods para executar em nós específicos ou preferir executar em nós específicos .
spec.shardPodSpec.podTemplate.affinity.podAntiAffinity
Tipo: string
Default: kubernetes.io/hostname
Define uma regra para distribuir Pods hospedar
MongoDB
recursos em locais diferentes. Um local pode ser um único nó, rack ou região. Por padrão, o Kubernetes Operator tenta espalhar Pods em diferentes nós.
spec.shardPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
Tipo: string
Default: kubernetes.io/hostname
Esta chave define qual etiqueta é usado para determinar qual domínio de topologia um nó pertence.
spec.shardPodSpec.podTemplate.metadata
Tipo: collection
Metadados para os Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada nó de fragmento do cluster fragmentado.
Para revisar quais campos você pode adicionar a
spec.shardPodSpec.podTemplate.metadata
, consulte a documentação do Kubernetes.
spec.shardPodSpec.podTemplate.spec
Tipo: collection
Especificações dos Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para cada nó de fragmento do cluster fragmentado.
Para analisar quais campos você pode adicionar ao
spec.shardPodSpec.podTemplate.spec
, consulte a Kubernetes API principal do v1 Core API.Observação
Quando você adiciona containers ao
spec.shardPodSpec.podTemplate.spec.containers
, o operador Kubernetes os adiciona ao pod do Kubernetes. Esses containers são anexados a cada container de nó do shard do cluster fragmentado no pod.Use essa configuração para especificar as alocações de CPU e RAM de cada Pod. Por exemplo, consulte as amostras no Github.
spec.shardSpecificPodSpec
Tipo: array
Lista que contém StatefulSet substitui por fragmento.
spec.shardSpecificPodSpec.podTemplate
Tipo: collection
Modelo para os Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para o fragmento específico.
Os valores do modelo têm precedência sobre os valores especificados no
spec.shardSpecificPodSpec
.Observação
O Kubernetes Operator não valida os campos que você fornece no
spec.shardSpecificPodSpec.podTemplate
.
spec.shardSpecificPodSpec.podTemplate.affinity.podAffinity
Tipo: string
Regra
MongoDB
do Kubernetes para determinar se vários Pods de recursos deve ser colocalizado com outros Pods . Para saber mais sobre os casos de uso, consulte Afinidade e Antiafinidade na documentação do Kubernetes.
spec.shardSpecificPodSpec.podTemplate.affinity.podAntiAffinity
Tipo: string
Default: kubernetes.io/hostname
Define uma regra para distribuir Pods hospedar
MongoDB
recursos em locais diferentes. Um local pode ser um único nó, rack ou região. Por padrão, o Kubernetes Operator tenta espalhar Pods em diferentes nós.
spec.shardSpecificPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
Tipo: string
Default: kubernetes.io/hostname
Esta chave define qual etiqueta é usado para determinar qual domínio de topologia um nó pertence.
spec.shardSpecificPodSpec.podTemplate.metadata
Tipo: collection
Metadados para os Pods Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para o shard específico.
Para revisar quais campos você pode adicionar a
spec.shardSpecificPodSpec.podTemplate.metadata
, consulte a documentação do Kubernetes.
spec.shardSpecificPodSpec.podTemplate.spec
Tipo: collection
Especificações dos Pods do Kubernetes que o MongoDB Enterprise Kubernetes Operator cria para o shard específico.
Para analisar quais campos você pode adicionar ao
spec.shardSpecificPodSpec.podTemplate.spec
, consulte a Kubernetes API principal do v1 Core API.Observação
Quando você adiciona containers ao
spec.shardSpecificPodSpec.podTemplate.spec.containers
, o operador Kubernetes os adiciona ao pod do Kubernetes. Esses containers são anexados aos containers de shard específicos no pod.Use essa configuração para especificar as alocações de CPU e RAM de cada Pod. Por exemplo, consulte as amostras no Github.
spec.topology
Tipo: string
Opcional
Padrão:
SingleCluster
Define a topologia do cluster fragmentado. Não pode ser alterado para um sistema existente. Se definido como
MultiCluster
:Todos os componentes do cluster fragmentado devem ter
clusterSpecList
definido: -spec.mongos.clusterSpecList
-spec.configSrv.clusterSpecList
-spec.shard.clusterSpecList
Os seguintes campos são ignorados, pois seus valores equivalentes são passados para cada cluster nos objetos
spec.<section>.clusterSpecList
: -spec.mongodsPerShardCount
é definido emspec.shard.clusterSpecList.members
-spec.mongosCount
é definido emspec.mongos.clusterSpecList.members
-spec.configServerCount
é definido emspec.configSrv.clusterSpecList.members
-spec.shardOverrides.memberConfig
é definido emspec.shardOverrides.clusterSpecList.memberConfig
-spec.shardOverrides.members
é definido emspec.shardOverrides.clusterSpecList.members
-spec.shardOverrides.statefulSet
é definido emspec.shardOverrides.clusterSpecList.statefulSet
Exemplo:
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: sc spec: shardCount: 3 # we don't specify mongodsPerShardCount, mongosCount and configServerCount as they don't make sense for multi-cluster topology: MultiCluster type: ShardedCluster version: 7.0.12 cloudManager: configMapRef: name: my-project credentials: my-credentials persistent: true shard: clusterSpecList: - clusterName: member-cluster-0 members: 2 # each shard will have 2 members in cluster 0, unless overriden - clusterName: member-cluster-1 members: 2 - clusterName: member-cluster-2 members: 1 shardOverrides: - shardNames: [sc-2] # this override will apply to the third shard (here, shards are indexed from 0 to 2 as we have 3 shards) clusterSpecList: - clusterName: member-cluster-0 # all other fields are optional, if not provided the fields from matching member cluster from shard.clusterSpecList will be taken by default members: 3 - clusterName: member-cluster-1 # we don't deploy this shard to member-cluster-1 # Note that it is also possible to make it explicit with members: 0 # we don't provide entry for clusterName: member-cluster-1, so it won't be deployed there - clusterName: member-cluster-2 members: 2 configSrv: clusterSpecList: - clusterName: member-cluster-0 members: 2 # config server will have 2 members in this cluster - clusterName: member-cluster-1 members: 1 - clusterName: member-cluster-2 members: 2 mongos: clusterSpecList: - clusterName: member-cluster-0 members: 2 # router will have 2 members in this cluster - clusterName: member-cluster-1 members: 1 Os campos a seguir estão relacionados exclusivamente a implantações nas quais
topology=MultiCluster
:spec.configSrv.clusterSpecList
Observação
Este campo está disponível exclusivamente para sistemas de cluster cluster fragmentado de vários clusters, que estão atualmente em visualização pública.
Tipo : array de objetos
Necessário se
topology=MultiCluster
Uma array de objetos para uso em sistemas de cluster fragmentado de cluster fragmentado com os seguintes campos de nível superior:
clusterName
Tipo: string
Nome do cluster onde o MongoDB Enterprise Kubernetes Operator agenda o StatefulSet.
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 MongoDB database em um cluster. Cada serviço externo tem seletores que correspondem ao 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çãoName
<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 omongod
.publishNotReadyAddress
true
Especifica que os registros DNS são criados mesmo que o Pod não esteja pronto. Não defina comofalse
para 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.
members
Tipo: número
Número de membros no conjunto de réplicas MongoDB.
memberConfig
Tipo: collection
Especificação para cada shard do MongoDB e seus membros em sua implantação do MongoDB de cluster multi-Kubernetes.
A ordem dos elementos no objeto para shard deve refletir a ordem dos membros no conjunto de réplicas. Por exemplo, o primeiro elemento afeta o Pod no índice
0
, o segundo elemento afeta o índice1
, 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"
podSpec.persistence
Tipo: collection
Disponível somente em
clusterSpecItem
objetos passados paraspec.configSrv.clusterSpecList
espec.shard.clusterSpecList
. Substitui a configuração de persistência existente para um determinado cluster.
statefulSet
Tipo: collection
Fornece a configuração para o StatefulSet substituição para cada um dos StatefulSets do cluster em uma implantação do 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.duplicateServiceObjects
Observação
Este campo está disponível exclusivamente para sistemas de cluster cluster fragmentado de vários clusters, que estão atualmente em visualização pública.
Tipo: booleano
Opcional
Padrão:
true
Ignorado se a topologia não for
MultiCluster
. Aplica-se a serviços para todos os componentes do cluster fragmentado :mongos
,configSrv
eshards
.- Se definido como
true
: - O Operador Kubernetes cria todos os
Pod Services
de todos os clusters de membros em cada cluster de membros. - Se definido como
false
: - O operador Kubernetes cria apenas
- Se definido como
spec.mongos.clusterSpecList
Observação
Este campo está disponível exclusivamente para sistemas de cluster cluster fragmentado de vários clusters, que estão atualmente em visualização pública.
Tipo : array de objetos
Necessário se
topology=MultiCluster
Uma array de objetos para uso em sistemas de cluster fragmentado de cluster fragmentado com os seguintes campos de nível superior:
clusterName
Tipo: string
Nome do cluster onde o MongoDB Enterprise Kubernetes Operator agenda o StatefulSet.
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 MongoDB database em um cluster. Cada serviço externo tem seletores que correspondem ao 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çãoName
<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 omongod
.publishNotReadyAddress
true
Especifica que os registros DNS são criados mesmo que o Pod não esteja pronto. Não defina comofalse
para 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.
members
Tipo: número
Número de membros no conjunto de réplicas MongoDB.
memberConfig
Tipo: collection
Especificação para cada shard do MongoDB e seus membros em sua implantação do MongoDB de cluster multi-Kubernetes.
A ordem dos elementos no objeto para shard deve refletir a ordem dos membros no conjunto de réplicas. Por exemplo, o primeiro elemento afeta o Pod no índice
0
, o segundo elemento afeta o índice1
, 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"
statefulSet
Tipo: collection
Fornece a configuração para o StatefulSet substituição para cada um dos StatefulSets do cluster em uma implantação do 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.shard.clusterSpecList
Observação
Este campo está disponível exclusivamente para sistemas de cluster cluster fragmentado de vários clusters, que estão atualmente em visualização pública.
Tipo : array de objetos
Necessário se
topology=MultiCluster
Uma array de objetos para uso em sistemas de cluster fragmentado de cluster fragmentado com os seguintes campos de nível superior:
clusterName
Tipo: string
Nome do cluster onde o MongoDB Enterprise Kubernetes Operator agenda o StatefulSet.
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 MongoDB database em um cluster. Cada serviço externo tem seletores que correspondem ao 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çãoName
<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 omongod
.publishNotReadyAddress
true
Especifica que os registros DNS são criados mesmo que o Pod não esteja pronto. Não defina comofalse
para 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.
members
Tipo: número
Número de membros no conjunto de réplicas MongoDB.
memberConfig
Tipo: collection
Especificação para cada shard do MongoDB e seus membros em sua implantação do MongoDB de cluster multi-Kubernetes.
A ordem dos elementos no objeto para shard deve refletir a ordem dos membros no conjunto de réplicas. Por exemplo, o primeiro elemento afeta o Pod no índice
0
, o segundo elemento afeta o índice1
, 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"
podSpec.persistence
Tipo: collection
Disponível somente em
clusterSpecItem
objetos passados paraspec.configSrv.clusterSpecList
espec.shard.clusterSpecList
. Substitui a configuração de persistência existente para um determinado cluster.
statefulSet
Tipo: collection
Fornece a configuração para o StatefulSet substituição para cada um dos StatefulSets do cluster em uma implantação do 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.shardOverrides
Observação
Este campo está disponível exclusivamente para sistemas de cluster cluster fragmentado de vários clusters, que estão atualmente em visualização pública.
Tipo : array de objetos
Opcional
Lista que contém substituições por fragmento. Cada objeto contém os seguintes campos:
shardNames
Obrigatório
O nome do shard ao qual esta substituição se aplica.
podSpec.Persistence
Opcional
Define como o Operador Kubernetes cria e vincula volumes persistentes a shards. Para
topology=MultiCluster
, ele define as configurações de persistência para todos os clusters de membros. Você pode definir as configurações de persistência para um cluster de membros específico nospec.shardOverrides.clusterSpecList.persistence
.additionalMongodConfig
Opcional
Substituição específica de fragmento para
spec.shard.additionalMongodConfig
.agent
Opcional
Substituição específica de fragmento para
spec.shard.agent
.statefulSet
Opcional
Substituição específica de shard para
spec.shardPodSpec.podTemplate
espec.shard.clusterSpecList.statefulSet
.members
Opcional
Disponível apenas quando
topology=SingleCluster
. Substituição específica do fragmento para substituição despec.mongodsPerShardCount
.memberConfig
Opcional
Disponível apenas quando
topology=SingleCluster
. Substituição específica de fragmento paraspec.shard.memberConfig
.
spec.shardPodSpec.persistence.single
Tipo: collection
O operador Kubernetes cria uma declaração de volume persistente e monte todos os três diretórios para dados, diário e registros no mesmo Volume persistente .
Observação
Você deve definir os valores nesta collection se
spec.persistent
: true
.Você pode definir esta collection ou as collections
persistence.multiple
, mas não ambas.
EscalarTipo de DadosDescriçãolabelSelector
stringTag usada para vincular volumes montados a diretórios.storage
stringTamanho mínimo do volume persistente que deve ser montado. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC.
O valor padrão é 16Gi.
Por exemplo, se cada nó de shard do cluster fragmentado fragmentado requer 60 gigabytes de espaço de armazenamento, defina esse valor como
60Gi
.storageClass
stringTipo de armazenamento especificado em uma declaração de volume persistente. Você pode criar esse tipo de armazenamento como um objeto StorageClass antes de usá-lo nesta especificação de objeto.
Certifique-se de definir a StorageClass para
reclaimPolicy
Reter. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente é removido.
Configurações do Prometheus
Você pode usar o Prometheus com seu recurso standalone, conjuntos de réplicas ou clusters fragmentados. Para saber mais, consulte Distribuir um recurso para usar com Prometheus. Para ver um exemplo, consulte Recurso MongoDB com Prometheus.
As seguintes configurações se aplicam quando você usa Prometheus com o recurso MongoDB:
spec.prometheus.metricsPath
Tipo: string
Opcional
Padrão:
"/metrics"
String legível por humanos que indica o caminho para o endpoint de métricas. Se você não especificar essa configuração, o padrão será aplicado.
spec.prometheus.passwordSecretRef
Tipo: objeto
Condicional
Objeto que contém os detalhes do segredo para autenticação HTTP básica. Se você deseja usar o Prometheus com seu recurso MongoDB, especifique esta configuração.
spec.prometheus.passwordSecretRef.key
Tipo: string
Opcional
Padrão:
"password"
String legível por humanos que identifica a chave no segredo que armazena a senha para autenticação HTTP básica. Se você não especificar essa configuração, o padrão será aplicado.
spec.prometheus.passwordSecretRef.name
Tipo: string
Condicional
Etiqueta legível por humanos que identifica o segredo que contém a senha para autenticação HTTP básica. Se você deseja usar o Prometheus com seu recurso MongoDB, especifique esta configuração.
spec.prometheus.port
Tipo: inteiro
Opcional
Padrão: 9216
Número que identifica a porta à qual o endpoint de métricas se conectará. Se você não especificar essa configuração, o padrão será aplicado.
spec.prometheus.tlseSecretKeyRef
Tipo: objeto
Opcional
Objeto que contém os detalhes do segredo para a autenticação TLS .
spec.prometheus.tlseSecretKeyRef.key
Tipo: string
Opcional
Padrão:
"password"
String legível por humanos que identifica a chave no segredo que armazena a senha para autenticação TLS. Se você não especificar essa configuração, o padrão será aplicado.
spec.prometheus.tlseSecretKeyRef.name
Tipo: string
Condicional
Etiqueta legível por humanos que identifica o segredo que contém a senha para autenticação TLS . Se quiser usar o Prometheus com seu recurso MongoDB e quiser usar a autenticação TLS , você deverá especificar essa configuração.
Configurações de segurança
As configurações de segurança a seguir se aplicam somente aos tipos de recursos do conjunto de réplicas e do cluster fragmentado:
spec.security.tls.enabled
Tipo: booleano
Padrão:
false
Importante
spec.security.tls.enabled
tornou-se obsoleto a partir da versão 1.19 do operador Kubernetes. Para habilitar o TLS, forneça um valor para a configuraçãospec.security.certsSecretPrefix
.Criptografa comunicações usando certificados TLS entre:
O MongoDB hospeda em um conjunto de réplicas ou configuração de cluster fragmentado
Clientes (
mongo
shell, drivers, MongoDB Compass e outros) e o deployment do MongoDB
Por padrão,
net.ssl.mode
está configurado pararequireSSL
. Para alterar o modo TLS usado para conexões de cliente e banco de dados, consultespec.additionalMongodConfig.net.ssl.mode
.
spec.security.tls.ca
Tipo: string
Forneça o nome do ConfigMap que armazena a CA para o
MongoDB
recurso .Importante
Se você usar uma CA customizada para assinar seus certificados TLS para o recurso
MongoDB
, deverá especificar esse parâmetro.O operador Kubernetes exige que você nomeie o certificado de recurso
MongoDB
ca-pem
no ConfigMap.
spec.security.certsSecretPrefix
Tipo: string
Texto para prefixo para os secrets do Kubernetes que você criou que contêm chaves TLS e certificados do conjunto de réplicas ou do cluster fragmentado.
É necessário prefixar os segredos com
<prefix>-<metadata.name>
.Por exemplo, se você chamar sua implantação
my-deployment
de e definir o prefixo comomdb
, deverá nomear o segredo TLS para as comunicações TLS do clientemdb-my-deployment-cert
. Além disso, você deve nomear o segredo TLS para autenticação interna do cluster (se ativado) comomdb-my-deployment-clusterfile
.Para saber mais sobre como nomear os segredos que contêm seus certificados TLS, veja o tópico em Distribuir um conjunto de réplicas que se aplica so seu sistema.
spec.security.tls.additionalCertificateDomains
Tipo: booleano
Lista de todos os domínios que devem ser adicionados aos certificados TLS para cada pod neste sistema. 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. Em vez disso, use
spec.connectivity.replicaSetHorizons
.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 quaisquer CSRs 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.additionalMongodConfig.net.ssl.mode
Tipo: string
Padrão:
requireSSL
Especifica qual
sslMode
é utilizado para conexões de rede. As seguintes opções são válidas:ValorDescriçãoallowSSL
As conexões entre servidores não usam TLS. Para conexões recebidas, o servidor aceita tanto TLS quanto não TLS.preferSSL
As conexões entre servidores usam TLS. Para conexões recebidas, o servidor aceita tanto TLS quanto não TLS.requireSSL
O servidor utiliza e aceita somente conexões criptografadas TLS.
spec.additionalMongodConfig.net.tls.disabledProtocols
Tipo: string
Novidade na versão 4.2 do MongoDB.
Impede que um servidor MongoDB em execução com TLS aceite conexões recebidas que usam um protocolo ou protocolos específicos. Para especificar vários protocolos, use uma lista de protocolos separados por vírgulas. Por exemplo,
TLS1_0,TLS1_1
.Esta configuração reconhece os seguintes protocolos:
TLS1_0
,TLS1_1
,TLS1_2
e iniciando no MongoDB 4.0.4 (e 3.6.9),TLS1_3
. Se você especificar um protocolo não reconhecido, o servidor não será iniciado.No macOS, você não pode desabilitar
TLS1_1
e habilitarTLS1_0
eTLS1_2
. Você também deve desabilitar pelo menosTLS1_0
ouTLS1_2
. Por exemplo,TLS1_0,TLS1_1
desabilitaTLS1_2
no macOS.A lista de protocolos que você desabilita substitui a lista padrão de protocolos desabilitados.
A partir da versão 4.0 do MongoDB, O MongoDB desabilita o uso do TLS 1.0 se o TLS 1.1+ estiver disponível no sistema. Para habilitar o TLS desabilitado 1.0, especifique
none
como o valor paraspec.additionalMongodConfig.net.tls.disabledProtocols
. Para saber mais sobre essa configuração, consulte Desativar TLS 1.0.Os membros dos conjuntos de réplicas e cluster fragmentado devem falar pelo menos um protocolo em comum.
spec.security.authentication
Tipo: collection
Especificações de autenticação para a implementação do MongoDB.
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 definido como
true
, você deverá definir um mecanismo de autenticação emspec.security.authentication.modes
.Importante
O Kubernetes Operator gerencia 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 UI ou as APIs do Cloud Manager ou do Ops Manager enquanto essa configuração existir na especificação do recurso.Omita esta configuração se quiser gerenciar a autenticação usando a UI ou as APIs do Cloud Manager ou do Ops Manager.
spec.security.authentication.modes
Tipo: array
Especifica o mecanismo de autenticação usado pelo deployment do MongoDB. Os valores válidos são
SCRAM
,SCRAM-SHA-1
,MONGODB-CR
,X509
eLDAP
. RecomendamosSCRAM-SHA-256
(SCRAM
) em vez deSCRAM-SHA-1
. Ao especificarSCRAM-SHA-1
, você também deverá especificarMONGODB-CR
.Observação
Autenticação interna do cluster X.509
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:fornecer um valor para a configuração
spec.security.certsSecretPrefix
.'
Se você fornecer mais de um valor para
spec.security.authentication.modes
, também deverá especificar um valor paraspec.security.authentication.agents.mode
.
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.requireClientTLSAuthentication
Tipo: booleano
Padrão:
false
Especifica se o host MongoDB exige que os clientes se conectem usando um certificado TLS. O padrão é
true
se você habilitar a autenticação TLS.Para habilitar a autenticação TLS, forneça um valor para a configuração
spec.security.certsSecretPrefix
.
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 ativar a autenticação LDAP , defina
spec.security.authentication.modes
como["LDAP"]
.
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 comonone
.Observação
Se você especificar uma string diferente de
none
outls
, o Kubernetes Operator continuará definindo a configuração comotls
.
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 TLS do servidor LDAP .
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 TLS do servidor LDAP .
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.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.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
password
campo , que armazena a senha.
spec.security.authentication.ldap.authzQueryTemplate
Tipo: string
Necessário para a autorização LDAP.
Um RFC4515 e RFC4516 Modelo de URL de query formatado em LDAP 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. (Disponível a partir da versão 4.2 do MongoDB)
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, espec.security.authentication.agents.mode
éLDAP
ouX509
.
spec.security.authentication.ldap.userToDNMapping
Tipo: string
Mapeia o nome de usuário fornecido para
mongod
oumongos
para autenticação em um Nome Distinto (DN) LDAP.
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.agents
Tipo: collection
Configuração de autenticação do MongoDB Agent para o projeto do Cloud Manager ou Ops Manager.
spec.security.authentication.agents.mode
Tipo: string
O mecanismo de autenticação que os MongoDB Agents de seu deployment do MongoDB usam. Os valores válidos são
SCRAM
,SCARM-SHA-1
,MONGODB-CR
,X509
eLDAP
. O valor especificado também deve estar presente emspec.security.authentication.modes
. RecomendamosSCRAM-SHA-256
(SCRAM
) em vezSCRAM-SHA-1
. Se você especificarSCRAM-SHA-1
, você também deverá especificarMONGODB-CR
.Esta configuração é necessária se você especificou mais de um valor para
spec.security.authentication.modes
.
spec.security.authentication.agents.automationUserName
Tipo: string
Nome do usuário que os MongoDB Agents usam para interagir com seu deployment do MongoDB. 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 é exigida se
spec.security.authentication.agents.mode
forLDAP
.
spec.security.authentication.agents.automationPasswordSecretRef
Tipo: collection
Detalhes do segredo que contém a senha do usuário
spec.security.authentication.agents.automationUserName
.Esta configuração é exigida se
spec.security.authentication.agents.mode
forLDAP
.
spec.security.authentication.agents.automationPasswordSecretRef.name
Tipo: string
Nome do segredo que contém a senha do usuário
spec.security.authentication.agents.automationUserName
. 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> Este segredo deve conter uma chave cujo valor corresponda à senha do usuário
spec.security.authentication.agents.automationUserName
em seu sistema do LDAP.Esta configuração é exigida se
spec.security.authentication.agents.mode
forLDAP
.
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 emspec.security.authentication.agents.automationUserName
.Esta configuração é exigida se
spec.security.authentication.agents.mode
forLDAP
.
spec.security.authentication.agents.clientCertificateSecretRef.name
Tipo: string
Especifica o segredo que contém o certificado TLS do MongoDB Agent. Se omitido, o padrão é
agent-certs
.Este segredo deve conter as seguintes chaves, cujos valores são certificados TLS que podem ser validados pelo servidor:
mms-automation-agent-pem
mms-backup-agent-pem
mms-monitoring-agent-pem
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> \ --from-file=mms-backup-agent-pem=<backup-cert.pem> \ --from-file=mms-monitoring-agent-pem=<monitoring-cert.pem> \ --namespace=<metadata.namespace>
spec.security.roles
Tipo: array
Array que define funções definidas pelo usuário que oferecem controle de acesso refinado sobre sua implantação MongoDB.
Para habilitar roles definidas pelo usuário, o
spec.security.authentication.enabled
deve sertrue
.Exemplo
Neste exemplo, um role definido pelo usuário denominado
customRole
permite aos usuários atribuídos a este role a:Inserir documentos na collection
cats
no banco de dadospets
eEncontre e insira documentos na collection
dogs
no banco de dadospets
.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-replica-set> 6 spec: 7 members: 3 8 version: "4.2.2-ent" 9 type: ReplicaSet 10 opsManager: 11 configMapRef: 12 name: <configMap.metadata.name> 13 credentials: <mycredentials> 14 persistent: true 15 security: 16 authentication: 17 enabled: true 18 modes: 19 - "SCRAM" 20 roles: 21 - role: "customRole" 22 db: admin 23 privileges: 24 - actions: 25 - insert 26 resource: 27 collection: cats 28 db: pets 29 - actions: 30 - insert 31 - find 32 resource: 33 collection: dogs 34 db: pets 35 ...
spec.security.roles.db
Tipo: string
O banco de dados no qual você deseja armazenar a função definida pelo usuário.
Exemplo
admin
spec.security.roles.authenticationRestrictions
Tipo: array
Array que define o endereço IP a partir do qual e para o qual os usuários atribuídos a este
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.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
actions
se aplicam.Essa collection deve incluir:
As configurações
spec.security.roles.privileges.resource.database
espec.security.roles.privileges.resource.collection
, ouA configuração
spec.security.roles.privileges.resource.cluster
com um valor detrue
.
spec.security.roles.privileges.resource.database
Tipo: string
Banco de dados ao qual o privilégio
actions
se aplica.Se você fornecer um valor para esta configuração, você também deverá fornecer um valor para
spec.security.roles.privileges.resource.collection
.
spec.security.roles.privileges.resource.collection
Tipo: string
Collection no
database
à qual o privilégioactions
se aplica.Se você fornecer um valor para esta configuração, você também deverá fornecer um valor para
spec.security.roles.privileges.resource.database
.
spec.security.roles.privileges.resource.cluster
Tipo: booleano
Padrão: falso
Sinalizador que indica que o privilégio
actions
se aplica a todos os bancos de dados e collections no MongoDB deployment. Se omitido, o padrão éfalse
.Se definido como true, não forneça valores para
spec.security.roles.privileges.resource.database
espec.security.roles.privileges.resource.collection
.
Exemplos
O exemplo a seguir mostra uma especificação de recurso para um sistema standalone com cada configuração fornecida:
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: my-standalone spec: version: "4.2.2-ent" service: my-service opsManager: # Alias of cloudManager configMapRef: name: my-project credentials: my-credentials persistent: true type: Standalone additionalMongodConfig: systemLog: logAppend: true verbosity: 4 operationProfiling: mode: slowOp podSpec: persistence: single: storage: "12Gi" storageClass: standard labelSelector: matchExpressions: - {key: environment, operator: In, values: [dev]} podTemplate: metadata: labels: label1: mycustomlabel affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: "mykey" weight: 50 ...
O exemplo a seguir mostra uma especificação de recurso para um conjunto de réplicas com cada configuração fornecida:
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: my-replica-set spec: members: 3 version: "6.0.0-ent" service: my-service opsManager: # Alias of cloudManager configMapRef: name: my-project credentials: my-credentials persistent: true type: ReplicaSet podSpec: persistence: multiple: data: storage: "10Gi" journal: storage: "1Gi" labelSelector: matchLabels: app: "my-app" logs: storage: "500M" storageClass: standard podTemplate: metadata: labels: label1: mycustomlabel affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: "mykey" weight: 50 spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: "mykey" weight: 50 security: certsSecretPrefix: "prefix" tls: ca: custom-ca authentication: enabled: true modes: ["X509"] internalCluster: "X509" statefulSet: spec: serviceName: my-service additionalMongodConfig: net: ssl: mode: preferSSL ...
O exemplo a seguir mostra uma especificação de recurso para um cluster fragmentado com cada configuração fornecida:
apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: my-sharded-cluster spec: shardCount: 2 mongodsPerShardCount: 3 mongosCount: 2 configServerCount: 3 version: "6.0.0-ent" service: my-service type: ShardedCluster ## Please Note: The default Kubernetes cluster name is ## `cluster.local`. ## If your cluster has been configured with another name, you can ## specify it with the `clusterDomain` attribute. opsManager: # Alias of cloudManager configMapRef: name: my-project credentials: my-credentials persistent: true configSrvPodSpec: # if "persistence" element is omitted then Operator uses the # default size (5Gi) for mounting single Persistent Volume podTemplate: spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: nodeId mongosPodSpec: podTemplate: spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: nodeId shardPodSpec: persistence: multiple: # if the child of "multiple" is omitted then the default size will be used. # 16GB for "data", 1GB for "journal", 3GB for "logs" data: storage: "20Gi" logs: storage: "4Gi" storageClass: standard podTemplate: spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: nodeId mongos: additionalMongodConfig: systemLog: logAppend: true verbosity: 4 configSrv: additionalMongodConfig: operationProfiling: mode: slowOp shard: additionalMongodConfig: storage: journal: commitIntervalMs: 50 security: certsSecretPrefix: "prefix" tls: ca: custom-ca authentication: enabled: true modes: ["X509"] internalCluster: "X509" statefulSet: spec: serviceName: my-service ...
Configurações do StatefulSet
As configurações StatefulSets a seguir se aplicam somente aos tipos de recursos de cluster fragmentado e conjunto de réplicas.
spec.statefulSet.spec
Tipo: collection
Especificação do StatefulSet que o MongoDB Enterprise Kubernetes Operator cria para
MongoDB
recursos .
spec.statefulSet.spec.serviceName
Tipo: string
Padrão:
<resource_name>-svc
e<resource_name>-svc-external
Nome do serviço Kubernetes a ser criado ou utilizado para um StatefulSet. Se o serviço com este nome já existir, o MongoDB Enterprise Kubernetes Operator não o excluirá ou recriará. Esta configuração permite que você crie seus próprios serviços personalizados e permite que o operador Kubernetes os reutilize.