Création de ressources de réseau de pods natifs VCN
Sur Compute Cloud@Customer, le réseau de pods natifs du VCN vous permet de gérer directement le trafic à partir des pods, car les adresses IP des pods proviennent directement du bloc CIDR du VCN et non d'une surcouche de réseau telle que la superposition de canal. Le réseau de pods natif du VCN offre plus de flexibilité et de contrôle sur le trafic et vous permet d'utiliser différentes règles de sécurité.
Le réseau de pods natifs de VCN connecte les noeuds d'une grappe Kubernetes aux sous-réseaux de pods du VCN OKE. Les adresses IP de pod dans le VCN OKE sont directement routables à partir d'autres réseaux en nuage virtuels connectés (appairés) au VCN OKE et à partir de réseaux sur place.
Lorsque vous créez une grappe qui utilise un réseau de pods natif VCN lors de la création d'une grappe, le VCN que vous spécifiez doit avoir un sous-réseau nommé pod
. Vous devez fournir un sous-réseau nommé pod
pour que le système puisse le trouver. Le sous-réseau de pods comporte des règles de sécurité qui permettent aux pods des noeuds de plan de contrôle de communiquer directement avec les pods des noeuds de travail et avec d'autres pods et d'autres ressources. Voir Création d'un sous-réseau de pods (VCN-Native Pod). Si vous sélectionnez VCN-Native Pod Networking et que vous n'avez pas de sous-réseau nommé pod
, la création de la grappe échouera.
Lorsque vous créez un groupe de noeuds pour une grappe qui utilise un réseau de pods natif VCN, le sous-réseau de pods que vous spécifiez (Communication de pod > Sous-réseau de communication de pod ou --pod-subnet-ids
) sert de fonction à un sous-réseau de pods pour les pods sur les noeuds de travail. Ce sous-réseau de pods doit comporter des règles de sécurité qui permettent aux pods des noeuds de travail de communiquer directement avec d'autres pods des noeuds de travail et des noeuds de plan de contrôle. Vous pouvez éventuellement spécifier le sous-réseau de noeuds de travail en tant que sous-réseau de pods. Le CIDR du sous-réseau de pods que vous spécifiez doit être supérieur à /25. La taille du sous-réseau de pod doit être supérieure à celle du sous-réseau de noeuds de travail.
En général, lorsque vous utilisez le réseau de pods natif du réseau en nuage virtuel (VCN), les règles de sécurité peuvent permettre aux pods de communiquer directement avec d'autres pods sur le même noeud ou sur d'autres noeuds de la grappe, avec d'autres grappes, avec d'autres services et avec Internet.
Formes de noeud et nombre de pods
Lors de l'utilisation du plugiciel CNI de réseau de pods natifs du VCN OCI, chaque pod a besoin d'une adresse IP privée. Par défaut, 31 adresses IP sont affectées à une carte VNIC à utiliser par les pods s'exécutant sur le noeud de travail.
Vous pouvez spécifier le nombre maximal de pods à exécuter sur un noeud de travail. Le maximum par défaut est de 31 pods par noeud de travail. Vous pouvez spécifier jusqu'à 110.
Une forme de noeud, et donc un noeud de travail, comporte au moins deux cartes vNIC. La première carte VNIC est connectée au sous-réseau de travail. La deuxième carte VNIC est connectée au sous-réseau de pods. Par conséquent, un noeud de travail peut prendre en charge au moins 31 pods. Si vous voulez plus de 31 pods sur un seul noeud de travail, spécifiez une forme pour le groupe de noeuds qui prend en charge trois cartes VNIC ou plus : une carte VNIC pour la connexion au sous-réseau du noeud de travail et au moins deux cartes VNIC pour la connexion au sous-réseau du pod.
Une forme de noeud standard VM.PCAStandard1.4 peut avoir un maximum de quatre cartes vNIC, et le noeud de travail peut prendre en charge jusqu'à 93 pods. Un VM.PCAStandard.E5. La forme de noeud flexible avec cinq OCPU peut avoir un maximum de cinq cartes vNIC, et le noeud de travail peut prendre en charge jusqu'à 110 pods. Un noeud ne peut pas avoir plus de 110 pods (voir Limites des ressources fournies par Compute Cloud@Customer).
La formule suivante résume le nombre maximal de pods pris en charge par noeud :
MIN( (Number of VNICs - 1) * 31 ), 110)
Pour plus d'informations sur toutes les formes de noeud, voir Formes de calcul.
Ressources de réseau de pods natifs VCN
Les définitions de ressource dans les sections suivantes de cette rubrique créent un exemple de travail de jeu de ressources de réseau pour les grappes de charges de travail lorsque vous utilisez le réseau de pods natifs de VCN. Utilisez cette configuration comme guide lorsque vous créez ces ressources. Vous pouvez modifier les valeurs des propriétés telles que les blocs CIDR et les adresses IP. Ne modifiez pas les valeurs des propriétés telles que le protocole réseau, le paramètre avec conservation de l'état ou le paramètre privé/public.
Voir Ports de réseau en grappe de charge de travail (VCN-Native Pod) pour des ports spécifiques qui doivent être ouverts à des fins spécifiques.
Créez les ressources de réseau suivantes. Pour utiliser Terraform, voir Exemples de scripts Terraform (VCN-Native Pod).
Créez toutes les ressources de réseau dans le même compartiment.
-
VCN. Voir Création d'un VCN (VCN-Native Pod).
-
Passerelle Internet
-
Passerelle NAT
-
Passerelle de routage dynamique
-
Passerelle d'appairage local
-
Règles de routage
-
Listes de sécurité
-
Les cinq sous-réseaux suivants :
-
Pod. Voir Création d'un sous-réseau de pods (VCN-Native Pod).
-
Travailleur. Voir Création d'un sous-réseau de travailleurs (VCN-Native Pod).
-
Équilibreur de charge de travail. Voir Création d'un sous-réseau d'équilibreurs de charge de travail (VCN-Native Pod).
-
Plan de contrôle. Voir Création d'un sous-réseau de plan de contrôle (VCN-Native Pod).
-
Équilibreur de charge de plan de contrôle. Voir Création d'un sous-réseau d'équilibreurs de charge de plan de contrôle (VCN-Native Pod).
-