Clusters publics et privés
Sur Compute Cloud@Customer, avant de créer un cluster, déterminez le type d'accès réseau requis par le cluster : cluster public ou cluster privé. Vous ne pouvez pas créer de clusters publics et privés dans un seul VCN.
La principale différence entre un cluster public et un cluster privé consiste à configurer des sous-réseaux publics ou privés pour l'adresse d'API Kubernetes et l'équilibreur de charge de processus actif.
Les sous-réseaux des noeuds de processus actif et de plan de contrôle sont toujours privés.
Pour les noeuds de processus actif et de plan de contrôle, vous pouvez configurer des règles de routage qui autorisent l'accès uniquement au sein du VCN ou en dehors du VCN. Cette documentation nomme ces tables de routage "vcn_private" et "nat_private". Vous pouvez choisir l'une de ces configurations de sous-réseau privé pour les noeuds de processus actif et les noeuds de plan de contrôle, que le cluster soit privé ou public.
Clusters publics
Un cluster public requiert les ressources réseau suivantes :
-
Sous-réseau public pour l'adresse d'API Kubernetes. Reportez-vous aux instructions de création d'un sous-réseau public "control-plane-endpoint" dans Création d'un sous-réseau de plan de contrôle OKE (superposition de canal) et Création d'un sous-réseau de plan de contrôle (pod natif VCN.
-
Sous-réseau public pour l'équilibreur de charge de travail. Reportez-vous aux instructions de création d'un sous-réseau "service-lb" public dans Création d'un sous-réseau d'équilibreur de charge de processus actif (superposition de canal) et Création d'un sous-réseau d'équilibreur de charge de processus actif (pod natif VCN).
-
Passerelle Internet permettant de connecter des ressources sur un sous-réseau public à Internet à l'aide d'adresses IP publiques.
-
Une passerelle NAT. Utiliser une passerelle NAT pour l'accès Internet sortant. Une passerelle NAT connecte les ressources d'un sous-réseau privé à Internet sans exposer d'adresses IP privées.
-
Au moins trois adresses IP publiques libres. Des adresses IP publiques gratuites sont requises pour la passerelle NAT, l'équilibreur de charge de plan de contrôle et l'équilibreur de charge de processus actif.
L'équilibreur de charge de travail nécessite une adresse IP publique gratuite pour exposer les applications. L'équilibreur de charge de travail peut nécessiter davantage d'adresses IP publiques gratuites en fonction des applications exécutées sur les pods.
Clusters privés
Si vous créez plusieurs réseaux cloud virtuels OKE, chaque CIDR doit être unique. Les CIDR de différents réseaux cloud virtuels pour les clusters privés ne peuvent pas chevaucher d'autres CIDR VCN ou d'autres CIDR sur site. Les adresses IP utilisées doivent être exclusives à chaque VCN.
Un cluster privé dispose des ressources réseau suivantes :
-
Sous-réseau privé pour l'adresse d'API Kubernetes. Reportez-vous aux instructions de création d'un sous-réseau privé "control-plane-endpoint" dans Création d'un sous-réseau de plan de contrôle OKE (superposition de canal) et Création d'un sous-réseau de plan de contrôle (pod natif VCN)
-
Sous-réseau privé pour l'équilibreur de charge de processus actif. Reportez-vous aux instructions de création d'un sous-réseau "service-lb" privé dans Création d'un sous-réseau d'équilibreur de charge de plan de contrôle OKE (superposition de canal) et Création d'un sous-réseau d'équilibreur de charge de plan de contrôle (pod natif VCN).
-
Une table de routage sans règles de routage. Cette table de routage autorise l'accès uniquement au sein du VCN.
-
(Facultatif) Passerelle d'appairage local (LPG). Utilisez une passerelle d'appairage local pour autoriser l'accès à partir d'autres réseaux cloud virtuels. Une passerelle d'appairage local permet d'accéder au cluster à partir d'une instance exécutée sur un autre VCN. Créez une passerelle d'appairage local sur le VCN OKE et créez une passerelle d'appairage local sur un deuxième VCN sur le Compute Cloud@Customer. Utilisez la commande LPG connect pour évaluer les deux passerelles d'appairage local. Les réseaux cloud virtuels appairés peuvent se trouver dans différentes locations. Les CIDR des réseaux cloud virtuels appairés ne peuvent pas se chevaucher. Reportez-vous à Connexion de réseaux cloud virtuels via une passerelle d'appairage local.
Créez une règle de routage pour diriger le trafic de sous-réseau VCN vers et depuis les passerelles d'appairage local, et des règles de sécurité pour autoriser ou refuser certains types de trafic. Reportez-vous à Création d'un VCN (superposition de canal) ou à Création d'un VCN (pod natif VCN) pour la table de routage à ajouter au VCN OKE et à une table de routage similaire à ajouter au deuxième VCN Ajoutez la même règle de routage sur le deuxième VCN, en indiquant le CIDR VCN OKE comme destination.
Installez le kit SDK OCI et
kubectl
sur l'instance sur le deuxième VCN et connectez-vous au cluster privé. Reportez-vous à Création d'un fichier de configuration Kubernetes. -
(Facultatif) Une passerelle de routage dynamique (DRG). Utilisez un DRG pour activer l'accès à partir du réseau sur site. Un DRG autorise le trafic entre le VCN OKE et l'espace d'adressage IP du réseau sur site. Créez le DRG dans le compartiment VCN OKE, puis attachez le VCN OKE à ce DRG. Reportez-vous à Connexion au réseau sur site via une passerelle de routage dynamique (DRG).
Créez une règle de routage pour diriger le trafic vers l'espace d'adressage IP du réseau de centre de données sur site. Reportez-vous à Création d'un VCN (superposition de canal) ou Création d'un VCN (pod natif VCN) pour la table de routage à ajouter au VCN OKE.