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 :
- Le VCN doit avoir un bloc CIDR défini suffisamment grand pour toutes les ressources requises par un cluster (adresse d'API Kubernetes, noeuds de processus actif, pods, équilibreurs de charge). Par exemple, pour un VCN qui prend en charge l'adressage IPv4 uniquement, un bloc CIDR /16 serait suffisamment grand pour presque tous les cas d'utilisation (10.0.0.0/16 par exemple). Le bloc CIDR que vous indiquez pour le VCN ne doit pas chevaucher le bloc CIDR que vous indiquez pour les pods lors de l'utilisation du module d'extension CNI flannel (reportez-vous à Utilisation du module d'extension CNI flannel pour la mise en réseau de pod) et pour les services Kubernetes (reportez-vous à Blocs IPv4 CIDR et moteur Kubernetes (OKE)).
- Le VCN doit avoir un nombre approprié de sous-réseaux définis pour les noeuds de processus actif, pour les équilibreurs de charge, pour l'adresse d'API Kubernetes et pour les pods lors de l'utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN (reportez-vous à Utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN pour la mise en réseau de pod). 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. Reportez-vous à Configuration des réseaux.
- Le VCN doit avoir des règles de sécurité définies (dans l'un ou l'autre des groupes de sécurité réseau et/ou les deux listes de sécurité pour chaque sous-réseau). Reportez-vous à Configuration de règles de sécurité dans des groupes de sécurité réseau et/ou des listes de sécurité.
- Oracle vous recommande de sélectionner l'option Résolution DNS pour le réseau cloud virtuel.
- Si vous utilisez des sous-réseaux publics, le réseau cloud virtuel doit disposer d'une passerelle Internet. Reportez-vous à Configuration de la passerelle Internet.
- Si vous utilisez des sous-réseaux privés, le réseau cloud virtuel doit disposer d'une passerelle NAT et d'une passerelle de service. Reportez-vous à Configuration de la passerelle NAT et à Configuration de la passerelle de service.
- Si le réseau cloud virtuel dispose d'une passerelle NAT, d'une passerelle de service ou d'une passerelle Internet, il doit également contenir une table de routage comportant les règles appropriées. Reportez-vous à Configuration de la 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 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
-
Pour éviter tout risque de routage asymétrique, une table de routage pour un sous-réseau public ne peut pas contenir à la fois une règle de routage qui cible une passerelle Internet et une règle de routage qui cible une passerelle de service (reportez-vous à Problèmes d'accès aux instances publiques à partir des services Oracle via une passerelle de service).
-
Pour plus d'informations sur la configuration des tables de routage, reportez-vous aux ressources suivantes :
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 :
- Table de routage : reportez-vous à Configuration de la table de routage.
- Options DHCP : reportez-vous à Configuration des options DHCP.
- Groupes de sécurité réseau et/ou liste de sécurité : reportez-vous à Configuration de règles de sécurité dans des groupes de sécurité réseau et/ou des listes de sécurité
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 :
- Si vous spécifiez un sous-réseau public pour l'adresse d'API Kubernetes, vous pouvez éventuellement l'exposer à Internet en lui affectant une adresse IP publique. L'adresse IP publique permet aux services cloud tiers (tels que les services d'intégration continue et de déploiement continu SaaS) d'accéder à l'adresse d'API Kubernetes. Tenez compte des éléments suivants :
- Si l'adresse d'API Kubernetes dispose d'une adresse IP publique, des règles de routage et des règles de sécurité doivent exister pour permettre l'accès à l'adresse à l'aide d'une passerelle Internet (reportez-vous à Exemple 1 : cluster avec un CNI de canal) Module d'extension, adresse d'API Kubernetes publique, noeuds de processus actif privés et équilibreurs de charge publics et Exemple 3 : cluster avec le module d'extension CNI OCI, adresse d'API Kubernetes publique, noeuds de processus actif privés et équilibreurs de charge publics.
- Si l'adresse d'API Kubernetes ne dispose pas d'adresse IP publique, des règles de routage et de sécurité doivent exister pour permettre l'accès à l'adresse à l'aide d'une passerelle de service et d'une passerelle NAT (reportez-vous à Exemple 2 : cluster) avec le module d'extension CNI de canal, l'adresse d'API Kubernetes privée, les noeuds de processus actif privés et les équilibreurs de charge publics et Exemple 4 : cluster avec le module d'extension CNI OCI, l'adresse d'API Kubernetes privée, les noeuds de processus actif privés et les équilibreurs de charge publics.
- Une fois que vous avez créé un cluster, vous pouvez modifier l'affectation d'une adresse IP publique à l'adresse d'API Kubernetes. Si vous modifiez l'affectation d'une adresse IP publique à l'adresse, vous devez également mettre à jour les règles de routage et de sécurité de façon appropriée.
- Si vous spécifiez un sous-réseau privé pour l'adresse d'API Kubernetes, le trafic peut accéder au sous-réseau d'adresse d'API Kubernetes à partir d'un autre sous-réseau de votre réseau cloud virtuel, à partir d'un autre réseau cloud virtuel ou à partir de votre réseau sur site (appairé à FastConnect). Vous pouvez également configurer un bastion sur un sous-réseau public pour atteindre l'adresse d'API Kubernetes (reportez-vous à Configuration d'un bastion pour l'accès au cluster).
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 à :
- Exemples de configuration de ressource réseau
- Listes de sécurité
- Groupes de sécurité réseau
- Règles de sécurité
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 à :
- Spécification de groupes de sécurité réseau (recommandé)
- Spécification des options de gestion des listes de sécurité lors du provisionnement d'un équilibreur de charge OCI
- Spécification des options de gestion des listes de sécurité lors du provisionnement d'un équilibreur de charge réseau OCI
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.