Quel type d'application puis-je exécuter dans Red Hat OpenShift on IBM Cloud ?

Applications sans état

Les applications sans état sont privilégiées pour des environnements natifs en cloud, tels que Kubernetes. Elles sont faciles à migrer et à mettre à l'échelle car elles déclarent des dépendances, stockent des configurations indépendamment du code et traitent les services de sauvegarde, tels que les bases de données, comme des ressources connectées et non comme des ressources couplées à l'application. Les pods d'application n'ont pas besoin de stockage permanent des données ou d'une adresse IP de réseau stable, et en tant que telles, les pods peuvent être arrêtés, rééchelonnées et mis à l'échelle en réponse aux demandes de charge de travail. L'application utilise un service DaaS (Database-as-a-Service) pour les données persistantes et les services NodePort, d'équilibreur de charge ou Ingress pour exposer la charge de travail sur une adresse IP stable.

Applications avec état

Comparées aux applications sans état, les applications avec état sont beaucoup plus compliquées à configurer, à gérer et à mettre à l'échelle car les pods requièrent des données persistantes et une identité de réseau stable. Les applications avec état sont souvent des bases de données ou d'autres charges de travail distribuées à forte consommation de données dans lesquelles le traitement est plus efficace à proximité des données proprement dites. Si vous souhaitez déployer une application avec état, vous devez configurer un stockage persistant et monter un volume persistant sur le pod qui est contrôlé par un objet StatefulSet. Vous pouvez choisir d'ajouter un stockage de fichiers, un stockage par blocs ou un stockage d'objets comme stockage persistant pour votre ensemble avec état. Vous pouvez également installer Portworx sur vos nœuds de travail en métal nu et utiliser Portworx comme solution de stockage défini par logiciel hautement disponible pour gérer le stockage persistant de vos applications avec état. Pour plus d'informations sur le fonctionnement des jeux d'état, consultez la documentation de Kubernetes.

Quelles sont les instructions de développement d'applications natives en cloud sans état ?

Consultez l'application à douze facteurs, une méthodologie neutre sur le plan linguistique qui permet d'étudier la manière de développer votre application en fonction de douze facteurs, résumés comme suit.

1. Base de code: Utilisez une base de code unique dans un système de contrôle de version pour vos déploiements. Lorsque vous extrayez une image pour votre déploiement de conteneur, spécifiez une balise d'image de test au lieu d'utiliser la dernière (valeur latest).
2. Dépendances : Déclarez et isolez explicitement des dépendances externes.
3. Configuration : Stockez une configuration spécifique au déploiement dans les variables d'environnement et non dans le code.
4. Services de sauvegarde : Traitez les services de sauvegarde, tels que des magasins de données ou des files d'attente de messages, comme des ressources connectées ou remplaçables.
5. Etapes d'application : Créez des étapes distinctes, telles que build, release, run, avec un cloisonnement strict entre chacune d'elles.
6. Processus : Exécutez un ou plusieurs processus sans état qui ne partagent rien et utilisez le stockage persistant pour sauvegarder les données.
7. Liaison de ports : Les liaisons de port sont autonomes et fournissent un noeud final de service sur un hôte et un port bien définis.
8. Accès concurrents : Gérez et mettez à l'échelle votre application via des instances de processus telles que les répliques et la mise à l'échelle horizontale. Définissez des demandes et des limites de ressource pour vos déploiements. Notez que les règles réseau Calico ne peuvent pas limiter la bande passante.
9. Supprimable : Concevez votre application pour qu'elle soit supprimable, avec un minimum de démarrage, un arrêt approprié et une tolérance aux arrêts de traitement brutaux. N'oubliez pas que les conteneurs, les pods et même les noeuds worker sont censés être supprimables, par conséquent, planifiez votre application en conséquence.
10. Parité entre le développement et la production: Mettez en place un pipeline d'intégration et de livraison continues pour votre application, avec une différence minimale entre l'application en développement et l'application en production.
11. Journaux : Traitez les journaux comme des flux d'événements : L'environnement externe ou d'hébergement traite et achemine les fichiers journaux. Important : dans Red Hat OpenShift on IBM Cloud, les journaux ne sont pas activés par défaut. Pour les activer, voir Configuration de l'acheminement des journaux.
12. Processus d'administration: Conservez les scripts d'administration ponctuels avec votre application et exécutez-les en tant qu' objet Kubernetes Job pour vous assurer que les scripts d'administration s'exécutent dans le même environnement que l'application elle-même. Pour l'orchestration de paquets plus importants que vous souhaitez exécuter dans vos clusters Kubernetes, envisagez d'utiliser un gestionnaire de paquets tel que Helm.

Qu'en est-il des applications sans serveur?

Vous pouvez exécuter des applications et des travaux sans serveur via le service IBM Cloud Code Engine. Code Engine peut également générer vos images pour vous.

J'ai déjà une application. Comment puis-je la faire migrer vers Red Hat OpenShift on IBM Cloud ?

Vous pouvez effectuer les étapes générales suivantes pour conteneuriser votre application :

1. Utilisez l'application à douze facteurs comme guide pour isoler les dépendances, séparer les processus en services distincts et réduire autant que possible l'état de votre application.
2. Recherchez une image de base appropriée à utiliser. Vous pouvez utiliser des images disponibles publiquement sur Docker Hub, des images publiques IBM, ou créer et gérer les vôtres dans votre espace privé IBM Cloud Container Registry.
3. Ajoutez à votre image Docker uniquement ce qui est nécessaire pour exécuter l'application.
4. Examinez les scénarios de modification d'application courants.
5. Au lieu de vous en remettre au stockage local, prévoyez d'utiliser du stockage persistant ou des solutions database-as-a-service en cloud pour sauvegarder les données de votre application.
6. A terme, restructurez vos processus d'application en microservices.

Exemples d'étapes permettant d'octroyer un accès privilégié de déploiement

Si vous disposez d'une application qui s'exécute avec des droits d'accès root, vous devez modifier votre déploiement pour qu'il fonctionne avec les contraintes de contexte de sécurité définies pour votre cluster Red Hat OpenShift. Par exemple, vous pouvez configurer votre projet avec un compte de service afin de contrôler l'accès privilégié, puis modifier votre déploiement pour utiliser ce compte de service.

Avant de commencer : accédez à votre cluster Red Hat OpenShift.

1. En tant qu'administrateur de cluster, créez un projet.

   oc adm new-project <project_name>
   

2. Ciblez le projet de sorte que les ressources que vous créez par la suite se trouvent dans l'espace de noms de projet.

   oc project <project_name>
   

3. Créez un compte de service pour le projet.

   oc create serviceaccount <sa_name>
   

4. Ajoutez une contrainte de contexte de sécurité (SCC) au compte de service pour le projet. Si vous souhaitez vérifier quelles règles se trouvent dans le contrôleur de communication série privileged, exécutez oc describe scc privileged. Pour plus d'informations sur les contraintes de contexte de sécurité, voir la documentation Red Hat OpenShift.

   oc adm policy add-scc-to-user privileged -n <project_name> -z <sa_name>
   

5. Dans votre fichier de configuration de déploiement, reportez-vous au compte de service privilégié et affectez la valeur privileged au contexte de sécurité.

   • Dans spec.template.spec, ajoutez serviceAccount: <sa_name>.
   • Dans spec.template.spec.containers, ajoutez securityContext: privileged: true.

   Exemple

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: myapp_deployment
     labels:
       app: myapp
   spec:
     ...
     template:
       ...
       spec:
         serviceAccount: <sa_name>
         containers:
         - securityContext:
             privileged: true
         ...
   

6. Déployez votre fichier de configuration d'application.

   oc apply -f <filepath/deployment.yaml>
   

7. Vérifiez que le pod est à l'état En cours d'exécution. Si un statut d'erreur s'affiche pour votre pod ou si celui-ci est bloqué dans un statut depuis un certain temps, décrivez le pod et consultez la section Evénements pour commencer à résoudre le problème lié à votre déploiement.

   oc get pods
   

Je croyais que je devais placer mon application dans un conteneur. C'est quoi cette histoire de pods ?

Un pod est la plus petite unité déployable que Kubernetes peut gérer. Vous placez votre conteneur (ou un groupe de conteneurs) dans un pod et utilisez le fichier de configuration de pod pour indiquer au pod comment configurer le conteneur et partager des ressources avec d'autres pods. Tous les conteneurs que vous placez dans un pod s'exécutent dans un contexte partagé, ce qui signifie qu'ils partagent la machine virtuelle ou physique.

Que mettre dans un conteneur

Lorsque vous pensez aux composants de votre application, cherchez à déterminer s'ils ont des besoins de ressources significativement différents pour des choses comme l'unité centrale et la mémoire. Certains composants peuvent-ils s'exécuter dans les meilleures conditions possibles, où il serait acceptable de les mettre hors service pendant un petit moment pendant que des ressources sont détournées vers d'autres zones. Un autre composant est-il destiné au client, auquel cas, il doit impérativement rester actif ? Répartissez-les dans des conteneurs distincts. Vous pouvez toujours les déployer sur le même pod de sorte qu'ils s'exécutent ensemble de manière synchronisée.

Eléments à placer dans un pod

il n'est pas nécessaire que les conteneurs pour votre application se trouvent dans le même pod. En fait, si vous disposez d'un composant qui est avec état et difficile à mettre à l'échelle, par exemple un service de base de données, placez-le dans un autre pod que vous pouvez planifier sur un noeud worker avec davantage de ressources pour gérer la charge de travail. Si vos conteneurs fonctionnent correctement s'ils s'exécutent sur différents noeuds worker, utilisez plusieurs pods. S'ils doivent se trouver sur la même machine et être mis à l'échelle ensemble, regroupez-les dans le même pod.

Si je peux utiliser une capsule, pourquoi ai-je besoin de tous ces types d'objets?

Créer un fichier YAML de pod est facile à faire. Vous pouvez en écrire un avec juste quelques lignes, comme suit :

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Mais, vous ne voulez pas vous arrêter là. Si le noeud exécuté par votre pod tombe en panne, ce dernier tombe également en panne et il n'est pas replanifié. Au lieu de cela, utilisez un déploiement pour prendre en charge la replanification des pods, les ensembles de répliques et les mises à jour continues. Un déploiement de base est pratiquement aussi facile à réaliser qu'un pod. Au lieu de définir le conteneur dans la spécification (spec) proprement dite, vous spécifiez des répliques (replicas) et un modèle (template) dans la spécification (spec) de déploiement. Le modèle possède sa propre spécification (spec) pour les conteneurs qu'il contient, par exemple :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Vous pouvez continuer d'ajouter des fonctions, par exemple, l'anti-affinité de pod ou des limites de ressource, le tout dans le même fichier YAML.

Pour une explication plus détaillée des différentes fonctionnalités que vous pouvez ajouter à votre déploiement, voir Créer un fichier YAML pour le déploiement de votre application.

Quel type d'objets Kubernetes puis-je créer pour mon application ?

Lorsque vous préparez le fichier YAML de votre application, vous disposez de plusieurs options pour augmenter la disponibilité, les performances et la sécurité de l'application. Par exemple, au lieu d'un simple pod, vous pouvez utiliser un objet contrôleur Kubernetes pour gérer votre charge de travail, par exemple un ensemble de répliques, un travail ou un ensemble de démons. Pour plus d'informations sur les pods et les contrôleurs, consultez la documentation Kubernetes. Un déploiement qui gère un ensemble de répliques de pods est un cas d'utilisation courant d'application.

Par exemple, un objet kind: Deployment est un bon choix pour déployer un pod d'application car avec cet objet, vous pouvez spécifier un ensemble de répliques pour obtenir une disponibilité accrue pour vos pods.

Le tableau suivant décrit les raisons pour lesquelles vous pourrez être amené à créer différents types d'objets de charge de travail Kubernetes.

Et si je souhaite utiliser des variables dans ma configuration d'application ? Comment ajouter ces variables au fichier YAML?

Pour ajouter des informations variables à vos déploiements au lieu de coder en dur les données dans le fichier YAML, vous pouvez utiliser une adresse Kubernetes ConfigMap ou un objet Secret objet.

Pour consommer un objet ConfigMap ou Secret, vous devez le monter sur le pod. L'objet ConfigMap ou Secret est combiné au pod juste avant l'exécution du pod. Vous pouvez réutiliser une spécification et une image de déploiement sur de nombreuses applications, mais les échanger ensuite contre des objets ConfigMap et Secret personnalisés. Les objets Secret peuvent prendre beaucoup d'espace de stockage dans le noeud local, donc planifiez-les en conséquence.

Ces deux ressources définissent des paires clé-valeur, mais vous les utilisez dans des contextes différents.

ConfigMap

Fournit des informations de configuration non sensibles pour les charges de travail spécifiées dans un déploiement. Vous pouvez utiliser des objets ConfigMap de trois manières principales.

• Système de fichiers : vous pouvez monter un fichier complet ou un ensemble de variables sur un pod. Un fichier et créé pour chaque entrée en fonction du contenu du nom de la clé du fichier défini avec la valeur.
• Variable d'environnement : définissez de manière dynamique la variable d'environnement pour une spécification de conteneur.
• Option de ligne de commande : Définir l'option de ligne de commande utilisée dans une spécification de conteneur.

Secret

Fournit les informations sensibles suivantes relatives à vos charges de travail. D'autres utilisateurs du cluster peuvent avoir accès au secret, donc n'oubliez pas que les informations qu'elle contient peuvent être partagées avec ces utilisateurs.

• Informations identifiant la personne (PII) : stockez les informations sensibles, telles que les adresses e-mail ou d'autres types d'informations requises pour la conformité de l'entreprise ou pour la réglementation officielle dans les secrets.
• Données d'identification : insérez les données d'identification, telles que les mots de passe, les clés et les jetons dans un secret pour réduire le risque d'exposition accidentelle. Par exemple, lorsque vous liez un service à votre cluster, les données d'identification sont stockées dans un secret.

Vous voulez sécuriser davantage vos secrets ? Demandez à l'administrateur de votre cluster d'activer un fournisseur de service de gestion de clés dans votre cluster pour chiffrer les secrets nouveaux ou existants.

Comment puis-je m'assurer que mon application dispose des ressources adéquates?

Lorsque vous spécifiez le fichier YAML de votre application, vous pouvez ajouter des fonctionnalités Kubernetes à la configuration de votre application pour l'aider à obtenir les ressources correctes. En particulier, définissez des limites de ressources et des demandes pour chaque conteneur défini dans votre fichier YAML.

Par ailleurs, l'administrateur de votre cluster doit configurer des contrôles de ressources pouvant affecter le déploiement de votre application, par exemple :

• quotas de ressources
• Priorité de pod

Comment ajouter des fonctionnalités à ma configuration d'application ?

Voir Spécification des exigences relatives à votre application dans votre fichier YAML pour obtenir la description de ce que vous pouvez inclure dans un déploiement. L'exemple comprend les options suivantes.

• jeux de répliques
• Labels
• affinité
• Politiques d'images
• Ports
• Demandes et limites de ressources
• Sondes Liveness Probe et Readiness Probe
• Services pour exposer le service d'application sur un port.
• Configmaps pour définir les variables d'environnement de conteneur.
• Secrets pour définir des variables d'environnement de conteneur.
• Volumes persistants montés sur le conteneur pour le stockage.

Comment ajouter des services IBM, tels que Watson, à mon application ?

Voir Ajout de services à des applications.

Comment puis-je augmenter la disponibilité de mon application ?

Tenez compte des options suivantes pour une disponibilité accrue de votre application.

Utilisez des déploiements et des ensembles de répliques pour déployer votre application et ses dépendances

Un déploiement est une ressource de Kubernetes que vous pouvez utiliser pour déclarer tous les composants de votre application et de ses dépendances. Avec les déploiements, vous n'avez pas à écrire toutes les étapes et vous pouvez ainsi vous concentrer sur votre application. Lorsque vous déployez plus d'un pod, un jeu de répliques est automatiquement créé pour vos déploiements qui surveille les pods et garantit que le nombre spécifié de pods est en cours d'exécution. Lorsqu'un pod tombe en panne, l'ensemble de répliques remplace le pod qui ne répond plus par un nouveau. Vous pouvez utiliser un déploiement afin de définir des stratégies de mise à jour pour votre application, notamment le nombre de pods que vous désirez ajouter lors d'une mise à jour en continu et le nombre de pods pouvant être indisponibles à un moment donné. Lorsque vous effectuez une mise à jour en continu, le déploiement vérifie si la révision fonctionne et arrête le déploiement lorsque des incidents sont détectés. Avec les déploiements, vous pouvez déployer simultanément plusieurs révisions avec différentes options. Par exemple, vous pouvez d'abord tester un déploiement avant de décider de l'utiliser en environnement de production. Les déploiements vous permettent de suivre toutes les révisions déployées. Vous pouvez utiliser cet historique pour rétablir une version antérieure si vous constatez que vos mises à jour ne fonctionnent pas comme prévu.

Incluez suffisamment de répliques pour répondre à la charge de travail de votre application, plus deux répliques

Pour rendre votre application encore plus disponible et réfractaire aux échecs, envisagez d'inclure des répliques supplémentaires au-delà du strict minimum requis pour gérer la charge de travail anticipée. Ces répliques supplémentaires pourront gérer la charge de travail en cas de panne d'un pod et avant que l'ensemble de répliques n'ait rétabli le pod défaillant. Pour une protection face à deux défaillances simultanées de pods, incluez deux répliques supplémentaires. Cette configuration correspond à un modèle N+2, où N désigne le nombre de pods destinés à traiter la charge de travail entrante et +2 indique deux répliques supplémentaires. Tant qu'il y a suffisamment d'espace dans votre cluster, vous pouvez avoir autant de pods que vous voulez.

Disséminez les pods entre plusieurs noeuds (anti-affinité)

Lorsque vous créez votre déploiement, vous pouvez déployer tous les pods sur le même noeud worker. C'est ce qu'on appelle l'affinité ou la colocalisation. Pour protéger votre application contre une défaillance de noeud worker, vous pouvez configurer votre déploiement de sorte à disséminer les pods entre plusieurs noeuds worker, et ce en utilisant l'option podAntiAffinity avec vos clusters standard. Vous pouvez définir deux types d'anti-affinité de pod : préféré (preferred) ou obligatoire (required). Pour plus d'informations, consultez la documentation de Kubernetes sur l'affectation de pods à des nœuds.

Pour obtenir un exemple d'affinité dans un déploiement d'application, voir Création du fichier YAML pour le déploiement de votre application.

Disséminez les pods entre plusieurs zones ou régions

Pour protéger votre application en cas de défaillance d'une zone, vous pouvez créer plusieurs clusters dans des zones distinctes ou ajouter des zones dans un pool de noeuds worker dans un cluster multizone. Les clusters multizones sont disponibles uniquement dans certaines zones multiples classiques ou VPC, telles que Dallas. Si vous créez plusieurs clusters dans des zones distinctes, vous devez configurer un équilibreur de charge global. Lorsque vous utilisez un ensemble de répliques et spécifiez l'anti-affinité pour les pods, Kubernetes répartit les pods d'application sur les différents noeuds. Si vos noeuds se trouvent dans plusieurs zones, les pods sont répartis entre les zones, pour augmenter la disponibilité de votre application. Si vous souhaitez limiter l'exécution de vos applications à une seule zone, vous pouvez configurer l'affinité de pod pour créer et labelliser un pool de noeuds worker dans une zone.

Dans le cadre d'un déploiement en cluster multizone, mes pods d'application sont-ils répartis uniformément entre les nœuds?

Les pods sont répartis uniformément entre les zones mais pas toujours entre les noeuds. Par exemple, si vous disposez d'un cluster avec un noeud dans chacune des trois zones et que vous déployez un ensemble de répliques de six pods, chaque noeud obtient deux pods. Cependant, si vous avez un cluster avec deux noeuds dans chacune des trois zones et que vous déployez un ensemble de répliques de six pods, chaque zone dispose de deux pods planifiés et peut ou non planifier un pod par noeud. Pour mieux contrôler la programmation, vous pouvez définir l'affinité des pods.

Si une zone tombe en panne, comment les pods sont-ils reprogrammés sur les nœuds restants dans les autres zones?

Tout dépend de la politique de planification que vous avez utilisée dans le déploiement. Si vous avez inclus l'affinité de pod spécifique au nœud, vos pods ne sont pas reprogrammés. Si vous ne l'avez pas fait, les pods sont créés sur les noeuds worker disponibles dans d'autres zones, mais risquent de ne pas être équilibrés. Par exemple, les deux pods peuvent être répartis sur les deux noeuds disponibles ou peuvent être planifiés tous les deux sur un noeud doté de la capacité disponible. De même, lorsque la zone indisponible est restaurée, les pods ne sont pas automatiquement supprimés et rééquilibrés entre les noeuds. Si vous souhaitez que les pods soient rééquilibrés entre les zones après le rétablissement de la zone, configurez l'outil Kubernetes descheduler. Dans les grappes multizones, essayez de maintenir la capacité de vos nœuds de travail à 50 % par zone afin qu'il reste suffisamment de capacité pour protéger votre grappe contre une défaillance zonale.

Que faire si je souhaite diffuser mon application dans plusieurs régions?

Pour protéger votre application d'une défaillance régionale, créez un deuxième cluster dans une autre région, configurez un équilibreur de charge global pour connecter vos clusters, et utilisez un YAML de déploiement pour déployer un ensemble de répliques dupliqué avec une anti-affinité de pod pour votre application.

Et si mes applications ont besoin d'un stockage persistant?

Utilisez un service de cloud, comme par exemple IBM Cloudant ou IBM Cloud Object Storage.

Comment puis-je mettre mon application à l'échelle ?

Si vous voulez ajouter et retirer des applications de manière dynamique par rapport à l'utilisation des charges de travail, voir Mise à l'échelle des applications pour connaître les étapes permettant d'activer la mise à l'échelle automatique de pod horizontale.

Comment puis-je organiser mes déploiements pour faciliter leur mise à jour et leur gestion ?

Maintenant que vous savez précisément ce que vous devez ajouter à votre déploiement, vous vous demandez sûrement comment faire pour gérer tous ces fichiers YAML ? Sans parler des objets qu'ils créent dans votre environnement Kubernetes !

Les conseils suivants peuvent vous aider à organiser vos fichiers YAML de déploiement.

• Utilisez un système de contrôle des versions, par exemple Git.
• Regroupez des objets Kubernetes connexes dans un seul fichier YAML. Par exemple, si vous créez un deployment, vous pouvez être amené à ajouter également le fichier service au fichier YAML. Séparez les objets par trois tirets (---), comme dans l'exemple ci-après.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• Vous pouvez utiliser la commande oc apply -f pour une application à la totalité d'un répertoire et non simplement à un fichier.
• Utilisez le projet kustomize qui peut vous aider à écrire, personnaliser et réutiliser vos configurations YAML de ressource Kubernetes.

Dans le fichier YAML, vous pouvez utiliser des libellés ou des annotations comme métadonnées pour gérer vos déploiements.

Labels

Les étiquettes sont des paires key:value qui peuvent être attachées aux objets Kubernetes tels que les pods et les déploiements. Ils peuvent être tout ce que vous voulez et sont utiles pour sélectionner des objets en fonction des informations de libellé. Les libellés fournissent la base du regroupement d'objets. Pour des idées de libellé, reportez-vous aux exemples ci-après.

• app: nginx
• version: v1
• env: dev

Annotations

Les annotations sont similaires aux étiquettes en ce sens qu'elles sont également des paires key:value. Elles sont plutôt recommandées pour des informations non identifiantes qui peuvent être optimisées par des outils ou des bibliothèques, par exemple, pour des informations supplémentaires relatives à la provenance d'un objet, à l'utilisation de l'objet, à des pointeurs vers des référentiels de suivi connexes ou une règle concernant l'objet. Vous ne sélectionnez pas des objets basés sur des annotations.

Quelles stratégies de mise à jour d'application puis-je utiliser ?

Pour mettre à jour votre application, vous pouvez choisir parmi différentes stratégies, telles que celles décrites ci-après. Vous pouvez commencer par un déploiement en continu ou un basculement instantané avant de passer à un déploiement cobaye plus complexe.

Déploiement en continu

Vous pouvez utiliser une fonctionnalité native Kubernetes pour créer un déploiement v2 et pour remplacer progressivement votre précédent déploiement v1. Cette approche exige que les applications soient compatibles avec les versions antérieures, de sorte que les utilisateurs qui reçoivent la version de l'application v2 ne subissent pas de changements radicaux. Pour plus d'informations, voir Gestion des déploiements en continu pour mettre à jour vos applications.

Basculement instantané

Egalement appelé déploiement Blue-Green, un basculement instantané nécessite de doubler les ressources informatiques de sorte que deux versions d'une application s'exécutent en même temps. Avec cette approche, vous pouvez faire passer vos utilisateurs à la version plus récente quasiment en temps réel. Veillez à utiliser des sélecteurs d'étiquettes de service (tels que version: green et version: blue) pour vous assurer que les demandes sont envoyées à la bonne version de l'application. Vous pouvez créer le nouveau déploiement version: green, attendre qu'il soit prêt, puis supprimer le déploiement version: blue. Vous pouvez également effectuer une Mise à jour évolutive, mais définir le paramètre maxUnavailable sur 0% et le paramètre maxSurge sur 100%.

Déploiement A/B ou cobaye

Une stratégie de mise à jour plus complexe, un déploiement cobaye, est lorsque vous choisissez un pourcentage d'utilisateurs, par exemple, 5 % et que vous les envoyez à la nouvelle version d'application. Vous collectez dans vos outils de journalisation et de surveillance des métriques relatives aux performances de la nouvelle version d'application, vous effectuez des tests A/B, puis vous déployez la mise à jour à d'autres utilisateurs. Comme pour tous les déploiements, spécifier un libellé pour l'application (par exemple, version: stable et version: canary) est essentiel.

Comment puis-je automatiser mon déploiement d'application ?

Si vous souhaitez exécuter votre application dans plusieurs clusters, plusieurs environnements privés et publics, ou même dans plusieurs fournisseurs de cloud, vous vous demandez peut-être comment faire pour que votre stratégie de déploiement fonctionnent dans tous ces environnements. Grâce à IBM Cloud et à d'autres outils open source, vous pouvez conditionner votre application de manière à automatiser les déploiements.

Configurez un pipeline d'intégration continue et de distribution continue (CI/CD)

Avec vos fichiers de configuration d'application organisés dans un système de gestion de contrôle de source tel que Git, vous pouvez créer votre pipeline afin de tester et déployer du code dans différents environnements, par exemple, test et prod. Collaborez avec votre administrateur de cluster pour configurer une intégration et une distribution continues.

Conditionnez vos fichiers de configuration d'application

Conditionnez votre application à l'aide d'outils tels que Kustomize ou Helm.

• Avec le projet kustomize, vous pouvez écrire, personnaliser et réutiliser les configurations YAML de vos ressources Kubernetes.
• Avec le Helm Kubernetes vous pouvez spécifier toutes les ressources Kubernetes dont votre application a besoin dans un tableau Helm. Ensuite, vous pouvez utiliser Helm pour créer les fichiers de configuration YAML et déployer ces fichiers dans votre cluster. Vous pouvez également intégrer les graphiques Helm fournis par IBM Cloud pour étendre les capacités de votre cluster, par exemple avec un plug-in de stockage en bloc.

Vous cherchez à créer des modèles de fichier YAML ? Certaines personnes utilisent Helm pour faire cela, ou vous pouvez essayer d'autres outils communautaires tels que ytt.

Comment puis-je m'assurer que mes services sont connectés aux bons déploiements et qu'ils sont prêts à fonctionner?

Pour la plupart des services, ajoutez un sélecteur à votre fichier .yaml de service de telle manière qu'il soit appliqué aux pods qui exécutent vos applications via ce libellé. Souvent, lorsque votre application démarre, vous ne voulez pas qu'elle traite les demandes immédiatement. Ajoutez une sonde Readiness Probe à votre déploiement de sorte que le trafic soit envoyé uniquement à un pod qui est considéré comme prêt. Pour un exemple de déploiement avec un service qui utilise des étiquettes et définit une sonde de préparation, consultez ce NGINX YAML.

Parfois, vous ne souhaitez pas que le service utilise un libellé. Vous pouvez par exemple disposer d'une base de données externe ou souhaiter faire pointer le service vers un autre service situé dans un autre espace de noms au sein du cluster. Dans ce cas, vous devez ajouter manuellement un objet de noeud final et le lier au service.

Comment puis-je exposer mes services sur Internet ?

Vous pouvez créer trois types de services pour la mise en réseau externe : NodePort, LoadBalancer et Ingress.

Vous disposez de différentes options en fonction de votre type de cluster. Pour plus d'informations, voir Planification des services de mise en réseau.

• Cluster standard : vous pouvez exposer votre application en utilisant un service NodePort, LoadBalancer ou Ingress.
• Cluster rendu privé en utilisant Calico : vous pouvez exposer votre application en utilisant un service NodePort, LoadBalancer ou Ingress. Vous devez également utiliser une règle réseau pré-DNAT Calico pour bloquer les ports de noeud publics.

Lorsque vous déterminez le nombre d'objets Service dont vous avez besoin dans votre cluster, gardez à l'esprit que Kubernetes utilise iptables pour gérer les règles de mise en réseau et d'acheminement de port. Si vous exécutez de nombreux services dans votre cluster, tels que 5000, les performances risquent d'être affectées.

Comment contrôler qui a accès à mes déploiements d'application ?

Les administrateurs de compte et de cluster peuvent contrôler l'accès à de nombreux niveaux distincts : le cluster, le projet Red Hat OpenShift, le pod et le conteneur.

Avec IBM Cloud IAM, vous pouvez affecter des droits à des utilisateurs individuels, des groupes ou des comptes de service au niveau de l'instance du cluster. Vous pouvez davantage restreindre l'accès au cluster en limitant les utilisateurs à certains espaces de noms au sein du cluster. Pour plus d'informations, voir Affectation d'accès au cluster.

Pour contrôler l'accès au niveau du pod, vous pouvez configurer des contraintes de contexte de sécurité (SCC).

Au sein du fichier YAML de déploiement de l'application, vous pouvez définir le contexte de sécurité d'un pod ou d'un conteneur. Pour plus d'informations, consultez la documentation de Kubernetes.

Après avoir déployé mon application, comment en surveiller l'état de santé ?

Vous pouvez configurer la journalisation et la surveillance de IBM Cloud pour votre cluster.