Documentation sur Oracle Cloud Infrastructure

Préalables au déploiement du contrôleur de trafic entrant natif OCI en tant que module complémentaire de grappe

Découvrez ce que vous devez faire avant de déployer le contrôleur de trafic entrant natif OCI en tant que module complémentaire de grappe pour équilibrer la charge et acheminer le trafic entrant vers les pods de service exécutés sur les noeuds de travail d'une grappe Kubernetes.

Avant de déployer le contrôleur de trafic entrant natif OCI en tant que module complémentaire de grappe :

Configuration d'un principal d'instance, d'utilisateur ou de charge de travail pour activer l'accès aux services et ressources OCI

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

Note :

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

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

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

Pour configurer un principal d'instance :

  1. Créez un nouveau groupe dynamique pour contenir les instances de calcul hébergeant les noeuds de travail de la grappe :
    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 appartiennent les instances de calcul.

    3. Suivez les instructions sous Pour créer un groupe dynamique et donnez un nom à ce groupe (par exemple, acme-oke-native-ingress-controller-dyn-grp).

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

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

      Par exemple :

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

Avant de déployer le contrôleur de trafic entrant natif OCI, vous devez :

Utilisation des 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 de trafic entrant natif OCI d'effectuer des actions sur les ressources de service OCI.

Pour configurer un principal d'utilisateur :

  1. Si aucun utilisateur approprié n'existe déjà, créez un utilisateur dans le service IAM (voir Pour créer un utilisateur).
  2. Si aucun groupe approprié n'existe déjà, créez un groupe dans le service IAM (voir Pour créer un groupe).
  3. Ajoutez l'utilisateur au groupe (voir Pour ajouter un utilisateur à un groupe).

  4. Obtenez les éléments suivants :

  5. Chargez la clé publique à partir de la paire de clés dans la console. Voir Comment charger la clé publique.
  6. Créez un fichier de configuration en tant que fichier .yaml contenant les informations d'identification et de connexion, dans le format suivant :
    auth:
  region: <region-identifier>
  passphrase: <passphrase>
  user: <user-ocid>
  fingerprint: <fingerprint>
  tenancy: <tenancy-ocid>
    où :
    • region: <region-identifier> est la région dans laquelle réside la grappe. Par exemple : us-ashburn-1
    • passphrase: <passphrase> spécifie la phrase secrète utilisée pour la clé si elle est chiffrée.
    • user: <user-ocid> est l'OCID de l'utilisateur que le contrôleur de trafic entrant natif OCI doit utiliser.
    • fingerprint: <fingerprint> est l'empreinte numérique de la clé publique.
    • tenancy: <tenancy-ocid> est l'OCID de la location contenant la grappe.

    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 la grappe en entrant :
    
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é privée téléchargé. Par exemple, ./oci/oci_api_key.pem
    • --namespace <namespace> indique l'espace de noms contenant le contrôleur de trafic entrant 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 de trafic entrant natif OCI, vous devez :

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

Vous pouvez configurer un principal d'identité de charge de travail pour permettre au contrôleur de trafic entrant natif OCI d'effectuer des actions sur les ressources de service OCI. Notez que vous ne pouvez utiliser des principaux d'identité de charge de travail qu'avec des grappes améliorées.

Pour configurer un principal d'identité de charge de travail :

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

Avant de déployer le contrôleur de trafic entrant natif OCI, vous devez :

Octroi d'autorisations au module complémentaire de grappe du contrôleur de trafic entrant natif OCI

Le contrôleur de trafic entrant natif OCI nécessite des autorisations pour accéder aux ressources créées par d'autres services Oracle Cloud Infrastructure (tels que le service d'équilibreur de charge et le service de certificats). Les autorisations que vous accordez sont les mêmes, que vous installiez le contrôleur de trafic entrant natif OCI en tant que programme autonome ou en tant que module complémentaire de grappe. En outre, les autorisations sont les mêmes, que vous ayez configuré un principal d'instance, un principal d'utilisateur ou un principal d'identité de charge de travail pour le contrôleur de trafic entrant natif OCI. Toutefois, la façon dont vous accordez ces autorisations dépend du type de principal que vous avez configuré :

Pour configurer des autorisations pour le contrôleur de trafic entrant natif OCI, créez une politique 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 de travail (dans le cas des principaux d'identité de charge de travail), avec des énoncés de politique pour accéder aux services et aux ressources OCI :

  1. Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques.
  2. Suivez les instructions sous Pour créer une politique et donnez un nom à la politique (par exemple, acme-oke-native-ingress-controller-policy).

  3. Si vous utilisez des principaux d'instance ou d'utilisateur, entrez des énoncés de politique pour autoriser l'accès aux services et ressources OCI utilisés par le contrôleur de trafic entrant natif OCI, dans le format suivant :

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

    où :

    • <group|dynamic-group> est group (dans le cas des principaux d'utilisateur) ou dynamic-group (dans le cas des principaux d'instance)
    • <subject-name> est le nom du groupe (dans le cas des principaux d'utilisateur) ou le nom du groupe dynamique (dans le cas des principaux d'instance). Par exemple, acme-oke-nat-ing-cont-dyn-grp. Notez que si un groupe ou un groupe dynamique ne se trouve pas dans le domaine d'identité par défaut, ajoutez le préfixe <group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>' au nom du groupe ou du groupe dynamique. Vous pouvez également spécifier un groupe ou un groupe dynamique à l'aide de son OCID, dans le format group id <group-ocid> ou dynamic-group id <dynamic-group-ocid>.
    • <verb> <resource> est l'un des suivants (toutes ces opérations sont requises dans des énoncés de politique distincts) :
      • 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 (obligatoire uniquement si vous voulez que le contrôleur de trafic entrant natif OCI applique des marqueurs définis aux équilibreurs de charge, voir Application de marqueurs définis à l'équilibreur de charge)
    • <location> est l'un des suivants :
      • tenancy, si vous voulez que le contrôleur de trafic entrant natif OCI ait accès aux ressources de l'ensemble de la location.
      • compartment <compartment-name> si vous voulez que le contrôleur de trafic entrant natif OCI ait uniquement accès aux ressources du compartiment portant le nom 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 énoncés de politique 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 liste complète d'énoncés de politique :

    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 de travail, entrez des énoncés de politique pour autoriser l'accès aux services et ressources OCI utilisés par le contrôleur de trafic entrant natif OCI, dans le 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 suivants (toutes ces opérations sont requises dans des énoncés de politique distincts) :
      • 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 (obligatoire uniquement si vous voulez que le contrôleur de trafic entrant natif OCI applique des marqueurs définis aux équilibreurs de charge, voir Application de marqueurs définis à l'équilibreur de charge)
    • <location> est l'un des suivants :
      • tenancy, si vous voulez que le contrôleur de trafic entrant natif OCI ait accès aux ressources de l'ensemble de la location.
      • compartment <compartment-name> si vous voulez que le contrôleur de trafic entrant natif OCI ait uniquement accès aux ressources du compartiment portant le nom compartment <compartment-name>.
    • request.principal.namespace = 'native-ingress-controller-system' est le nom de l'espace de noms créé pour le contrôleur de trafic entrant 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 de trafic entrant natif OCI lors de l'installation.
    • <cluster-ocid> est l'OCID de la grappe 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 pour la liste complète des énoncés de politique 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 de cert-manager

Le contrôleur de trafic entrant natif OCI, qu'il soit installé en tant que programme autonome ou en tant que module complémentaire de grappe, utilise des webhooks pour injecter des portes de disponibilité des pods dans les spécifications de pod. Pour assurer la sécurité, le serveur webhook doit fonctionner en mode HTTPS, ce qui nécessite une paire de certificats et de clés. Le contrôleur de trafic entrant natif OCI utilise le gestionnaire de certificats (également connu sous le nom de gestionnaire de certificats) pour générer et gérer les certificats et les clés pour le serveur de webhook. Vous devez donc installer le gestionnaire de certificats sur la grappe pour utiliser les portes de disponibilité des pods.

Que vous installiez le contrôleur de trafic entrant natif OCI en tant que programme autonome ou en tant que module complémentaire de grappe, vous pouvez installer et exécuter cert-manager de deux façons :

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

    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 que module complémentaire de grappe. Pour plus d'informations sur l'installation de cert-manager en tant que module complémentaire de grappe, voir Installation d'un module complémentaire de grappe.

Pour plus d'informations sur cert-manager, consultez la documentation sur cert-manager.io.

Notez que l'installation du contrôleur de trafic entrant natif OCI en tant que module complémentaire de grappe échoue si vous n'avez pas déjà installé cert-manager, soit en tant que produit à code source libre, soit en tant que module complémentaire de grappe.