Configuration de ressources réseau pour la création et le déploiement de clusters

Découvrez comment configurer les ressources réseau pour utiliser Kubernetes Engine (OKE).

Pour pouvoir utiliser Kubernetes Engine afin de créer et de déployer des clusters dans les régions d'une location, procédez comme suit :

  • Dans la location, un compartiment doit déjà contenir les ressources réseau nécessaires (telles qu'un VCN, des sous-réseaux, une passerelle Internet, une table de routage, des groupes de sécurité réseau et/ou des listes de sécurité). Si ce compartiment n'existe pas, vous devez le créer. Les ressources réseau peuvent résider dans le compartiment racine. Toutefois, si plusieurs équipes sont censées créer des clusters, il est recommandé de créer un compartiment distinct pour chaque équipe.
  • Au sein du compartiment, les ressources réseau (telles qu'un VCN, des sous-réseaux, une passerelle Internet, une table de routage, des groupes de sécurité réseau et/ou des listes de sécurité) doivent être configurées de manière appropriée dans chaque région dans laquelle vous souhaitez créer et déployer des clusters. Lorsque vous créez un cluster, Kubernetes Engine peut automatiquement créer et configurer des ressources réseau dans le workflow Création rapide. Vous pouvez également spécifier explicitement les ressources réseau existantes à utiliser dans le workflow Création personnalisée. Si vous spécifiez des ressources réseau existantes, celles-ci doivent être correctement configurées au préalable, comme décrit dans cette rubrique.

Cette rubrique décrit la configuration requise pour chaque ressource réseau. Pour consulter les détails d'une configuration standard, reportez-vous à Exemples de configuration de ressource réseau.

Un certain nombre de tutoriels de développeur connexes sont disponibles.

Configuration du réseau cloud virtuel

Le réseau cloud virtuel dans lequel vous voulez créer et déployer des clusters doit être configuré comme suit :

Reportez-vous à Réseaux cloud virtuels et sous-réseaux et à Exemples de configuration de ressource réseau.

Configuration de la passerelle Internet

Si vous avez l'intention d'utiliser des sous-réseaux publics (pour les noeuds de processus actif, les équilibreurs de charge et/ou l'adresse d'API Kubernetes) et que les sous-réseaux nécessitent un accès à Internet ou à partir de celui-ci, le VCN doit disposer d'une passerelle Internet. La passerelle Internet doit être indiquée comme cible du bloc CIDR de destination 0.0.0.0/0 en tant que règle de routage dans une table de routage.

Reportez-vous à Réseaux cloud virtuels et sous-réseaux et à Exemples de configuration de ressource réseau.

Configuration de la passerelle NAT

Si vous avez l'intention d'utiliser des sous-réseaux privés (pour les noeuds de processus actif, l'adresse d'API Kubernetes ou les pods lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking) et que les sous-réseaux nécessitent un accès à Internet, le VCN doit disposer d'une passerelle NAT. Par exemple, si vous vous attendez à ce que les applications déployées téléchargent des logiciels ou accèdent à des services tiers.

La passerelle NAT doit être indiquée comme cible du bloc CIDR de destination 0.0.0.0/0 en tant que règle de routage dans une table de routage.

Reportez-vous à Passerelle NAT et à Exemples de configuration de ressource réseau.

Configuration de la passerelle de service

Si vous prévoyez d'utiliser des sous-réseaux privés pour les noeuds de processus actif, l'adresse d'API Kubernetes ou les pods lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking, le VCN doit disposer d'une passerelle de service.

Créez la passerelle de service dans le même VCN et le même compartiment que le sous-réseau des noeuds de processus actif, le sous-réseau de l'adresse d'API Kubernetes ou le sous-réseau des pods, et sélectionnez l'option Tous les services <region> dans Oracle Services Network.

La passerelle de service doit être indiquée comme cible pour Tous les services <region> dans Oracle Services Network en tant que règle de routage dans une table de routage.

Reportez-vous à Accès aux services Oracle : passerelle de service et à Exemples de configuration de ressource réseau.

Configuration de la table de routage

Table de routage pour les sous-réseaux de noeuds de processus actif

Si vous avez l'intention de déployer des noeuds de processus actif dans un sous-réseau public, la table de routage du sous-réseau doit comporter une règle de routage qui spécifie la passerelle Internet comme cible pour le bloc CIDR de destination 0.0.0.0/0.

Si vous avez l'intention de déployer des noeuds de processus actif dans un sous-réseau privé, la table de routage du sous-réseau doit comporter les éléments suivants :

  • une règle de routage qui spécifie la passerelle de service comme cible pour Tous les services <region> dans Oracle Services Network,
  • une règle de routage qui spécifie la passerelle NAT comme cible pour le bloc CIDR de destination 0.0.0.0/0.

Table de routage pour les sous-réseaux d'adresse d'API Kubernetes

Si vous avez l'intention de déployer l'adresse d'API Kubernetes dans un sous-réseau public, la table de routage du sous-réseau doit comporter une règle de routage qui spécifie la passerelle Internet comme cible pour le bloc CIDR de destination 0.0.0.0/0.

Si vous avez l'intention de déployer l'adresse d'API Kubernetes dans un sous-réseau privé, la table de routage du sous-réseau doit comporter :

  • une règle de routage qui spécifie la passerelle de service comme cible pour Tous les services <region> dans Oracle Services Network,
  • une règle de routage qui spécifie la passerelle NAT comme cible pour le bloc CIDR de destination 0.0.0.0/0.

Table de routage pour les sous-réseaux d'équilibreurs de charge

Si vous avez l'intention de déployer des équilibreurs de charge dans des sous-réseaux publics, la table de routage du sous-réseau doit comporter une règle de routage qui spécifie la passerelle Internet comme cible pour le bloc CIDR de destination 0.0.0.0/0.

Si vous avez l'intention de déployer des équilibreurs de charge dans des sous-réseaux privés, la table de routage du sous-réseau peut être vide.

Table de routage pour le sous-réseau de pods

Si vous avez l'intention d'utiliser le module d'extension CNI OCI VCN-Native Pod Networking pour la mise en réseau de pod, déployez des pods dans un sous-réseau privé. La table de routage du sous-réseau doit comporter les éléments suivants :

  • une règle de routage qui spécifie la passerelle de service comme cible pour Tous les services <region> dans Oracle Services Network,
  • une règle de routage qui spécifie la passerelle NAT comme cible pour le bloc CIDR de destination 0.0.0.0/0.

Si vous avez l'intention d'utiliser le module d'extension CNI flannel pour la mise en réseau de pod, aucun sous-réseau de pod n'est requis.

Remarques sur la configuration d'une table de routage

Configuration des options DHCP

Des options DHCP doivent être configurées pour le réseau cloud virtuel dans lequel vous voulez créer et déployer des clusters. La valeur par défaut Type DNS du résolveur Internet et de réseau cloud virtuel est acceptable.

Reportez-vous à Options DHCP et à Exemples de configuration de ressource réseau.

Configuration des sous-réseaux

Les caractéristiques du cluster que vous souhaitez créer déterminent le nombre de sous-réseaux à configurer. Il est recommandé d'utiliser des sous-réseaux régionaux pour simplifier l'implémentation du basculement entre les domaines de disponibilité en cas d'incident.

Le VCN dans lequel vous souhaitez créer et déployer des clusters doit comporter au moins deux sous-réseaux différents (facultatif, plus) :

  • Un sous-réseau d'adresse d'API Kubernetes
  • Un sous-réseau de noeuds de processus actif
  • un ou deux sous-réseaux d'équilibreur de charge régionaux propres à un domaine de disponibilité (facultatif)
  • un sous-réseau de pods (lors de l'utilisation d'un réseau de pod natif VCN)
  • un sous-réseau de bastion (facultatif)

Vous pouvez choisir de combiner les sous-réseaux ainsi que les règles de sécurité. Toutefois, cette approche rend la sécurité plus difficile à gérer et n'est donc pas recommandée, sauf si vous utilisez des groupes de sécurité réseau pour contrôler l'accès aux clusters.

Les blocs CIDR de sous-réseau ne doivent pas chevaucher les blocs CIDR que vous spécifiez pour les pods exécutés dans le cluster (reportez-vous à Blocs IPv4 CIDR et moteur Kubernetes (OKE)).

Les noeuds virtuels et gérés ont des exigences différentes. Vous devez donc configurer légèrement différemment les sous-réseaux de noeuds de processus actif et les sous-réseaux de pod lorsque vous utilisez des noeuds virtuels plutôt que des noeuds gérés.

Les sous-réseaux doivent être configurés avec les propriétés suivantes :

Reportez-vous à Réseaux cloud virtuels et sous-réseaux et à Exemples de configuration de ressource réseau.

Configuration du sous-réseau d'adresse d'API Kubernetes

Le sous-réseau d'adresse d'API Kubernetes héberge une adresse permettant d'accéder à l'API Kubernetes sur le plan de contrôle du cluster.

Le sous-réseau d'adresse d'API Kubernetes doit être un sous-réseau régional, et peut être privé ou public :

Configuration du sous-réseau de noeuds de processus actif

Un sous-réseau de noeuds de processus actif héberge des noeuds de processus actif. Tous les noeuds gérés d'un pool de noeuds appartiennent au même sous-réseau de noeuds de processus actif.

Le sous-réseau de noeuds de processus actif peut être un sous-réseau régional unique ou plusieurs sous-réseaux propres à des domaines de disponibilité (un dans chaque domaine de disponibilité).

Noeuds gérés/autogérés : le sous-réseau de noeuds de processus actif peut être public ou privé. Cependant, pour une sécurité maximale, nous recommandons que le sous-réseau de noeuds de processus actif soit un sous-réseau privé.

Noeuds virtuels : le sous-réseau de noeuds de processus actif peut être public ou privé. Cependant, pour une sécurité maximale, nous recommandons que le sous-réseau de noeuds de processus actif soit un sous-réseau privé. Nous recommandons également que le sous-réseau de noeuds de processus actif et le sous-réseau de pod soient identiques (auquel cas, le sous-réseau de noeuds de processus actif doit être privé car les noeuds virtuels requièrent que le sous-réseau de pod soit privé).

Configuration de sous-réseau de pod

Un sous-réseau de pod héberge les pods sur les noeuds de processus actif d'un pool de noeuds lors de l'utilisation du réseau de pod natif VCN (reportez-vous à Utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN pour le réseau de pod).

Le sous-réseau de pod doit être un sous-réseau régional unique.

Noeuds gérés : le sous-réseau de pod doit être un sous-réseau privé.

Noeuds virtuels : le sous-réseau de pod doit être un sous-réseau privé. Nous recommandons que le sous-réseau de pod et le sous-réseau de noeuds de processus actif soient identiques (auquel cas, le sous-réseau de noeuds de processus actif doit également être privé).

Configuration du sous-réseau d'équilibreurs de charge

Les sous-réseaux d'équilibreurs de charge connectent les équilibreurs de charge Oracle Cloud Infrastructure créés par les services Kubernetes de type LoadBalancer.

Les sous-réseaux d'équilibreurs de charge peuvent être des sous-réseaux régionaux uniques ou des sous-réseaux propres à des domaines de disponibilité (un dans chaque domaine de disponibilité). Cependant, nous recommandons d'opter pour des sous-réseaux régionaux.

Les sous-réseaux d'équilibreurs de charge peuvent être publics ou privés, selon la façon dont les applications déployées sur le cluster sont accessibles. Si les applications sont accessibles en interne à partir de votre réseau cloud virtuel, optez pour des sous-réseaux d'équilibreurs de charge privés. Si les applications sont accessibles à partir d'Internet, optez pour des sous-réseaux d'équilibreurs de charge publics.

Configuration de sous-réseau de bastion (facultatif)

Un bastion facultatif dans un sous-réseau de bastion peut fournir un accès sécurisé à l'adresse d'API Kubernetes et un accès SSH aux noeuds de processus actif. Reportez-vous à Configuration d'un bastion pour l'accès à un cluster.

Configuration des règles de sécurité dans les groupes de sécurité réseau et/ou les listes de sécurité

Les règles de sécurité doivent être définies pour le VCN dans lequel vous souhaitez créer et déployer des clusters. Vous pouvez définir les règles de sécurité de l'une des manières suivantes ou des deux :

  • Dans Groupes de sécurité réseau (recommandé) que vous sélectionnez pour les pools de noeuds, pour l'adresse d'API Kubernetes, pour les pods (lors de l'utilisation d'une mise en réseau de pod native VCN) et pour les équilibreurs de charge (le cas échéant) lorsque vous créez un cluster.
  • Dans les listes de sécurité déjà associées aux sous-réseaux que vous sélectionnez pour les noeuds de processus actif, pour l'adresse d'API Kubernetes, pour les pods (lors de l'utilisation de la mise en réseau de pod native VCN) et pour les équilibreurs de charge (le cas échéant) lorsque vous créez un cluster.

Les noeuds de processus actif, l'adresse d'API Kubernetes, les pods (lors de l'utilisation d'un réseau de pod natif VCN) et l'équilibreur de charge ont des exigences de règle de sécurité différentes, comme décrit dans cette rubrique. Vous pouvez ajouter des règles supplémentaires pour répondre à vos besoins spécifiques.

Si vous spécifiez des règles de sécurité à la fois dans des groupes de sécurité réseau et des listes de sécurité, toutes les règles de sécurité sont appliquées (c'est-à-dire l'union des règles de sécurité).

Pour plus d'informations, reportez-vous à :

Règles de sécurité pour l'adresse d'API Kubernetes

Les règles entrantes suivantes doivent être définies pour l'adresse d'API Kubernetes, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Source Protocole/Port de destination Description
Avec conservation de statut CIDR des noeuds de processus actif TCP/6443 Communication entre le processus actif Kubernetes et l'adresse d'API Kubernetes.
Avec conservation de statut CIDR des noeuds de processus actif TCP/12250 Communication entre le processus actif Kubernetes et l'adresse d'API Kubernetes.
Avec conservation de statut CIDR de pods TCP/6443 Communication d'adresse d'API de pod vers Kubernetes (lors de l'utilisation d'un réseau de pod natif VCN).
Avec conservation de statut CIDR de pods TCP/12250 Communication d'adresse d'API de pod vers Kubernetes (lors de l'utilisation d'un réseau de pod natif VCN).
Avec conservation de statut CIDR des noeuds de processus actif ICMP 3,4 Repérage de chemin.

Les règles entrantes facultatives suivantes peuvent être définies pour l'adresse d'API Kubernetes, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Source Protocole/Port de destination Description
Avec conservation de statut 0.0.0.0/0 ou sous-réseaux spécifiques TCP/6443 Accès client à l'adresse d'API Kubernetes

Les règles sortantes suivantes doivent être définies pour l'adresse d'API Kubernetes, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Destination Protocole/Port de destination Description
Avec conservation de statut Tous les services <region> dans Oracle Services Network TCP/443 Autorisez l'adresse d'API Kubernetes à communiquer avec OKE.
Avec conservation de statut CIDR des noeuds de processus actif TCP/ALL Tout le trafic vers les noeuds de processus actif (lors de l'utilisation de flannel pour la mise en réseau de pod).
Avec conservation de statut CIDR de pods ALL/ALL

Communication entre l'adresse d'API Kubernetes et le pod (lors de l'utilisation d'un réseau de pod natif VCN).

Avec conservation de statut CIDR des noeuds de processus actif ICMP 3,4 Repérage de chemin.
Avec conservation de statut CIDR des noeuds de processus actif TCP 10250, ICMP Communication entre l'adresse d'API Kubernetes et le noeud de processus actif (lors de l'utilisation d'un réseau de pod natif VCN).

Règles de sécurité pour les noeuds de processus actif

Les noeuds de processus actifs sont créés avec des adresses IP publiques ou privées, selon que vous indiquez des sous-réseaux publics ou privés lors de la définition des pools de noeuds d'un cluster. Kubernetes Engine doit pouvoir accéder aux noeuds de processus actif.

Les règles entrantes suivantes doivent être définies pour les noeuds de processus actif, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Source Protocole/Port de destination Description
Avec conservation de statut CIDR des noeuds de processus actif ALL/ALL Permet la communication depuis (ou vers) les noeuds de processus actif.
Avec conservation de statut CIDR de pods ALL/ALL Autorise les pods sur un nœud de travail à communiquer avec les pods sur d'autres nœuds de travail (lors de l'utilisation d'un réseau de pod natif VCN).
Avec conservation de statut CIDR de l'adresse d'API Kubernetes TCP/ALL Autorisez l'adresse d'API Kubernetes à communiquer avec les noeuds de processus actif.
Avec conservation de statut 0.0.0.0/0 ICMP 3,4 Repérage de chemin.
Avec conservation de statut CIDR de l'adresse d'API Kubernetes TCP 10250, ICMP Communication entre l'adresse d'API Kubernetes et le noeud de processus actif (lors de l'utilisation d'un réseau de pod natif VCN).

Les règles entrantes facultatives suivantes peuvent être définies pour les noeuds de processus actif (noeuds gérés uniquement), dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Source Protocole/Port de destination Description
Avec conservation de statut 0.0.0.0/0 ou CIDR de sous-réseau TCP/22 (Facultatif) Autorise le trafic SSH entrant vers les noeuds de processus actif.

Les règles sortantes suivantes doivent être définies pour les noeuds de processus actif, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Destination Protocole/Port de destination Description
Avec conservation de statut CIDR des noeuds de processus actif ALL/ALL Permet la communication depuis (ou vers) les noeuds de processus actif.
Avec conservation de statut CIDR de pods ALL/ALL Autoriser les noeuds de processus actifs à communiquer avec les pods sur d'autres noeuds de processus actifs (lors de l'utilisation d'un réseau de pod natif VCN).
Avec conservation de statut 0.0.0.0/0 ICMP 3,4 Repérage de chemin.
Avec conservation de statut Tous les services <region> dans Oracle Services Network TCP/ALL Autorise les noeuds à communiquer avec OKE.
Avec conservation de statut CIDR de l'adresse d'API Kubernetes TCP/6443 Communication entre le processus actif Kubernetes et l'adresse d'API Kubernetes.
Avec conservation de statut CIDR de l'adresse d'API Kubernetes TCP/12250 Communication entre le processus actif Kubernetes et l'adresse d'API Kubernetes.

Les règles sortantes facultatives suivantes peuvent être définies pour les noeuds de processus actif, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Destination Protocole/Port de destination Description
Avec conservation de statut 0.0.0.0/0 TCP/ALL (Facultatif) Autorise les noeuds de processus actif à communiquer avec Internet.

Règles de sécurité pour les sous-réseaux de pod

Lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking pour la mise en réseau de pod :

  • les règles de sécurité définies pour le sous-réseau de noeud de processus actif, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité, doivent inclure les éléments suivants :

    • Règles entrantes et sortantes avec conservation de statut qui autorisent tout le trafic entre les noeuds de processus actif
    • Règles entrantes et sortantes avec conservation de statut qui autorisent tout le trafic entre les noeuds de processus actif et l'équilibreur de charge
    • Règles sortantes avec état autorisant le trafic entre les noeuds de processus actifs et le moteur Kubernetes
  • les règles de sécurité définies pour le sous-réseau de pod, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité, doivent inclure des règles entrantes et sortantes avec conservation de statut qui autorisent tout le trafic entre les pods

Les règles entrantes suivantes doivent être définies pour les sous-réseaux de pod, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Source Protocole/Port de destination Description
Avec conservation de statut CIDR de l'adresse d'API Kubernetes ALL/ALL Communication entre l'adresse d'API Kubernetes et le pod (lors de l'utilisation d'un réseau de pod natif VCN).
Avec conservation de statut CIDR des noeuds de processus actif ALL/ALL Autorise les pods sur un noeud de processus actif à communiquer avec les pods sur d'autres noeuds de processus actifs.
Avec conservation de statut CIDR de pods ALL/ALL Permettre aux pods de communiquer entre eux.

Les règles sortantes suivantes doivent être définies pour les sous-réseaux de pod, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Destination Protocole/Port de destination Description
Avec conservation de statut CIDR de pods ALL/ALL Permettre aux pods de communiquer entre eux.
Avec conservation de statut Tous les services <region> dans Oracle Services Network ICMP 3,4 Repérage de chemin.
Avec conservation de statut Tous les services <region> dans Oracle Services Network TCP/ALL Autorisez les noeuds de processus actif à communiquer avec les services OCI.
Avec conservation de statut CIDR de l'adresse d'API Kubernetes TCP/6443 Communication d'adresse d'API de pod vers Kubernetes (lors de l'utilisation d'un réseau de pod natif VCN).
Avec conservation de statut CIDR de l'adresse d'API Kubernetes TCP/12250 Communication d'adresse d'API de pod vers Kubernetes (lors de l'utilisation d'un réseau de pod natif VCN).

Les règles sortantes facultatives suivantes peuvent être définies pour un sous-réseau de pod, dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité :

Etat Destination Protocole/Port de destination Description
Avec conservation de statut 0.0.0.0/0 TCP/443 (Facultatif) Autoriser les pods à communiquer avec Internet.

Règles de sécurité pour les équilibreurs de charge et les équilibreurs de charge réseau

Lorsque le moteur Kubernetes provisionne un équilibreur de charge OCI ou un équilibreur de charge réseau pour un service Kubernetes de type LoadBalancer, des règles de sécurité appropriées doivent exister pour autoriser le trafic entrant et sortant vers et depuis le sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge réseau. Dans le cas des noeuds gérés (et non des noeuds virtuels), ces règles de sécurité sont créées automatiquement par défaut pour les équilibreurs de charge, mais pas automatiquement par défaut pour les équilibreurs de charge réseau. Pour plus d'informations sur le provisionnement d'un équilibreur de charge OCI ou d'un équilibreur de charge réseau pour un service Kubernetes de type LoadBalancer, reportez-vous à Définition de services Kubernetes de type LoadBalancer.

Vous pouvez définir des règles de sécurité entrantes et sortantes pour le sous-réseau dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité. Pour plus d'informations, reportez-vous à :

Définissez la règle de sécurité entrante suivante dans l'un ou les deux :

  • un groupe de sécurité réseau (recommandé) auquel la ressource d'équilibreur de charge ou d'équilibreur de charge réseau a été ajoutée
  • une liste de sécurité associée au sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge réseau
Etat Source Protocole/Port de destination Description
Avec conservation de statut 0.0.0.0/0 ou CIDR spécifique TCP/443 Autoriser le trafic entrant vers l'équilibreur de charge.

Définissez le protocole et le port de destination de la règle entrante de manière appropriée pour répondre à des exigences d'application spécifiques. Par exemple, spécifiez UDP comme protocole pour une application qui gère le trafic UDP.

Définissez la règle de sécurité sortante suivante dans l'un ou les deux :

  • un groupe de sécurité réseau (recommandé) auquel la ressource d'équilibreur de charge ou d'équilibreur de charge réseau a été ajoutée
  • une liste de sécurité associée au sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge réseau
Etat Destination Protocole/Port de destination Description
Avec conservation de statut CIDR des noeuds de processus actif TOUT/300000-32767 Autoriser le trafic vers les noeuds de processus actif.

Par défaut, les équilibreurs de charge OCI ou les équilibreurs de charge réseau provisionnés par le proxy Kubernetes Engine demandent à tous les noeuds de processus actif du cluster. Lorsque les demandes sont transmises par proxy aux noeuds de processus actif du cluster, les règles de sécurité entrantes et sortantes suivantes doivent exister (dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité) pour que l'équilibreur de charge ou l'équilibreur de charge réseau communique avec les noeuds de processus actif sur le port 10256 (port d'état de kube-proxy) :

  • Règle de sécurité entrante pour la liste de sécurité (ou le groupe de sécurité réseau) du sous-réseau de noeud de processus actif afin de permettre à l'équilibreur de charge ou à l'équilibreur de charge réseau de communiquer avec kube-proxy sur les noeuds de processus actif :
    Etat Source Protocole/Port de destination Description
    Avec conservation de statut CIDR de sous-réseau d'équilibreurs de charge ou de réseaux TOUT/10256 Autorisez l'équilibreur de charge OCI ou l'équilibreur de charge réseau à communiquer avec kube-proxy sur les noeuds de processus actif.
  • Règle de sécurité sortante pour la liste de sécurité (ou le groupe de sécurité réseau) du sous-réseau d'équilibreur de charge ou d'équilibreur de charge réseau afin de permettre à l'équilibreur de charge ou à l'équilibreur de charge réseau de communiquer avec kube-proxy sur les noeuds de processus actif :
    Etat Destination Protocole/Port de destination Description
    Avec conservation de statut CIDR de sous-réseau de noeuds de processus actif TOUT/10256 Autorisez l'équilibreur de charge OCI ou l'équilibreur de charge réseau à communiquer avec kube-proxy sur les noeuds de processus actif.

Lors du provisionnement d'un équilibreur de charge réseau pour un service Kubernetes de type LoadBalancer, procédez comme suit :

  • Vous pouvez indiquer que les demandes se terminent à l'adresse IP client indiquée dans les en-têtes des paquets IP, plutôt que d'être transmises par proxy à d'autres noeuds de processus actif du cluster (en définissant externalTrafficPolicy: Local). Reportez-vous à Terminaison de demandes sur le noeud de réception.
  • Si vous indiquez que les demandes se terminent à l'adresse IP du client, vous pouvez également indiquer si l'adresse IP du client doit être conservée dans les en-têtes des paquets IP (à l'aide de l'annotation oci-network-load-balancer.oraclecloud.com/is-preserve-source). Reportez-vous à la section Preserving The Client IP Address.

Dans les deux cas, vous devez avoir configuré une règle de sécurité (dans un groupe de sécurité réseau (recommandé) et/ou dans une liste de sécurité) pour les noeuds de processus actif du cluster afin d'autoriser le trafic entrant du bloc CIDR où les connexions client sont établies vers tous les ports de noeud (30000 à 32767). Si l'application est exposée à Internet, définissez le bloc CIDR source de la règle de sécurité sur 0.0.0.0/0. Vous pouvez également définir le bloc CIDR source de la règle de sécurité sur un bloc CIDR spécifique (par exemple, si les connexions client proviennent d'un sous-réseau spécifique).

Etat Source Protocole/Port de destination Description
Avec conservation de statut 0.0.0.0/0 ou CIDR de sous-réseau TOUT/300000-32767 Autoriser les noeuds de processus actif à recevoir des connexions via l'équilibreur de charge réseau OCI.

Règles de sécurité pour les sous-réseaux de bastion

Un bastion facultatif dans un sous-réseau de bastion peut fournir un accès sécurisé à l'adresse d'API Kubernetes et un accès SSH aux noeuds de processus actif. Pour plus d'informations sur les règles de sécurité entrantes et sortantes à définir, reportez-vous à Configuration d'un bastion pour l'accès au cluster.