Déployer Kubernetes sans serveur avec des noeuds virtuels OCI Kubernetes Engine
Les deux modes d'exploitation peuvent prendre en charge des 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-performances. Le compromis entre les noeuds gérés et les noeuds virtuels réside dans les noeuds gérés ; vous avez un meilleur contrôle sur l'infrastructure des 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 sont plus pertinents 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 l'infrastructure de noeud qui n'est pas disponible avec les noeuds virtuels, utilisez les noeuds gérés.
Architecture
Pour intégrer le cluster OKE à OCI Vault, l'opérateur de clés secrètes externes est déployé dans le cluster OKE. Vous pouvez ainsi définir une ressource SecretStore qui est mise en correspondance avec OCI Vault afin de contenir le mot de passe de la base de données. Une fois la ressource SecretStore mise en correspondance, le cluster OKE peut accéder au mot de passe en tant que clé secrète Kubernetes. Un rôle OCI Identity and Access Management avec le droit d'accès en lecture dans OCI Vault 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 du coffre OCI.
Le schéma suivant illustre cette architecture de référence.
Description de l'illustration k8n-virtual-nodes.png
k8n-noeuds-virtuels-oracle.zip
L'architecture comprend les composants suivants :
- Tenancy
Une location est une partition sécurisée et isolée configurée par Oracle 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'entreprise ou d'organisation. En général, une entreprise dispose d'une seule location et reflète sa structure organisationnelle au sein de cette location. Une location unique 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 précise, incluant 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 (entre pays, voire continents).
- Compartiment
Les compartiments sont des partitions logiques inter-région au sein d'une location Oracle Cloud Infrastructure. Utilisez des compartiments pour organiser les ressources dans Oracle Cloud, en contrôler l'accès et définir des quotas d'utilisation. Pour contrôler l'accès aux ressources d'un compartiment donné, vous définissez des stratégies qui indiquent qui peut accéder aux ressources et les actions réalisables.
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
- Domaines de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec du matériel et une alimentation indépendants. Lorsque vous répartissez les ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes physiques du serveur, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent le contrôle sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud 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é.
- Equilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatique à partir d'un seul point d'entrée vers plusieurs serveurs dans le back-end.
- Passerelle Internet
La passerelle Internet autorise le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.
- Passerelle NAT (Network Address Translation)
Une passerelle NAT permet aux ressources privées d'un VCN d'accéder aux hôtes sur Internet, sans les exposer aux connexions Internet entrantes.
- Passerelle de service
La passerelle de service fournit un accès à partir d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic entre le VCN et le service Oracle passe par la structure du réseau Oracle et ne traverse pas Internet.
- Vault
Oracle Cloud Infrastructure Vault permet de gérer de manière centralisée les clés de cryptage qui protègent vos données et les informations d'identification de clé secrète utilisées pour sécuriser l'accès à vos ressources dans le cloud. Vous pouvez utiliser le service Vault pour créer et gérer des coffres, des clés et des clés secrètes.
- Registry
Oracle Cloud Infrastructure Registry est un registre géré par Oracle qui vous permet de simplifier votre workflow du développement jusqu'à la 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 garantit un déploiement et une gestion fiables des applications.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent 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 via des passerelles.
- OCI Kubernetes Engine
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 en conteneur vers le cloud. Indiquez les ressources de calcul requises par vos applications et Kubernetes Engine les provisionne sur Oracle Cloud Infrastructure dans une location existante. OKE utilise Kubernetes pour automatiser le déploiement, le redimensionnement et la gestion des applications en conteneur dans les clusters d'hôtes.
- Oracle MySQL Database Service
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 sécurisées natives du cloud. Optimisé pour et exclusivement disponible dans OCI, Oracle MySQL Database Service est conçu, 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é hautes performances (HeatWave) qui permet d'exécuter des analyses sophistiquées en temps réel directement sur une base de données MySQL opérationnelle.
- Contrôleur d'entrée
Un contrôleur d'entrée (ing) est un composant qui s'exécute dans un cluster Kubernetes et gère les ressources entrantes. 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 d'entrée s'exécute généralement sous la forme d'un pod distinct dans le cluster et peut être redimensionné 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 de réduire le risque d'exposition des données à des utilisateurs non autorisés. Oracle Container Engine for Kubernetes prend en charge le cryptage des clés secrètes Kubernetes au repos.
- Opérateur de clés secrètes externes
L'opérateur de clés secrètes externes Kubernetes intègre Oracle Container Engine for Kubernetes à Oracle Cloud Infrastructure Vault. L'opérateur lit les informations à partir d'API externes et injecte automatiquement les valeurs dans une clé secrète Kubernetes.
- SecretStore
Le plan de contrôle de cluster Kubernetes stocke les données de configuration sensibles (comme les jetons d'authentification, les certificats et les informations d'identification) en tant qu'objets secrets Kubernetes dans
etcd.Etcdest une banque clé-valeur distribuée open source que Kubernetes utilise pour la coordination des clusters et la gestion de l'état. In the Kubernetes clusters created by Container Engine for Kubernetes,etcdwrites and reads data to and from block storage volumes in the Oracle Cloud Infrastructure Block Volumes service. Par défaut, Oracle crypte les données dans les volumes de blocs au repos, y compris les clés secrètesetcdet Kubernetes. Oracle gère ce cryptage par défaut à l'aide d'une clé de cryptage maître, sans aucune action de votre part. Pour un contrôle supplémentaire sur le cycle de vie de la clé de cryptage maître et sur son utilisation, vous pouvez choisir de gérer la clé de cryptage maître vous-même plutôt qu'Oracle ne la gère pour vous.Lorsque vous créez un cluster, vous pouvez indiquer que les clés secrètes Kubernetes dans
etcddoivent être cryptées à l'aide d'Oracle Key Management Cloud Service. - Pod
Un pod est un groupe de 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 aux 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 hôte logique unique.
- 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 à des sous-réseaux dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresse IP privée standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) auquel vous avez l'intention de 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 du flux de trafic et des exigences 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é.
Utiliser des sous-réseaux régionaux.
- Groupes de sécurité réseau
Vous pouvez utiliser des groupes de sécurité réseau pour définir un ensemble de règles entrantes et sortantes qui s'appliquent à des cartes d'interface réseau virtuelles spécifiques. Nous vous recommandons d'utiliser des groupes de sécurité réseau plutôt que des listes de sécurité, car ces derniers 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é réseau pour définir un ensemble de règles entrantes et sortantes qui s'appliquent à des cartes d'interface réseau virtuelles spécifiques. Nous vous recommandons d'utiliser des groupes de sécurité réseau plutôt que des listes de sécurité, car ces derniers vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.
- Bande passante d'é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 indiquer une forme personnalisée (flexible) dans laquelle vous définissez une plage de bande passante et laisser le service redimensionner automatiquement la bande passante en fonction des modèles de trafic. Dans l'une ou l'autre approche, vous pouvez modifier la forme à tout moment après avoir créé l'équilibreur de charge.
Points à prendre en compte
Tenez compte des points suivants lorsque vous utilisez des noeuds virtuels.
Pour commencer avec des noeuds virtuels, vous devez d'abord créer un cluster OCI Kubernetes Engine avec un pool de noeuds virtuels ou ajouter un pool de noeuds virtuels à un cluster Kubernetes Engine (OKE) existant.
- 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 de CPU et de mémoire pouvant être allouées à chaque pod. Chaque pod peut allouer jusqu'aux limites de mémoire et de CPU de la forme sélectionnée.
-
Les noeuds virtuels redimensionnent les pods avec la configuration de l'outil de redimensionnement automatique de pod horizontal (HPA). Il n'est pas nécessaire de configurer l'outil de redimensionnement automatique de noeud.
-
Vous pouvez placer vos noeuds virtuels dans des domaines de disponibilité et des domaines de pannes spécifiques qui sont les plus adaptés à vos besoins en haute disponibilité. Pour le niveau maximal de redondance, placez un noeud virtuel dans chaque domaine de pannes dans le domaine de disponibilité de votre cluster OKE.
-
Utilisez les libellés de noeud Kubernetes pour indiquer le placement de vos pods sur des noeuds virtuels. Pour obtenir une distribution uniforme des pods sur les noeuds, utilisez la contrainte
PodTopologySpread.
-
-
Les noeuds virtuels utilisent le réseau de pod natif VCN. Le nombre de pods disponibles dans le cluster est limité par le nombre d'adresses IP disponibles dans le sous-réseau.
- Native Pod Networking fournit à chaque pod une adresse IP native des sous-réseaux du VCN, ce qui permet à chaque pod de bénéficier de fonctionnalités de sécurité réseau OCI intégrées telles que les journaux de flux VCN, les stratégies de routage, le point d'accès de test virtuel et les groupes de sécurité.
- Envisagez d'utiliser une plage de sous-réseaux qui tient compte du nombre de pods et de noeuds que vous prévoyez d'utiliser et qui offre de la place pour la croissance.
- Définissez des groupes de sécurité réseau pour limiter le type de trafic pouvant entrer et sortir des pods.
- Utilisez les journaux de flux VCN pour inspecter tout le trafic réseau entre les pods ou utilisez le point d'accès de test virtuel pour capturer le trafic réseau.
- Les pods dans les noeuds virtuels ont accès à d'autres services OCI avec une identité de charge globale.
Dans certains cas, un pod peut avoir besoin d'accéder à d'autres services dans OCI.
- Utilisez l'identité de charge globale pour accorder des privilèges aux pods dans les noeuds virtuels. L'identité de charge globale associe les rôles OCI Identity and Access Management aux comptes de service Kubernetes affectés aux pods.
- Les noeuds virtuels fournissent une isolation au niveau de l'hyperviseur pour votre pod.
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 dans la mémoire ou le stockage et exfiltrer les données. Les données exfiltrées peuvent potentiellement appartenir à un autre locataire dans un environnement colocatif.
- Le noeud virtuel fournit une isolation 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 du cluster, ce qui réduit la possibilité d'un noeud arrêté ou de données exfiltrées appartenant à un autre locataire en raison d'un code malveillant.