Documentation Oracle Cloud Infrastructure

Configuration du contrôleur d'entrée natif OCI sur un cluster Kubernetes

Découvrez comment configurer le contrôleur d'entrée natif OCI pour implémenter les règles et les options de configuration définies dans une ressource entrante Kubernetes 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.

Le contrôleur d'entrée natif OCI implémente les règles et les options de configuration définies dans une ressource entrante Kubernetes pour équilibrer la charge et acheminer le trafic entrant vers les pods de service exécutés sur les noeuds de processus actif d'un cluster. Le contrôleur d'entrée natif OCI crée un équilibreur de charge flexible OCI pour gérer les demandes et configure l'équilibreur de charge OCI pour qu'il achemine les demandes en fonction des règles définies dans la ressource entrante. Si des modifications sont apportées aux règles de routage ou à d'autres ressources de prise en charge, le contrôleur d'entrée natif OCI met à jour la configuration de l'équilibreur de charge en conséquence. Le contrôleur d'entrée natif OCI s'exécute en tant que pod unique, sur un noeud de processus actif sélectionné de manière aléatoire dans le cluster.

Le contrôleur d'entrée natif OCI crée les ressources d'équilibreur de charge OCI comme suit :

  • Equilibreur de charge pour chaque ressource IngressClass sur laquelle vous avez indiqué le contrôleur d'entrée natif OCI comme contrôleur.
  • Ensemble de back-ends d'équilibreur de charge pour chaque combinaison unique de nom de service Kubernetes et de numéro de port que vous incluez dans les règles de routage des ressources Ingress du cluster.
  • Processus d'écoute d'équilibreur de charge pour chaque port unique que vous incluez dans les règles de routage dans les ressources Ingress du cluster. Le contrôleur d'entrée natif OCI détermine le protocole (HTTP, HTTPS, HTTP/2) pour chaque processus d'écoute en fonction de la configuration du back-end entrant.

Le contrôleur d'entrée natif OCI ajoute en tant que back-ends à un ensemble de back-ends les pods qui servent d'adresses pour le port et le nom de service Kubernetes respectifs, ou les noeuds de processus actif sur lesquels ces pods peuvent être exécutés, selon le module d'extension CNI utilisé par le cluster pour le réseau de pod :

  • Si le cluster utilise le module d'extension CNI de mise en réseau de pod natif OCI VCN pour le réseau de pod, le contrôleur d'entrée natif OCI ajoute les pods en tant que back-ends.
  • Si le cluster utilise le module d'extension CNI flannel pour la mise en réseau de pod, le contrôleur d'entrée natif OCI ajoute les noeuds de processus actif en tant que back-ends. Dans ce cas, le contrôleur d'entrée natif OCI utilise le paramètre externalTrafficPolicy dans le manifeste du service pour déterminer les noeuds de processus actif à ajouter à l'ensemble de back-ends, comme suit :
    • Si la valeur est externalTrafficPolicy: Cluster, le contrôleur d'entrée natif OCI ajoute à l'ensemble de back-ends tous les noeuds de processus actif du cluster.
    • Si la valeur est externalTrafficPolicy: Local, le contrôleur d'entrée natif OCI ajoute à l'ensemble de back-ends uniquement les noeuds de processus actif sur lesquels les pods du service ont été déployés.

Le contrôleur d'entrée natif OCI crée des ressources d'équilibreur de charge OCI soumises aux limites de service d'équilibreur de charge normales en ce qui concerne le nombre total d'adresses IP, d'ensembles de back-ends, de processus d'écoute et de serveurs back-end. Pour plus d'informations, reportez-vous à Limites sur les ressources Load Balancing.

Vous pouvez déployer le contrôleur d'entrée natif OCI sur un cluster Kubernetes de l'une ou l'autre des manières suivantes :

Lorsque vous utilisez le contrôleur d'entrée natif OCI pour équilibrer la charge et acheminer le trafic entrant, tenez compte des points suivants :

  • Si vous installez le contrôleur d'entrée natif OCI en tant que programme autonome, le cluster doit exécuter Kubernetes version 1.26 ou ultérieure. Si vous installez le contrôleur d'entrée natif OCI en tant qu'extension de cluster, le cluster doit exécuter Kubernetes version 1.28 ou ultérieure.
  • Des règles de sécurité de sous-réseau d'équilibreur de charge doivent être configurées pour le cluster.
  • Le cluster peut utiliser le module d'extension CNI de mise en réseau de pod natif OCI VCN ou le module d'extension CNI flannel pour les fonctions de réseau de pod. Si le cluster utilise le module d'extension CNI flannel pour la mise en réseau de pod, le contrôleur d'entrée natif OCI prend uniquement en charge les services back-end de type: NodePort, comme indiqué dans le manifeste du service.
  • 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.
  • Vous pouvez indiquer des principaux d'identité de charge globale avec des clusters améliorés, mais pas avec des clusters de base.
  • Si le contrôleur d'entrée natif OCI a déjà été déployé sur un cluster en tant que programme autonome, ne déployez pas également l'extension de cluster de contrôleur d'entrée natif OCI sur le cluster.