Déployer Kubernetes sans serveur avec les noeuds virtuels du moteur Kubernetes pour OCI
Les deux modes d'exploitation peuvent prendre en charge les applications de base jusqu'aux applications les plus critiques. Avec les noeuds virtuels, les opérations Kubernetes sont simplifiées et offrent le meilleur rapport prix-performance. Le compromis entre les noeuds gérés et les noeuds virtuels est avec les noeuds gérés; vous avez un meilleur contrôle sur votre infrastructure de noeuds. Vous pouvez configurer vos ressources Kubernetes pour qu'elles utilisent HostPort et HostNetwork ou exécuter DaemonSets et d'autres options qui peuvent être requises pour vos applications ou outils. Dans la plupart des cas d'utilisation, ces options ne sont pas requises.
Les noeuds virtuels ont le plus de sens lorsque vous n'avez pas besoin d'affiner le contrôle de l'exécution et de la gestion de vos conteneurs. Si vos applications nécessitent la configuration de votre infrastructure de noeuds qui n'est pas disponible avec les noeuds virtuels, utilisez les noeuds gérés.
Architecture
Pour intégrer la grappe OKE à la chambre forte OCI, l'opérateur Clés secrètes externes est déployé dans la grappe OKE. Vous pouvez ainsi définir une ressource SecretStore mappée à la chambre forte OCI pour contenir le mot de passe de la base de données. Une fois la ressource SecretStore mappée, la grappe OKE peut accéder au mot de passe en tant que clé secrète Kubernetes. Un rôle de gestion des identités et des accès OCI autorisé à lire à partir de la chambre forte OCI permet au pod d'accéder à la clé secrète. Le rôle est associé au compte de service Kubernetes utilisé dans la définition du pod pour lui accorder l'accès en lecture à partir de la chambre forte OCI.
Le diagramme suivant illustre cette architecture de référence.
Description de l'illustration k8n-virtual-nodes.png
L'architecture comprend les composants suivants :
- Location
Une location est une partition sécurisée et isolée qu'Oracle configure dans Oracle Cloud lors de votre inscription à Oracle Cloud Infrastructure. Vous pouvez créer, organiser et administrer vos ressources dans Oracle Cloud au sein de votre location. Une location est synonyme d'une société ou d'une organisation. Habituellement, une société aura une seule location et reflétera sa structure organisationnelle au sein de cette location. Une seule location est généralement associée à un seul abonnement, et un seul abonnement n'a généralement qu'une seule location.
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (dans différents pays ou continents).
- Compartiment
Les compartiments sont des partitions logiques inter-régions dans une location Oracle Cloud Infrastructure. Utilisez des compartiments pour organiser vos ressources dans Oracle Cloud, contrôler l'accès aux ressources et définir des quotas d'utilisation. Pour contrôler l'accès aux ressources d'un compartiment donné, vous devez définir des politiques qui spécifient qui peut accéder aux ressources et les actions qui peuvent être exécutées.
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données indépendants et autonomes dans une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent pas les éléments d'infrastructure (alimentation ou refroidissement, par exemple) ni le réseau de domaines de disponibilité interne. Par conséquent, une défaillance d'un domaine de disponibilité ne devrait pas affecter les autres domaines de disponibilité de la région.
- Domaines d'erreur
Un domaine d'erreur est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines d'erreur avec une puissance et un matériel indépendants. Lorsque vous répartissez des ressources entre plusieurs domaines d'erreur, vos applications peuvent tolérer les pannes physiques de serveur, la maintenance du système et les pannes d'alimentation au sein d'un domaine d'erreur.
- Réseau en nuage virtuel (VCN) et sous-réseau
Un VCN est un réseau défini par logiciel personnalisable que vous avez configuré dans une région Oracle Cloud Infrastructure. Comme les réseaux en nuage virtuels traditionnels, ils vous offrent un contrôle sur votre environnement de réseau. Un VCN peut disposer de plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Équilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing permet une répartition automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dorsaux.
- Passerelle Internet
La passerelle Internet permet le trafic entre les sous-réseaux publics d'un VCN et l'Internet public.
- Passerelle de traduction d'adresses de réseau (NAT)
Une passerelle NAT permet aux ressources privées d'un VCN d'accéder à des hôtes sur Internet, sans les exposer aux connexions Internet entrantes.
- Passerelle de service
La passerelle de service fournit l'accès d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic entre le réseau VCN et le service Oracle circule sur la matrice réseau Oracle et ne passe pas par Internet.
- Chambre forte
Oracle Cloud Infrastructure Vault vous permet de gérer, de manière centralisée, les clés de chiffrement qui protègent vos données et les données d'identification de clé secrète que vous utilisez pour sécuriser l'accès à vos ressources dans le nuage. Vous pouvez utiliser le service de chambre forte pour créer et gérer des chambres fortes, des clés et des clés secrètes.
- Registre
Oracle Cloud Infrastructure Registry est un registre géré par Oracle qui vous permet de simplifier votre flux de travail, du développement à la mise en production. Le registre vous permet de stocker, de partager et de gérer facilement des artefacts de développement, tels que des images Docker. L'architecture hautement disponible et évolutive d'Oracle Cloud Infrastructure vous permet de déployer et de gérer vos applications en toute confiance.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic qui doivent être autorisés à entrer et à sortir du sous-réseau.
- Table de routage
Les tables de routage virtuelles contiennent des règles pour acheminer le trafic des sous-réseaux vers des destinations en dehors d'un VCN, généralement au moyen de passerelles.
- Moteur Kubernetes pour OCI
Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine ou OKE) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications conteneurisées dans le nuage. Vous indiquez les ressources de calcul dont vos applications ont besoin et Kubernetes Engine les provisionne sur Oracle Cloud Infrastructure dans une location existante. OKE utilise Kubernetes pour automatiser le déploiement, l'ajustement et la gestion des applications conteneurisées sur les grappes d'hôtes.
- Service Oracle MySQL Database
Oracle MySQL Database Service est un service de base de données Oracle Cloud Infrastructure (OCI) entièrement géré qui permet aux développeurs de développer et de déployer rapidement des applications natives en nuage sécurisées. Optimisé pour et exclusivement disponible dans OCI, Oracle MySQL Database Service est créé, géré et pris en charge à 100 % par les équipes d'ingénierie OCI et MySQL.
Oracle MySQL Database Service dispose d'un moteur d'analyse intégré à haute performance (HeatWave) pour exécuter des analyses en temps réel sophistiquées directement sur une base de données opérationnelle MySQL.
- Contrôleur de trafic entrant
Un contrôleur de trafic entrant (ing) est un composant qui s'exécute dans une grappe Kubernetes et gère les ressources de trafic entrant. Il reçoit le trafic du réseau externe, l'achemine vers le service approprié et effectue l'équilibrage de charge et la terminaison SSL. Le contrôleur de trafic entrant s'exécute généralement en tant que pod distinct dans la grappe et peut être ajusté indépendamment des services qu'il gère.
- Clés secrètes Kubernetes
Les clés secrètes Kubernetes peuvent inclure des données de configuration sensibles telles que des jetons d'authentification, des mots de passe et des clés SSH. Les clés secrètes vous permettent de contrôler les données sensibles et réduisent le risque d'exposer les données à des utilisateurs non autorisés. Oracle Container Engine for Kubernetes prend en charge le chiffrement des clés secrètes Kubernetes au repos.
- Opérateur de clé secrète externe
L'opérateur de clé secrète externe de Kubernetes intègre Oracle Container Engine for Kubernetes à Oracle Cloud Infrastructure Vault. L'opérateur lit les informations des API externes et insère automatiquement les valeurs dans une clé secrète Kubernetes.
- SecretStore
Le plan de contrôle de la grappe Kubernetes stocke les données de configuration sensibles (comme les jetons d'authentification, les certificats et les données d'identification) en tant qu'objets de clé secrète Kubernetes dans
etcd.Etcdest un magasin de valeurs de clés distribué à source ouverte, utilisé par Kubernetes pour la coordination et la gestion des états des grappes. Dans les grappes Kubernetes créées par Container Engine pour Kubernetes,etcdécrit et lit des données vers et depuis des volumes de stockage par blocs dans le service Oracle Cloud Infrastructure Block Volumes. Par défaut, Oracle chiffre les données des volumes par blocs au repos, notamment les clés secrètesetcdet Kubernetes. Oracle gère ce chiffrement par défaut à l'aide d'une clé de chiffrement principale, sans aucune action de votre part. Pour un contrôle supplémentaire sur le cycle de vie de la clé de chiffrement principale et sur la façon dont elle est utilisée, vous pouvez choisir de la gérer vous-même, plutôt qu'Oracle de la gérer pour vous.Lorsque vous créez une grappe, vous pouvez spécifier que les clés secrètes Kubernetes dans
etcddoivent être chiffrées à l'aide d'Oracle Key Management Cloud Service. - Pod
Un pod est un groupe d'un ou de plusieurs conteneurs et de leur stockage partagé, ainsi que toutes les options spécifiques sur la façon dont ils doivent être exécutés ensemble. En général, les conteneurs d'un pod partagent le même réseau et le même espace mémoire et peuvent accéder à des volumes partagés pour le stockage. Ces ressources partagées permettent aux conteneurs d'un pod de communiquer en interne de manière transparente, comme s'ils étaient installés sur un seul hôte logique.
- Noeud virtuel
Un noeud virtuel est une abstraction logicielle d'un noeud réel. Les noeuds virtuels sont déployés dans la location d'OCI et sont entièrement surveillés et gérés par OCI.
Recommandations
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur place ou un autre fournisseur de nuage) auquel vous voulez configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
Utilisez des sous-réseaux régionaux.
- Groupes de sécurité de réseau
Vous pouvez utiliser des groupes de sécurité de réseau pour définir un jeu de règles de trafic entrant et sortant qui s'appliquent à des cartes vNIC spécifiques. Nous vous recommandons d'utiliser des groupes plutôt que des listes de sécurité, car ils vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.
Vous pouvez utiliser des groupes de sécurité de réseau pour définir un jeu de règles de trafic entrant et sortant qui s'appliquent à des cartes vNIC spécifiques. Nous vous recommandons d'utiliser des groupes plutôt que des listes de sécurité, car ils vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.
- Bande passante de l'équilibreur de charge
Lors de la création de l'équilibreur de charge, vous pouvez sélectionner une forme prédéfinie qui fournit une bande passante fixe, ou spécifier une forme personnalisée (flexible) dans laquelle vous définissez une plage de bande passante et laissez le service ajuster la bande passante automatiquement en fonction des modèles de trafic. Avec l'une ou l'autre approche, vous pouvez modifier la forme en tout temps après avoir créé l'équilibreur de charge.
Points à considérer
Tenez compte des points suivants lorsque vous utilisez des noeuds virtuels.
Pour commencer avec des noeuds virtuels, vous devez d'abord créer une grappe du moteur Kubernetes pour OCI avec un groupe de noeuds virtuels ou ajouter un groupe de noeuds virtuels à une grappe Kubernetes Engine (OKE) existante.
- Sélectionnez la forme et le positionnement de vos noeuds virtuels.
-
La forme détermine le type de processeurs ainsi que la quantité de ressources d'UC et de mémoire pouvant être affectées à chaque pod. Chaque pod peut affecter jusqu'aux limites de mémoire et d'UC de la forme sélectionnée.
-
Les noeuds virtuels adapteront les pods avec la configuration de HPA (Horizontal Pod Autoscaler). Il n'est pas nécessaire de configurer le composant d'ajustement automatique de noeud.
-
Vous pouvez placer vos noeuds virtuels dans des domaines de disponibilité et des domaines d'erreur particuliers qui sont les mieux adaptés à vos besoins en matière de haute disponibilité. Pour un niveau maximal de redondance, placez un noeud virtuel dans chaque domaine d'erreur au sein du domaine de disponibilité de votre grappe OKE.
-
Utilisez des étiquettes de noeud Kubernetes pour spécifier le positionnement de vos pods sur les noeuds virtuels. Pour obtenir une répartition uniforme des pods entre les noeuds, utilisez la contrainte
PodTopologySpread.
-
-
Les noeuds virtuels utilisent un réseau de pods natif de VCN. Le nombre de pods disponibles dans la grappe est limité par le nombre d'adresses IP disponibles dans le sous-réseau.
- Le service de réseau de pods natif fournit à chaque pod une adresse IP native pour les sous-réseaux du VCN, ce qui permet à chaque pod de bénéficier des fonctions de sécurité de réseau OCI intégrées telles que les journaux de flux de VCN, les politiques de routage, le VTAP et les groupes de sécurité.
- Envisagez d'utiliser un intervalle de sous-réseaux qui permet le nombre de pods et de noeuds que vous prévoyez d'utiliser et qui offre une marge de croissance.
- Définissez des groupes de sécurité de réseau pour limiter le type de trafic pouvant entrer et sortir des pods.
- Utilisez les journaux de flux de VCN pour inspecter tout le trafic réseau entre les pods ou utilisez le VTAP pour saisir le trafic réseau.
- Les pods des noeuds virtuels ont accès à d'autres services OCI avec une identité de charge de travail.
Dans certains cas, un pod peut avoir besoin d'accéder à d'autres services dans OCI.
- Utilisez l'identité de charge de travail pour accorder des privilèges aux pods des noeuds virtuels. Workload Identity associe des rôles de gestion des identités et des accès OCI à des comptes de service Kubernetes affectés à des pods.
- Les noeuds virtuels assurent l'isolement au niveau de l'hyperviseur pour votre module de réseautage.
Les vulnérabilités de sécurité pourraient potentiellement permettre aux processus malveillants à l'intérieur d'un conteneur de " s'échapper " et affecter le noyau du noeud, ce qui pourrait entraîner l'arrêt du noeud. Le code malveillant peut également accéder aux données en mémoire ou en stockage et les exfiltrer. Les données exfiltrées peuvent potentiellement appartenir à un autre locataire dans un environnement multilocataire.
- Virtual Node fournit un isolement au niveau de l'hyperviseur pour vos pods. Un pod ne partage pas le calcul, la mémoire et le réseau avec d'autres pods de la grappe, ce qui atténue la possibilité qu'un noeud arrêté ou des données exfiltrées appartenant à un autre locataire soient causées par un code malveillant.