Kubernetes - API

L'API Kubernetes sert de base au schéma de configuration déclaratif du système. KubectlL'outil de ligne de commande peut être utilisé pour créer, mettre à jour, supprimer et obtenir un objet API. L'API Kubernetes agit comme un communicateur entre les différents composants de Kubernetes.

Ajouter une API à Kubernetes

L'ajout d'une nouvelle API à Kubernetes ajoutera de nouvelles fonctionnalités à Kubernetes, ce qui augmentera les fonctionnalités de Kubernetes. Cependant, parallèlement, cela augmentera également le coût et la maintenabilité du système. Afin de créer un équilibre entre le coût et la complexité, quelques ensembles sont définis pour cela.

L'API qui est ajoutée devrait être utile à plus de 50% des utilisateurs. Il n'y a pas d'autre moyen d'implémenter la fonctionnalité dans Kubernetes. Les circonstances exceptionnelles sont discutées lors de la réunion de la communauté de Kubernetes, puis l'API est ajoutée.

Modifications de l'API

Afin d'augmenter la capacité de Kubernetes, des modifications sont continuellement apportées au système. C'est fait par l'équipe Kubernetes pour ajouter la fonctionnalité à Kubernetes sans supprimer ni affecter la fonctionnalité existante du système.

Pour illustrer le processus général, voici un exemple (hypothétique) -

  • Un utilisateur POST un objet Pod pour /api/v7beta1/...

  • Le JSON est unmarshalled en un v7beta1.Pod structure

  • Les valeurs par défaut sont appliquées au v7beta1.Pod

  • le v7beta1.Pod est converti en un api.Pod structure

  • le api.Pod est validée et toutes les erreurs sont renvoyées à l'utilisateur

  • le api.Pod est converti en v6.Pod (car la v6 est la dernière version stable)

  • le v6.Pod est rassemblé en JSON et écrit dans etcd

Maintenant que nous avons stocké l'objet Pod, un utilisateur peut OBTENIR cet objet dans n'importe quelle version d'API prise en charge. Par exemple -

  • Un utilisateur obtient le pod de /api/v5/...

  • Le JSON est lu à partir de etcd et unmarshalled dans une v6.Pod structure

  • Les valeurs par défaut sont appliquées au v6.Pod

  • le v6.Pod est converti en une structure api.Pod

  • le api.Pod est converti en v5.Pod structure

  • le v5.Pod est rassemblé en JSON et envoyé à l'utilisateur

L'implication de ce processus est que les modifications d'API doivent être effectuées avec soin et de manière rétrocompatible.

Gestion des versions d'API

Pour faciliter la prise en charge de plusieurs structures, Kubernetes prend en charge plusieurs versions d'API, chacune à un chemin d'API différent, tel que /api/v1 ou /apsi/extensions/v1beta1

Les normes de gestion des versions chez Kubernetes sont définies dans plusieurs normes.

Niveau alpha

  • Cette version contient alpha (par exemple v1alpha1)

  • Cette version peut être boguée; la version activée peut avoir des bogues

  • La prise en charge des bogues peut être abandonnée à tout moment.

  • Recommandé pour être utilisé uniquement dans les tests à court terme car le support peut ne pas être présent tout le temps.

Niveau bêta

  • Le nom de la version contient beta (par exemple v2beta3)

  • Le code est entièrement testé et la version activée est censée être stable.

  • La prise en charge de la fonctionnalité ne sera pas abandonnée; il peut y avoir quelques petits changements.

  • Recommandé uniquement pour les utilisations non critiques en raison du risque de modifications incompatibles dans les versions ultérieures.

Niveau stable

  • Le nom de la version est vXX est un entier.

  • Des versions stables des fonctionnalités apparaîtront dans le logiciel publié pour de nombreuses versions ultérieures.