Documentation Oracle Cloud Infrastructure

Oracle Database Operator for Kubernetes

Lorsque vous activez l'extension de cluster Oracle Database Operator for Kubernetes, vous pouvez transmettre les paires clé/valeur suivantes en tant qu'arguments.

Pour utiliser Oracle Database Operator en tant qu'extension de cluster, vous devez également déployer le gestionnaire de certificats (en tant que produit autonome ou en tant qu'extension de cluster). Si vous déployez le gestionnaire de certificats en tant que produit autonome, définissez l'argument de configuration skipAddonDependenciesCheck sur true.

Arguments de configuration communs à la plupart des modules complémentaires de cluster
Clé (API et CLI) Nom d'affichage de la clé (console) Description Obligatoire/Facultatif Valeur par défaut Exemple de valeur
affinity affinité

Groupe de règles de programmation d'affinité.

Format JSON en texte brut ou encodé Base64.

Non utilisé par:
  • Opérateur GPU Nvidia
Equivalents possibles :
  • Repérage des fonctionnalités de noeud, utilisez master.affinity
  • Opérateur réseau NVIDIA, utilisez operator.affinity
  • Pilote CSI SMB, utilisez contoller.affinity
  • Opérateur de GPU AMD, utilisez controllerManager.affinity
 Facultatif NULL NULL
nodeSelectors Sélecteurs de noeud

Vous pouvez utiliser des sélecteurs de noeud et des libellés de noeud pour contrôler les noeuds de processus actif sur lesquels les pods d'extension sont exécutés.

Pour qu'un pod s'exécute sur un noeud, le sélecteur de noeud du pod doit avoir la même clé/valeur que l'étiquette du noeud.

Définissez nodeSelectors sur une paire clé/valeur correspondant à la fois au sélecteur de noeud du pod et au libellé du noeud de processus actif.

Format JSON en texte brut ou encodé Base64.

Non utilisé par:
  • Opérateur GPU NVIDIA
  • Pilote CSI SMB
Equivalents possibles :
  • Repérage des fonctionnalités de noeud, utilisez worker.nodeSelector
  • Opérateur réseau NVIDIA, utilisez operator.nodeSelectors
  • Opérateur de GPU AMD, utilisez selector ou controllerManager.nodeSelector
 Facultatif NULL {"foo":"bar", "foo2": "bar2"}

Le pod s'exécutera uniquement sur les noeuds possédant le libellé foo=bar ou foo2=bar2.
numOfReplicas numOfReplicas Nombre de répliques du déploiement de l'extension.
Non utilisé par:
  • Module d'extension GPU AMD
  • Opérateur GPU NVIDIA
  • Opérateur réseau NVIDIA
  • Pilote CSI SMB
Equivalents possibles :
  • CoreDNS, utilisez nodesPerReplica
  • Repérage des fonctionnalités de noeud, utilisez master.replicaCount
  • Opérateur de GPU AMD, utilisez controllerManager.replicas
 Requis 1

Crée une réplique du déploiement d'extension par cluster.

 2

Crée deux répliques du déploiement d'extension par cluster.
rollingUpdate rollingUpdate

Contrôle le comportement souhaité de la mise à jour non simultanée par maxSurge et maxUnavailable.

Format JSON en texte brut ou encodé Base64.

Non utilisé par:
  • Repérage des fonctionnalités du noeud
  • Opérateur réseau NVIDIA
  • Pilote CSI SMB
Equivalents possibles :
  • Opérateur de GPU NVIDIA, utilisez daemonsets.rollingUpdate.maxUnavailable
  • Opérateur de GPU AMD, utilisez upgradePolicy dans devicePlugin, metricsExporter, testRunner, configManager ou draDriver
 Facultatif NULL NULL
tolerations tolérances

Vous pouvez utiliser des tolérances et des taches pour contrôler les noeuds de processus actif sur lesquels les pods d'extension s'exécutent.

Pour qu'un pod s'exécute sur un noeud présentant une entorse, le pod doit avoir une tolérance correspondante.

Définissez tolerations sur une paire clé/valeur correspondant à la fois à la tolérance du pod et à la tache du noeud de processus actif.

Format JSON en texte brut ou encodé Base64.

Equivalents possibles :
  • Repérage des fonctionnalités de noeud, utilisez master.tolerations et/ou worker.tolerations
  • Opérateur de GPU NVIDIA, utilisez daemonsets.tolerations
  • Opérateur réseau NVIDIA, utilisez operator.tolerations
  • Pilote CSI SMB, utilisez controller.tolerations
  • Opérateur GPU AMD, utilisez les tolérances dans devicePlugin, metricsExporter, testRunner, configManager, draDriver ou controllerManager
 Facultatif NULL [{"key":"tolerationKeyFoo", "value":"tolerationValBar", "effect":"noSchedule", "operator":"exists"}]

Seuls les pods présentant cette tolérance peuvent être exécutés sur des noeuds de processus actif présentant la tache tolerationKeyFoo=tolerationValBar:noSchedule.
topologySpreadConstraints topologySpreadConstraints

Comment répartir les pods correspondants entre la topologie donnée.

Format JSON en texte brut ou encodé Base64.

Non utilisé par:
  • Repérage des fonctionnalités du noeud
  • Opérateur GPU NVIDIA
  • Opérateur réseau NVIDIA
  • Pilote CSI SMB
  • Opérateur de GPU AMD
 Facultatif NULL NULL
Arguments de configuration propres à ce module complémentaire de cluster
Clé (API et CLI) Nom d'affichage de la clé (console) Description Obligatoire/Facultatif Valeur par défaut Exemple de valeur
manager.ContainerResources ressources de conteneur gestionnaire

Vous pouvez spécifier les quantités de ressources demandées par les conteneurs d'extension et définir les limites d'utilisation des ressources que les conteneurs d'extension ne peuvent pas dépasser.

Format JSON en texte brut ou encodé Base64.

 Facultatif NULL {"limits": {"cpu": "500m", "memory": "200Mi" }, "requests": {"cpu": "100m", "memory": "100Mi"}}

Créez des conteneurs d'extension qui demandent 100 milllicores de CPU et 100 mégaoctets de mémoire. Limitez les conteneurs d'extension à 500 milllicores de CPU et 200 mégaoctets de mémoire.
skipAddonDependenciesCheck skipAddonDependenciesCheck Vérifier si d'autres modules nécessaires ont été déployés (comme le module du gestionnaire de certificats). Facultatif NULL true
Considérations relatives aux clusters volumineux

Le tableau suivant décrit les considérations relatives à la configuration de ce module complémentaire de cluster dans les clusters volumineux.

Nom d'argument Nombre de noeuds de processus métier de rôles Description à mesure que la taille du cluster augmente Risques Recommandation
manager.ContainerResources Y (Oui)

Définit les demandes et les limites de CPU et de mémoire pour les pods d'opérateur.

Au fur et à mesure que la taille du cluster augmente, l'opérateur effectue les opérations suivantes :

  • Croissance significative du cache informateur
  • Plus de flux de surveillance
  • Une empreinte mémoire plus importante
  • Plus d'activités de rapprochement

Si les ressources sont sous-dimensionnées :

  • Les pods d'opérateur peuvent être arrêtés car ils dépassent leurs limites de mémoire.
  • La latence de rapprochement peut augmenter.
  • Un backlog de file d'attente d'événements peut retarder le traitement.

Allouez suffisamment de mémoire et de CPU pour gérer la charge supplémentaire dans les clusters volumineux. Faites particulièrement attention au dimensionnement de la mémoire car le cache d'indicateurs augmente à mesure que la taille du cluster augmente.

numOfReplicas N

Contrôle le nombre de pods d'opérateur déployés.

D'autres répliques améliorent la tolérance aux pannes et le basculement en cas d'incident grâce à l'élection des dirigeants.

Un seul pod sert de leader actif pour un contrôleur. D'autres répliques restent en veille et ne prennent le relais que si l'amorce échoue.

L'augmentation du nombre de répliques ne permet pas une mise à l'échelle linéaire du débit de rapprochement car les répliques de secours ne traitent pas les boucles de rapprochement pour le même contrôleur.

Un faible nombre de répliques augmente le risque de temps d'arrêt de l'opérateur et de récupération plus lente après des échecs.

Utilisez un nombre modéré de répliques, par exemple de trois à cinq, pour fournir une haute disponibilité. N'augmentez pas le nombre de répliques pour améliorer les performances de rapprochement.

affinity / nodeSelectors / tolerations N

Contrôlez l'emplacement de programmation des pods d'opérateur dans le cluster.

Positionnement approprié du pod :

  • Réduit les interférences des charges de travail gourmandes en ressources.
  • Maintient l'opérateur sur des noeuds stables avec moins d'attrition et moins de perturbations.
  • Permet à l'opérateur de s'exécuter sur des noeuds dédiés ou à mémoire élevée adaptés aux modules de plan de contrôle.
S'il n'est pas défini correctement, l'opérateur Oracle Database peut atterrir sur les mauvais noeuds ou ne pas planifier du tout, ce qui peut entraîner un retard de rapprochement et des performances instables.

Utilisez ces arguments pour programmer des pods d'opérateur sur des noeuds d'infrastructure dédiés. Appliquez des règles anti-affinité de pod si nécessaire pour améliorer la résilience.

rollingUpdate N

Contrôle la stratégie de mise à jour du déploiement pour l'opérateur.

Lors des mises à niveau dans des clusters volumineux, la stratégie de mise à jour non simultanée :

  • Empêche les temps d'arrêt des opérateurs.
  • Maintient la disponibilité d'au moins certaines répliques.
  • Empêche l'arrêt simultané de toutes les répliques.

Si elle n'est pas correctement configurée, une mise à niveau peut brièvement arrêter trop de pods Oracle Database Operator à la fois, ce qui entraîne des retards de rapprochement et une perte de sécurité du basculement.

Configurez les paramètres de mise à jour non simultanée, tels que maxUnavailable et maxSurge , pour permettre aux mises à niveau de se terminer sans interrompre les opérations de cluster.

topologySpreadConstraints N

Contrôle la répartition des répliques d'opérateurs entre les noeuds et les domaines de disponibilité.

La distribution de répliques empêche tous les pods d'opérateur de s'exécuter sur le même noeud ou dans le même domaine de disponibilité et réduit l'effet des pannes de noeud ou de domaine de disponibilité.

S'ils ne sont pas configurés correctement, les pods d'opérateur peuvent être planifiés sur le même noeud ou dans la même zone de disponibilité, ce qui augmente le risque de perte de plusieurs répliques lors d'une défaillance de noeud ou de zone.

Utilisez des contraintes de répartition de topologie pour fournir une haute disponibilité dans les clusters volumineux.