Documentação do Oracle Cloud Infrastructure

Oracle Database Operator para Kubernetes

Ao ativar o complemento de cluster do Oracle Database Operator for Kubernetes, você pode especificar os pares de chave/valor a seguir como argumentos.

Observe que, para usar o Oracle Database Operator como um complemento de cluster, você também precisa implantar o cert-manager (como um produto standalone ou como um complemento de cluster). Se você implantar o cert-manager como um produto independente, defina o argumento de configuração skipAddonDependenciesCheck como true.

Argumentos de Configuração Comuns à maioria dos Complementos de Cluster
Chave (API e CLI) Nome para Exibição da Chave (Console) Descrição Obrigatório/Opcional Valor Padrão Valor de Exemplo
affinity afinidade

Um grupo de regras de programação de afinidade.

Formato JSON em texto simples ou codificado em Base64.

Não utilizado por:
  • Operador de GPU Nvidia
Possíveis equivalentes:
  • Descoberta de Recursos do Nó, use master.affinity
  • Operador de Rede NVIDIA, use operator.affinity
  • Driver SMB CSI, use contoller.affinity
  • Operador de GPU AMD, use controllerManager.affinity
 Opcional nulo nulo
nodeSelectors seletores de nó

Você pode usar seletores de nó e labels de nó para controlar os nós de trabalho nos quais os pods complementares são executados.

Para que um pod seja executado em um nó, o seletor de nós do pod deve ter a mesma chave/valor do label do nó.

Defina nodeSelectors como um par de chave/valor que corresponda ao seletor de nós do pod e ao label do nó de trabalho.

Formato JSON em texto simples ou codificado em Base64.

Não utilizado por:
  • Operador de GPU NVIDIA
  • SMB do Driver CSI
Possíveis equivalentes:
  • Descoberta de Recursos do Nó, use worker.nodeSelector
  • Operador de Rede NVIDIA, use operator.nodeSelectors
  • Operador de GPU AMD, use selector ou controllerManager.nodeSelector
 Opcional nulo {"foo":"bar", "foo2": "bar2"}

O pod só será executado em nós que tenham o label foo=bar ou foo2=bar2.
numOfReplicas numOfReplicas O número de réplicas da implantação do complemento.
Não utilizado por:
  • Plug-in de GPU AMD
  • Operador de GPU NVIDIA
  • Operador de Rede NVIDIA
  • SMB do Driver CSI
Possíveis equivalentes:
  • CoreDNS, use nodesPerReplica
  • Descoberta de Recursos do Nó, use master.replicaCount
  • Operador de GPU AMD, use controllerManager.replicas
 Obrigatório 1

Cria uma réplica da implantação do complemento por cluster.

 2

Cria duas réplicas da implantação do complemento por cluster.
rollingUpdate rollingUpdate

Controla o comportamento desejado de atualização incremental por maxSurge e maxUnavailable.

Formato JSON em texto simples ou codificado em Base64.

Não utilizado por:
  • Descoberta de Recurso do Nó
  • Operador de Rede NVIDIA
  • SMB do Driver CSI
Possíveis equivalentes:
  • Operador de GPU NVIDIA, use daemonsets.rollingUpdate.maxUnavailable
  • Operador de GPU AMD, use upgradePolicy em devicePlugin, metricsExporter, testRunner, configManager ou draDriver
 Opcional nulo nulo
tolerations tolerâncias

Você pode usar taints e tolerations para controlar os nós de trabalho nos quais os pods complementares são executados.

Para que um pod seja executado em um nó que tenha uma taint, o pod deve ter uma tolerância correspondente.

Defina tolerations como um par de chave/valor que corresponda à tolerância do pod e à mancha do nó de trabalho.

Formato JSON em texto simples ou codificado em Base64.

Possíveis equivalentes:
  • Descoberta de Recursos do Nó, use master.tolerations e/ou worker.tolerations
  • Operador de GPU NVIDIA, use daemonsets.tolerations
  • Operador de Rede NVIDIA, use operator.tolerations
  • Driver SMB CSI, use controller.tolerations
  • Operador de GPU AMD, usar tolerações em devicePlugin, metricsExporter, testRunner, configManager, draDriver ou controllerManager
 Opcional nulo [{"key":"tolerationKeyFoo", "value":"tolerationValBar", "effect":"noSchedule", "operator":"exists"}]

Somente pods que têm essa tolerância podem ser executados em nós de trabalho que têm a mancha tolerationKeyFoo=tolerationValBar:noSchedule.
topologySpreadConstraints topologySpreadConstraints

Como distribuir pods correspondentes entre a topologia fornecida.

Formato JSON em texto simples ou codificado em Base64.

Não utilizado por:
  • Descoberta de Recurso do Nó
  • Operador de GPU NVIDIA
  • Operador de Rede NVIDIA
  • SMB do Driver CSI
  • AMD GPU Operator
 Opcional nulo nulo
Argumentos de Configuração Específicos para esta Extensão de Cluster
Chave (API e CLI) Nome para Exibição da Chave (Console) Descrição Obrigatório/Opcional Valor Padrão Valor de Exemplo
manager.ContainerResources recursos de contêiner do gerente

Você pode especificar as quantidades de recursos solicitadas pelos contêineres de complementos e definir limites de uso de recursos que os contêineres de complementos não podem exceder.

Formato JSON em texto simples ou codificado em Base64.

 Opcional nulo {"limits": {"cpu": "500m", "memory": "200Mi" }, "requests": {"cpu": "100m", "memory": "100Mi"}}

Crie contêineres complementares que solicitem 100 mililitros de CPU e 100 mebibytes de memória. Limite os contêineres complementares a 500 milicores de CPU e 200 mebibytes de memória.
skipAddonDependenciesCheck skipAddonDependenciesCheck Verificar se outros complementos necessários foram implantados (como o complemento cert-manager). Opcional nulo true
Considerações sobre Clusters Grandes

A tabela a seguir descreve considerações para configurar este complemento de cluster em clusters grandes.

Nome do Argumento Número wrt de Atribuições dos Nós Descrição À medida que o tamanho do cluster aumenta Riscos Recomendação
manager.ContainerResources S

Define as solicitações e os limites de CPU e memória para os pods do operador.

À medida que o tamanho do cluster aumenta, o operador experimenta:

  • Crescimento significativo no cache do informante
  • Mais streams de relógio
  • Um volume de memória maior
  • Mais atividade de reconciliação

Se os recursos forem subdimensionados:

  • Os pods do operador podem ser encerrados porque excedem seus limites de memória.
  • A latência de reconciliação pode aumentar.
  • Um backlog de fila de eventos pode atrasar o processamento.

Aloque memória e CPU suficientes para lidar com a carga adicional em clusters grandes. Dê especial atenção ao dimensionamento de memória porque o cache do informador aumenta à medida que o tamanho do cluster aumenta.

numOfReplicas N

Controla o número de pods do operador implantados.

Réplicas adicionais melhoram a tolerância a falhas e o failover por meio da eleição do líder.

Apenas um pod atua como o líder ativo de um controlador. Outras réplicas permanecem em espera e assumem apenas se o líder falhar.

O aumento do número de réplicas não fornece dimensionamento linear do throughput de reconciliação porque as réplicas stand-by não processam loops de reconciliação para o mesmo controlador.

Uma baixa contagem de réplicas aumenta o risco de tempo de inatividade do operador e recuperação mais lenta após falhas.

Use um número moderado de réplicas, como três a cinco, para fornecer alta disponibilidade. Não aumente o número de réplicas para melhorar o desempenho da reconciliação.

affinity / nodeSelectors / tolerations N

Controle onde os pods do operador são programados no cluster.

Posicionamento de pod apropriado:

  • Reduz a interferência de cargas de trabalho com muitos recursos.
  • Mantém o operador em nós estáveis com menos rotatividade e menos interrupções.
  • Permite que o operador execute em nós dedicados ou de alta memória que são adequados para complementos de plano de controle.
Se não estiver definido corretamente, o Oracle Database Operator poderá pousar nos nós errados ou falhar na programação, o que pode levar a reconciliação atrasada e desempenho instável.

Use esses argumentos para programar pods do operador em nós de infraestrutura dedicados. Aplique regras antiafinidade de pod sempre que necessário para melhorar a resiliência.

rollingUpdate N

Controla a estratégia de atualização de implantação do operador.

Durante as atualizações em clusters grandes, a estratégia de atualização contínua:

  • Impede o tempo de inatividade do operador.
  • Mantém a disponibilidade de pelo menos algumas réplicas.
  • Evita que todas as réplicas sejam encerradas ao mesmo tempo.

Se não estiver configurado corretamente, um upgrade poderá reduzir rapidamente muitos pods do Oracle Database Operator de uma só vez, causando atrasos na reconciliação e perda de segurança de failover.

Configure definições de atualização incremental, como maxUnavailable e maxSurge , para permitir que os upgrades sejam concluídos sem interromper as operações do cluster.

topologySpreadConstraints N

Controla como as réplicas do operador são distribuídas entre nós e domínios de disponibilidade.

A distribuição de réplicas impede que todos os pods do operador sejam executados no mesmo nó ou no mesmo domínio de disponibilidade e reduz o efeito de falhas no nó ou no domínio de disponibilidade.

Se não estiver configurado corretamente, os pods do operador poderão ser programados no mesmo nó ou na mesma zona de disponibilidade, aumentando o risco de perder várias réplicas durante uma falha de nó ou zona.

Use restrições de distribuição de topologia para fornecer alta disponibilidade em clusters grandes.