En savoir plus sur la conception d'une topologie Kubernetes dans le cloud
Oracle Cloud Infrastructure Container Engine for Kubernetes est un service géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers des clusters Kubernetes dans le cloud.
Architecture
L'architecture d'une topologie Kubernetes dans le cloud dépend de facteurs tels que l'accessibilité des charges de travail en conteneur à partir de l'Internet public, la taille et le nombre de pools de noeuds, ainsi que les exigences de tolérance aux pannes de vos charges de travail.
Le diagramme suivant illustre une architecture de référence d'un cluster Kubernetes dans une région Oracle Cloud Infrastructure contenant plusieurs domaines de disponibilité.
- Réseau cloud virtuel (VCN) : toutes les ressources de la topologie se trouvent dans un environnement VCN unique.
- Sous-réseaux :
Le kit VCN de cette architecture contient quatre sous-réseaux, deux publics et deux privés. L'un des sous-réseaux publics est destiné à l'hôte de base ; l'autre concerne l'équilibreur de charge Internet. Parmi les deux sous-réseaux privés, un pour un hôte d'administration contenant les outils nécessaires à la gestion du cluster Kubernetes. L'autre sous-réseau privé est destiné aux noeuds du cluster Kubernetes.
Tous les sous-réseaux sont régionaux. En d'autres termes, ils s'étendent sur tous les domaines de disponibilité de la région, abrégés au format AD1, AD2 et AD3 dans le diagramme d'architecture. Ils sont donc protégés par rapport à une défaillance du domaine de disponibilité. Vous pouvez utiliser les sous-réseaux pour les ressources à déployer sur n'importe quel domaine de disponibilité de la région.
- Passerelles réseau
- Passerelle de service (facultatif)
La passerelle de service permet aux ressources de VCN d'accéder aux services Oracle tels qu'Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure File Storage et Oracle Cloud Infrastructure Database en privé, c'est-à-dire sans exposer le trafic à l'Internet public. Les connexions via la passerelle de service peuvent être lancées à partir des ressources de VCN, et non à partir des services avec lesquels les ressources communiquent.
- Passerelle NAT (facultatif)
La passerelle NAT permet aux instances de calcul connectées à des sous-réseaux privés dans VCN d'accéder à l'Internet public. Les connexions via la passerelle NAT peuvent être lancées à partir des ressources de VCN, et non à partir de l'Internet public.
- Passerelle Internet
La passerelle Internet permet la connexion entre l'Internet public et toutes les ressources dans les sous-réseaux publics de VCN.
- Passerelle de service (facultatif)
- Hôte de base (facultatif)
L'hôte bastion est une instance de calcul servant de point d'entrée à la topologie hors du cloud.
Les infos de paramétrage de l'hôte de base sont généralement fournies dans une zone démilitarisée. Cela vous permet de protéger les ressources sensibles en les plaçant dans des réseaux privés inaccessibles directement à partir de l'extérieur du cloud. Vous exposez un point d'entrée unique et connu que vous pouvez auditer régulièrement. Par conséquent, vous évitez d'afficher des composants de la topologie plus sensibles, sans compromettre l'accès.
L'hôte bastion dans la topologie échantillon est attaché à un sous-réseau public et dispose d'une adresse IP publique. Une règle de sécurité entrante est configurée de façon à autoriser les connexions SSH à l'hôte de base à partir de l'Internet public. Pour fournir un niveau de sécurité supplémentaire, vous pouvez limiter l'accès SSH à l'hôte de base à un bloc spécifique d'adresses IP.
Vous pouvez accéder aux instances Oracle Cloud Infrastructure dans les sous-réseaux privés via l'hôte de base. Pour ce faire, activez le transfert
ssh-agent, qui vous permet de vous connecter à l'hôte de base, puis d'accéder au serveur suivant en transmettant les informations d'identification à partir de votre ordinateur. Vous pouvez également accéder aux instances dans le sous-réseau privé à l'aide du tunneling SSH dynamique. Le tunnel dynamique fournit un proxy SOCKS sur le port local, mais les connexions proviennent de l'hôte distant. - Noeuds d'équilibreur de charge :
Les noeuds de l'équilibreur de charge interceptent et distribuent le trafic vers les noeuds Kubernetes disponibles qui exécutent vos applications en conteneur. Si les applications doivent être accessibles à partir de l'Internet public, utilisez des équilibreurs de charge publics ; sinon, utilisez des équilibreurs de charge privés, qui n'ont pas d'adresse IP publique. L'architecture affiche deux noeuds d'équilibreur de charge, chacun dans un domaine de disponibilité distinct.
- Hôte d'administration (facultatif) :
En utilisant un hôte d'administration, vous pouvez éviter d'installer et d'exécuter des outils de gestion d'infrastructure tels que
kubectl,helmet la CLI Oracle Cloud Infrastructure en dehors du cloud. Dans l'architecture de référence, l'hôte d'administration se trouve dans un sous-réseau privé et est accessible via l'hôte de base. Pour pouvoir exécuter l'interface de ligne de commande Oracle Cloud Infrastructure sur l'hôte d'administration, vous devez le désigner en tant que principal d'instance. - Noeuds de salarié Kubernetes :
Les noeuds de salarié Kubernetes sont les instances de calcul sur lesquelles vous pouvez déployer vos applications en conteneur. Tous les noeuds de processus actifs de cette architecture de référence se trouvent dans un seul pool de noeuds et sont attachés à un sous-réseau privé. Si nécessaire, vous pouvez créer plusieurs pools de noeuds.
Les noeuds de salarié dans l'architecture de référence ne sont pas accessibles directement à partir de l'Internet public. Les utilisateurs des applications en conteneur peuvent y accéder via l'équilibreur de charge. Les administrateurs peuvent accéder aux noeuds de travail via l'hôte de base.
L'architecture affiche trois noeuds de travail, chacun dans un domaine de disponibilité distinct au sein de la région : AD1, AD2 et AD3. Les noeuds maîtres Kubernetes sont exécutés dans la location d'Oracle et ne sont pas affichés.
Si la région dans laquelle vous souhaitez déployer vos applications en conteneur contient un seul domaine de disponibilité, les noeuds de salarié sont distribués sur les domaines de pannes (FD) du domaine de disponibilité, comme indiqué dans l'architecture suivante.
A propos des services et des droits d'accès obligatoires
Cette solution requiert les droits d'accès et services suivants :
| Service | Droits d'accès obligatoires |
|---|---|
| Oracle Cloud Infrastructure Identity and Access Management | Gérer les groupes et stratégies dynamiques. |
| Oracle Cloud Infrastructure Networking | Gérer les réseaux cloud virtuels, les sous-réseaux, les passerelles Internet, les passerelles NAT, les passerelles de service, les tables de routage et les listes de sécurité. |
| Oracle Cloud Infrastructure Compute | Gérer les instances de calcul. |
| Oracle Cloud Infrastructure Container Engine for Kubernetes | Gérez les clusters et les pools de noeuds.
Reportez-vous à Configuration de stratégie pour la création et le déploiement d'un cluster. |