Parcours de formation : Faire évoluer des applications – Considérations relatives à la production

Dans cet ensemble de tutoriels, certaines considérations de planification sont simplifiées afin que vous puissiez vous concentrer sur l'apprentissage des principales fonctionnalités et services de l'édition Enterprise de Google Kubernetes Engine (GKE). Avant de commencer à créer votre propre environnement Google Kubernetes Engine (GKE) édition Enterprise, semblable à celui décrit dans cette série de tutoriels, vous devez tenir compte de quelques considérations supplémentaires relatives à la planification. Ces considérations incluent le niveau de gestion du cluster, la mise en réseau et les types de disponibilité.

Mise en réseau

Les clusters GKE nécessitent une planification minutieuse des adresses IP. Les options de mise en réseau que vous choisissez ont une incidence sur l'architecture de vos clusters GKE. Après avoir été configurées, certaines de ces options ne peuvent plus être modifiées sans recréer le cluster.

Dans cet ensemble de tutoriels, vous allez utiliser des clusters en mode Autopilot qui utilisent toujours la mise en réseau en mode VPC natif. Les clusters de VPC natif utilisent des plages d'adresses IP d'alias sur les nœuds GKE et sont requis pour créer des clusters sur des VPC partagés. Il est plus facile de faire évoluer des clusters de VPC natif que des clusters basés sur le routage, d'autant que cela ne consomme pas de routes Google Cloud. Les clusters de VPC natif sont donc moins sensibles aux limites de routage.

Avant de créer votre propre environnement GKE Enterprise et de déployer des charges de travail, consultez les conseils de mise en réseau suivants :

Modes de cluster

Dans cet ensemble de tutoriels, vous allez créer un cluster GKE Enterprise régional qui utilise le mode Autopilot. Les clusters Autopilot sont préconfigurés avec une configuration de cluster optimisée, prête pour les charges de travail de production. Vous pouvez également utiliser des clusters en mode Standard, pour une configuration plus flexible de l'infrastructure sous-jacente.

Pour une présentation plus complète, consultez les documents de planification qui commencent par les choix de configuration des clusters.

Espaces de noms

Les espaces de noms vous permettent d'organiser vos applications et d'en isoler les composants les uns des autres. Chaque espace de noms possède son propre ensemble de ressources, telles que des ressources Pod, Service et Deployment. Par exemple, vous pouvez créer un espace de noms pour tous vos services d'interface, et un autre espace de noms pour vos services de backend. Ce regroupement facilite la gestion de vos services et le contrôle de l'accès à ceux-ci.

Dans cet ensemble de tutoriels, vous allez déployer les ressources Pod et Service de l'exemple d'application Cymbal Bank, dans un espace de noms unique. Cette approche réduit la complexité du déploiement, mais ne vous permet pas d'utiliser des espaces de noms pour attribuer des ressources à différentes équipes et à différents utilisateurs, comme vous le feriez dans un environnement de production. Elle ne vous permet pas non plus de bénéficier des fonctionnalités de gestion des équipes de GKE Enterprise, qui vous aident à structurer vos parcs, vos espaces de noms et vos autorisations pour permettre aux équipes d'agir de manière indépendante en tant que "locataires" distincts sur votre parc, avec leurs propres ressources. Pour découvrir une version plus sécurisée et prête pour la production de l'exemple d'application Cymbal Bank utilisant plusieurs espaces de noms, consultez la page Architecture de l'application Cymbal Bank.

Budgets d'interruptions de pods

Les règles de budget d'interruption de pods (PDB) contribuent à garantir les performances de l'application en empêchant l'interruption simultanée des pods lorsque vous apportez une modification au système, et en limitant le nombre de pods indisponibles simultanément dans une application répliquée.

Vous n'allez configurer ni utiliser aucune règle PDB dans cette série de tutoriels. Une fois que vous avez terminé le tutoriel pour simuler une défaillance, vos ressources Service et vos nœuds doivent tous répondre comme prévu. Lorsque vous déployez vos propres charges de travail, les règles PDB appliquées sur les nœuds risquent de bloquer le drainage des nœuds.

Si vous utilisez des règles PDB, vérifiez votre configuration avant de marquer les nœuds comme non ordonnançables et de les drainer. En cas de drainage des nœuds non concluant, vous risquez de rencontrer des problèmes avec les événements de maintenance programmés.

Étapes suivantes

Commencez par suivre le premier tutoriel sur le déploiement d'un seul cluster GKE, exécutant une application basée sur des microservices.