Concepts relatifs à Kubernetes Engine (OKE) et à 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 de Kubernetes Engine, 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 Kubernetes Engine, vous indiquez le type de cluster à créer. Vous pouvez spécifier :

• Cluster amélioré : les clusters améliorés prennent en charge toutes les fonctionnalités disponibles, y compris celles qui ne sont pas prises en charge par les clusters de base (notamment les noeuds virtuels, la gestion des extensions de cluster, l'identité de la charge globale et des 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 Kubernetes Engine, mais aucune des fonctionnalités améliorées fournies par Kubernetes Engine. Les clusters de base ont un objectif de niveau de service, mais pas un contrat de niveau de service soutenu financièrement.

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.

Reportez-vous à la section Comparing Enhanced Clusters with Basic Clusters.

Notez que toutes les références à "clusters" dans la documentation Kubernetes Engine 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 de plan de contrôle") dans la location du service Kubernetes Engine. 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é.

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 à l'aide de Kubernetes Engine, 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 à la section Comparing Virtual Nodes with Managed Nodes.

Toutes les références aux noeuds et aux noeuds de processus actif dans la documentation Kubernetes Engine 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 Kubernetes Engine 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 LoadBalancer ServiceType crée un équilibreur de charge Oracle Cloud Infrastructure sur des 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 Kubernetes Engine, 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 Kubernetes Engine 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.