Documentation Oracle Cloud Infrastructure

Prérequis pour le déploiement du contrôleur d'entrée natif OCI en tant qu'extension de cluster

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

Avant de déployer le contrôleur d'entrée natif OCI en tant qu'extension de cluster :

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).

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

Octroi de droits d'accès à l'extension de cluster de contrôleurs entrants natifs OCI

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.

Notez que l'installation du contrôleur d'entrée natif OCI en tant qu'extension de cluster échoue si vous n'avez pas encore installé cert-manager, en tant que produit open source ou en tant qu'extension de cluster.