5.9. Configuration de l'événement Tuning

5.9.1. Remplacer les configurations de déploiement du système Knative Eventing

Vous pouvez remplacer les configurations par défaut pour certains déploiements spécifiques en modifiant la spécification deployments dans la ressource personnalisée (CR) KnativeEventing. Actuellement, la modification des paramètres de configuration par défaut est prise en charge pour les champs eventing-controller, eventing-webhook, et imc-controller, ainsi que pour les champs readiness et liveness pour les sondes.

Important

La spécification replicas ne peut pas remplacer le nombre de répliques pour les déploiements qui utilisent l'Horizontal Pod Autoscaler (HPA), et ne fonctionne pas pour le déploiement eventing-webhook.

Note

Vous ne pouvez remplacer que les sondes définies par défaut dans le déploiement.

Tous les déploiements de Knative Serving définissent par défaut une sonde de préparation et une sonde de disponibilité, à ces exceptions près :

  • net-kourier-controller et 3scale-kourier-gateway ne définissent qu'une sonde de préparation.
  • net-istio-controller et net-istio-webhook ne définissent pas de sondes.

5.9.1.1. Remplacer les configurations de déploiement

Actuellement, le remplacement des paramètres de configuration par défaut est possible pour les champs eventing-controller, eventing-webhook et imc-controller, ainsi que pour les champs readiness et liveness pour les sondes.

Important

La spécification replicas ne peut pas remplacer le nombre de répliques pour les déploiements qui utilisent l'Horizontal Pod Autoscaler (HPA), et ne fonctionne pas pour le déploiement eventing-webhook.

Dans l'exemple suivant, une CR KnativeEventing remplace le déploiement eventing-controller de sorte que :

  • Le délai d'attente de la sonde readiness eventing-controller est fixé à 10 secondes.
  • Le déploiement a spécifié des limites de ressources de CPU et de mémoire.
  • Le déploiement comporte 3 répliques.
  • L'étiquette example-label: label est ajoutée.
  • L'annotation example-annotation: annotation est ajoutée.
  • Le champ nodeSelector est défini pour sélectionner les nœuds portant l'étiquette disktype: hdd.

Exemple de CR KnativeEventing

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  deployments:
  - name: eventing-controller
    readinessProbes: 1
      - container: controller
        timeoutSeconds: 10
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

1
Vous pouvez utiliser les surcharges de sonde readiness et liveness pour remplacer tous les champs d'une sonde dans un conteneur d'un déploiement comme spécifié dans l'API Kubernetes, à l'exception des champs liés au gestionnaire de la sonde : exec, grpc, httpGet, et tcpSocket.
Note

Les paramètres d'étiquetage et d'annotation de KnativeEventing CR remplacent les étiquettes et les annotations du déploiement, tant pour le déploiement lui-même que pour les pods qui en résultent.

Ressources supplémentaires

5.9.2. Haute disponibilité

La haute disponibilité (HA) est une fonctionnalité standard des API Kubernetes qui permet de garantir que les API restent opérationnelles en cas de perturbation. Dans un déploiement HA, si un contrôleur actif tombe en panne ou est supprimé, un autre contrôleur est immédiatement disponible. Ce contrôleur prend en charge le traitement des API qui étaient gérées par le contrôleur qui n'est plus disponible.

HA dans OpenShift Serverless est disponible via l'élection de leader, qui est activée par défaut après l'installation du plan de contrôle Knative Serving ou Eventing. Lors de l'utilisation d'un modèle HA d'élection de leader, les instances de contrôleurs sont déjà planifiées et en cours d'exécution dans le cluster avant qu'elles ne soient nécessaires. Ces instances de contrôleurs sont en concurrence pour l'utilisation d'une ressource partagée, connue sous le nom de verrou d'élection du leader. L'instance du contrôleur qui a accès à la ressource de verrouillage de l'élection du leader à un moment donné est appelée le leader.

HA dans OpenShift Serverless est disponible via l'élection de leader, qui est activée par défaut après l'installation du plan de contrôle Knative Serving ou Eventing. Lors de l'utilisation d'un modèle HA d'élection de leader, les instances de contrôleurs sont déjà planifiées et en cours d'exécution dans le cluster avant qu'elles ne soient nécessaires. Ces instances de contrôleurs sont en concurrence pour l'utilisation d'une ressource partagée, connue sous le nom de verrou d'élection du leader. L'instance du contrôleur qui a accès à la ressource de verrouillage de l'élection du leader à un moment donné est appelée le leader.

5.9.2.1. Configuration des répliques de haute disponibilité pour Knative Eventing

La haute disponibilité (HA) est disponible par défaut pour les composants Knative Eventing eventing-controller, eventing-webhook, imc-controller, imc-dispatcher, et mt-broker-controller, qui sont configurés pour avoir deux répliques chacun par défaut. Vous pouvez changer le nombre de répliques pour ces composants en modifiant la valeur spec.high-availability.replicas dans la ressource personnalisée (CR) KnativeEventing.

Note

Pour Knative Eventing, les déploiements mt-broker-filter et mt-broker-ingress ne sont pas mis à l'échelle par HA. Si plusieurs déploiements sont nécessaires, redimensionnez ces composants manuellement.

Conditions préalables

  • Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
  • L'opérateur OpenShift Serverless et Knative Eventing sont installés sur votre cluster.

Procédure

  1. Dans la perspective de la console web de OpenShift Container Platform Administrator, naviguez vers OperatorHub → Installed Operators.
  2. Sélectionnez l'espace de noms knative-eventing.
  3. Cliquez sur Knative Eventing dans la liste de Provided APIs pour l'OpenShift Serverless Operator afin d'accéder à l'onglet Knative Eventing.

  4. Cliquez sur knative-eventing, puis sur l'onglet YAML dans la page knative-eventing.

    Knative Eventing YAML

  5. Modifier le nombre de répliques dans le CR KnativeEventing:

    Exemple YAML

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  high-availability:
    replicas: 3

5.9.2.2. Configurer les répliques de haute disponibilité pour l'implémentation du courtier Knative pour Apache Kafka

La haute disponibilité (HA) est disponible par défaut pour l'implémentation du courtier Knative pour les composants Apache Kafka kafka-controller et kafka-webhook-eventing, qui sont configurés pour avoir deux répliques par défaut. Vous pouvez changer le nombre de répliques pour ces composants en modifiant la valeur spec.high-availability.replicas dans la ressource personnalisée (CR) KnativeKafka.

Conditions préalables

  • Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
  • L'opérateur OpenShift Serverless et le courtier Knative pour Apache Kafka sont installés sur votre cluster.

Procédure

  1. Dans la perspective de la console web de OpenShift Container Platform Administrator, naviguez vers OperatorHub → Installed Operators.
  2. Sélectionnez l'espace de noms knative-eventing.
  3. Cliquez sur Knative Kafka dans la liste de Provided APIs pour l'OpenShift Serverless Operator afin d'accéder à l'onglet Knative Kafka.

  4. Cliquez sur knative-kafka, puis sur l'onglet YAML dans la page knative-kafka.

    Knative Kafka YAML

  5. Modifier le nombre de répliques dans le CR KnativeKafka:

    Exemple YAML

    apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
  name: knative-kafka
  namespace: knative-eventing
spec:
  high-availability:
    replicas: 3