Configuration de l'API Satellite

Utilisez l'API IBM Cloud Satellite pour automatiser le provisionnement et la gestion de vos emplacements, hôtes et clusters dans des environnements hybrides et multicloud.

IBM Cloud Satellite partage la même interface de programme d'application (API) que IBM Cloud Kubernetes Service et Red Hat OpenShift on IBM Cloud, de sorte que vous pouvez utiliser les mêmes méthodes pour créer et gérer de manière cohérente vos ressources Satellite.

A propos de l'API

L'API Satellite automatise la mise à disposition et la gestion des ressources d'infrastructure IBM Cloud pour vos clusters de sorte que vos applications disposent des ressources de calcul, de mise en réseau et de stockage dont elles ont besoin pour servir vos utilisateurs.

L'API prend en charge les différents fournisseurs d'infrastructure disponibles pour vous permettre de créer des clusters et des ressources. L'API v2 est conçue pour éviter, dans la mesure du possible, de rompre une fonctionnalité existante. Toutefois, prenez soin de passer en revue les différences entre l'API v1 et l'API v2 qui sont présentées ci-après.

Préfixe de noeud final d'API: API v1 : https://containers.cloud.ibm.com/global/v1; API v2 : https://containers.cloud.ibm.com/global/v2
Documents de référence d'API: API v1 : https://cloud.ibm.com/apidocs/kubernetes/containers-v1-v2; API v2: https://cloud.ibm.com/apidocs/kubernetes/containers-v1-v2
Style d'architecture d'API: API v1 : Representational State Transfer (REST) qui se concentre sur les ressources avec lesquelles vous interagissez via des méthodes HTTP telles que GET, POST, PUT, PATCH et DELETE.; API v2 : appels de procédure distante (RPC) qui mettent l'accent sur les actions uniquement via les méthodes HTTP GET et POST.
Réponses GET: API v1 : la méthode GET pour une collection de ressources (telle que GET v1/clusters) renvoie les mêmes détails pour chaque ressource de la liste en tant que méthode GET pour une ressource individuelle (telle que GET v1/clusters/{idOrName}).; API v2 : pour renvoyer des réponses plus rapidement, la méthode v2 GET pour une collection de ressources (telle que GET v2/clusters) renvoie uniquement un sous-ensemble d'informations détaillées dans une méthode GET pour une ressource individuelle (telle que GET v2/clusters/{idOrName}). Certaines réponses de liste incluent une propriété de fournisseurs afin de déterminer si l'élément renvoyé s'applique à l'infrastructure classique ou à l'infrastructure VPC. Par exemple, la liste GET zones renvoie certains résultats, tels que mon01, qui sont disponibles uniquement dans le fournisseur d'infrastructure classique,, tandis que d'autres résultats, tels que us-south-01, sont disponibles uniquement dans le fournisseur d'infrastructure VPC.
Réponses de cluster, de noeud worker et de pool de noeuds worker: API v1 : les réponses incluent uniquement les informations spécifiques au fournisseur d'infrastructure classique, telles que les VLAN dans le cluster GET et les réponses de worker.; API v2 : les informations renvoyées varient en fonction du fournisseur d'infrastructure. Pour ces réponses propres aux fournisseurs, vous pouvez spécifier le fournisseur dans votre demande. Par exemple, les clusters VPC ne renvoient pas les informations VLAN, car ils n'ont pas de VLAN. En revanche, ils renvoient des informations réseau CIDR et de sous-réseau.