Concepts relatifs à Kubernetes Engine (OKE) et à Kubernetes

OKE est un service entièrement géré, évolutif et hautement disponible pour le déploiement d'applications en conteneur dans le cloud à l'aide de Kubernetes. Utilisez OKE lorsque l'équipe de développement souhaite créer, déployer et gérer des applications cloud natifs en toute confiance. Vous pouvez choisir d'exécuter des applications sur des noeuds virtuels, des noeuds gérés ou des noeuds autogérés, et OKE les provisionne dans une location OCI existante.

OKE utilise des versions de Kubernetes certifiées conformes par la Fondation Cloud Native Computing Foundation (CNCF). OKE est lui-même conforme à l'ISO (ISO-IEC 27001, 27017, 27018).

Kubernetes est le système open source qui automatise le déploiement, le redimensionnement et la gestion des applications en conteneur dans les clusters d'hôtes. Les hôtes (ou noeuds) d'un cluster fonctionnent ensemble pour exécuter des charges globales en conteneur.

Kubernetes gère et planifie les conteneurs sur ces noeuds. Il organise les conteneurs en unités logiques appelées pods, qui sont déployés et mis à l'échelle en fonction des exigences de l'application. Les pods simplifient la gestion, la mise en réseau et la découverte de services, ce qui facilite la création et l'exploitation d'applications distribuées complexes avec Kubernetes.

Un cluster Kubernetes est un groupe de noeuds (machines qui exécutent des applications). Un noeud peut être une machine physique ou virtuelle. La capacité du noeud (nombre d'UC et quantité de mémoire) est définie lors de sa création. Un cluster comprend les éléments suivants :

• Des noeuds de plan de contrôle (auparavant appelés "noeuds maître"). En général, trois noeuds de plan de contrôle sont présents pour la haute disponibilité.
• Des noeuds de processus actif, organisés en pools de noeuds.

Lorsque vous créez un cluster à l'aide d'OKE, vous pouvez le créer en tant que cluster de base ou en tant que cluster amélioré.

Lorsque vous créez un cluster avec OKE, vous indiquez le type de cluster à créer. Vous pouvez indiquer les éléments suivants :

• Cluster amélioré : les clusters améliorés prennent en charge toutes les fonctionnalités disponibles, y compris les fonctionnalités telles que les noeuds virtuels, la gestion des extensions de cluster, l'identité de charge globale et les noeuds de processus actif supplémentaires par cluster. Les clusters améliorés sont fournis avec un contrat de niveau de service (SLA) soutenu financièrement.
• Cluster de base : les clusters de base prennent en charge toutes les fonctionnalités de base fournies par Kubernetes et OKE. Les clusters de base sont livrés avec un objectif de niveau de service (SLO), mais pas un contrat de niveau de service (SLA) soutenu financièrement.

Pour une comparaison plus détaillée, reportez-vous à Comparaison de clusters améliorés avec des clusters de base.

Tenez compte des éléments suivants lors de la création des clusters :

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

La création d'un nouveau cluster en tant que cluster amélioré vous permet d'ajouter facilement des fonctionnalités améliorées ultérieurement, même si vous n'avez pas initialement sélectionné de fonctionnalités améliorées. Si vous choisissez de créer un cluster en tant que cluster de base, vous pouvez toujours choisir de mettre à niveau le cluster de base vers un cluster amélioré ultérieurement. Toutefois, vous ne pouvez pas rétrograder un cluster amélioré vers un cluster de base.

Notez que toutes les références aux clusters dans la documentation OKE font référence à la fois aux clusters améliorés et aux clusters de base, sauf indication contraire explicite.

Le plan de contrôle de cluster Kubernetes implémente les fonctionnalités de base de Kubernetes. Il est exécuté sur les instances de calcul (appelées "noeuds des plans de contrôle") dans la location de service OKE. Le plan de contrôle de cluster est entièrement géré par Oracle.

Le plan de contrôle de cluster exécute un certain nombre de processus, notamment les suivants :

• kube-apiserver permettant de prendre en charge les opérations d'API Kubernetes demandé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. Le processus kube-apiserver inclut les contrôleurs d'admissions requis pour les opérations Kubernetes avancées
• kube-controller-manager permettant de gérer les différents composants Kubernetes (par exemple, le contrôleur de réplication, le contrôleur d'adresses, le contrôleur d'espace de noms et le contrôleur de comptes de service)
• kube-scheduler permettant de contrôler l'emplacement du cluster dans lequel exécuter les travaux
• etcd permettant de stocker les données de configuration du cluster
• cloud-controller-manager permettant de mettre à jour et de supprimer les noeuds de processus actif (à l'aide du contrôleur de noeud), de créer des équilibreurs de charge lorsque des services Kubernetes de type: LoadBalancer sont créés (à l'aide du contrôleur de service) et de configurer des routages réseau (à l'aide du contrôleur de routage). OCI-cloud-controller-manager implémente également une interface conteneur-stockage-interface, un pilote flexvolume et un provisionneur flexvolume (pour plus d'informations, reportez-vous à la documentation OCI Cloud Controller Manager (CCM) sur GitHub).

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

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

L'accès à l'API Kubernetes est régi par plusieurs couches de sécurité. Vous utilisez les stratégies OCI IAM pour contrôler qui peut utiliser OKE pour gérer les clusters et obtenir l'accès au plan de contrôle de cluster lui-même. Dans le cluster, vous utilisez le contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour contrôler ce que les utilisateurs authentifiés et les comptes de service peuvent faire avec l'API Kubernetes (par exemple, lors de l'utilisation de kubectl).

Les noeuds de processus actif constituent le plan de données du cluster. Les applications que vous déployez dans un cluster sont exécutées sur les noeuds de processus actif.

Chaque noeud de processus actif exécute un certain nombre de processus, notamment :

• kubelet qui permet de communiquer avec le plan de contrôle de cluster,
• kube-proxy qui permet de tenir à jour les règles de configuration réseau.

Les processus de plan de contrôle de cluster surveillent et enregistrent l'état des noeuds de processus actif, et répartissent les opérations demandées entre eux.

Un pool de noeuds est un sous-ensemble de noeuds de processus actif au sein d'un cluster qui ont tous la même configuration. Les pools de noeuds permettent de créer des pools de machines ayant différentes configurations au sein d'un cluster. Par exemple, vous pouvez créer un pool de noeuds en tant que machines virtuelles dans un cluster et un autre pool de noeuds en tant que machines Bare Metal. Un cluster doit comporter au moins un pool de noeuds, mais un pool de noeuds peut ne contenir aucun noeud de processus actif.

Les noeuds de processus actif d'un pool de noeuds sont connectés à un sous-réseau de noeuds de processus actif dans votre réseau cloud virtuel.

Lorsque vous créez un pool de noeuds, vous indiquez que les noeuds de processus actif du pool de noeuds sont tous créés en tant que noeuds virtuels ou tous créés en tant que noeuds gérés.

Lorsque vous créez un pool de noeuds avec OKE, vous indiquez que les noeuds de processus actif du pool de noeuds doivent être créés en tant qu'un ou plusieurs 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 en conteneur à grande échelle sans frais opérationnels liés à la mise à niveau de l'infrastructure de plan de données et à la gestion de la capacité des clusters. Vous pouvez uniquement créer des noeuds virtuels dans des clusters améliorés.
• Noeuds gérés, exécutés sur des instances de calcul (bare metal ou machine virtuelle) dans votre location, et au moins partiellement gérés par vous. En tant que 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é du cluster. Vous pouvez créer des noeuds gérés dans des clusters de base et des clusters améliorés.

Reportez-vous à Comparaison entre les noeuds virtuels et les noeuds gérés.

Notez que toutes les références aux noeuds et aux noeuds de travail dans la documentation OKE font référence aux noeuds virtuels et aux noeuds gérés, sauf indication contraire explicite.

Pour plus d'informations, reportez-vous à Utilisation des noeuds autogérés.

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

Lorsqu'une application exécutée sur un noeud de processus actif comprend plusieurs conteneurs, Kubernetes regroupe les conteneurs en une seule unité logique appelée pod pour faciliter leur gestion et leur repérage. Les conteneurs du pod partagent le même espace de noms réseau et le même espace de stockage. Ils peuvent être gérés comme un seul objet par le plan de contrôle de cluster. Plusieurs pods fournissant la même fonctionnalité peuvent être regroupés dans un ensemble logique unique appelé service.

Les clusters Kubernetes utilisent des modules d'extension d'interface réseau de conteneur (CNI) pour implémenter la connectivité réseau pour les pods exécutés sur des noeuds de processus actif. Les modules d'extension CNI configurent les interfaces réseau, provisionnent les adresses IP et maintiennent la connectivité.

Pour plus d'informations sur les pods, reportez-vous à la documentation Kubernetes.

Dans Kubernetes, un service est une abstraction qui définit un ensemble logique de pods et une stratégie permettant d'y accéder. L'ensemble de pods ciblé 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 pouvez exposer un service sur une adresse IP externe en dehors d'un cluster.

Les ServiceTypes de Kubernetes vous permettent d'indiquer le type de service à exposer. Un élément LoadBalancer ServiceType crée un équilibreur de charge OCI sur les sous-réseaux d'équilibreur de charge dans votre VCN.

Pour plus d'informations sur les services en général, reportez-vous à la documentation Kubernetes. Pour plus d'informations sur la création de services d'équilibreur de charge avec OKE, reportez-vous à Définition de services Kubernetes de type LoadBalancer.

Kubernetes a adopté la spécification de l'interface réseau de conteneurs (CNI) pour la gestion des ressources réseau. Le CNI se compose d'une spécification et de bibliothèques pour écrire des plug-ins afin de configurer des interfaces réseau dans des conteneurs Linux, ainsi que d'un certain nombre de plug-ins pris en charge.

Les clusters Kubernetes utilisent des modules d'extension d'interface réseau de conteneur (CNI) pour implémenter la connectivité réseau pour les pods exécutés sur des noeuds de processus actif. Les modules d'extension CNI configurent les interfaces réseau, provisionnent les adresses IP et maintiennent la connectivité.

Pour plus d'informations, reportez-vous à la documentation CNI sur GitHub.

Un fichier manifeste Kubernetes comprend des instructions dans un fichier YAML ou JSON qui indiquent comment déployer une application vers les noeuds d'un cluster Kubernetes. Les instructions comprennent des informations sur le déploiement Kubernetes, sur le service Kubernetes et sur d'autres objets Kubernetes pouvant être créés sur le cluster. Le fichier manifeste est également appelé couramment spécifications du pod ou fichier deployment.yaml (bien qu'autres noms de fichier soient autorisés). Les paramètres à inclure dans un fichier manifeste Kubernetes sont décrits dans la documentation Kubernetes.

Un contrôleur d'admission Kubernetes intercepte les demandes authentifiées et autorisées adressées au serveur d'API Kubernetes avant d'admettre un objet (un pod, par exemple) dans le cluster. Un contrôleur d'admission peut valider un objet, le modifier ou les deux. De nombreuses fonctionnalités avancées dans Kubernetes nécessitent l'activation d'un contrôleur d'admission. Pour plus d'informations, reportez-vous à la documentation Kubernetes.

La version de Kubernetes que vous sélectionnez lorsque vous créez un cluster à l'aide de OKE détermine les contrôleurs d'admission pris en charge par ce cluster. Pour connaître les contrôleurs d'admission pris en charge, l'ordre dans lequel ils s'exécutent sur le serveur d'API Kubernetes et les versions de Kubernetes dans lesquelles ils sont pris en charge, reportez-vous à Contrôleurs d'admission pris en charge.

Un cluster Kubernetes peut être organisé en espaces de noms afin de répartir les ressources du cluster entre plusieurs utilisateurs. A l'origine, un cluster possède les espaces de noms suivants :

• default, pour les ressources qui n'ont pas d'autre 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 afin de déterminer la disponibilité du noeud
• kube-public, généralement utilisé pour les ressources qui doivent être accessibles dans le cluster

Pour plus d'informations sur les espaces de noms, reportez-vous à la documentation Kubernetes.