Configuration des ressources de réseau pour la création et le déploiement de grappes
Découvrez comment configurer les ressources réseau pour qu'elles utilisent Kubernetes Engine (OKE).
Avant de pouvoir utiliser Kubernetes Engine pour créer et déployer des grappes dans les régions d'une location :
- La location doit déjà comporter un compartiment contenant les ressources de réseau nécessaires (comme un VCN, des sous-réseaux, une passerelle Internet, une table de routage, des groupes de sécurité de réseau ou des listes de sécurité). Si un tel compartiment n'existe pas déjà, vous devez le créer. Notez que les ressources de réseau peuvent se trouver dans le compartiment racine. Toutefois, si plusieurs équipes doivent être amenées à créer des grappes, il est recommandé de créer un compartiment distinct pour chaque équipe.
- Dans le compartiment, les ressources de réseau (VCN, sous-réseaux, passerelle Internet, table de routage, groupes de sécurité de réseau ou listes de sécurité) doivent être configurées correctement dans chaque région où vous voulez créer et déployer des grappes. Lors de la création d'une grappe, Kubernetes Engine peut créer et configurer automatiquement de nouvelles ressources de réseau dans le flux de création rapide. Vous pouvez aussi spécifier explicitement les ressources de réseau existantes à utiliser dans le flux de création personnalisée. Si vous spécifiez des ressources de réseau existantes, vous ou une autre personne devez avoir déjà configuré ces ressources correctement, comme indiqué dans cette rubrique.
Cette rubrique décrit la configuration nécessaire pour chaque ressource de réseau. Pour consulter les détails d'une configuration type, voir Exemples de configurations de ressource de réseau.
Plusieurs tutoriels pour développeurs connexes sont disponibles.
Configuration du VCN
Le VCN dans lequel créer et déployer des grappes doit être configuré comme suit :
- Un bloc CIDR défini pour le VCN doit être suffisamment grand pour toutes les ressources requises par une grappe (point d'extrémité d'API Kubernetes, noeuds de travail, pods, équilibreurs de charge). Par exemple, pour un réseau VCN qui prend en charge l'adressage IPv4 seulement, 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 spécifiez pour le VCN ne doit pas chevaucher le bloc CIDR que vous spécifiez pour les pods lors de l'utilisation du plugiciel CNI de canal (voir Utilisation du plugiciel CNI de canal pour le réseau de pods) et pour les services Kubernetes (voir Blocs IPv4 CIDR et Kubernetes Engine (OKE)).
- Le VCN doit avoir un nombre approprié de sous-réseaux définis pour les noeuds de travail, pour les équilibreurs de charge, pour le point d'extrémité de l'API Kubernetes et pour les pods lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI (voir Utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour le réseau de pods). La meilleure pratique consiste à utiliser des sous-réseaux régionaux pour faciliter la mise en oeuvre du basculement entre les domaines de disponibilité. Voir Configuration des sous-réseaux.
- Le VCN doit comporter des règles de sécurité définies (dans l'un ou l'autre des groupes de sécurité de réseau ou des listes de sécurité pour chaque sous-réseau ou les deux). Voir Configuration des règles de sécurité dans les groupes de sécurité de réseau ou les listes de sécurité.
- Oracle recommande de sélectionner la résolution DNS pour le VCN.
- Si vous utilisez des sous-réseaux publics, le VCN doit comporter une passerelle Internet. Voir Configuration d'une passerelle Internet.
- Si vous utilisez des sous-réseaux privés, le VCN doit comporter une passerelle NAT et une passerelle de service. Voir Configuration d'une passerelle NAT et Configuration d'une passerelle de service.
- Si le VCN utilise une passerelle NAT, une passerelle Internet ou une passerelle de service, il doit comporter une table de routage dans laquelle les règles appropriées sont définies. Voir Configuration d'une table de routage.
Voir Réseaux en nuage virtuels et sous-réseaux et Exemples de configurations de ressources de réseau.
Configuration d'une passerelle Internet
Si vous avez l'intention d'utiliser des sous-réseaux publics (pour les noeuds de travail, les équilibreurs de charge et/ou le point d'extrémité de l'API Kubernetes) et que ceux-ci nécessitent un accès à/à partir d'Internet, le VCN doit comporter une passerelle Internet. La passerelle Internet doit être spécifiée en tant que cible pour le bloc CIDR de destination 0.0.0.0/0 dans une règle de routage d'une table de routage.
Voir Réseaux en nuage virtuels et sous-réseaux et Exemples de configurations de ressources de réseau.
Configuration d'une passerelle NAT
Si vous avez l'intention d'utiliser des sous-réseaux privés (pour les noeuds de travail, le point d'extrémité de l'API Kubernetes ou les pods lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN OCI) et que ces derniers nécessitent l'accès à Internet, le VCN doit comporter une passerelle NAT. C'est le cas par exemple si les applications déployées doivent télécharger des logiciels ou accéder à des services tiers.
La passerelle NAT doit être spécifiée en tant que cible pour le bloc CIDR de destination 0.0.0.0/0 dans une règle de routage d'une table de routage.
Voir Passerelle NAT et Exemples de configurations de ressources de réseau.
Configuration d'une passerelle de service
Si vous avez l'intention d'utiliser des sous-réseaux privés pour les noeuds de travail, le point d'extrémité de l'API Kubernetes ou les pods lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN OCI, le VCN doit comporter une passerelle de service.
Créez la passerelle de service dans les mêmes VCN et compartiment que le sous-réseau de noeuds de travail, le sous-réseau de point d'extrémité de l'API Kubernetes ou le sous-réseau de pods, et sélectionnez l'option Tous les services de <région> dans Oracle Services Network.
La passerelle de service doit être spécifiée en tant que cible pour Tous les services de <région> dans Oracle Services Network dans une règle de routage d'une table de routage.
Voir Accès aux services Oracle : Passerelle de service et Exemples de configurations de ressources de réseau.
Configuration d'une table de routage
Table de routage pour les sous-réseaux de noeuds de travail
Si vous avez l'intention de déployer des noeuds de travail 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 en tant que cible pour le bloc CIDR de destination 0.0.0.0/0.
Si vous avez l'intention de déployer des noeuds de travail 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 en tant que cible pour Tous les services de <région> dans Oracle Services Network
- une règle de routage qui spécifie la passerelle NAT en tant que cible pour le bloc CIDR de destination 0.0.0.0/0
Table de routage pour les sous-réseaux de point d'extrémité d'API Kubernetes
Si vous avez l'intention de déployer le point d'extrémité de l'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 en tant que cible pour le bloc CIDR de destination 0.0.0.0/0.
Si vous avez l'intention de déployer le point d'extrémité de l'API Kubernetes dans un sous-réseau privé, la table de routage doit comporter :
- une règle de routage qui spécifie la passerelle de service en tant que cible pour Tous les services de <région> dans Oracle Services Network
- une règle de routage qui spécifie la passerelle NAT en tant que 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 des sous-réseaux doit comporter une règle de routage qui spécifie la passerelle Internet en tant que 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 des sous-réseaux peut être vide.
Table de routage pour le sous-réseau de pods
Si vous avez l'intention d'utiliser le plugiciel CNI de réseau de pods natif du VCN pour OCI pour le service de réseau de pods, déployez les pods dans un sous-réseau privé. La table de routage du sous-réseau doit avoir :
- une règle de routage qui spécifie la passerelle de service en tant que cible pour Tous les services de <région> dans Oracle Services Network
- une règle de routage qui spécifie la passerelle NAT en tant que cible pour le bloc CIDR de destination 0.0.0.0/0
Si vous avez l'intention d'utiliser le plugiciel CNI flannel pour le réseau de pods, un sous-réseau de pod n'est pas requis.
Notes sur la configuration de la table de routage
-
Pour éviter la possibilité 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 (voir Problèmes liés à l'accès à vos instances publiques à partir des services Oracle au moyen d'une passerelle de service).
-
Pour plus d'informations sur la configuration des tables de routage, voir :
Configuration des options DHCP
Les options DHCP doivent être configurées pour le VCN dans lequel vous voulez créer et déployer des grappes. La valeur par défaut de Type de DNS, Résolveur Internet et de réseau en nuage virtuel, est acceptable.
Voir Options DHCP et Exemples de configurations de ressources de réseau.
Configuration des sous-réseaux
Les caractéristiques de la grappe que vous voulez créer déterminent le nombre de sous-réseaux à configurer. La meilleure pratique consiste à utiliser des sous-réseaux régionaux pour faciliter la mise en oeuvre du basculement entre les domaines de disponibilité.
Le VCN dans lequel vous voulez créer et déployer des grappes doit comporter au moins deux sous-réseaux différents (ou plus) :
- un sous-réseau de point d'extrémité d'API Kubernetes
- un sous-réseau de noeuds de travail
- un sous-réseau d'équilibreurs de charge régional ou spécifique d'un domaine de disponibilité (facultatif)
- un sous-réseau de pods (lors de l'utilisation du réseau de pods natif du VCN)
- un sous-réseau d'hôte bastion (facultatif)
Vous pouvez combiner les sous-réseaux et 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é de 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 la grappe (voir Blocs IPv4 CIDR et Kubernetes Engine (OKE).
Les noeuds virtuels et les noeuds gérés ont des exigences différentes. Vous devez donc configurer les sous-réseaux de noeuds de travail et les sous-réseaux de pod différemment 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 : Voir Configuration d'une table de routage
- Options DHCP : Voir Configuration des options DHCP
- Groupes de sécurité de réseau ou liste de sécurité : Voir Configuration de règles de sécurité dans les groupes de sécurité de réseau ou les listes de sécurité
Voir Réseaux en nuage virtuels et sous-réseaux et Exemples de configurations de ressources de réseau.
Configuration du sous-réseau de point d'extrémité d'API Kubernetes
Le sous-réseau de point d'extrémité d'API Kubernetes héberge un point d'extrémité qui permet d'accéder à l'API Kubernetes dans le plan de contrôle de la grappe.
Le sous-réseau de point d'extrémité de l'API Kubernetes doit être un sous-réseau régional et peut être un sous-réseau privé ou public :
- Si vous spécifiez un sous-réseau public pour le point d'extrémité de l'API Kubernetes, vous pouvez éventuellement l'exposer à Internet en lui affectant une adresse IP publique. L'adresse IP publique permet aux services en nuage tiers (tels que les services CI/CD SaaS) d'accéder au point d'extrémité de l'API Kubernetes. Notez ce qui suit :
- Si le point d'extrémité de l'API Kubernetes a une adresse IP publique, des règles de routage et des règles de sécurité doivent exister pour permettre l'accès au point d'extrémité à l'aide d'une passerelle Internet (voir Exemple 1 : Grappe avec CNI Flannel Plugiciel, point d'extrémité d'API Kubernetes public, noeuds de travail privés et équilibreurs de charge publics et Exemple 3 : Grappe avec plugiciel CNI OCI, point d'extrémité d'API Kubernetes public, noeuds de travail privés et équilibreurs de charge publics.
- Si le point d'extrémité de l'API Kubernetes n'a pas d'adresse IP publique, des règles de routage et des règles de sécurité doivent exister pour permettre l'accès au point d'extrémité à l'aide d'une passerelle de service et d'une passerelle NAT (voir Exemple 2 : Grappe avec le plugiciel CNI Flannel, le point d'extrémité d'API Kubernetes privé, les noeuds de travail privés et les équilibreurs de charge publics et Exemple 4 : Grappe avec plugiciel CNI OCI, point d'extrémité d'API Kubernetes privé, noeuds de travail privés et équilibreurs de charge publics.
- Après avoir créé une grappe, vous pouvez ensuite modifier si une adresse IP publique est affectée au point d'extrémité de l'API Kubernetes. Si vous changez si une adresse IP publique est affectée au point d'extrémité, notez que vous devez également mettre à jour les règles de routage et de sécurité de manière appropriée.
- Si vous spécifiez un sous-réseau privé pour le point d'extrémité de l'API Kubernetes, le trafic peut accéder au sous-réseau de point d'extrémité de l'API Kubernetes à partir d'un autre sous-réseau de votre VCN, d'un autre VCN ou de votre réseau sur place (appairé avec FastConnect). Vous pouvez également configurer un hôte bastion sur un sous-réseau public pour atteindre le point d'extrémité de l'API Kubernetes (voir Configuration d'un hôte bastion pour l'accès à une grappe).
Configuration du sous-réseau de noeuds de travail
Un sous-réseau de noeuds de travail héberge les noeuds de travail. Tous les noeuds gérés d'un groupe de noeuds appartiennent au même sous-réseau de noeuds de travail.
Le sous-réseau de noeuds de travail peut être un sous-réseau régional unique ou plusieurs sous-réseaux propres au domaine de disponibilité (un par domaine de disponibilité).
Noeuds gérés/autogérés : Le sous-réseau de noeuds de travail peut être public ou privé. Cependant, pour plus de sécurité, il est préférable que le sous-réseau de noeuds de travail soit un sous-réseau privé.
Noeuds virtuels : Le sous-réseau de noeuds de travail peut être public ou privé. Cependant, pour plus de sécurité, il est préférable que le sous-réseau de noeuds de travail soit un sous-réseau privé. Nous recommandons également que le sous-réseau de noeuds de travail et le sous-réseau de pod soient le même sous-réseau (dans ce cas, le sous-réseau de noeuds de travail doit être un sous-réseau privé, car les noeuds virtuels requièrent que le sous-réseau de pod soit un sous-réseau privé).
Configuration du sous-réseau de pod
Un sous-réseau de pods héberge les pods sur les noeuds de travail d'un groupe de noeuds lors de l'utilisation du réseau de pods natif du VCN (voir Utilisation du plugiciel CNI de réseau de pods natif du VCN OCI pour le réseau de pods).
Le sous-réseau de pod doit être un seul sous-réseau régional.
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 travail soient le même sous-réseau (dans ce cas, le sous-réseau de noeuds de travail doit également être un sous-réseau privé).
Configuration des sous-réseaux d'équilibreurs de charge
Les sous-réseaux d'équilibreurs de charge connectent les équilibreurs de charge d'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 à un domaine de disponibilité (un par domaine de disponibilité). Cependant, il est préférable d'utiliser des sous-réseaux régionaux.
Les sous-réseaux d'équilibreurs de charge peuvent être des sous-réseaux publics ou privés, selon la façon dont les applications déployées sur la grappe seront accessibles. Si l'accès aux applications est effectué depuis votre VCN, utilisez des sous-réseaux privés pour les sous-réseaux d'équilibreurs de charge. Si l'accès aux applications se fait à partir d'Internet, utilisez des sous-réseaux publics pour les sous-réseaux d'équilibreurs de charge.
Configuration du sous-réseau d'hôte bastion (facultatif)
Un hôte bastion facultatif dans un sous-réseau d'hôte bastion peut fournir un accès sécurisé au point d'extrémité de l'API Kubernetes et un accès SSH aux noeuds de travail. Voir Configuration d'un hôte bastion pour l'accès à une grappe.
Configuration des règles de sécurité dans les groupes de sécurité de réseau ou les listes de sécurité
Des règles de sécurité doivent être définies pour le VCN dans lequel créer et déployer des grappes. Vous pouvez définir les règles de sécurité de l'une ou l'autre des façons suivantes, ou les deux :
- Dans les groupes de sécurité de réseau (recommandés), que vous sélectionnez pour les groupes de noeuds, pour le point d'extrémité de l'API Kubernetes, pour les pods (lors de l'utilisation du réseau de pods natif de VCN) et pour les équilibreurs de charge (le cas échéant) lorsque vous créez une grappe.
- Dans les listes de sécurité qui sont déjà associées aux sous-réseaux que vous sélectionnez pour les noeuds de travail, pour le point d'extrémité de l'API Kubernetes, pour les pods (lors de l'utilisation du réseau de pods natif du VCN) et pour les équilibreurs de charge (le cas échéant) lorsque vous créez une grappe.
Les noeuds de travail, le point d'extrémité de l'API Kubernetes, les pods (lors de l'utilisation du réseau de pods natif de 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é dans les groupes de sécurité de réseau et les 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, voir :
- Exemples de configurations de ressources de réseau
- Listes de sécurité
- Groupes de sécurité de réseau
- Règles de sécurité
Règles de sécurité pour le point d'extrémité d'API Kubernetes
Les règles de trafic entrant suivantes doivent être définies pour le point d'extrémité de l'API Kubernetes, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | Bloc CIDR de noeuds de travail | TCP/6443 | Communication entre les noeuds de travail Kubernetes et le point d'extrémité de l'API Kubernetes. |
| Avec état | Bloc CIDR de noeuds de travail | TCP/12250 | Communication entre les noeuds de travail Kubernetes et le point d'extrémité de l'API Kubernetes. |
| Avec état | CIDR des pods | TCP/6443 | Communication entre le pod et le point d'extrémité de l'API Kubernetes (lors de l'utilisation du réseau de pods natif de VCN). |
| Avec état | CIDR des pods | TCP/12250 | Communication entre le pod et le point d'extrémité de l'API Kubernetes (lors de l'utilisation du réseau de pods natif de VCN). |
| Avec état | Bloc CIDR de noeuds de travail | ICMP 3,4 | Détection de chemin. |
Les règles de trafic entrant facultatives suivantes peuvent être définies pour le point d'extrémité d'API Kubernetes, dans un groupe de sécurité de réseau (recommandé) et/ou dans une liste de sécurité :
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | 0.0.0.0/0 ou sous-réseaux spécifiques | TCP/6443 | Accès du client au point d'extrémité de l'API Kubernetes |
Les règles de trafic sortant suivantes doivent être définies pour le point d'extrémité d'API Kubernetes, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Destination | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | Tous les services de <région> dans Oracle Services Network | TCP/443 | Autoriser le point d'extrémité de l'API Kubernetes à communiquer avec OKE. |
| Avec état | Bloc CIDR de noeuds de travail | TCP/ALL | Tout le trafic vers les noeuds de travail (lorsque vous utilisez un canal pour le réseau de pods). |
| Avec état | CIDR des pods | ALL/ALL |
Point d'extrémité d'API Kubernetes pour la communication entre les pods (lors de l'utilisation du réseau de pods natif de VCN). |
| Avec état | Bloc CIDR de noeuds de travail | ICMP 3,4 | Détection de chemin. |
| Avec état | Bloc CIDR de noeuds de travail | TCP 10250, ICMP | Communication entre point d'extrémité d'API Kubernetes et noeud de travail (lors de l'utilisation du réseau de pods natif de VCN). |
Règles de sécurité pour les noeuds de travail
Les noeuds de travail sont créés avec des adresses IP publiques ou privées, selon que vous spécifiez des sous-réseaux publics ou privés lors de la définition des groupes de noeuds d'une grappe. Kubernetes Engine doit pouvoir accéder aux noeuds de travail.
Les règles de trafic entrant suivantes doivent être définies pour les noeuds de travail, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | Bloc CIDR de noeuds de travail | ALL/ALL | Permet la communication à partir des noeuds de travail (ou vers). |
| Avec état | CIDR des pods | ALL/ALL | Permettre aux pods d'un noeud de travail de communiquer avec ceux des autres noeuds de travail (lors de l'utilisation du réseau de pods natif du VCN). |
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | TCP/ALL | Autoriser le point d'extrémité de l'API Kubernetes à communiquer avec les noeuds de travail. |
| Avec état | 0.0.0.0/0 | ICMP 3,4 | Détection de chemin. |
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | TCP 10250, ICMP | Communication entre point d'extrémité d'API Kubernetes et noeud de travail (lors de l'utilisation du réseau de pods natif de VCN). |
Les règles de trafic entrant facultatives suivantes peuvent être définies pour les noeuds de travail (noeuds gérés uniquement), dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | 0.0.0.0/0 ou bloc CIDR du sous-réseau | TCP/22 | (Facultatif) Permettre le trafic SSH entrant vers les noeuds de travail. |
Les règles de trafic sortant suivantes doivent être définies pour les noeuds de travail, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Destination | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | Bloc CIDR de noeuds de travail | ALL/ALL | Permet la communication à partir des noeuds de travail (ou vers). |
| Avec état | CIDR des pods | ALL/ALL | Autoriser les noeuds de travail à communiquer avec les pods sur d'autres noeuds de travail (lors de l'utilisation du réseau de pods natif de VCN). |
| Avec état | 0.0.0.0/0 | ICMP 3,4 | Détection de chemin. |
| Avec état | Tous les services de <région> dans Oracle Services Network | TCP/ALL | Permettre aux noeuds de communiquer avec OKE. |
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | TCP/6443 | Communication entre les noeuds de travail Kubernetes et le point d'extrémité de l'API Kubernetes. |
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | TCP/12250 | Communication entre les noeuds de travail Kubernetes et le point d'extrémité de l'API Kubernetes. |
Les règles de trafic sortant facultatives suivantes peuvent être définies pour les noeuds de travail, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Destination | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | 0.0.0.0/0 | TCP/ALL | (Facultatif) Permettre aux noeuds de travail de communiquer avec Internet. |
Règles de sécurité pour les sous-réseaux de pod
Lors de l'utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour le réseau de pods :
-
les règles de sécurité définies pour le sous-réseau de noeuds de travail, dans un groupe de sécurité de réseau (recommandé) et/ou dans une liste de sécurité, doivent inclure :
- Règles de trafic entrant et sortant avec état qui autorisent tout le trafic entre les noeuds de travail
- Règles de trafic entrant et sortant avec état qui autorisent tout le trafic entre les noeuds de travail et l'équilibreur de charge
- Règles de trafic sortant avec état qui autorisent le trafic entre les noeuds de travail et Kubernetes Engine
- les règles de sécurité définies pour le sous-réseau de pod, dans un groupe de sécurité de réseau (recommandé) et/ou dans une liste de sécurité, doivent inclure des règles de trafic entrant et sortant avec état qui autorisent tout le trafic entre les pods
Les règles de trafic entrant suivantes doivent être définies pour les sous-réseaux de pods, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | ALL/ALL | Point d'extrémité d'API Kubernetes pour la communication entre les pods (lors de l'utilisation du réseau de pods natif de VCN). |
| Avec état | Bloc CIDR de noeuds de travail | ALL/ALL | Permettre aux pods d'un noeud de travail de communiquer avec ceux des autres noeuds de travail. |
| Avec état | CIDR des pods | ALL/ALL | Permettre aux pods de communiquer entre eux. |
Les règles de trafic sortant suivantes doivent être définies pour les sous-réseaux de pods, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Destination | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | CIDR des pods | ALL/ALL | Permettre aux pods de communiquer entre eux. |
| Avec état | Tous les services de <région> dans Oracle Services Network | ICMP 3,4 | Détection de chemin. |
| Avec état | Tous les services de <région> dans Oracle Services Network | TCP/ALL | Autoriser les noeuds de travail à communiquer avec les services OCI. |
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | TCP/6443 | Communication entre le pod et le point d'extrémité de l'API Kubernetes (lors de l'utilisation du réseau de pods natif de VCN). |
| Avec état | Bloc CIDR de point d'extrémité de l'API Kubernetes | TCP/12250 | Communication entre le pod et le point d'extrémité de l'API Kubernetes (lors de l'utilisation du réseau de pods natif de VCN). |
Les règles de trafic sortant facultatives suivantes peuvent être définies pour un sous-réseau de pod, dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité :
| État | Destination | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | 0.0.0.0/0 | TCP/443 | (Facultatif) Autorisez les pods à communiquer avec Internet. |
Règles de sécurité pour les équilibreurs de charge et les équilibreurs de charge de réseau
Lorsque le moteur Kubernetes provisionne un équilibreur de charge OCI ou un équilibreur de charge de réseau pour un service Kubernetes de type LoadBalancer, des règles de sécurité appropriées doivent exister pour permettre le trafic entrant et sortant vers et depuis le sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge de 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 ne sont pas créées automatiquement par défaut pour les équilibreurs de charge de réseau. Pour plus d'informations sur le provisionnement d'un équilibreur de charge OCI ou d'un équilibreur de charge de réseau pour un service Kubernetes de type LoadBalancer, voir Définition des services Kubernetes de type LoadBalancer.
Vous pouvez définir des règles de sécurité de trafic entrant et sortant pour le sous-réseau dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité. Pour plus d'informations, voir :
- Définir des groupes de sécurité de 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 de réseau OCI
Définissez la règle de sécurité de trafic entrant suivante dans l'une des deux :
- un groupe de sécurité de réseau (recommandé) auquel l'équilibreur de charge ou la ressource d'équilibreur de charge de réseau a été ajouté
- une liste de sécurité associée au sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge de réseau
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | 0.0.0.0/0 ou bloc 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 de trafic entrant en fonction 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é de trafic sortant suivante dans l'une des deux :
- un groupe de sécurité de réseau (recommandé) auquel l'équilibreur de charge ou la ressource d'équilibreur de charge de réseau a été ajouté
- une liste de sécurité associée au sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge de réseau
| État | Destination | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | Bloc CIDR de noeuds de travail | TOUT/30000-32767 | Autoriser le trafic vers les noeuds de travail. |
Par défaut, les équilibreurs de charge OCI ou les équilibreurs de charge de réseau provisionnés par les demandes de mandataire du moteur Kubernetes à tous les noeuds de travail de la grappe. Lorsque des demandes sont mandatées aux noeuds de travail de la grappe, les règles de sécurité de trafic entrant et sortant suivantes doivent exister (dans un groupe de sécurité de réseau (recommandé) ou dans une liste de sécurité) pour que l'équilibreur de charge ou l'équilibreur de charge de réseau communique avec les noeuds de travail du port 10256 (le port d'état kube-proxy) :
- Règle de sécurité de trafic entrant pour la liste de sécurité (ou le groupe de sécurité de réseau) du sous-réseau de noeuds de travail afin de permettre à l'équilibreur de charge ou à l'équilibreur de charge de réseau de communiquer avec kube-proxy sur les noeuds de travail :
État Source Protocole/ Port Description Avec état Bloc CIDR de sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge de réseau TOUT /10256 Autoriser l'équilibreur de charge OCI ou l'équilibreur de charge de réseau à communiquer avec kube-proxy sur les noeuds de travail. - Règle de sécurité sortante pour la liste de sécurité (ou le groupe de sécurité de réseau) du sous-réseau de l'équilibreur de charge ou de l'équilibreur de charge de réseau pour permettre à l'équilibreur de charge ou à l'équilibreur de charge de réseau de communiquer avec le mandataire kube sur les noeuds de travail :
État Destination Protocole/ Port Description Avec état Bloc CIDR de sous-réseau de noeud de travail TOUT /10256 Autoriser l'équilibreur de charge OCI ou l'équilibreur de charge de réseau à communiquer avec kube-proxy sur les noeuds de travail.
Lors du provisionnement d'un équilibreur de charge de réseau pour un service Kubernetes de type LoadBalancer :
- Vous pouvez spécifier que les demandes prennent fin à l'adresse IP du client spécifiée dans les en-têtes des paquets IP, plutôt que d'être mandatées à d'autres noeuds de travail de la grappe (en définissant
externalTrafficPolicy: Local). Voir Fin des demandes au niveau du noeud de réception. - Si vous spécifiez que les demandes se terminent à l'adresse IP du client, vous pouvez également spécifier 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). Voir Conservation de l'adresse IP du client.
Notez que dans les deux cas, vous devez avoir configuré une règle de sécurité (dans un groupe de sécurité de réseau (recommandé) et/ou dans une liste de sécurité) pour les noeuds de travail de la grappe afin d'autoriser le trafic entrant depuis le bloc CIDR où les connexions client sont effectuées, vers tous les ports de noeud (30000 à 32767). Si l'application est exposée à Internet, réglez le bloc CIDR Source de la règle de sécurité à 0.0.0.0/0. Vous pouvez également régler le bloc CIDR Source de la règle de sécurité à un bloc CIDR spécifique (par exemple, si les connexions client proviennent d'un sous-réseau spécifique).
| État | Source | Protocole/ Port | Description |
|---|---|---|---|
| Avec état | 0.0.0.0/0 ou bloc CIDR du sous-réseau | TOUT/30000-32767 | Autoriser les noeuds de travail à recevoir des connexions au moyen de l'équilibreur de charge de réseau OCI. |
Règles de sécurité pour les sous-réseaux d'hôte bastion
Un hôte bastion facultatif dans un sous-réseau d'hôte bastion peut fournir un accès sécurisé au point d'extrémité de l'API Kubernetes et un accès SSH aux noeuds de travail. Pour plus d'informations sur les règles de sécurité de trafic entrant et sortant à définir, voir Configuration d'un hôte bastion pour l'accès à la grappe.