Concepts relatifs à Kubernetes Engine (OKE) et à Kubernetes

Découvrez les concepts clés que vous devez comprendre avant d'utiliser Kubernetes Engine (OKE).

Cette rubrique décrit les concepts clés relatifs à l'utilisation de Kubernetes Engine.

Grappes Kubernetes

Une grappe Kubernetes est un groupe de noeuds (machines exécutant des applications). Chaque noeud peut être une machine physique ou virtuelle. La capacité d'un noeud (nombre d'UC et capacité de mémoire) est définie lors de la création du noeud. Une grappe comprend :

  • Des noeuds de plan de contrôle (précédemment appelés "noeuds principaux"). En général, il existe trois noeuds de plan de contrôle pour assurer la haute disponibilité.
  • Des noeuds de travail, organisés en groupes de noeuds.

Lors de la création d'une grappe à l'aide de Kubernetes Engine, vous pouvez créer la nouvelle grappe en tant que grappe de base ou en tant que grappe améliorée.

Grappes améliorées et de base

Lors de la création d'une grappe avec Kubernetes Engine, vous spécifiez le type de grappe à créer. Vous pouvez spécifier :

  • Grappe améliorée : Les grappes améliorées prennent en charge toutes les fonctions disponibles, y compris les fonctions qui ne sont pas prises en charge par les grappes de base (telles que les noeuds virtuels, la gestion des modules complémentaires de grappe, l'identité de charge de travail et les noeuds de travail supplémentaires par grappe). Les grappes améliorées sont accompagnées d'un contrat de niveau de service (CNS) soutenu financièrement.
  • Grappe de base : Les grappes de base prennent en charge toutes les fonctionnalités de base fournies par Kubernetes et Kubernetes Engine, mais aucune des fonctions améliorées fournies par Kubernetes Engine. Les clusters de base sont fournis avec un objectif de niveau de service (SLO), mais pas un contrat de niveau de service (SLA) soutenu financièrement.

Notez les informations suivantes concernant la création des grappes :

  • Lorsque vous utilisez la console pour créer une grappe, si vous ne sélectionnez aucune fonction améliorée lors de la création de la grappe, vous avez la possibilité de créer la grappe en tant que grappe de base. Par défaut, une nouvelle grappe est créée en tant que grappe améliorée, sauf si vous choisissez explicitement de créer une grappe de base.
  • Lorsque vous utilisez l'interface de ligne de commande ou l'API pour créer une grappe, vous pouvez spécifier s'il faut créer une grappe de base ou une grappe améliorée. Si vous ne spécifiez pas explicitement le type de grappe à créer, une nouvelle grappe est créée en tant que grappe de base par défaut.

La création d'une nouvelle grappe en tant que grappe améliorée vous permet d'ajouter facilement des fonctions améliorées ultérieurement, même si vous n'avez sélectionné aucune fonction améliorée au départ. Si vous choisissez de créer une nouvelle grappe en tant que grappe de base, vous pouvez toujours choisir de mettre à niveau la grappe de base vers une grappe améliorée ultérieurement. Toutefois, vous ne pouvez pas rétrograder un cluster amélioré vers un cluster de base.

Voir Comparaison des grappes améliorées et des grappes de base.

Notez que toutes les références aux "grappes" dans la documentation sur Kubernetes Engine font référence à la fois aux grappes améliorées et aux grappes de base, sauf indication contraire explicite.

Plan de contrôle de grappe Kubernetes et API Kubernetes

Le plan de contrôle de la grappe Kubernetes met en oeuvre la fonctionnalité Kubernetes de base. Il s'exécute sur des instances de calcul (appelées "noeuds de plan de contrôle") dans la location du service Kubernetes Engine. Le plan de contrôle de la grappe est entièrement géré par Oracle.

Le plan de contrôle de la grappe exécute un certain nombre de processus, dont les suivants :

  • kube-apiserver pour prendre en charge les opérations de l'API Kubernetes lancées à partir de l'outil de ligne de commande Kubernetes (kubectl) et d'autres outils de ligne de commande, ainsi qu'à partir d'appels REST directs. kube-apiserver comprend les contrôleurs d'admission requis pour les opérations Kubernetes avancées.
  • kube-controller-manager pour gérer les différents composants de Kubernetes (par exemple, le contrôleur de réplication, le contrôleur de points d'extrémité, le contrôleur d'espaces de noms et le contrôleur de comptes de service)
  • kube-scheduler pour contrôler l'emplacement de la grappe où les tâches doivent être exécutées
  • etcd pour stocker les données de configuration de la grappe
  • cloud-controller-manager pour mettre à jour et supprimer des noeuds de travail (à l'aide du contrôleur de noeuds), pour créer des équilibreurs de charge lors de la création des services Kubernetes de type: LoadBalancer (à l'aide du contrôleur de services) et pour configurer des routes de réseau (à l'aide du contrôleur de routage). Le gestionnaire OCI-cloud-controller-manager met également en oeuvre une interface de stockage de conteneurs, un pilote de volume flexible et un provisionneur de volume flexible (pour plus d'informations, voir la documentation sur OCI Cloud Controller Manager (CCM) sur GitHub).

L'API Kubernetes permet aux utilisateurs finaux d'interroger et de manipuler les ressources Kubernetes (telles que les pods, les espaces de noms, les configurations et les événements).

Vous accédez à l'API Kubernetes dans le plan de contrôle de la grappe via un point d'extrémité hébergé dans un sous-réseau de votre VCN. Ce sous-réseau de point d'extrémité de l'API Kubernetes peut être un sous-réseau privé ou public. Si vous spécifiez un sous-réseau public pour le point d'extrémité de l'API Kubernetes, vous pouvez éventuellement l'exposer à Internet en affectant une adresse IP publique au point d'extrémité (ainsi qu'une adresse IP privée). Vous contrôlez l'accès au sous-réseau de point d'extrémité de l'API Kubernetes à l'aide de règles de sécurité définies pour les groupes de sécurité de réseau (recommandé) ou les listes de sécurité.

Note

Dans les versions antérieures, les grappes étaient provisionnées avec des points d'extrémité d'API Kubernetes publics qui n'étaient pas intégrés à votre réseau VCN.

Vous pouvez continuer à créer de telles grappes à l'aide de la CLI ou de l'API, mais pas de la console. Notez que vous pouvez uniquement créer ces grappes en tant que grappes de base, et non en tant que grappes améliorées.

Les noeuds de travail, les groupes de noeuds et le plan de données de la grappe Kubernetes

Les noeuds de travail constituent le plan de données de la grappe. Les applications que vous déployez dans une grappe s'exécutent dans des noeuds de travail.

Chaque noeud de travail exécute un certain nombre de processus, dont les suivants :

  • kubelet pour communiquer avec le plan de contrôle de la grappe
  • kube-proxy pour tenir à jour les règles de réseau

Les processus du plan de contrôle de la grappe surveillent et enregistrent l'état des noeuds de travail et répartissent les opérations demandées entre les noeuds.

Un groupe de noeuds est un sous-ensemble de noeuds de travail d'une grappe qui ont tous la même configuration. Les groupes de noeuds permettent de créer des groupes de machines ayant des configurations différentes dans une grappe. Par exemple, dans une grappe, vous pouvez créer un groupe pour les noeuds correspondant à des machines virtuelles, et un autre groupe pour les noeuds associés à des machines sans système d'exploitation. Une grappe doit comporter au moins un groupe de noeuds, mais il n'est pas nécessaire qu'un groupe de noeuds contienne des noeuds de travail.

Les noeuds de travail d'un groupe de noeuds sont connectés à un sous-réseau de noeuds de travail dans votre VCN.

Lors de la création d'un groupe de noeuds, vous spécifiez que les noeuds de travail du groupe de noeuds sont tous créés en tant que noeuds virtuels ou tous créés en tant que noeuds gérés.

Noeuds virtuels et noeuds gérés

Lors de la création d'un groupe de noeuds avec le moteur Kubernetes, vous spécifiez que les noeuds de travail du groupe de noeuds doivent être créés en tant qu'un ou l'autre des éléments suivants :

  • Noeuds virtuels, entièrement gérés par Oracle. Les noeuds virtuels offrent une expérience Kubernetes sans serveur, ce qui vous permet d'exécuter des applications conteneurisées à grande échelle sans les frais d'exploitation liés à la mise à niveau de l'infrastructure de plan de données et à la gestion de la capacité des grappes. Vous ne pouvez créer des noeuds virtuels que dans des grappes améliorées.
  • Noeuds gérés, s'exécutant sur des instances de calcul (sans système d'exploitation ou sur machine virtuelle) dans votre location, et gérés au moins en partie par vous. Comme vous êtes responsable de la gestion des noeuds gérés, vous avez la possibilité de les configurer pour répondre à vos besoins spécifiques. Vous êtes responsable de la mise à niveau de Kubernetes sur les noeuds gérés et de la gestion de la capacité de la grappe. Vous pouvez créer des noeuds gérés dans des grappes de base et des grappes améliorées.

Voir Comparaison des noeuds virtuels et des noeuds gérés.

Notez que toutes les références aux 'noeuds' et aux 'noeuds de travail' dans la documentation sur Kubernetes Engine font référence à la fois aux noeuds virtuels et aux noeuds gérés, sauf indication contraire explicite.

Noeuds auto-gérés

Un noeud autogéré est un noeud de travail hébergé sur une instance de calcul (ou un groupe d'instances) que vous avez créée vous-même dans le service de calcul, plutôt que sur une instance de calcul que Kubernetes Engine a créée pour vous. Les noeuds autogérés sont souvent appelés " Apportez vos propres noeuds " (BYON). Contrairement aux noeuds gérés et aux noeuds virtuels (qui sont regroupés en groupes de noeuds gérés et en groupes de noeuds virtuels respectivement), les noeuds autogérés ne sont pas regroupés en groupes de noeuds.

Vous utilisez le service de calcul pour créer les instances de calcul sur lesquelles héberger des noeuds autogérés. L'utilisation du service de calcul vous permet de configurer des instances de calcul pour des charges de travail spécialisées, notamment des combinaisons de formes de calcul et d'images qui ne sont pas disponibles pour les noeuds gérés et les noeuds virtuels. Par exemple, vous pouvez vouloir des instances avec des formes conçues pour les charges de travail accélérées du matériel (telles que les formes de GPU) ou des formes conçues pour les charges de travail de calcul de haute performance qui nécessitent des coeurs de processeur à fréquence élevée (telles que les formes de calcul de haute performance et optimisées). Vous pouvez connecter de nombreuses instances de ce type à un réseau à bande passante élevée à très faible latence pour former un réseau en grappe d'Oracle Cloud Infrastructure (voir Utilisation des réseaux en grappe RDMA).

Si vous voulez simplifier l'administration et gérer plusieurs noeuds autogérés en tant que groupe, utilisez le service de calcul pour créer un groupe d'instances de calcul afin d'héberger un ou plusieurs noeuds autogérés.

Lors de la création d'une instance de calcul (ou d'un groupe d'instances) pour héberger un noeud autogéré, vous spécifiez la grappe Kubernetes à laquelle ajouter l'instance. Vous pouvez uniquement ajouter des noeuds autogérés à des grappes améliorées.

Pour plus d'informations, voir Utilisation de noeuds autogérés.

Notez que toutes les références aux "noeuds" et aux "noeuds de travail" dans la documentation sur Kubernetes Engine couvrent les noeuds autogérés, sauf indication contraire explicite.

Pods

Lorsqu'une application qui s'exécute sur un noeud de travail comprend plusieurs conteneurs, Kubernetes regroupe ceux-ci dans une seule unité logique appelée "pod" pour faciliter la gestion et la détection. Les conteneurs du pod partagent le même espace de noms de réseau et le même espace de stockage, et peuvent être gérés comme un objet unique par le plan de contrôle de la grappe. Plusieurs pods offrant les mêmes fonctionnalités peuvent être regroupés dans un même ensemble logique appelé service.

Les grappes Kubernetes utilisent des plugiciels d'interface réseau en conteneurs (CNI) pour mettre en oeuvre la connectivité réseau des pods s'exécutant sur les noeuds de travail. Les plugiciels CNI configurent les interfaces réseau, provisionnent les adresses IP et assurent la connectivité.

Pour plus d'informations sur les pods, voir la documentation sur Kubernetes.

Services

Dans Kubernetes, un service est une abstraction qui définit un jeu logique de pods et une politique permettant d'y accéder. Le jeu des pods ciblés par un service est généralement déterminé par un sélecteur.

Pour certaines parties d'une application (par exemple, les éléments frontaux), vous voudrez peut-être exposer un service sur une adresse IP externe en dehors d'une grappe.

Les éléments ServiceTypes Kubernetes vous permettent de spécifier le type de service que vous souhaitez exposer. Un élément LoadBalancer ServiceType crée un équilibreur de charge Oracle Cloud Infrastructure dans les sous-réseaux d'équilibreurs de charge de votre VCN.

Pour plus d'informations sur les services en général, voir la documentation sur Kubernetes. Pour plus d'informations sur la création de services d'équilibreur de charge avec Kubernetes Engine, voir Définition des services Kubernetes de type LoadBalancer.

Plugiciels d'interface réseau de conteneurs (CNI)

Kubernetes a adopté la spécification CNI (Container Network Interface) pour la gestion des ressources réseau. Le CNI se compose d'une spécification et de bibliothèques pour l'écriture de plugins pour configurer des interfaces réseau dans des conteneurs Linux, ainsi que d'un certain nombre de plugins pris en charge.

Les grappes Kubernetes utilisent des plugiciels d'interface réseau en conteneurs (CNI) pour mettre en oeuvre la connectivité réseau des pods s'exécutant sur les noeuds de travail. Les plugiciels CNI configurent les interfaces réseau, provisionnent les adresses IP et assurent la connectivité.

Pour plus d'informations, voir la documentation CNI sur GitHub.

Fichiers de manifeste (ou spécifications de pod)

Un fichier manifeste Kubernetes comprend des instructions dans un fichier yaml ou json indiquant comment déployer une application vers le ou les noeuds d'une grappe Kubernetes. Ces instructions comprennent des informations sur le déploiement de Kubernetes, le service Kubernetes et les autres objets Kubernetes à créer dans la grappe. Le manifeste est également appelé spécification de pod ou fichier deployment.yaml (même si d'autres noms de fichier sont autorisés). Les paramètres à inclure dans un fichier manifeste Kubernetes sont décrits dans la documentation sur Kubernetes.

Contrôleurs d'admission

Un contrôleur d'admission Kubernetes intercepte les demandes authentifiées et autorisées au serveur d'API Kubernetes avant d'accepter un objet (par exemple, un pod) dans la grappe. Un contrôleur d'admission peut valider un objet, le modifier ou les deux. De nombreuses fonctions avancées de Kubernetes nécessitent l'activation d'un contrôleur d'admission. Pour plus d'informations, voir la documentation relative à Kubernetes.

La version de Kubernetes que vous sélectionnez lors de la création d'une grappe à l'aide de Kubernetes Engine détermine les contrôleurs d'admission pris en charge par cette grappe. Pour identifier les contrôleurs d'admission pris en charge, l'ordre dans lequel ils sont exécutés sur le serveur d'API Kubernetes et les versions de Kubernetes qui les prennent en charge, voir Contrôleurs d'admission pris en charge.

Espaces de noms

Une grappe Kubernetes peut être organisée en espaces de noms pour répartir les ressources de la grappe entre plusieurs utilisateurs. Au départ, une grappe comporte les espaces de noms suivants :

  • par défaut, pour les ressources sans espace de noms
  • kube-system, pour les ressources créées par le système Kubernetes
  • kube-node-lease, pour un objet de location par noeud pour déterminer la disponibilité des noeuds
  • kube-public, généralement utilisé pour les ressources qui doivent être accessibles dans l'ensemble de la grappe

Pour plus d'informations sur les espaces de noms, voir la documentation sur Kubernetes.