Déployer une application sur Kubernetes

DevOps Insights arrivera en fin de vie et sera supprimé le 31 août 2026. Continuous Delivery sera supprimé dans les régions suivantes le 12 février 2027 : au-syd, ca-mon, ca-tor, us-east. Code Risk Analyzer sera également retiré du marché dans toutes les régions à cette date. Si ces fonctionnalités ne sont pas activement utilisées dans une région donnée, elles pourraient y être supprimées plus tôt et ne plus accepter de nouvelles instances. En savoir plus

Dans ce tutoriel, vous apprenez à créer une chaîne d'outils ouverte en utilisant différentes stratégies de déploiement. Vous apprenez également comment les chaînes d'outils sont implémentée dans le service IBM Cloud® Continuous Delivery et comment développer et déployer une application Web simple (application) à l'aide de chaînes d'outils.

Ce tutoriel est basé sur un navigateur. Vous pouvez également créer une chaîne d'outils ouverte similaire dans Terraform, comme indiqué dans l'exemple IBM Cloud Terraform Provider ibm-cd-toolchain-simple-helm.

Ce tutoriel utilise des stratégies de déploiement qui ont Kubernetes comme cible de déploiement. La chaîne d'outils utilisée dans ce tutoriel implémente des pratiques DevOps standard telles que l'analyse de code, les tests d'acceptation, les pensions Git, l'intégration continue et les fonctions de distribution continue. Après avoir créé un cluster Kubernetes et une chaîne d'outils, vous modifiez le code de votre application et insérez la modification dans le référentiel Git Repos and Issue Tracking. Lorsque vous appuyez les modifications sur votre repo, le pipeline de distribution basé sur Tekton construit et déploie automatiquement le code.

Tekton est un framework open source, indépendant des éditeurs et natif d' Kubernetes, qui vous permet de développer, de tester et de déployer des applications. Tekton fournit un ensemble de composants partagés permettant de mettre en place des systèmes d'intégration continue et de livraison continue. En tant que projet open source, Tekton est géré par la Fondation Continuous Delivery. L'objectif est de moderniser la livraison continue en fournissant des spécifications industrielles pour les pipelines, les flux de travail et d'autres éléments de base. Avec Tekton, vous pouvez créer, tester et déployer des systèmes sur site ou des fournisseurs de services cloud en faisant abstraction des détails de mise en œuvre sous-jacents. Les pipelines Tekton sont générés dans Continuous Delivery.

Le modèle utilisé dans ce tutoriel fonctionne avec le plan Standard ou Lite pour Kubernetes. Avec le plan standard, vous pouvez accéder à votre application à l'aide du nom du serveur de noms de domaine. Dans le plan Lite, vous pouvez accéder à votre application à l'aide le port de nœud.

Vous pouvez utiliser une stratégie de déploiement pour mettre à jour une application dans un environnement de production, de manière contrôlée. L'utilisation d'une stratégie de déploiement peut apporter les avantages suivants :

  • Évitez les temps d'arrêt des applications.
  • Activer le test de production de nouvelles fonctions sans affecter les clients.
  • Limiter l'impact des problèmes de production à un sous-ensemble d'utilisateurs.
  • Activez l'annulation rapide de la version précédente si des problèmes sont trouvés.

De nombreuses stratégies de déploiement possibles sont disponibles. En général, ils dépendent de l'exécution de plusieurs instances de l'application et de la gestion de la mise à jour des différentes instances. Vous pouvez préconfigurer les stratégies de déploiement communes suivantes dans Continuous Delivery :

Basic
Déploie la nouvelle version en arrêtant et en mettant à jour toutes les instances en cours d'exécution simultanément, ce qui entraîne un temps d'arrêt. Pour effectuer une restauration, vous devez déployer à nouveau la version précédente, ce qui entraîne un temps d'indisponibilité supplémentaire. Bien que cette stratégie soit simple, rapide et peu exigeante en ressources d'exécution, elle est la plus risquée et entraîne des temps d'arrêt. La stratégie de déploiement de base n'est pas recommandée pour les applications critiques qui doivent être hautement disponibles.
Mise à jour en continu
Comme la stratégie de base, cette stratégie de déploiement est simple, rapide et nécessite peu de ressources d'exécution. Cependant, étant donné que chaque instance en cours d'exécution est mise hors service et mise à jour individuellement, évitant ainsi les temps d'arrêt, le retour en arrière vous oblige à déployer à nouveau la version précédente. Cette approche, qui prend du temps, peut poser des problèmes si la version actuelle de l'application en production est défectueuse.
déploiement Blue-Green
Crée deux environnements de production distincts et permanents (bleu et vert), et un seul de ces environnements reçoit du trafic à la fois. La version actuelle est toujours déployée dans l'environnement inactif et le trafic y est transféré une fois le déploiement terminé, sans temps d'arrêt. Comme vous ne devez basculer que le trafic vers l'environnement inchangé, le rollback n'entraîne pas de temps d'arrêt. Comme cette stratégie nécessite deux environnements de production complets, les besoins en ressources sont plus élevés. Cependant, cette stratégie permet de puissants flux de développeurs, comme la possibilité de tester de nouvelles versions d'applications dans l'environnement de production avant d'autoriser le trafic des clients. Le déploiement Blue-Green prend également en charge l'annulation rapide.
Libération Canary
Déploie une nouvelle édition en parallèle avec l'environnement de production d'origine (similaire à Blue-Green), sans interruption. La quantité de trafic envoyée aux instances mises à jour et originales est gérée de manière à ce que la nouvelle version soit disponible pour un sous-ensemble contrôlé d'utilisateurs pendant le déploiement. Au fil du temps, le trafic envoyé vers la nouvelle version est augmenté jusqu'à ce que tout le trafic y soit envoyé, et vous pouvez alors arrêter l'ancien environnement de production. Pour une annulation rapide lorsque le déploiement est en cours, vous pouvez acheminer tout le trafic vers l'environnement de production d'origine. Étant donné que cette stratégie ne nécessite deux environnements de production complets que pendant le déploiement, l'utilisation globale des ressources est inférieure à celle du déploiement « bleu-vert ». La stratégie de déploiement de la version Canary est la plus lente à passer d'une version précédente à une version actuelle du logiciel en cours de déploiement. Les déploiements Canary permettent aux organisations de tester deux versions différentes du logiciel côte à côte en production.

Avant de commencer

Avant de commencer ce tutoriel, vérifiez que vous disposez des ressources suivantes :

  • Un compteIBM Cloud. Selon votre type de compte IBM Cloud, l'accès à certaines ressources peut être limité. Selon les limites de votre plan de compte, certaines fonctions requises par certaines stratégies de déploiement risquent de ne pas être disponibles. Pour plus d'informations sur les comptes « IBM Cloud », consultez les articles « Configurer votre compte IBM Cloud » et « Passer à un compte supérieur ».

  • Une clé Cluster Kubernetes et une clé d'interface de programmation. Vous pouvez créer ces ressources à l'aide de l'interface utilisateur ou de l'interface de ligne de commande. La mise à disposition de ce cluster peut prendre du temps. Au fur et à mesure que le cluster est créé, il passe par les étapes de déploiement, en attente et d'opérationnalité. Pour plus d'informations sur les clusters Kubernetes, voir Clusters de Kubernetes. Bien que vous puissiez utiliser les déploiements Rolling et Blue-Green pour les plans Lite, vous devez créer un cluster Kubernetes pour les plans standard.

  • Une instance du service Continuous Delivery.

  • Facultatif. Secrets stockés dans un coffre de gestion de secrets et gérés centralement à partir d'un seul emplacement. Pour plus d'informations sur le choix des différentes offres de gestion des secrets et de protection des données, voir Gestion des secrets IBM Cloud. Si vous ne disposez pas déjà d'une instance de fournisseur de coffre de gestion des secrets de votre choix, créez-vous un.

  • Facultatif. Espace de nom créé à l'aide de la ligne de commande du registre de conteneur. Pour créer un espace de noms, tapez la commande suivante :

    ibmcloud cr namespace-add <my namespace>

    Vous pouvez également créer un espace de nom sur la page Registre de conteneur. Pour plus d'informations sur la création d'un espace de nom dans cet emplacement, voir le service Registre de conteneur IBM Cloud.

Contenu connexe

Création de la chaîne d'outils

Dans cette étape, vous allez créer une chaîne d'outils pour développer une application Kubernetes. Le cluster Kubernetes cible est configuré lors de la configuration de la chaîne d'outils à l'aide de votre clé d'interface de programmation IBM Cloud et de votre nom de cluster Kubernetes. Vous pouvez modifier ces paramètres ultérieurement en mettant à jour la configuration Delivery Pipeline. Tout code fusionné dans la branche du référentiel cible Git est automatiquement généré, validé et déployé dans le cluster Kubernetes.

Pour créer une chaîne d'outils pour développer une application Kubernetes, cliquez sur

Créer une chaîne d'outils

Sinon, depuis la IBM Cloud console, cliquez sur l'icône Menu (icône hamburger ) > Automatisation de la plateforme > Chaînes d'outils. Sur la page Chaînes d'outils, cliquez sur Créer une chaîne d'outils. Sur la page « Créer une chaîne d'outils », cliquez sur « Développer une application Kubernetes ».

Configuration du nom et de la région de la chaîne d'outils

Passez en revue les informations par défaut des paramètres de chaîne d'outils. Le nom de la chaîne d'outils l'identifie dans IBM Cloud. Veillez à ce qu'il n'existe qu'une seule chaîne d'outils de ce nom dans une même région et un même groupe de ressources IBM Cloud.

La région de la chaîne d'outils peut être différente de celle du cluster et du registre.

Kubernetes Nom et région de la chaîne d'outils sécurisée de l'application
Kubernetes Nom et région de la chaîne d'outils sécurisée de l'application

Sélectionnez la stratégie de déploiement

La chaîne d'outils crée un pipeline de déploiement continu pour déployer l'image d'application Docker sur le IBM Cloud® Kubernetes Service. Sélectionnez la stratégie de déploiement à utiliser. Selon la stratégie de déploiement que vous choisissez (Rolling, Blue-Green ou Canary), vous devez fournir plus de détails.

  1. Cliquez sur la stratégie de déploiement que vous souhaitez utiliser pour votre chaîne d'outils.

    Kubernetes
    Stratégies de déploiement sécurisé des applicationsStratégies de déploiement

  2. Cliquez sur Continu.

Configuration du code source de l'application

Dans l'étape de l'application, les options recommandées pour le code source de l'application sont affichées par défaut. Pour afficher toutes les options disponibles pour l'intégration Git sous-jacente, cliquez sur Options avancées. Par défaut, la chaîne d'outils utilise l'exemple par défaut qui clone l'application exemple sous la forme d'un référentiel Git Repos and Issue Tracking hébergé par IBM.

Kubernetes référentiel d'applications sécurisé
Kubernetes référentiel d'applications sécurisé

Vous pouvez changer le nom de l'application repo. La région du repo reste la même que la région de la chaîne d'outils.

Le modèle de chaîne d'outils fournit une application Exemple NodeJS . Si vous souhaitez lier un référentiel d'application existant pour la chaîne d'outils, sélectionnez Apportez votre propre application et indiquez l'URL du référentiel. La chaîne d'outils prend en charge la liaison uniquement aux pensions Git Repos and Issue Tracking existantes.

Par défaut, le modèle de référentiel d'application est cloné dans votre organisation Git Repos and Issue Tracking. Pour modifier l'organisation, activez Options avancées et indiquez le propriétaire du référentiel.

Configuration du référentiel d'inventaire

Le référentiel d'inventaire enregistre les détails des artefacts générés par les chaînes d'outils d'intégration continue. Vous pouvez soit créer un nouveau dépôt d'inventaire qui soit un clone du modèle de dépôt d'inventaire, soit utiliser un dépôt d'inventaire existant que vous partagez entre plusieurs chaînes d'outils.

Kubernetes référentiel sécurisé d'inventaire des
Kubernetes applications référentiel sécurisé d'inventaire des applications

Par défaut, le modèle repo Inventory est cloné sur votre organisation Git Repos and Issue Tracking. Pour modifier l'organisation, sélectionnez Options avancées et indiquez le propriétaire du référentiel.

Secrets de stockage de sécurité

Plusieurs outils de cette chaîne d'outils nécessitent des secrets, tels qu'une clé d'API IBM Cloud. Vous devez stocker en toute sécurité tous les secrets dans un coffre et les faire référence comme requis par la chaîne d'outils.

A l'aide de IBM Cloud, vous pouvez choisir parmi diverses offres de gestion de secrets et de protection des données qui vous aident à protéger vos données sensibles et à centraliser votre secret. Dans l'étape Secrets, vous pouvez spécifier les intégrations de coffre à ajouter ou à supprimer de votre chaîne d'outils. Pour plus d'informations sur l'ajout et la suppression d'intégrations de coffre, y compris les prérequis et l'utilisation de conseils, voir Gestion des secrets IBM Cloud.

En utilisant des conseils dans un modèle, une chaîne d'outils est automatiquement renseignée avec des secrets préconfigurés ; vous n'avez pas besoin de sélectionner manuellement les secrets des intégrations de coffre qui sont associés à la chaîne d'outils.

Ce tutoriel utilise IBM Secrets Manager comme coffre des secrets.

Kubernetes Options de sécurité des secrets d'application Options
Kubernetes de sécurité des secrets d'application

IBM Secrets Manager stocke et applique des informations confidentielles telles que les clés d'API, la signature d'image ou les données d'identification HashiCorp qui font partie de votre chaîne d'outils.

Kubernetes Options de sécurité des
Kubernetes secrets d'application Options de sécurité des secrets d'application

Pour plus d'informations sur la gestion de vos secrets dans IBM Key Protect ou HashiCorp,, voir Secrets.

Configuration de la cible de déploiement

Configurez le cluster Kubernetes cible pour le déploiement de l'application. Une fois que l'application a passé la phase de génération, de test et d'analyse, le pipeline déploie l'image d'application construite sur le cluster de Kubernetes cible. Ce déploiement est maintenant prêt pour les tests d'acceptation ou d'intégration.

Si la clé de l'interface de programmation dispose de l'accès requis, les zones suivantes se chargent automatiquement à l'aide de la clé d'interface de programmation créée, extraite d'un coffre ou spécifiée manuellement. Si la clé de l'interface de programmation est valide, les valeurs de la région du registre de conteneur et de l'espace de nom de la région, du nom, de l'espace de nom et du groupe de ressources sont automatiquement renseignée. Vous pouvez mettre à jour l'une de ces zones pour qu'elle corresponde à votre configuration.

  • Nom de l'application: Le nom de l'application. Le nom d'application par défaut est hello-containers.

  • Clé d'interface de programmation IBM Cloud : La clé d'interface de programmation utilisée pour interagir avec l'outil de l'interface de ligne de commande ibmcloud dans plusieurs tâches. Utilisez l'une des méthodes suivantes pour spécifier la clé d'interface de programmation que vous souhaitez utiliser :

    • Cliquez sur l'icône de clé pour importer une clé d'interface de programmation existante à partir d'une coffre de secret de votre choix.
    • Copiez et collez une clé d'interface de programmation existante.
    • Cliquez sur Nouveau pour créer une clé d'interface de programmation.
    • Générez un nouveau api-key si vous n'avez pas de clé d'interface de programmation existante.

    Vous pouvez immédiatement sauvegarder la clé d'interface de programmation générée sur un coffre existant de votre choix.

L'application est déployée à l'aide de la stratégie de déploiement que vous avez indiquée. L'exemple suivant montre les détails d'un déploiement de type Rolling ou Blue-Green.

Kubernetes Détails de la cible de déploiement sécurisé de l'application pour le déploiement continu ou bleu-vert Détails de la cible de
Kubernetes déploiement continu sécurisé de l'application

Si vous avez sélectionné la stratégie de déploiement « Canary », vous devez préciser des informations supplémentaires concernant la cible de déploiement.

  • Taille de l'étape Canary : Définit la quantité de trafic à rediriger vers la nouvelle version du déploiement canary.

  • Intervalle de l'étape Canary : Définit l'intervalle de temps entre chaque test canari pour passer à la nouvelle version du déploiement Canary.

Kubernetes Détails de la cible de déploiement sécurisé de l'application Canary Détails de la
Kubernetes cible de déploiement sécurisé de l'application Canary

Ajouter des intégrations d'outil facultatives

Vous pouvez ajouter l'intégration d'outils IBM Cloud® DevOps Insights à votre chaîne d'outils sans configuration supplémentaire.

DevOps Insights est inclus dans la chaîne d'outils créée. Vous n'avez pas besoin de fournir des étapes de configuration pour DevOps Insights. Le pipeline d'intégration continue utilise automatiquement l'instance DevOps Insights incluse dans la chaîne d'outils. DevOps Insights regroupe les données de code, de test, de génération et de déploiement pour fournir une visibilité à la vitesse et à la qualité de toutes vos équipes et éditions.

Cliquez sur Continu.

Compléter la configuration de la chaîne d'outils

Dans la page Récapitulatif, cliquez sur Créer. Plusieurs étapes s'exécutent automatiquement pour configurer votre chaîne d'outils.

Vous pouvez configurer les intégrations de chaînes d'outils individuelles une fois que le pipeline a été créé.

Kubernetes Résumé de la chaîne d'outils pour applications sécurisées
Kubernetes Résumé de la chaîne d'outils pour applications sécurisées

Exploration de votre nouvelle chaîne d'outils

Une fois que la chaîne d'outils a été créée, les différentes intégrations d'outil qui la constituent s'affichent dans un diagramme.

Exploration des pipelines

Vous pouvez explorer les pipelines pour comprendre le flux de la chaîne d'outils et les différentes opérations qui s'exécutent dans chaque pipeline. La chaîne d'outils que vous venez de créer contient trois pipelines :

  • Pipeline de demande d'extraction : S'exécute lorsqu'un développeur fusionne les modifications de sa branche de développement à la branche principale, ou à toute autre branche du référentiel. Le pipeline de demande d'extraction exécute les opérations de test d'unité et d'analyse statique sur le code source de l'application.
  • Pipeline d'intégration continue : S'exécute lorsque vous fusionnez une modification dans la branche principale du référentiel de code source d'application. Le pipeline d'intégration continue exécute le test d'unité, la couverture de code et les analyses statiques sur le code source de l'application, la vérification CIS et la vérification de nomenclature. Le pipeline de distribution continue génère également les artefacts de génération binaires et les télécharge sur IBM Cloud® Kubernetes Service, tel qu'il est configuré dans la chaîne d'outils. Et le pipeline d'intégration continue génère les métadonnées des artefacts de construction et les stocke dans le référentiel Inventory.
  • Pipeline de déploiement continu : Déploie les artefacts de génération dans l'environnement de déploiement. Le pipeline vérifie le déploiement réussi de l'application en exécutant le contrôle de santé. Vous devez déclencher manuellement ce pipeline une fois le pipeline d'intégration en continu terminé. En fonction de la stratégie de déploiement que vous avez sélectionnée, d'autres déclencheurs sont ajoutés au pipeline de distribution continue.

Exécution de la demande d'extraction et des pipelines d'intégration continue

Pour démarrer le pipeline de demande d'extraction, créez une demande de fusion dans votre application repo :

  1. Sur la page Présentation de la chaîne d'outils, sur la carte Référentiels, cliquez sur l'application du référentiel compliance-app-<timestamp>.
  2. A partir du référentiel maître, créez une branche.
  3. Mettez à jour un code dans l'exemple d'application de noeud ou le fichier readme et sauvegardez ces modifications.
  4. Soumettez la demande de fusion.
  5. Sur la page Présentation de la chaîne d'outils, sur la carte Référentiels, cliquez sur le référentielpr-pipeline pour lancer le pipeline de demande d'extraction. La demande de fusion correspondante dans votre application repo reste à l'état en attente jusqu'à ce que toutes les étapes du pipeline de demande d'extraction se terminent correctement.
  6. Une fois que l'exécution du pipeline de demande d'extraction aboutit, vous pouvez la sélectionner pour explorer les étapes terminées.

Succès du pipeline de demandes de
du pipeline de demandes de

Pour démarrer le pipeline d'intégration continue, fusionnez la demande de fusion d'intégration continue dans votre application repo :

  1. Accédez à la demande de fusion.
  2. Fusionner la demande afin que vos modifications soient copiées sur la branche principale de votre application repo. Le pipeline d'intégration continue est automatiquement déclenché.
  3. Sur la page Présentation de la chaîne d'outils d'intégration continue, sur la carte Référentiels, cliquez sur le référentiel ci-pipeline pour démarrer le pipeline d'intégration continue.
  4. Une fois l'exécution du pipeline d'intégration continue réussie, vous pouvez cliquer sur l'exécution du pipeline pour explorer les étapes terminées.

Succès
du pipeline d'intégration continueSuccès du pipeline d'intégration continue

Pratique du décalage à gauche

Dans le domaine du développement d'applications sécurisées, le « shift-left » est une pratique qui permet de prévenir et de détecter des problèmes tels que les défauts et les failles de sécurité, et d'effectuer des contrôles de conformité dès les premières étapes du processus de développement logiciel. Cette pratique consistant à déplacer les contrôles de qualité plus tôt dans le cycle de développement comprend les pratiques suivantes :

  • Exécuter des vérifications qui peuvent être exécutées sur le code ou sur le référentiel lui-même et n'ont pas besoin de l'image générée, le plus tôt possible. Ces vérifications empêchent la fusion du code non conforme dans la branche principale du référentiel. Étant donné qu’aucune preuve n’est recueillie au cours du pipeline des pull requests, l’objectif est d’avancer les contrôles de conformité à un stade plus précoce du processus de développement.
  • Toutes les vérifications sont exécutées dans chaque exécution de pipeline. Si une vérification précédente échoue, le pipeline passe à la vérification suivante. Pour évaluer si votre exécution a échoué, vérifiez l'étape finale de votre pipeline qui dispose d'un évaluateur de pipeline.

Les résultats des tests unitaires et des analyses de vulnérabilité sont publiés dans l'instance DevOps Insights de la chaîne d'outils. Pour consulter ces résultats, cliquez sur la mosaïque DevOps Insights dans la chaîne d'outils et accédez à la page du tableau de bord de la qualité.

Résultats de l'intégration continue de Toolchain*Résultats " caption-side="bottom"} l'intégration continue de{: caption="

Pour évaluer si vous avez des défaillances dans l'exécution de votre pipeline, vérifiez l'étape finale de votre pipeline, qui dispose d'un évaluateur de pipeline.

Explorez le pipeline de distribution continue

La demande d'extraction et les pipelines d'intégration continue sont communs à toutes les stratégies de déploiement. Les modifications de conception et d'implémentation du pipeline de distribution continue sont basées sur la stratégie de déploiement que vous avez précédemment sélectionnée dans ce tutoriel.

Ce tutoriel montre comment fonctionne la stratégie de déploiement en continu à l'aide de l'application exemple.

Exploration du déploiement en continu

La stratégie de déploiement en continu utilisée dans ce tutoriel montre comment vous pouvez utiliser une stratégie de déploiement avec le service Continuous Delivery pour exécuter votre charge de travail de production sur Kubernetes. Le pipeline de livraison continue fournit deux déclencheurs pour le déploiement continu. Vous pouvez démarrer un pipeline de distribution continue de l'une des manières suivantes :

  • Déclenche manuellement le pipeline de distribution continue.
  • Déclencheur automatique du pipeline de distribution continue après chaque action Merge dans le référentiel Inventory. Après la fusion, vous devez déclencher manuellement le pipeline de livraison continue.

Un déclencheur Git Repos and Issue Tracking est configuré pour déclencher un pipeline de distribution automatique automatique, mais il est désactivé par défaut. Vous pouvez activer ce déclencheur après la première fois que vous promouvez un changement.

Déclencheurs du pipeline de livraison continue pour le déploiement
du pipeline de livraison continue pour le déploiement

Étant donné que la stratégie de déploiement continu met à jour de manière incrémentielle toutes les instances de production avec la nouvelle version du logiciel, elle n'entraîne pas de temps d'arrêt. Toutefois, la stratégie de déploiement d'annulation nécessite de redéployer la version précédente, ce qui peut prendre un certain temps.

Une fois l'exécution du pipeline de distribution continue réussie, vous pouvez localiser l'URL de l'application dans l'étape perform deployment du pipeline de distribution continue.

Application URL pour un déploiement continu
Application URL en cours de livraison continue

Etapes suivantes

Si vous souhaitez supprimer l'application exemple qui s'exécute sur Kubernetes, vous devez nettoyer le cluster Kubernetes :

  1. Accédez à la page d'accueil Kubernetes Cluster.

  2. Sélectionnez le cluster sur lequel l'application exemple est en cours d'exécution.

  3. Cliquez sur Tableau de bord Kubernetes.

  4. À partir de l'emplacement où l'application exemple est en cours d'exécution, sélectionnez Espace de nom.

    Kubernetes espace de noms espace
    Kubernetes de noms

  5. Supprimez les déploiements, services et ingresses associés qui sont répertoriés dans l'espace de nom sélectionné.

Besoin d'aide ?

IBM Cloud IBM l'assistant IA de , qui est alimenté par l' watsonx de , est conçu pour vous aider à découvrir comment travailler dans l' IBM Cloud, et à créer des solutions avec le catalogue de produits et services disponibles. Voir Obtenir de l'aide de l'assistant IA.

Pour plus d'options de support, voir Obtention de l'aide et du support pour Continuous Delivery.