Documentation Oracle Cloud Infrastructure

Prérequis pour le déploiement du contrôleur d'entrée natif OCI en tant que programme autonome

Découvrez ce que vous devez faire pour pouvoir déployer le contrôleur d'entrée natif OCI en tant que programme autonome afin d'équilibrer la charge et d'acheminer le trafic entrant vers des pods de service exécutés sur des noeuds de processus actif dans un cluster Kubernetes.

Avant de déployer le contrôleur d'entrée natif OCI en tant que programme autonome :

Configuration d'un principal d'instance, d'un principal d'utilisateur ou d'un principal d'identité de charge globale pour permettre l'accès aux services et ressources OCI

Pour créer un équilibreur de charge et acheminer le trafic entrant, le contrôleur d'entrée natif OCI, qu'il soit installé en tant que programme autonome ou en tant qu'extension de cluster, effectue des actions sur d'autres ressources de service Oracle Cloud Infrastructure (y compris le service Load Balancer et le service Certificates). Pour effectuer ces actions sur les ressources de service OCI, le pod de contrôleur d'entrée natif OCI utilise les informations d'identification d'un acteur autorisé (ou d'un principal). Vous pouvez actuellement configurer les types de principal suivants pour permettre au contrôleur d'entrée natif OCI d'effectuer des actions sur les ressources de service OCI :

Remarque :

  • L'utilisation de principaux d'instance pour permettre au contrôleur d'entrée natif OCI d'accéder aux services et aux ressources OCI n'est pas prise en charge dans les clusters avec des noeuds virtuels.
  • L'utilisation de principaux d'identité de charge globale pour permettre au contrôleur d'entrée natif OCI d'accéder aux services et aux ressources OCI est prise en charge avec des clusters améliorés, mais pas avec des clusters de base.

Utilisation de principaux d'instance pour permettre l'accès aux services et aux ressources OCI

Vous pouvez configurer un principal d'instance pour permettre au contrôleur d'entrée natif OCI d'effectuer des actions sur les ressources de service OCI. Notez que vous pouvez uniquement utiliser des principaux d'instance avec des noeuds gérés.

Pour configurer un principal d'instance, procédez comme suit :

  1. Créez un groupe dynamique pour contenir les instances de calcul hébergeant les noeuds de processus actif du cluster :
    1. Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Domaines. Sous Domaine d'identité, sélectionnez Groupes dynamiques.

    2. Sélectionnez le compartiment auquel les instances de calcul appartiennent.

    3. Suivez les instructions dans Procédure de création d'un groupe dynamique et donnez un nom au groupe dynamique (par exemple, acme-oke-native-ingress-controller-dyn-grp).

    4. Entrez une règle qui inclut les instances de calcul dans le compartiment, au format suivant :
      ALL {instance.compartment.id = '<compartment-ocid>'}

      où <compartment-ocid> est l'OCID du compartiment dans lequel les pools de noeuds de cluster sont créés.

      Par exemple :

      ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
    5. Sélectionnez Créer un groupe dynamiques.

Avant de déployer le contrôleur d'entrée natif OCI, vous allez :

Utilisation de principaux d'utilisateur pour permettre l'accès aux services et ressources OCI

Vous pouvez configurer un principal d'utilisateur pour permettre au contrôleur d'entrée natif OCI d'effectuer des actions sur les ressources de service OCI.

Pour configurer un principal d'utilisateur, procédez comme suit :

  1. Si un utilisateur approprié n'existe pas encore, créez-en un dans IAM (reportez-vous à Procédure de création d'un utilisateur).
  2. Si aucun groupe approprié n'existe déjà, créez-en un dans IAM (reportez-vous à Procédure de création d'un groupe).
  3. Ajoutez l'utilisateur au groupe (reportez-vous à Procédure d'ajout d'un utilisateur à un groupe).

  4. Obtenez les éléments suivants :

  5. Téléchargez la clé publique à partir de la paire de clés dans la console. Reportez-vous à Procédure de téléchargement de la clé publique.
  6. Créez un fichier de configuration en tant que fichier .yaml contenant les informations d'identification, au format suivant :
    auth:
  region: <region-identifier>
  passphrase: <passphrase>
  user: <user-ocid>
  fingerprint: <fingerprint>
  tenancy: <tenancy-ocid>
    où :
    • region: <region-identifier> est la région où réside le cluster. Par exemple, us-ashburn-1
    • passphrase: <passphrase> indique la phrase de passe utilisée pour la clé si elle est cryptée.
    • user: <user-ocid> est l'OCID de l'utilisateur que le contrôleur d'entrée natif OCI doit utiliser.
    • fingerprint: <fingerprint> est l'empreinte de la clé publique.
    • tenancy: <tenancy-ocid> est l'OCID de la location contenant le cluster.

    Par exemple :

    auth:
  region: us-ashburn-1
  passphrase: examplepass
  user: ocid1.user.oc1..aaaaaaaa_example
  fingerprint: 67:d9:74:4b:21:example
  tenancy: ocid1.tenancy.oc1..aaaaaaaa_example
  7. Créez une ressource de clé secrète Kubernetes dans le cluster en saisissant ce qui suit :
    
kubectl create secret generic <secret-name> \
--from-file=config=<config-file>.yaml \
--from-file=private-key=<private-key-file-path>.pem \
--namespace <namespace>
    où :
    • <secret-name> indique le nom de la clé secrète à créer. Par exemple, oci-config
    • --from-file=config=<config-file>.yaml indique le nom et le chemin du fichier .yaml contenant les informations d'identification que vous avez créées précédemment. Par exemple, user-auth-config.yaml
    • --from-file=private-key=./oci/oci_api_key.pem indique le nom et le chemin du fichier de clés privées téléchargé. Par exemple, ./oci/oci_api_key.pem
    • --namespace <namespace> indique l'espace de noms contenant le contrôleur d'entrée natif OCI

    Par exemple :

    
kubectl create secret generic oci-config \
--from-file=config=user-auth-config.yaml \
--from-file=private-key=./oci/oci_api_key.pem \
--namespace acme-namespace

Avant de déployer le contrôleur d'entrée natif OCI, vous devez :

Utilisation de principaux d'identité de charge globale pour permettre l'accès aux services et aux ressources OCI

Vous pouvez configurer un principal d'identité de charge globale pour permettre au contrôleur d'entrée natif OCI d'effectuer des actions sur les ressources de service OCI. Notez que vous pouvez uniquement utiliser des principaux d'identité de charge globale avec des clusters améliorés.

Pour configurer un principal d'identité de charge globale, procédez comme suit :

  1. Obtenez l'OCID du cluster (par exemple, à l'aide de l'onglet Détails du cluster de la console).

  1. Avant de déployer le contrôleur d'entrée natif OCI, vous allez :

Octroi de droits d'accès au contrôleur d'entrée natif OCI en tant que programme autonome

Le contrôleur d'entrée natif OCI nécessite des droits d'accès aux ressources créées par d'autres services Oracle Cloud Infrastructure (tels que le service Load Balancer et le service Certificates). Les droits d'accès que vous octroyez sont les mêmes, que vous installiez le contrôleur d'entrée natif OCI en tant que programme autonome ou en tant qu'extension de cluster. De plus, les droits d'accès sont identiques, que vous ayez configuré un principal d'instance, un principal d'utilisateur ou un principal d'identité de charge globale pour le contrôleur d'entrée natif OCI. Toutefois, la façon dont vous accordez ces autorisations dépend du type de principal que vous avez configuré :

Afin de configurer les droits d'accès pour le contrôleur d'entrée natif OCI, créez une stratégie pour le groupe (dans le cas des principaux d'utilisateur), pour le groupe dynamique (dans le cas des principaux d'instance) ou pour la charge globale (dans le cas des principaux d'identité de charge globale), avec des instructions de stratégie permettant d'accéder aux services et ressources OCI :

  1. Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Stratégies.
  2. Suivez les instructions dans Procédure de création d'une stratégie et donnez un nom à cette stratégie (par exemple, acme-oke-native-ingress-controller-policy).

  3. Si vous utilisez des principaux d'instance ou des principaux d'utilisateur, entrez des instructions de stratégie pour autoriser l'accès aux services et ressources OCI utilisés par le contrôleur d'entrée natif OCI, au format suivant :

    Allow <group|dynamic-group> <subject-name> to <verb> <resource> in <location>

    où :

    • <group|dynamic-group> correspond à group (dans le cas des principaux d'utilisateur) ou à dynamic-group (dans le cas des principaux d'instance)
    • <subject-name> est soit le nom du groupe (dans le cas des principaux utilisateur), soit le nom du groupe dynamique (dans le cas des principaux d'instance). Par exemple, acme-oke-nat-ing-cont-dyn-grp. Si un groupe ou un groupe dynamique ne se trouve pas dans le domaine d'identité par défaut, faites précéder le nom de groupe ou de groupe dynamique du nom de domaine d'identité au format <group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>'. Vous pouvez également indiquer un groupe ou un groupe dynamique à l'aide de son OCID, au format group id <group-ocid> ou dynamic-group id <dynamic-group-ocid>.
    • <verb> <resource> est l'un des éléments suivants (tous ces éléments sont requis dans des instructions de stratégie distinctes) :
      • manage load-balancers
      • use virtual-network-family
      • manage cabundles
      • manage cabundle-associations
      • manage leaf-certificates
      • read leaf-certificate-bundles
      • manage leaf-certificate-versions
      • manage certificate-associations
      • read certificate-authorities
      • manage certificate-authority-associations
      • read certificate-authority-bundles
      • read public-ips
      • manage floating-ips
      • manage waf-family
      • read cluster-family
      • use tag-namespaces (requis uniquement si vous voulez que le contrôleur d'entrée natif OCI applique des balises définies aux équilibreurs de charge, reportez-vous à Application de balises définies à l'équilibreur de charge)
    • <location> est l'un des éléments suivants :
      • tenancy, si vous voulez que le contrôleur d'entrée natif OCI ait accès aux ressources dans l'ensemble de la location.
      • compartment <compartment-name> si vous voulez uniquement que le contrôleur d'entrée natif OCI ait accès aux ressources du compartiment dont le nom est compartment <compartment-name>.

    Par exemple :

    Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment

    La syntaxe de la liste complète des instructions de stratégie est la suivante :

    Allow <group|dynamic-group> <subject-name> to manage load-balancers in <location>   
Allow <group|dynamic-group> <subject-name> to use virtual-network-family in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundles in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundle-associations in <location>
Allow <group|dynamic-group> <subject-name> to manage leaf-certificates in <location>
Allow <group|dynamic-group> <subject-name> to read leaf-certificate-bundles in <location>
Allow <group|dynamic-group> <subject-name> to manage leaf-certificate-versions in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authorities in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-authority-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authority-bundles in <location>
Allow <group|dynamic-group> <subject-name> to read public-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage floating-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage waf-family in <location>
Allow <group|dynamic-group> <subject-name> to read cluster-family in <location>
Allow <group|dynamic-group> <subject-name> to use tag-namespaces in <location>

    Exemple de la liste complète des instructions de stratégie :

    Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment   
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use virtual-network-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundle-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificates in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read leaf-certificate-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificate-versions in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authorities in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-authority-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authority-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read public-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage floating-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage waf-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read cluster-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use tag-namespaces in compartment acme-oke-cluster-compartment
  4. Si vous utilisez des principaux d'identité de charge globale, entrez des instructions de stratégie pour autoriser l'accès aux services et ressources OCI utilisés par le contrôleur d'entrée natif OCI, au format suivant :
    Allow any-user to <verb> <resource> in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

    où :

    • <verb> <resource> est l'un des éléments suivants (tous ces éléments sont requis dans des instructions de stratégie distinctes) :
      • manage load-balancers
      • use virtual-network-family
      • manage cabundles
      • manage cabundle-associations
      • manage leaf-certificates
      • read leaf-certificate-bundles
      • manage leaf-certificate-versions
      • manage certificate-associations
      • read certificate-authorities
      • manage certificate-authority-associations
      • read certificate-authority-bundles
      • read public-ips
      • manage floating-ips
      • manage waf-family
      • read cluster-family
      • use tag-namespaces (requis uniquement si vous voulez que le contrôleur d'entrée natif OCI applique des balises définies aux équilibreurs de charge, reportez-vous à Application de balises définies à l'équilibreur de charge)
    • <location> est l'un des éléments suivants :
      • tenancy, si vous voulez que le contrôleur d'entrée natif OCI ait accès aux ressources dans l'ensemble de la location.
      • compartment <compartment-name> si vous voulez uniquement que le contrôleur d'entrée natif OCI ait accès aux ressources du compartiment dont le nom est compartment <compartment-name>.
    • request.principal.namespace = 'native-ingress-controller-system' est le nom de l'espace de noms créé pour le contrôleur d'entrée natif OCI lors de l'installation.
    • request.principal.service_account = 'oci-native-ingress-controller' est le nom du compte de service créé pour le contrôleur d'entrée natif OCI lors de l'installation.
    • <cluster-ocid> est l'OCID du cluster que vous avez obtenu précédemment.

    Par exemple :

    Allow any-user to manage load-balancers in tenancy where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa______ska'}

    La syntaxe de la liste complète des instructions de stratégie est la suivante :

    Allow any-user to manage load-balancers in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use virtual-network-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundle-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage leaf-certificates in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read leaf-certificate-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage leaf-certificate-versions in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authorities in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-authority-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authority-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read public-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage floating-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage waf-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read cluster-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use tag-namespaces in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

Installation du gestionnaire de certificats

Le contrôleur d'entrée natif OCI, qu'il soit installé en tant que programme autonome ou en tant qu'extension de cluster, utilise des webhooks pour injecter des portes de préparation de pod dans les spécifications de pod. Pour assurer la sécurité, le serveur de webhook doit s'exécuter en mode HTTPS, ce qui nécessite une paire de certificats et de clés. Le contrôleur d'entrée natif OCI utilise Certificate Manager (également appelé cert-manager) pour générer et gérer les certificats et les clés du serveur de webhook. Vous devez donc installer cert-manager sur le cluster pour utiliser les portes de préparation de pod.

Que vous installiez le contrôleur d'entrée natif OCI en tant que programme autonome ou en tant qu'extension de cluster, vous pouvez installer et exécuter le gestionnaire de certificats de deux manières :

  • Vous pouvez installer et exécuter cert-manager en tant que produit open source, en saisissant :

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

  • Vous pouvez installer et exécuter cert-manager en tant qu'extension de cluster. Pour plus d'informations sur l'installation de cert-manager en tant qu'extension de cluster, reportez-vous à la section Installing a Cluster Add-on.

Pour plus d'informations sur cert-manager, reportez-vous à la documentation cert-manager.io.

Installation de l'interface de ligne de commande Helm pour installer le contrôleur d'entrée natif OCI en tant que programme autonome

Helm est un gestionnaire de packages pour Kubernetes. Helm est couramment utilisé pour créer, packager, configurer et déployer des applications Kubernetes en combinant des fichiers de configuration dans un seul package réutilisable appelé graphique Helm. Les graphiques sont packagés et distribués dans un format d'archive appelé archive de dossier. Un graphique contient les informations nécessaires pour installer un ensemble de ressources Kubernetes sur un cluster Kubernetes. Un graphique comprend :

  • un fichier chart.yaml, décrivant l'application,
  • un fichier values.yaml, fournissant des valeurs par défaut pour les paramètres d'application
  • modèles des fichiers utilisés par l'application
  • autres dépendances

Helm dispose également d'un client de ligne de commande, la CLI Helm (parfois appelée helm, toutes en minuscules).

Pour installer le contrôleur d'entrée natif OCI en tant que programme autonome, le contrôleur d'entrée natif OCI est disponible sous forme de graphique Helm. Pour pouvoir installer le graphique de contrôleur d'entrée natif OCI, vous devez d'abord installer l'interface de ligne de commande Helm.

Pour installer l'interface de ligne de commande Helm, suivez les instructions de la documentation d'installation Helm afin de télécharger et d'extraire le fichier d'archive ZIP ou tar.gz approprié.

Clonage du référentiel de contrôleur entrant natif OCI et définition des paramètres dans values.yaml

Pour cloner le contrôleur d'entrée natif OCI et définir des paramètres dans values.yaml en vue de l'installation du contrôleur d'entrée natif OCI en tant que programme autonome, procédez comme suit :

  1. Cloner le référentiel de contrôleur d'entrée natif OCI à partir de GitHub en saisissant la commande suivante :
    git clone https://github.com/oracle/oci-native-ingress-controller
  2. Dans le référentiel Git local, accédez au répertoire oci-native-ingress-controller et ouvrez le fichier values.yaml dans un éditeur de texte.
  3. Dans le fichier values.yaml, définissez le paramètre compartment_id sur l'OCID du compartiment dans lequel le contrôleur d'entrée natif OCI doit créer l'équilibreur de charge et le certificat OCI. Par exemple :
    compartment_id: "ocid1.compartment.oc1..aaaaaaaa______ddq"
  4. Dans le fichier values.yaml, définissez le paramètre subnet_id sur l'OCID du sous-réseau de l'équilibreur de charge. Par exemple :
    subnet_id: "ocid1.subnet.oc1.iad.aaaaaaaa______dba"
  5. Dans le fichier values.yaml, définissez le paramètre cluster_id sur l'OCID du cluster. Par exemple :
    cluster_id: "ocid1.cluster.oc1.iad.aaaaaaaa______ska"
  6. Dans le fichier values.yaml, indiquez comment le contrôleur d'entrée natif OCI doit accéder aux services et aux ressources OCI comme suit :
  7. (Facultatif) Si vous voulez exécuter plusieurs instances du contrôleur d'entrée natif OCI pour des raisons de disponibilité, modifiez la valeur de replicaCount dans le fichier values.yaml. Par exemple :
    replicaCount: 3
    Par défaut, replicaCount est défini sur 1, ce qui signifie qu'une instance du contrôleur d'entrée natif OCI est exécutée en tant que pod unique. Pour garantir la disponibilité, vous pouvez augmenter replicaCount (généralement vers 2 ou 3) afin d'exécuter plusieurs instances de contrôleur d'entrée natives OCI en tant que pods différents. Un pod est nommé en tant que leader et agit en tant que contrôleur d'entrée natif OCI, tandis que les pods restants attendent dans un état passif. Si le leader devient par la suite indisponible, l'un des autres pods est nommé en tant que leader et agit en tant que contrôleur d'entrée natif OCI.
  8. Enregistrez les modifications que vous avez apportées dans le fichier values.yaml et fermez le fichier.
  9. Si vous voulez que le contrôleur d'entrée natif OCI accède aux services et ressources OCI à l'aide d'un principal d'identité de charge globale, vous devez définir des variables d'environnement supplémentaires comme suit :
    1. Dans le référentiel Git local, accédez au répertoire oci-native-ingress-controller/templates et ouvrez le fichier deployment.yaml dans un éditeur de texte.
    2. Dans le fichier deployment.yaml, définissez les variables d'environnement suivantes comme indiqué : 
        env:
    - name: OCI_RESOURCE_PRINCIPAL_VERSION
      value: "2.2"
    - name: OCI_RESOURCE_PRINCIPAL_REGION
      value: "us-ashburn-1"
    3. Enregistrez les modifications que vous avez apportées dans le fichier deployment.yaml et fermez le fichier.