Conception des composants de votre topologie

Passez en revue les options d'architecture relatives à la conception du réseau pour la topologie Kubernetes, déterminer si vous avez besoin des hôtes d'administration et de base, et concevoir les pools de noeuds.

Conception du réseau

Déterminez les exigences en matière d'accès aux données de vos applications en conteneur et déterminez les ressources de mise en réseau dont vous avez besoin.

Tenez compte des exigences d'échelle de votre charge de travail lorsque vous décidez de la taille de réseau, c'est-à-dire des plages CIDR pour le VCN et les sous-réseaux.

Joindre les noeuds de salarié à un sous-réseau différent dans VCN. Utilisez des sous-réseaux distincts pour les autres ressources, telles que les noeuds d'équilibreur de charge, l'hôte de base et l'hôte d'administration.

L'approche recommandée consiste à joindre les noeuds de salarié Kubernetes à un sous-réseau privé. Chaque noeud actif ne dispose que d'une adresse IP privée. Utilisez un équilibreur de charge (interne ou public) pour distribuer le trafic aux noeuds de travail. Pour permettre aux noeuds de travail d'initier l'accès aux hôtes sur le réseau Internet public, utilisez une passerelle NAT.

Si vous envisagez de créer des services de type NodePort, associez les noeuds de travail Kubernetes à un sous-réseau public. Le trafic vers et depuis les noeuds est acheminé via la passerelle Internet. Chaque noeud actif dispose d'une adresse IP publique et d'une adresse privée. Vous devez configurer explicitement les règles de sécurité afin d'autoriser l'accès aux noeuds de salarié à partir de l'Internet public.

Vous pouvez utiliser une passerelle de service pour acheminer tout le trafic depuis les noeuds de travail vers les autres services Oracle Cloud (tels qu'Oracle Cloud Infrastructure Object Storage ) au sein de la région.

Restreindre l'accès administratif

Envisagez d'utiliser un hôte de base et un hôte admin pour accéder à votre topologie et la gérer dans le cloud.

Pour protéger les noeuds de travail Kubernetes contre l'accès non autorisé depuis l'extérieur du cloud, isolez les noeuds de travail dans un sous-réseau qui ne dispose pas d'un accès à Internet public et ne les achemine pas.

Déployez un hôte de base et utilisez-le comme seul point d'entrée pour les connexions SSH aux autres instances de calcul de la topologie, y compris pour les noeuds de travail. Pour une sécurité accrue, envisagez d'autoriser un accès SSH à l'hôte bastion uniquement sur un ensemble connu d'adresses IP en dehors du cloud.

Pour les opérations d'administration sur votre topologie Kubernetes dans le cloud, envisagez de créer un hôte d'administration dans le cloud à l'aide des outils requis tels que kubectl et la CLI d'Oracle Cloud Infrastructure qui y sont installés. Utilisez bastion comme serveur jump pour les connexions SSH à l'hôte admin.

Conception des pools de noeuds

Un pool de noeuds est un groupe d'instances de calcul configurées de manière identique au sein d'un cluster Kubernetes. Les pools de noeuds vous permettent de déployer et de gérer des applications avec différentes exigences en ressources de manière efficace. Vous pouvez, par exemple, créer un pool de noeuds distinct pour chaque application ou service en conteneur.

Choisissez le nombre de pools de noeuds à créer et le nombre de noeuds de travail dans chaque pool en fonction du nombre et de la taille des charges de travail en conteneur. Un minimum de trois noeuds de processus actifs sont créés dans chaque pool. Tous les noeuds de salarié d'un pool donné sont créés à l'aide de la même forme que celle que vous indiquez.

Garantir la haute disponibilité

Assurez-vous que les charges de travail en conteneur dans le cloud ne sont pas affectées par les coupures du centre de données.

Les régions Oracle Cloud Infrastructure contiennent plusieurs domaines de disponibilité tolérant aux pannes. Les domaines de disponibilité ne partagent pas d'infrastructure, telles que l'alimentation, le refroidissement et le réseau interne. Il est peu probable qu'un échec dans un domaine de disponibilité affecte les autres dans la même région. Dans une région comportant plusieurs domaines de disponibilité, les noeuds de travail sont répartis sur ces domaines. Vous pouvez associer les noeuds aux sous-réseaux régionaux, qui s'étendent sur tous les domaines de disponibilité.

Chaque domaine de disponibilité contient trois domaines de pannes : chaque groupement isolé de matériel et d'infrastructure. Une panne matérielle ou un événement de maintenance qui affecte un domaine de pannes n'affecte pas les ressources dans les autres domaines de pannes. Dans les régions ayant un domaine de disponibilité unique, les noeuds de travail sont répartis sur les domaines de pannes dans le centre de données.