Conteneurs et Kubernetes

Ingénierie de plateforme : tirez parti de l’expérience Google

Fri, 24 Oct 2025 05:00:00 +0000

Comment abordez-vous le développement logiciel ? Chez Google, nous nous efforçons constamment de créer de meilleurs services, plus rapidement. Pour y parvenir, notre équipe Developer Platform et Google Cloud ont noué un partenariat stratégique et se mobilisent autour d’une vision commune : capitaliser sur nos solutions internes et nos outils d’ingénierie pour les mettre à disposition des clients Google Cloud.

Le premier défi du développement logiciel consiste à bien comprendre comment les équipes, petites ou grandes, peuvent trouver le juste équilibre entre efficacité, qualité et coûts, tout en créant de la valeur. À l’occasion de notre récente intervention lors de PlatformCon 2025, nous avons présenté les éléments clés de notre approche de l’ingénierie de plateforme, une approche que nous avons baptisée « shift down ».

Le shift down consiste à intégrer les décisions et les responsabilités directement au sein des plateformes internes de développement (IDP), afin de réduire la charge opérationnelle qui pèse sur les développeurs. Elle se distingue de la tendance DevOps du shift left, qui vise à déplacer davantage d’efforts en amont du cycle de développement, une méthode qui montre ses limites à grande échelle face à l’ampleur et au rythme des évolutions des besoins.
Là où le shift left tend à alourdir la charge des équipes lorsqu’il est appliqué à grande échelle, le shift down cherche au contraire à tirer le maximum de valeur des ressources existantes. Cette approche permet aux entreprises d’innover rapidement tout en maintenant un niveau de qualité, de risque et de coûts soutenables, quels que soient leurs modèles économiques.

Lors de notre intervention, nous avons partagé plusieurs enseignements qui se sont révélés particulièrement utiles dans notre démarche en matière de développement logiciel et d’ingénierie de plateforme :

Partir du modèle économique. En prenant le modèle économique comme point de départ, les organisations peuvent orienter l’évolution de leur plateforme et de leurs investissements en fonction de leurs objectifs de marge, de leur tolérance au risque et de leurs exigences de qualité. Chez Google, notre plateforme centrale doit répondre à une grande diversité de modèles économiques, ce qui impose un travail constant de raffinement stratégique et d’adaptation..
Se concentrer sur les critères de qualité pour un pilotage centralisé. Les critères de qualité — fiabilité, sécurité, efficacité et performance — sont des caractéristiques transverses émergentes (ou emergent properties) des systèmes logiciels. Elles jouent un rôle essentiel pour créer de la valeur métier et maîtriser les risques. On les qualifie souvent « d’exigences non fonctionnelles » car ils décrivent la manière dont le logiciel se comporte, et non ce qu’il fait fonctionnellement. Avec une stratégie shift down, la responsabilité de ces critères de qualité peut être intégrée directement au sein des systèmes et de l’infrastructure de la plateforme, réduisant ainsi considérablement la charge opérationnelle qui pèse sur chaque développeur.
Abstractions et couplage, deux leviers essentiels pour maîtriser les critères de qualité. Notre approche de la conception de plateformes repose sur deux leviers techniques essentiels pour maîtriser les critères de qualité : les abstractions et le couplage. Dans une stratégie shift down, les abstractions permettent de rendre les systèmes plus compréhensibles, de mieux gérer les risques, de clarifier les responsabilités et de contrôler les coûts en encapsulant la complexité. Le couplage, quant à lui, indique le degré d’interconnexion et d’interdépendance entre les composants d’un système ou d’un écosystème de développement. Pour réussir une stratégie shift down, le bon niveau de couplage est déterminant, car il permet à la plateforme et à l’écosystème de développement d’intégrer et d’influencer directement les critères de qualité. Concrètement, c’est grâce au couplage que nous pouvons proposer des solutions complètes d’infrastructure et de plateforme sous forme de services cohérents, comme Google Kubernetes Engine (GKE).
Responsabilités partagées, formation et règles communes sont des leviers « sociaux » essentiels. À grande échelle, la responsabilité partagée constitue un levier organisationnel déterminant. Elle repose d’abord sur la formation, par exemple en sensibilisant les ingénieurs à l’usage des plateformes et de l’IA. Elle s’appuie aussi sur la promotion d’une culture one team (« une seule équipe ») afin d’encourager les profils centrés sur un livrable ou un composant donné à s’ouvrir à la mission globale et à l’engagement envers les clients. Par ailleurs, des règles explicites, comme des guides de style appliqués de manière centralisée ou des API conçues dès l’origine pour être sécurisées (secure by design), permettent d’intégrer des garanties de qualité directement dans la plateforme et l’infrastructure, réduisant ainsi considérablement la charge opérationnelle des développeurs tout en assurant la cohérence et l’automatisation des contrôles à grande échelle.
Utiliser une cartographie. Gérer les besoins de nombreuses entités métiers avec une seule plateforme est un problème vaste et complexe : il vous faut donc une cartographie. Chez Google, nous utilisons ce que nous appelons le modèle d’écosystème, un framework conceptuel qui fait office de cartographie et qui permet de classer les différents environnements de développement logiciel, allant de systèmes très flexibles, sous contrôle direct des développeurs, à des environnements fortement intégrés et normés, où c’est l’écosystème lui-même qui garantit les critères de qualité. Le rôle essentiel de ce framework est de fournir un outil visuel et conceptuel permettant d’évaluer dans quelle mesure les mécanismes de contrôle de l’écosystème sont alignés avec les risques métier. Autrement dit, il sert à vérifier que le niveau de supervision et de garantie des critères de qualité est proportionné au coût potentiel des erreurs. L’objectif est de rester dans la « zone d’efficacité de l’écosystème » : un équilibre où les contrôles suffisent à limiter les risques majeurs liés aux erreurs humaines, sans pour autant imposer de contraintes excessives qui ralentiraient l’innovation et démotiveraient les développeurs.

6. Segmenter le problème en identifiant les différents types de plateformes et d’écosystèmes. L’expérience développeur et l’infrastructure de la plateforme évoluent en fonction de l’échelle et du degré de shift down. Il ne suffit donc pas de savoir où se situe la « zone d’efficacité de l’écosystème » : il faut aussi identifier le type d’écosystème auquel on a affaire. Nous distinguons les écosystèmes en fonction du niveau de supervision et de garantie appliqué aux critères de qualité. Plus un écosystème devient intégré verticalement — comme l’écosystème fortement optimisé « Assured » de Google (Type 4) — plus la plateforme prend nativement en charge des critères de qualité essentiels. Cela permet aux spécialistes, tels que les site reliability engineers (SRE) ou les équipes de sécurité, d’assumer pleinement leur rôle grâce à une observabilité à grande échelle et à des capacités intégrées. À l’inverse, dans des écosystèmes moins homogènes comme « YOLO », « AdHoc » ou « Guided » (Types 0 à 2), les développeurs gèrent une part plus importante de la responsabilité en matière de qualité, tandis que les équipes spécialisées disposent de moins de leviers de contrôle direct et de mécanismes d’application moins étendus. Précisons toutefois : les modèles précités (Assured, YOLO, AdHoc et Guided) ne sont pas des indicateurs de maturité. Le meilleur type d’écosystème et de plateforme est simplement celui qui correspond le mieux aux besoins de votre entreprise (cf. point n°1 ci-dessus !).

Faire les bons choix en matière d’ingénierie de plateforme

En résumé, la leçon la plus importante à retenir, c’est qu’il faut bien peser ses choix et prendre des décisions éclairées. L’ingénierie de plateforme doit être adaptée à chaque entité métier et à chaque application afin d’obtenir les meilleurs résultats. Elle doit avant tout s’attacher à repérer les problèmes récurrents, qui reviennent systématiquement dans différents domaines métier, pour les résoudre une bonne fois pour toutes avec des solutions robustes et réutilisables. Cette approche est au cœur de notre stratégie de shift down. Elle vise à aller vers des plateformes composables, capables d’intégrer directement dans l’infrastructure les décisions et les responsabilités liées à la qualité logicielle. Concrètement, cela signifie que la plateforme prend en charge directement les choix et les responsabilités liés à la qualité logicielle (sécurité, fiabilité, performance, etc.), au lieu de les laisser reposer uniquement sur les développeurs. Dit autrement, avec l’approche shift down, vous renforcez votre capacité à maximiser la valeur métier en mobilisant les bonnes ressources, au niveau de qualité requis, et avec des coûts maîtrisés dans la durée.

Pour aller plus loin, n’hésitez pas à consulter l’intégralité de notre intervention à PlatformCon 2025 sur le sujet.

Planification des workloads GKE : stratégies pour gérer les ressources sous contraintes

Thu, 04 Sep 2025 07:00:00 +0000

En optant pour Google Kubernetes Engine (GKE), vous avez choisi un environnement d’exécution de conteneurs hautement managé qui prend en charge, pour vous, toutes les opérations chronophages et complexes, depuis les mises à jour automatiques jusqu'à la gestion simplifiée des nœuds. Dit autrement, vous avez misé sur une efficacité maximale. Cette dernière, intrinsèque à tous services managés, vous permet de vous concentrer davantage sur vos applications, sans vous soucier de l’infrastructure sous-jacente. Dans un monde idéal, combiner cette gestion entièrement automatisée aux capacités avancées d’autoscaling de GKE garantit une gestion optimale des workloads à tout instant. Vos applications s’adaptent en temps réel, accédant aux ressources nécessaires au bon moment, sans effort.

Malheureusement, la réalité sur le terrain est toujours un peu plus complexe et nous impose de relever quelques défis supplémentaires. Certes, GKE met à disposition un autoscaling efficient reposant sur quatre piliers complémentaires (Horizontal Pod Autoscaler ‘HPA’, Vertical Pod Autoscaler ‘VPA’, Cluster Autoscaler et le provisionnement automatique des nœuds ou Node Auto Provisioning). Des fondations qui font automatiquement évoluer les workloads et l’infrastructure en fonction des besoins. Mais orchestrer une plateforme vraiment efficiente pour des workloads en perpétuelle évolution exige bien plus que la simple capacité à « passer automatiquement à l’échelle ». Il faut aussi jongler avec l'optimisation des coûts, la disponibilité des ressources, la vitesse de provisioning, les performances et la flexibilité opérationnelle. Tous ces facteurs impactent – et contraignent parfois – la gestion de la répartition des workloads sur GKE. Difficile alors d’y voir clair : Quelle stratégie adopter ? Quels compromis accepter ? Choisir la meilleure voie devient un vrai exercice d’équilibriste.

Dans cet article, nous allons nous concentrer spécifiquement sur le « scheduler GKE » (planificateur GKE) et les facteurs qui peuvent influencer ses décisions de répartition des workloads quand les ressources sont limitées. Nous verrons comment anticiper et concevoir des solutions pour ces situations en s'appuyant sur les différentes fonctionnalités GKE et les options de configuration de workloads appropriées.

Un problème d’optimisation sous contraintes, avant tout

En pratique, une planification efficace de la gestion des ressources sur GKE ne consiste pas à chercher LA solution parfaite. Il faut plutôt envisager le problème sous l’angle d’une optimisation multi-critères sous contraintes. Dans la plupart des cas, il s'agit moins de surmonter des limitations strictes que de trouver le meilleur compromis entre des priorités qui peuvent entrer en concurrence :

Coût : vous voulez réduire les dépenses d'infrastructure globales, optimiser l'utilisation des ressources, éviter le sur-provisionnement et privilégier les solutions rentables.
Performance : vous voulez vous assurer que les workloads respectent leurs SLO en fonction de leur importance pour l'entreprise.
Flexibilité et agilité : vous voulez pouvoir réagir aux variations de charge de vos workloads en attribuant la bonne capacité au bon moment.

Pour faire les bons arbitrages et configurer efficacement GKE, vous devez d’abord identifier vos préférences et fixer vos seuils de tolérance sur chacune de ces dimensions.

Les briques de base de GKE

Sans être le seul facteur en jeu, l'autoscaling et sa configuration jouent un rôle clé dans la planification des workloads. La configuration de la montée en charge est spécifique à chaque environnement. Nous avons documenté certaines bonnes pratiques pour vous guider.

Sur GKE, l’autoscaling s’exerce sur quatre axes :

Horizontal Pod Autoscaler (HPA) - ajuste le nombre de répliques de pods
Vertical Pod Autoscaler (VPA) - ajuste les demandes de ressources des pods en fonction de l'utilisation réelle
Cluster Autoscaler (CA) - ajuste automatiquement le nombre de nœuds
Node Auto Provisioner (NAP) - ajuste la taille des pools de nœuds selon les besoins des workloads.

Quand la capacité devient contrainte, il est primordial de connaître précisément ce que vos workloads demandent et consomment comme ressources. Le scheduler GKE s'appuie sur la valeur resource.request de chaque pod pour décider où placer les workloads de façon optimale. Si cette valeur n'est pas définie, le scheduler risque de positionner vos pods sur des nœuds sous-dimensionnés, ce qui provoque des préemptions en cascade et donc de l’instabilité. Le paramétrage correct des requests reste donc essentiel : n’hésitez pas à consulter notre documentation détaillée sur ce sujet.

Scénarios de planification des workloads sous contraintes

« Mais alors, quelles sont mes alternatives pour obtenir une plateforme à la fois performante et efficace quand la capacité est contrainte ? », vous demandez-vous certainement.
Passons ici en revue quelques situations courantes et explorons les différents leviers à votre disposition pour optimiser les coûts, la performance et la flexibilité.

Scénario 1 - Capacité fixe ou limitée : comment garantir les ressources aux workloads prioritaires ?

Dans ce scénario, le nombre de nœuds disponibles est considéré comme statique mais les workloads continuent à évoluer en fonction de la demande. Vous devez donc réserver des ressources pour les workloads critiques et définir explicitement des ordres de priorité (afin d’éviter qu’un service essentiel ne soit évincé par des charges moins stratégiques).

La Solution : des classes de priorité des workloads et des taints (altérations) / tolérances

Les Classes de priorité instaurent une hiérarchie d’importance des workloads : le scheduler accorde la préséance aux workloads en fonction de leur niveau de criticité. Comme l’illustre le schéma ci-dessus, lorsque les ressources se raréfient, le scheduler évince (préempte) les workloads de priorité basse (en bleu) pour libérer les ressources nécessaires à ceux de priorité supérieure (en rouge).

Les Taints et Tolérances servent à réserver et garantir la capacité. Les « Taints » sont des marqueurs appliqués aux nœuds pour indiquer qu’ils ne doivent pas accepter de charges de travail supplémentaires. Ce sont en quelque sorte des « interdictions par défaut » : pour simplifier, un « taint » interdit l’installation d’un pod sur le nœud « tainté » sauf s’il possède une autorisation spéciale. Les Tolérances permettent de définir ces « autorisations spéciales » : ce sont des paramètres ajoutés aux pods pour leur permettre d’être placés sur des nœuds taintés.
Dit autrement, ces marqueurs empêchent le placement de workloads sur des nœuds inappropriés et réservent l’intégralité des ressources de certains nœuds « taintés » (par exemple dotés de GPU ou de SSD ultra-rapide) à des workloads spécifiquement autorisés. Tant qu’un pod n’a pas la « tolérance » (l’autorisation spéciale) qui force le « taint » (l’interdiction par défaut) du nœud, il ne pourra jamais y être placé, même si sa classe de priorité est plus élevée que celle des pods autorisés. C’est donc la garantie qu’une capacité précieuse (un GPU, un SSD ultra performant, etc.) ne sera jamais consommée par inadvertance par des workloads non prévus à cet effet.

Scénario 2 - Pics soudains de trafic : comment scaler sans dégradation des performances ni erreurs ?

Dans ce scénario, le défi consiste à placer sans délai, le plus rapidement possible, de nouveaux workloads sur un cluster capable de s’étendre horizontalement à la volée. Même si GKE propose des fonctionnalités telles que container-optimized compute et image streaming, qui réduisent considérablement le temps de provisionnement des nouveaux nœuds, la planification des pods reste toujours beaucoup plus rapide que le redimensionnement de nœuds. Le différentiel de vitesse — les pods démarrent en quelques secondes alors que l’ajout d’un nœud prend beaucoup plus de temps — peut provoquer des goulets d’étranglement sur les ressources et dégrader le SLO.

La Solution : Le provisionnement des Pods (Placeholder pods ou Pods de Réserve) et les profils d’autoscaling

Les Placeholder pods (ou balloon pods), autrement dit les Pods Réservés, permettent d’avoir en permanence de la capacité disponible sans le cluster. Lorsqu’un pic soudain survient et que de nouveaux pods doivent être placés, ces pods « balloon » sont évincés (préemptés) afin de libérer immédiatement la capacité qu’ils retenaient et y déployer tout aussi rapidement les nouveaux pods requis. L’autoscaler du cluster provisionne ensuite de nouveaux nœuds pour reloger les balloon pods évincés et, si nécessaire, ajouter encore de la capacité.
Les profils d’autoscaling permettent de régler la mise hors service des nœuds selon des objectifs de coût ou de performance. Dit autrement, ces profils indiquent comment et quand les nœuds du cluster doivent être supprimés afin d’opérer un « scale-down » automatique. GKE propose deux profils d’autoscaling, applicables au niveau du cluster : balanced et optimize-utilization. Le profil balanced réduit la taille des nœuds de façon moins agressive qu’optimize-utilization, maintenant ainsi les nœuds disponibles plus longtemps : un nouveau pic de demande ne pâtira donc pas du temps de création de nœuds. Optimize-utilization, en revanche, supprime les nœuds plus rapidement pour maximiser l’utilisation des ressources et réduire les coûts.

Les compute classes (définies ci-après) permettent aussi de réduire le nombre de nœuds de façon ciblée, workload par workload. Elles permettent de définir des règles de consolidation (seuil d’utilisation, délai d’inactivité, etc.) qui déterminent quand un nœud peut être supprimé pour un workload donné.

Scénario 3 : Comment ajouter des nœuds dans un cluster quand le type de nœud souhaité n’est pas disponible ?

Dans ce scénario, vous souhaitez étendre votre cluster sans savoir si le type de nœud requis ou préféré, tel un accélérateur hardware ou une VM spot, sera réellement disponible.

La Solution : GKE custom compute classes (ou classes de calcul personnalisées).

Les « compute classes » permettent de définir des types de nœuds préférés et de secours lorsque vous étendez votre cluster. Vous pouvez fixer des priorités pour des propriétés précises de nœuds (CPU, accélérateurs hardware), pour des caractéristiques globales (famille de VM, minimum CPU/Mémoire, instances Spot), ou même pour un type d’instance exact (par ex. : n4-standard-16).
Ces « compute classes » assurent en outre une migration active vers la meilleure option disponible : si un nœud de priorité supérieure (comme une VM Spot) se libère après le déploiement, les workloads se réalignent automatiquement dessus.
Si votre organisation profite déjà de remises “Committed Use Discounts” (CUD) basées sur les ressources (engagement de facturation sur un volume précis de vCPU/RAM contre un tarif réduit), vous pouvez configurer vos « compute classes » pour consommer en priorité ces ressources déjà payées avant de solliciter d’autres types de nœuds. Et pour gagner encore en souplesse entre familles de machines, régions et plateformes de calcul, envisagez à terme de basculer vers les CUD flexibles.

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: my-class\r\nspec:\r\n priorities:\r\n rules:\r\n - machineFamily: n4\r\n minCores: 16\r\n - machineType: e2-standard-16\r\n - nodepools: [pool1, pool2]\r\n autoscalingPolicy:\r\n consolidationDelayMinutes: 20\r\n nodepoolAutoCreation:\r\n enabled: true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f5910ca04d0>)])]>

Scénario 4 : Que faire quand les ressources matérielles souhaitées ne sont pas disponibles dans une région ?

Dans ce scénario, la capacité requise par le workload est à la fois très spécifique et fortement sollicitée. Il se peut même que ces ressources ne soient pas disponibles dans une région donnée, même en jonglant avec les compute classes. Un casse-tête fréquent pour les applications IA, qui ont besoin d’une infrastructure ultra-performante et d’accélérateurs GPU ou TPU rarement disponibles en grande quantité.

La Solution : Multi-Cluster Orchestrator et Multi-Cluster Gateway

Multi-Cluster Orchestrator est un projet open-source dont l’objectif est de « simplifier les déploiements multi-cluster, optimiser l’utilisation des ressources et les coûts et renforcer la fiabilité, la scalabilité et les performances des workloads ». Intégré à GKE, cet outil permet aux ingénieurs plateforme de localiser les ressources au sein des régions Google Cloud, puis de déclencher automatiquement le provisionnement d’un cluster dans la région où ces ressources sont disponibles.
Multi-Cluster Gateway est une solution réseau pour GKE qui s’appuie sur l’API Kubernetes Gateway pour piloter le trafic applicatif entre plusieurs clusters, potentiellement répartis sur plusieurs régions. Elle simplifie considérablement l’exposition des services et l’équilibrage de charge dans des environnements GKE géographiquement distribués.

Combinées, ces deux solutions permettent une orchestration fluide des workloads dans un environnement multi-régions et offrent une résilience accrue face aux limitations de capacité de certaines régions cloud.

Conclusion et pour aller plus loin

GKE fournit aux ingénieurs plateforme un arsenal complet d’outils pour optimiser l’allocation des ressources, même lorsqu’ils sont confrontés à des contraintes de capacité. Pour que la planification de ressources soit réellement efficace et holistique, il faut connaître ses workloads sur le bout des doigts : criticité, profils d’usage, besoins de ressources spécifiques (CPU, mémoire, GPU, etc.). Travailler en environnement contraint peut être un formidable levier pour maîtriser les coûts… à condition de savoir préserver le niveau de performances.

Pour affiner votre démarche, n’hésitez pas à exploiter les ressources suivantes :

Apprenez à interpréter les indicateurs clés du cluster GKE et des workloads — comme le taux d’utilisation ou le bon dimensionnement (rightsizing) — pour mieux anticiper les besoins en capacité. Ces indicateurs constituent la base de toute planification solide.
Surveillez les événements de mise à l’échelle (scaling), tels que les échecs de planification de pods et les changements du nombre de nœuds/pods, à l’aide du tableau de bord « Unschedulable Pods ».
Découvrez la nouvelle fonctionnalité « GKE Horizontal Pod Autoscaling Observability Events », qui permet d’accéder aux journaux des décisions prises par l’autoscaler HPA. Un outil précieux pour analyser les événements de scaling et affiner la conception de votre plateforme en fonction des comportements observés.

Pourquoi il ne faut plus avoir peur de Kubernetes

Wed, 30 Aug 2023 08:00:00 +0000

Synonyme de portabilité et d’évolutivité, la conteneurisation permet d’exploiter pleinement le potentiel du Cloud tout en réduisant le temps consacré à la gestion de son infrastructure.

Le nom même de Kubernetes signifie “capitaine” en grec, à l’image du commandant chargé d’assurer la sécurité de son navire. Tout comme ce capitaine expérimenté, il s’agit d’une technologie éprouvée : chez Google, nous exécutons des workloads conteneurisés depuis une quinzaine d’années, travaillant main dans la main avec une communauté open source engagée et passionnée.

Kubernetes et la communauté open source

L’histoire de Kubernetes est fortement liée à celle de la communauté open source. Cette dernière a considérablement évolué au fil des années, mais reste tout aussi engagée en faveur du partage et de l’entraide. Google croit profondément en l’open source, à sa valeur pour l’ensemble de la communauté des développeurs ainsi qu’à sa rentabilité. Nous cherchons tous à résoudre les mêmes problèmes. Au lieu de réinventer la roue, l’open source permet aux entreprises d’apporter de la valeur ajoutée à des produits existants.

Par exemple, l’une des tendances actuelles en matière d’open source est le développement de solutions de sécurité. Les problématiques évoluent depuis quelques années : il ne s’agit plus de protéger seulement votre système de production, mais toute votre chaîne d'approvisionnement logicielle. La culture du partage de l’univers de la conteneurisation open source est à double tranchant : en téléchargeant les conteneurs d’autrui, on peut s’exposer à des risques. Plusieurs initiatives open source s’attaquent à la question, notamment l’Open Software Security Foundation, ainsi que la communauté Sigstore, dont Google fait partie. Ainsi, nous avons mis au point Software Delivery Shield, solution de sécurité de la chaîne d'approvisionnement logicielle entièrement gérée de bout en bout.

Kubernetes, en l'occurrence, a été développé pour aborder le problème de la gestion d’un parc de serveurs à grande échelle. Un, deux ou trois serveurs sont relativement faciles à gérer. Lorsqu’il s’agit de dix serveurs, voire des milliers, que l’on doit installer et configurer, de préférence de manière automatisée, cela devient bien plus compliqué. Inspiré de Borg, le système de gestion de clusters interne de Google, Kubernetes a été développé et mis à la disposition de la communauté open source en 2015.

Extensibilité, portabilité et abstraction des complexités opérationnelles

Kubernetes peut être défini comme le “système d’exploitation du Cloud”, un framework permettant de développer, de gérer et de coordonner les applications conteneurisées dans le cadre d’une infrastructure et une structure cohérente. Kubernetes agit en tant que couche d’abstraction : sa compatibilité multi-architecture et multi-environnement permet de créer des clusters qui agissent comme un unique terminal. Plutôt que de déployer manuellement des répliques de l'application sur différents serveurs, l’on peut simplement demander à Kubernetes de créer un certain nombre de répliques de l'application, de manière manuelle ou automatisée. En tant que développeur, plus besoin de se demander où sont ses serveurs, quelle est leur configuration, comment ils sont gérés - c’est Kubernetes qui s’en charge.

Kubernetes est également extensible. Les utilisateurs peuvent ajouter ou personnaliser des fonctionnalités par le biais d’API, de contrôleurs et de ressources personnalisées. Il s’agit d’un système avant tout déclaratif : le développeur envisage l'état souhaité des applications et de l'infrastructure et envoie une commande sous la forme de fichier YAML, laissant Kubernetes se charger des détails d'implémentation. Par exemple, l’on peut dire, “Il faudrait exécuter 10 répliques de telle application, 10 fois par jour,” ou bien l’on peut étendre l'API de manière à pouvoir déclarer mon intention de créer une ressource, autrement dit un CRD, ou Custom Resource Definition. L’intérêt pour les développeurs réside dans le fait de pouvoir gérer toutes les dépendances de son application à travers un seul système. En regroupant toutes ces configurations dans un ou plusieurs fichiers YAML, la gestion de l'application devient plus simple. On parle dans ce cas de Kubernetes Resource Model, ou KRM.

Comment j'ai appris à ne plus m'en faire et à aimer Kubernetes

Kubernetes a la réputation d’être complexe. En réalité, cela dépend de ce que l’on cherche à faire. Si l’on souhaite simplement déployer des applications, ce sera relativement simple. Il existe de multiples solutions open source, telles que Helm, qui met à disposition des cartes de navigation (“Helm Charts”) permettant de définir, d’installer et de mettre à jour des applications Kubernetes.

Cependant, la complexité augmente lorsqu’il s’agit de cas d’utilisation plus avancés, tels que la gestion de clusters, ce qui nécessite une connaissance assez approfondie des paramètres et fonctionnalités de la plateforme. Certains gèrent leurs propres clusters en exploitant l'infrastructure des fournisseurs de cloud, tandis que d’autres optent pour les services entièrement managés. GKE Autopilot, propose une expérience simplifiée et automatisée de Google Kubernetes Engine (GKE), dont la configuration des nœuds, du scaling, et de la sécurité entre autres.

La communauté Kubernetes a commencé à développer des solutions pour faciliter l’utilisation de Kubernetes, tels que Knative, qui agit comme une couche d'abstraction. L’utilisation de WebAssembly (WASM) offre également des possibilités intéressantes en termes d’isolation et de portabilité des applications. WASM peut constituer un pas vers la fin du “vendor lock-in” en permettant de déployer des applications sur différentes plateformes sans trop dépendre d'un fournisseur spécifique.

Il existe de nombreuses ressources autour du sujet. Le Kubernetes Podcast from Google propose chaque semaine des actualités et des entretiens avec la communauté Kubernetes, tandis que la chaîne YouTube ContainerBytes aborde en détail GKE et la conteneurisation.

Le programme Google Cloud Innovators offre également aux développeurs l’opportunité de développer leurs compétences et de rentrer en contact avec d’autres professionnels et experts Google. Pour toute question, n’hésitez pas à nous contacter.

Tests de montée en charge sur Google Kubernetes Engine : ce qu’il faut savoir avant de se lancer

Wed, 02 Aug 2023 14:00:00 +0000

Le passage à l’échelle d’une application n’est pas toujours évident. Des systèmes qui se montrent prévisibles et fiables à petite échelle peuvent avoir un comportement chaotique et incontrôlable lorsqu’ils sont passés à l’échelle, mettant ainsi en évidence les limites de leur conception logicielle ou exhibant un fonctionnement avec des performances dégradées, voire pas de fonctionnement du tout.

Pour éviter ces désagréments, il est essentiel de pouvoir tester leur déploiement à grande échelle avant de les passer en production.

Pouvoir prédire les performances et la fiabilité d’une application lors de son passage à l’échelle demeure toutefois une opération complexe qui suppose une attention particulière. En général, la quantité de ressources informatiques attribuées à un système permet de prédire son fonctionnement lors du passage à l’échelle. Mais il arrive que d’autres facteurs doivent également être pris en compte, comme le nombre de connexions simultanées et le nombre de clients (tenants) ou encore les règles de sécurité à appliquer.

En outre, la façon d’effectuer les tests de montée en charge dépend de la nature même de l’application : nouveau produit, migration en provenance d’un autre fournisseur de cloud, redimensionnement d’un existant… En nous basant sur notre expérience des grands clusters Google Kubernetes Engine (GKE), nous partageons ici les meilleures pratiques ainsi que les conseils que nous donnons aux clients GKE lorsqu’ils cherchent à monter en charge sur leurs workloads.

Avantages des tests de montée en charge

Le principal avantage des tests de montée en charge est de permettre d’identifier les goulets d'étranglement et les optimisations à réaliser qui n’apparaissent pas forcément à une échelle inférieure, de sorte que l’application fonctionne bien et de façon fiable une fois passée à l’échelle.

Mais ces tests présentent également d’autres avantages :

Gagner en confiance. Si vous avez réussi à faire passer votre application au double de sa taille actuelle, vous devriez vous sentir tranquille à l'idée de la faire fonctionner à son échelle normale.
Anticiper les problèmes potentiels. Les tests peuvent vous inciter à améliorer vos procédures d'observabilité. Par exemple, de nombreux clients ne supervisent pas la latence de l'API GKE. Mais lorsqu'ils remarquent à quel point le suivi de la latence de l'API Kubernetes permet de détecter les premiers signes d’un problème sur le « Control Plane », ils décident de l'ajouter à Cloud Operations, la suite d'observabilité de Google Cloud.
Vérifier le coût d’exploitation de l’application passée à l’échelle. Typiquement, rapporté au nombre de sessions, d'utilisateurs ou de traitements exécutés, le coût d'exploitation d’une application passée à l’échelle peut être moins élevé, ce qui surprend parfois les clients.

Définir les objectifs des tests de montée en charge

Définir des objectifs pertinents pour ses tests de montée en charge est essentiel. Tester des hypothèses erronées peut coûter cher. De plus, aux coûts réels des tests, s’ajoute le risque de créer un faux sentiment de confiance dans le fonctionnement de l’application : Mal définir ses objectifs peut engendrer de graves incidents lors de la mise à l’échelle en production.

De façon générale, vos objectifs doivent être exprimés sous la forme d'une valeur orientée métier. Ils doivent aussi être mesurables. Exemples : doubler le nombre de tâches traitées simultanément, tripler le nombre de requêtes d'utilisateurs par seconde ou être en mesure de gérer une panne dans une région. Prenez cet objectif et affichez-le bien en vue sur votre tableau de bord des tests.

Vous devez également faire correspondre ces objectifs avec des quantités de ressources identifiées. Par exemple, si vous redimensionnez le système existant, la méthode la plus courante consiste à supposer une croissance linéaire de l'utilisation des ressources et à ajouter une marge de sécurité. Ainsi, si un système fonctionne de manière fiable avec 100 000 CPU et que vous souhaitez doubler les performances, vous pouvez passer à 250 000 CPU.
Ces hypothèses brutes effectuées pour redimensionner le système testé ne sont bien sûr qu’une estimation, mais elles permettent de se faire une idée de la marge de manœuvre dont on dispose avant d’atteindre les limites matérielles du système. Il faut bien entendu profiter des tests pour confirmer ces estimations.

Voici une liste de ressources à vérifier lors du passage à l’échelle :

Nombre de nœuds/Pods/containers
Nombre de services
Nombre de namespaces
Quantité de CPU/GPU/mémoire
Nombre de secrets/ConfigMaps/CRDs

Assurez-vous d’en provisionner suffisamment pour le passage à l’échelle.

De plus, vérifiez l’utilisation typique des ressources de Google Cloud, comme le nombre de VPC, leurs instances et alias, ou le nombre total de clusters ou de nodepools (pools de nœuds) dans le projet.

Les grands systèmes peuvent être très fiables tant que les choses sont stables. C'est souvent à l’occasion de changements que les choses commencent à mal tourner. Pour construire un scénario de test approprié, vérifiez les points de friction les plus courants pendant le test. On peut notamment citer la mise à niveau de clusters, les pannes de zone ou des préemptions importantes de PVM (Preempible Virtual Machine, des VM à bas coûts qui peuvent être interrompues à tout moment par le fournisseur Cloud). Assurez-vous que toutes les métriques et tous les logs sont correctement collectés pendant la procédure de test.

Quantifier le coût des tests de montée en charge

Les tests de montée en charge peuvent être très coûteux, c’est certain. Dans les cas extrêmes, ils peuvent coûter jusqu’à des centaines de milliers d’euros ! Nous sommes bien placés pour en parler : nous testons les versions de GKE chez Google Cloud avec parfois jusqu’à 20 configurations de tests différentes sur 15 000 nœuds, et ceci au moins deux fois par semaine. Nous vérifions également la montée en charge des versions open source de Kubernetes, en effectuant 5 000 tests de nœuds par jour.

Même si vous effectuez vos tests de montée en charge sur une configuration minimale, vous devez toujours optimiser vos coûts. Le moyen le plus simple d’y parvenir est d’effectuer des tests aussi courts que possible. Nos tests internes en sont un bon exemple : nous avons optimisé une procédure de test qui prenait 15 heures et l’avons ainsi réduit à moins de trois heures, tout en conservant le périmètre du test inchangé.

Voici quelques méthodes d’optimisation que vous pouvez utiliser :

Effectuez vos tests avec des ressources informatiques moins coûteuses. Si possible, exécutez vos tests sur des machines virtuelles Spot, qui sont jusqu'à 91 % moins chères que les instances ordinaires.
Simplifiez la couche de stockage. Tant que vous ne testez pas la couche de stockage elle-même, vous pouvez remplacer les cibles par défaut (Cloud Storage, LocalSSD) par des disques persistants standard (plus économiques).
Lorsque c’est possible, optimisez les workloads de test en restreignant les ressources mémoire et CPU des containers par rapport à ce que vous utiliserez en production.

Par ailleurs, lorsque vous estimez le coût de vos tests, n’oubliez pas d’inclure tous les postes de coûts (compute, réseau, stockage) en les estimant à leur valeur maximale attendue. Pour évaluer la durée du test, pensez à inclure le temps nécessaire pour une montée à l’échelle puis pour une réduction des capacités. D'après notre expérience, vous aurez besoin d'au moins deux ou trois tests complets pour atteindre votre objectif.

Enfin, sachez qu’il n’existe pas de recette miracle : vous devrez trouver le meilleur équilibre entre l’optimisation des coûts et l’obtention de résultats sur un système aussi proche que possible de l’environnement de production.

Préparation de l'infrastructure

Lorsque vous exécutez des tests de montée en charge de grande envergure, nous vous conseillons de le faire au sein d’un projet Google Cloud distinct, avec un compte dédié en termes de facturation. En procédant ainsi, vous pouvez gérer les quotas (ressources Google Cloud) de vos différents projets de manière indépendante. Autrement dit, vous pourrez attribuer un quota spécifique à votre projet de test en fonction des ressources que vous envisagez d’utiliser. Aidez-vous des bonnes pratiques listées dans la documentation GKE Plan for large workloads | Google Kubernetes Engine (GKE) afin d’ajuster au mieux vos quotas. Prenez le temps de bien configurer le réseau. Définissez l'adressage CIDR ou les équilibreurs de charge (Load Balancers) afin de monter à l’échelle dans différentes dimensions à commencer par les plus communes telles que le nombre de nœuds, de pods ou de services. Pour optimiser votre démarche, nous vous conseillons également de vous inspirer de la documentation GKE address management: Introduction and overview | Cloud Architecture Center.

Bien qu’il soit techniquement possible d’effectuer vos tests de montée en charge sans l’aide de l’équipe Google Cloud en charge de votre compte, nous vous conseillons néanmoins de l’impliquer dans votre démarche dès le début du projet. Ainsi, elle pourra vous aider à comprendre les limites de la plateforme et vous mettre en contact avec des experts sur le sujet. Vous pourrez même avoir accès aux meilleures pratiques et aux solutions provisoires de contournement d’un problème avant même qu’elles ne soient rendues publiques.

Nous vous conseillons également d’informer l’équipe Google chargée de la gestion des ressources et de l’inclure également à votre projet dès la phase de préparation. Certaines périodes de l'année se prêtent moins bien que d'autres à l'exécution de volumineux tests de montée en charge. Typiquement, nous vous déconseillons les périodes du Black Friday, Cyber Monday ou encore autour du réveillon du Nouvel An. De fait, le premier trimestre de l'année constitue le moment idéal pour préparer vos tests et le second trimestre pour les exécuter.

Une fois le calendrier des tests fixé, prévoyez un essai rapide quelques jours avant la réalisation du test en situation réelle : vous pourrez ainsi vérifier que tous les « tuyaux » sont correctement connectés. Dernière étape avant de vous lancer, assurez-vous d’avoir bien rédigé tous les scénarios de tests et prouvé qu’ils fonctionnent, d’avoir enregistré la configuration de vos tests dans des « repositories » et d’avoir prévu des tableaux de bord pour afficher les résultats de vos tests.

Exécution des tests

Chaque exécution de test est différente. Toutefois, on constate de nombreux points communs entre les tests réussis. Exécuter le test avec la bonne équipe est sans doute la règle la plus basique à respecter. Votre équipe peut être constituée de DevOps, d’architectes ou de développeurs. Certains de nos clients prévoient une journée dans l’agenda de leur équipe pour organiser une « war-room » (réunion de crise). Réunir tous les architectes et développeurs au même endroit peut aussi être une excellente idée pour trouver des solutions plus rapidement en cas de problème.

Attendez-vous à ce que certains composants du système testé soient instables pendant la phase d’exécution. L'objectif d'un programme de test est de collecter autant de données que possible afin d’identifier les comportements problématiques et les résoudre. Dans cette perspective, nous avons tendance chez Google Cloud à enregistrer tous les échanges et toutes les investigations menées pendant les phases de tests : combinés aux logs et métriques collectés, ces enregistrements peuvent être très utiles au débogage par la suite.

Le compte-rendu du test doit non seulement inclure des métriques techniques mais aussi une ventilation des coûts par ressource. Elle vous sera très utile pour estimer le coût du fonctionnement de votre application à grande échelle.

Ayant effectué de nombreux tests de montée en charge, nos ingénieurs sont des experts dans ce domaine. Malgré tout, ils détectent généralement plusieurs problèmes lors du premier essai et il est rare qu'un seul essai suffise pour atteindre les objectifs du test. En fonction de l'ampleur des ajustements nécessaires, vous devrez généralement procéder à une nouvelle exécution du test dans un délai d'environ un mois. Parfois, vous devrez procéder à une refonte plus approfondie ou exécuter une nouvelle série de tests. Mais n’oubliez pas que sans les tests, vous n'auriez jamais pu anticiper ces questions avant qu’elles ne deviennent un problème en production !

En résumé…

Le redéploiement vers le cloud vous donne l'occasion de reconsidérer les machines que vous utilisez pour vos workloads sous un angle nouveau et intéressant. Un des grands avantages du cloud est d’être piloté par le logiciel. Un logiciel qui devient dès lors la principale interface pour interagir avec le réseau, le stockage, les workloads et les systèmes sous-jacents qui les gèrent. Cette approche ouvre la voie à une infinité de façons d’intégrer, imaginer et utiliser le cloud.

Tester les modifications apportées à votre code fait partie intégrante de la culture moderne du cycle de vie du développement logiciel. Dès lors que l’on considère les systèmes cloud sous cet angle logiciel, il devient évident que chaque changement apporté au système se traduit par une évolution de l’environnement qui doit être traitée comme une nouvelle version. Ceci est vrai que ce changement est une nouvelle version de Kubernetes, un nouveau composant comme une base de données en mémoire, un système de cache ou encore une évolution de l’architecture telle qu’un passage d’un déploiement mono-cluster à un multi-clusters.

Bien que le coût des tests de montée en charge puisse être considérable, c'est souvent le moyen le plus efficace et le plus rapide pour préparer son système à fonctionner à plus grande échelle. Nous sommes convaincus que GKE est la meilleure plateforme pour exécuter des workloads conséquents et complexes. S’aligner sur les meilleures pratiques que nous avons nous-mêmes développées et expérimentées au fil des années en développant et testant Kubernetes et GKE peut simplifier votre démarche. Nous sommes ravis de partager notre expérience afin de vous aider à construire le système le plus avancé possible en vous appuyant sur notre plateforme. Suivez ce lien pour en savoir plus sur les meilleures pratiques dans le domaine de la scalabilité avec GKE, ou contactez le responsable technique de votre compte si vous souhaitez en parler davantage.

Comprendre la mise en réseau dans GKE

Fri, 14 Oct 2022 06:00:00 +0000

Principes de base de la mise en réseau

L’orchestrateur Kubernetes s’est imposé comme la plateforme open source de référence pour gérer les workloads et services containerisés. Créé à l’origine par Google, il trouve en GKE (Google Kubernetes Engine) une implémentation optimale afin de vous permettre d’exécuter Kubernetes et vos containers au sein de l’infrastructure Google Cloud dans un environnement entièrement managé.

GKE et Kubernetes reposent sur quelques piliers techniques communs qu’il est important de connaître. Le réseau est bien évidemment l’un d’eux. Nous vous proposons ici d’explorer les composantes réseau de GKE (Google Kubernetes Engine) et les différentes options disponibles.

L’adressage IP

Pour communiquer entre eux, les différents composants réseau de Kubernetes utilisent, comme on peut s’en douter, des adresses IP et des ports pour communiquer. Pour rappel, les adresses IP sont des adresses uniques qui identifient les différents composants du réseau.

Les composants clés :

Les containers - Il s'agit des plus petits composants d'exécution des processus applicatifs. Un ou plusieurs containers sont exécutés au sein d’un « pod ».
Les Pods – Les Pods regroupent « physiquement » une collection de containers. Les pods sont affectés à des nœuds.
Les Nœuds - Les nœuds sont des machines de travail (des serveurs) au sein d’un cluster Kubernetes (un cluster est donc une collection de nœuds). Un nœud exécute zéro ou plusieurs pods.

Les services clés :

ClusterIP - Ces adresses IP internes au cluster permettent d’exposer les services.
Load Balancer – Assure l’équilibrage des charges du trafic interne ou du trafic externe vers les nœuds du cluster.
Ingress – est un type spécial d'équilibreur de charge (load balancer) qui gère le trafic HTTP(S).

Les adresses IP sont attribuées aux composants et aux services à partir de différents sous-réseaux. Des masques de sous-réseau à longueur variable (VLSM) sont utilisés pour créer des blocs CIDR. Le nombre d'hôtes disponibles sur un sous-réseau dépend du masque de sous-réseau utilisé.

Remarque : la formule pour calculer le nombre d’hôtes disponibles dans Google Cloud est 2n- 4, et non 2n- 2 contrairement aux usages classiques des réseaux « on prem » (sur site).

Le flux d'attribution des adresses IP se présente comme suit :

1/ Les nœuds se voient attribuer des adresses IP à partir du réseau VPC du cluster.

2/ Par défaut, les adresses IP des Load Balancers internes sont automatiquement attribuées à partir du bloc IPv4 du nœud. Si nécessaire, vous pouvez créer une plage spécifique pour vos Load Balancers en utilisant l'option loadBalancerIP.

3/ Les pods se voient attribuer des adresses IP à partir de la plage assignée aux pods pour le nœud considéré. Par défaut, le nombre maximal de pods par nœud est de 110. Pour allouer une adresse à ce nombre, ce nombre est multiplié par 2 (110*2=220) et le sous-réseau le plus proche est utilisé, soit une place CIDR /24.
Ce mécanisme permet d'avoir un tampon pour la planification des pods. Il est important de se souvenir que si ce nombre maximal de pods par nœud est personnalisable au moment de la création, il ne peut être modifié une fois le cluster créé.

4/ Les containers partagent l'adresse IP des pods sur lesquels ils fonctionnent.

5/ Les adresses IP des services (Cluster IP) sont attribuées à partir d'un pool d'adresses réservé aux services.

Vous trouverez dans la bible technique « VPC-native clusters », au sein de la section dédiée aux plages d’adresses IP, un exemple de planification et de délimitation des plages d'adresses.

Le DNS (Système de nom de domaine)

Le DNS permet la résolution de noms en adresses IP. Des entrées de nom de domaine sont automatiquement créées dans le DNS pour les différents services. Il existe quelques options dans GKE pour contrôler le DNS.

kube-dns - Service complémentaire natif de Kubernetes, Kube-dns permet par défaut aux différents pods d'un cluster de résoudre les requêtes DNS. Le document "Using kube-dns'' décrit son fonctionnement.
Cloud DNS - Il s'agit du service DNS managé de Google Cloud. Il peut être utilisé pour gérer le DNS de votre cluster. Utiliser Cloud DNS en lieu et place de kube-dns présente quelques avantages. En effet, Cloud DNS :

Élimine (au moins en partie) la gestion d'un serveur DNS hébergé au sein du cluster.
Prend en charge la résolution locale DNS sur les nœuds GKE. Cela se fait par une mise en cache locale des réponses, ce qui offre à la fois vitesse et évolutivité.
S'intègre à la suite de surveillance Google Cloud Operations.

Service Directory est un autre service de Google Cloud qui peut être intégré à GKE et à Cloud DNS pour gérer les services via des espaces de noms (namespaces). Le repo github « gke-networking-recipes » contient quelques exemples de Service Directory que vous pouvez essayer pour les LoadBalancers internes, ClusterIP, Headless et NodePort.

Pour une meilleure compréhension des différentes options DNS dans GKE, veuillez consulter l'article DNS sur GKE : tout ce que vous devez savoir.

Les Load Balancers

Les Load Balancers (ou services d’équilibrage de charge) contrôlent l'accès et distribuent le trafic sur les ressources du cluster. Voici quelques options à connaître dans GKE :

Ingress

Les Ingress sont des objets Kubernetes qui gèrent l’accès externe aux services d’un cluster et le trafic HTTP(S) correspondant. Lorsqu'un tel objet (une telle ressource) est utilisé, il crée un Load Balancer HTTP(S) pour GKE. Lors de la configuration, vous pouvez attribuer une adresse IP statique à l'équilibreur de charge, afin de garantir que l'adresse reste la même.

Dans GKE, vous pouvez provisionner à la fois des Ingress externes et internes. Les liens vers les guides ci-dessous vous montrent comment les configurer :

GKE vous permet de tirer profit du load balancing natif des containers, qui dirige le trafic directement vers l'IP du pod à l'aide des groupes d'extrémité de réseau (NEG – Network Endpoint Group).

Le service de routage

Au niveau routage, trois concepts principaux doivent retenir votre attention :

Frontend - Votre service est exposé aux clients par le biais d'un « frontend » : ce dernier accepte le trafic en fonction de diverses règles. Il peut s'agir d'un nom DNS ou d'une adresse IP statique.
Load Balancing - Une fois que le trafic est autorisé, l'équilibreur de charge distribue les ressources disponibles pour répondre à la demande en fonction des règles.
Backend - Différents points de terminaison qui peuvent être utilisés dans GKE.

Opérations

Dans GKE, vous avez plusieurs façons de concevoir la mise en réseau de vos clusters :

Standard - Ce mode permet à l'administrateur de configurer l'infrastructure sous-jacente des clusters. Ce mode est avantageux si vous avez besoin d'un niveau de contrôle et de responsabilité plus approfondi.
AutoPilot (Pilote automatique) - GKE fournit et gère l'infrastructure sous-jacente du cluster. Pratique et préconfiguré pour s’adapter à tous les usages, ce mode vous offre néanmoins une certaine liberté de gestion.
Private Cluster (Cluster privé) - Ce mode n'autorise que les connexions IP internes. Si vous avez néanmoins besoin qu'un client ait accès à l'Internet (par exemple, pour des mises à jour), vous pouvez utiliser un Cloud NAT.
Private Service Access – Ce mode permet à votre VPC de communiquer avec les services des fournisseurs (de service) via des adresses IP privées. Le service Private Service Connect permet la consommation privée de services à travers les réseaux VPC (Virtual Private Cloud).

En résumé

Regroupés, tous ces éléments permettent de rapidement tracer un paysage de la gestion réseau sous GKE. Une vue de haut niveau qui peut se résumer ainsi :

Des adresses IP sont assignées aux différentes ressources de votre clusters : Nœuds, Pods, Containers et Services.
Ces plages d’adresses IP sont réservées aux différents types de ressources. Vous avez la possibilité d'ajuster la taille de la plage pour répondre à vos besoins en définissant un sous-réseau. Il est recommandé de restreindre les accès externes inutiles à votre cluster.
Par défaut, les pods ont la possibilité de communiquer à travers le cluster.
Pour exposer les applications fonctionnant sur les pods, vous avez besoin d'un service.
Des adresses IP de clusters (Cluster IPs) sont attribuées aux services.
Pour la résolution DNS, vous pouvez vous appuyer sur une option native telle que « kube-dns » ou utiliser Google Cloud DNS au sein de votre cluster GKE.
Les Load Balancers peuvent être utilisés en interne et en externe avec votre cluster pour exposer les applications et distribuer le trafic.
Ingress gère le trafic HTTP(S). Il utilise le service de load balancing HTTP(S) de Google Cloud. Ingress peut être utilisé pour des configurations internes et externes.

Pour en savoir plus sur la mise en réseau GKE, consultez les documents suivants :

Documentation : Stratégies de gestion des adresses IP lors de la migration vers GKE

Documentation : Bonnes pratiques pour la mise en réseau GKE

Blog : DNS sur GKE : tout ce que vous devez savoir

YouTube : Concepts de mise en réseau de GKE

Une question ? Besoin d’approfondir un sujet ? Envie de partager une idée ? N'hésitez pas à me contacter sur Linkedin ou Twitter (@ammettw).

Pourquoi automatisation et scalabilité sont les deux plus importantes caractéristiques de votre plateforme Kubernetes

Fri, 30 Sep 2022 08:00:00 +0000

Toujours plus exigeants, les consommateurs s’attendent aujourd’hui à des services instantanément réactifs au travers d’apps ultra-conviviales et d’interactions personnalisées. Peu importe la taille de l'entreprise, la complexité du problème ou la réglementation du secteur, à leurs yeux, l’expérience utilisateur doit primer sur tout le reste.

« Les technologies cloud-natives permettent aux entreprises de créer et d'exécuter des applications évolutives dans des environnements modernes et dynamiques tels que les clouds publics, privés et hybrides. Les containers, le maillage des services, les microservices, les infrastructures immuables et les API déclaratives illustrent cette approche. Toutes ces techniques permettent de mettre en place des systèmes à ‘couplage lâche’ qui sont à la fois résilients, gérables et observables. Associées à une automatisation robuste, elles permettent aux développeurs d'effectuer des changements à fort impact de manière fréquente et prévisible avec un minimum de labeur » (selon la Cloud Native Computing Foundation).

Le cloud moderne donne la priorité aux containers

Les containers se sont imposés comme l’un des meilleurs moyens de développer des applications Cloud modernes. Ils sont plus légers, plus rapides, plus portables et plus simples à gérer que les machines virtuelles. Les containers aident les développeurs à construire des systèmes plus simples à tester et plus sûrs. Parallèlement, ils permettent aux équipes d'exploitation de mieux isoler les workloads au sein de clusters plus économiques et efficients.

Alors que les besoins IT évoluent rapidement, portés par des demandes de consommateurs en perpétuelle évolution, créer et gérer des applications cloud modernes nécessitent bien plus qu’une plateforme de services managés. Le cloud moderne est devenu synonyme de containers et disposer d'une stratégie Kubernetes est désormais essentiel au succès des projets informatiques.

Kubernetes… pour les développeurs « next-gen »

Une plateforme managée de containers telle que Kubernetes peut encore étendre davantage les atouts des containers. On peut voir Kubernetes comme un moyen de créer des plateformes personnalisées qui appliquent les règles auxquelles votre entreprise adhère grâce à des contrôles sur la création de projets, les nœuds utilisés et les bibliothèques et repositories employés. Ces contrôles ne sont généralement pas gérés par les développeurs d'applications ; ils leur fournissent plutôt un cadre régi et sécurisé dans lequel ils peuvent opérer.

Kubernetes n'est pas seulement une technologie. Pour votre entreprise, c’est aussi un modèle pour créer de la valeur – et la faire croitre -, un moyen de développer des applications et des services fiables, et une façon de sécuriser et de développer des capacités informatiques cloud pour favoriser l'innovation.

L’open source simplifie les choses

Google a inventé Kubernetes et demeure le principal contributeur à ce projet devenu open source.
L'open source procure la liberté de fonctionner n’importe où, autrement dit sur l’infrastructure ou le cloud de votre choix.
En outre, l'écosystème qui entoure les projets open source comme Kubernetes vous permet de bénéficier de plugins et d'extensions standardisés pour créer une plateforme complète et conviviale adaptée à vos besoins et à vos développeurs.
Vous pouvez créer en interne des applications modernes au top grâce à l'open source puis les transférer de manière transparente et sécurisée vers Google Cloud lorsqu'elles sont prêtes à être déployées dans le cloud.

GKE montre la voie

Par nature, l'open source donne beaucoup de liberté. Les services managés basés sur les technologies open source offrent, quant à eux, les meilleures pratiques préintégrées pour déployer et exécuter ces logiciels open source. Créé par les mêmes développeurs qui ont conçu Kubernetes, Google Kubernetes Engine (GKE) offre ainsi le meilleur des deux approches.
GKE vous permet de profiter du Kubernetes le plus standard, exploité de manière experte par la société qui le connaît le mieux.
Autrement dit GKE vous permet de profiter pleinement des capacités d’innovation et de modernisation offertes par Kubernetes, sans risque que vous vous embourbiez dans les dépannages de problèmes d'infrastructure et dans la complexe gestion des opérations quotidiennes liées au déploiement de conteneurs à l'échelle de l'entreprise.
La recette du succès à long terme de Kubernetes repose sur deux piliers : une automatisation qui fait la différence et une scalabilité qui permet de faire des économies.

#1 - Une automatisation qui fait la différence

Les entreprises basées sur le cloud partagent une même prérogative : le changement… Elles veulent être capables de s’adapter rapidement aux conditions changeantes. Et cela s'applique également aux plateformes qu’elles utilisent ! La plateforme applicative doit être élastique et capable d'absorber les changements sans temps d'arrêt.
GKE offre une automatisation multidimensionnelle pour exploiter efficacement et facilement vos applications. Grâce au mode Autopilot entièrement managé, combiné aux multiples capacités de mise à l'échelle automatique, vous pouvez démarrer en quelques minutes avec un cluster sécurisé, prêt pour la production, tout en conservant un contrôle total sur les configurations et la maintenance.

Opérations du jour 2 - Avec GKE, vous avez la possibilité d'automatiser le provisionnement et les mises à niveau des nœuds ainsi que les mises à jour du plan de contrôle. Vous pouvez limiter ces automatisations à certains nœuds.
Ces fonctionnalités vous offrent la flexibilité d'automatiser votre infrastructure comme vous le souhaitez, de gagner du temps et d'alléger les exigences de maintenance. De plus, avec les canaux de diffusion de GKE, vous avez le pouvoir de décider non seulement quand, mais aussi comment et quoi mettre à niveau dans vos clusters et nœuds.

Une stack Cloud moderne - Vous pouvez installer des solutions de maillage de services (service mesh) et de gestion de la configuration (config management) en un seul clic, tout en nous confiant le provisionnement et l'exploitation de ces solutions.
Google Cloud provisionne, met à l'échelle, sécurise et met à jour à la fois les plans de contrôle et de données, vous offrant ainsi tous les avantages d'un maillage de services sans aucune charge opérationnelle. Vous pouvez laisser Google gérer les tâches de mise à niveau et de cycle de vie de votre cluster et de votre maillage de services. En outre, vous pouvez profiter de la télémétrie avancée, de la sécurité et des règles de réseau de couche 7 fournies par le maillage (mesh).

Optimisation des coûts - Pour optimiser vos ressources Kubernetes, appuyez-vous sur les différents mécanismes et sources de données mis à disposition : les insights d'optimisation des coûts de GKE, le redimensionnement optimal des workloads ou encore l'estimateur de coûts. Ces fonctions sont directement accessibles depuis la console Google Cloud.
Découvrez comment une startup en robotique a changé de cloud pour Google Cloud et réduit ses coûts d'exploitation de Kubernetes grâce à GKE Autopilot : moins de tâches de maintenance de nuit car les clusters sont mis à l'échelle et maintenus par Google Cloud, des dépenses réduites, des développeurs plus productifs car libérés de la gestion de Kubernetes, une expérience meilleure et plus sécurisée pour les clients, etc.

Solutions partenaires - Vous pouvez aisément intégrer et utiliser vos solutions DevOps et de sécurité préférées avec GKE Autopilot. Bien qu'il s'agisse d'une plateforme Kubernetes entièrement managée offrant une approche autonome des nœuds, GKE Autopilot conserve la prise en charge des « Node Agents » (Agents de nœuds) à l'aide de DaemonSets. Il devient ainsi possible de, par exemple, collecter des métriques au niveau du nœud sans avoir besoin d'exécuter un « sidecar » dans chaque Pod.

#2 - Des économies d’échelle

Qu’il s’agisse d’augmenter la voilure pour répondre à un soudain pic d’activité ou au contraire de la réduire pour limiter les dépenses, les applications cloud modernes n'ont jamais été aussi importantes.
Seul GKE peut exécuter des clusters de 15 000 nœuds ! C’est jusqu'à 10 fois la capacité proposée par les autres acteurs du cloud. De quoi vraiment exécuter vos applications de manière efficace et fiable à très grande échelle.
Des entreprises comme Kitabisa et IoTex ont déjà pu constater les avantages d’une exécution de leurs applications cloud modernes sur GKE, la plateforme Kubernetes la plus évolutive du marché.

"La valeur transformatrice de GKE est devenue évidente lorsque de graves inondations ont frappé Sumatra en novembre 2021, touchant 25 000 personnes. Notre système a facilement absorbé un pic de 30% des dons." – Kitabisa

"Nous sommes régulièrement confrontés à des pics massifs de montée en charge provenant d'endroits aléatoires de l'univers crypto. À l'avenir, la plateforme IoTeX sécurisera des milliards d'appareils connectés alimentant la blockchain de leurs instantanés de données. Avec GKE Autopilot et Cloud Load Balancing, nous pouvons facilement absorber n’importe quelle charge, quelle que soit l'ampleur ou la vitesse de notre croissance." - Larry Pang, responsable de l'écosystème, IoTeX

Vous voulez apprendre à intégrer GKE dans votre propre environnement de cloud computing ? Inscrivez-vous maintenant pour obtenir des conseils stratégiques et découvrir les meilleures pratiques pour alimenter la croissance de votre entreprise à l’aide d’applications cloud modernes...

Kubernetes : êtes-vous prêts à devenir une star de l’architecture ?

Thu, 26 May 2022 08:00:00 +0000

Kubernetes est devenu, dans bien des esprits, l’incontournable technologie pour mener à bien sa transformation à l’ère du cloud. Résultat, le concept du « cloud-natif » est devenu synonyme de « conteneurs natifs ». Kubernetes est une technologie éprouvée : outre les importantes contributions de la communauté open source, Google exécute des workloads conteneurisés depuis 15 ans. Inspiré de Borg, le système interne à Google de gestion des clusters, Kubernetes facilite tout ce qui est lié au déploiement et à la gestion des applications.

La plateforme spécialisée dans le recrutement de développeurs Honeypot.io a récemment publié un documentaire vidéo qui relate l’histoire de Kubernetes en s’appuyant sur les personnes qui ont contribué à sa naissance et à son essor. La vidéo raconte notamment comment les ingénieurs de Google ont commencé à travailler sur un orchestrateur de conteneurs qui sera plus tard connu sous le nom de Kubernetes. Force est de constater qu’un long chemin a été parcouru depuis que Google a basculé Kubernetes en open source, confiant sa gestion à la Cloud Native Computing Foundation (CNFC) pour le rendre vraiment accessible à tous.

Google croit profondément en l’open source. Cette conviction profonde a non seulement permis de donner naissance à Kubernetes mais s’est surtout construite plus globalement autour de deux idées. Premièrement, investir dans l’open source est rentable. Deuxièmement, il ne peut y avoir de leadership sans action, qu’il s’agisse de contribuer, conduire un changement positif ou encore de travailler avec les partenaires et les fondations. Et cette conviction profite à nos clients puisqu’ils bénéficient non seulement de notre leadership sur les technologies de « cloud ouvert » mais également de nos investissements dans les écosystèmes et communautés open source.

Kubernetes n'est pas seulement une technologie. C'est aussi un modèle de création de valeur pour votre entreprise, une façon de développer des applications et des services et un moyen pour sécuriser et favoriser l’innovation en développant des services « cloud-natifs ».

Google fournit l’une des meilleures infrastructures pour exécuter des projets critiques, cloud natifs et open source – ayant tous Kubernetes pour socle principal. Idéal pour retirer rapidement les bénéfices des projets d’innovation, le moteur Google Kubernetes Engine (GKE) évite aux entreprises de s’enliser dans la résolution de problèmes d'infrastructure et la gestion des opérations quotidiennes liées au déploiement de conteneurs.

En 2021, les conteneurs et Kubernetes ont enregistré une année record en termes d’adoption par les organisations du monde entier. Parallèlement, GKE (construit à partir de la version open source de Kubernetes) est devenu le service Kubernetes entièrement automatisé le plus évolutif et le plus rentable du marché. Seul GKE assure une gestion entièrement automatisée du cycle de vie des clusters, y compris les mises à niveau et la sauvegarde/restauration. Révolutionnaire, son nouveau mode « autopilot » applique automatiquement les meilleures pratiques du marché et peut éliminer toutes les opérations de gestion des nœuds. Nous sommes convaincus que la nouvelle fonctionnalité d’autoscaling de GKE, qui permet à nos clients d’exécuter des clusters de 15 000 nœuds, est plus performant que nos concurrents par un facteur 10. GKE est également l’une des meilleures solutions du marché en termes d’optimisation des coûts. Et parmi les autres fonctionnalités uniques de GKE, citons la journalisation et la surveillance pré-intégrées des clusters, des nœuds et des conteneurs à partir d’un seul et unique tableau de bord.

Les dernières évaluations et retours des analystes confirment la position d’expert de GKE sur le marché. Dans le Gartner Public Cloud Kubernetes Scorecard, le score global de GKE atteignait 92 sur 100, tandis que AWS EKS et Azure AKS obtenaient respectivement 87 et 82. De la même façon, dans la récente étude Forrester Wave™ Container Platforms Q1 2022, Google Cloud se classe loin devant la concurrence grâce à son leadership sur la gestion des conteneurs.

N'hésitez pas à vous inscrire à notre formation en ligne pour apprendre à construire, optimiser et sécuriser vos applications avec les dernières innovations apportées à Kubernetes.

Si vous souhaitez accélérer votre formation à Google Cloud, vous pouvez également vous inscrire ici afin de rejoindre les Google Cloud Innovators et entrer en contact avec d'autres membres de la communauté technique. Vous pourrez aussi accéder à des événements spéciaux, notamment des approfondissements techniques et des discussions en direct avec des dirigeants et des experts de Google.

Une nouvelle formation gratuite pour bien démarrer avec GKE !

Tue, 17 Aug 2021 16:00:00 +0000

L'adoption de Kubernetes continue de croître sans relâche dans toutes les industries. A l’automne dernier, 91 % des professionnels de l’IT et de la sécurité déclaraient déjà que leurs entreprises utilisaient Kubernetes pour l'orchestration de conteneurs. Désormais, les équipes techniques s’interrogent pour savoir comment tirer le meilleur parti de Kubernetes.

Pour de nombreuses entreprises, utiliser un service Kubernetes géré par un fournisseur de cloud s’avère plus pratique et aisé que de partir seul à l’aventure en s’appuyant sur une distribution open source.

Google Kubernetes Engine (GKE) facilite le déploiement de clusters en un clic tout en offrant un large éventail de services et d'outils complémentaires dans le cloud. Les formations en ligne et les documentations proposées sur Google Cloud fluidifient la prise en main et facilitent la transition pour entreprises engagées dans une modernisation de leurs applications. Malgré tout, la richesse de l’offre est telle qu’il peut parfois s’avérer difficile de savoir par où commencer.

Depuis le 22 juin, Google Cloud propose une formation gratuite d'une demi-journée, « Cloud OnBoard : Débuter avec Google Kubernetes Engine ». Cette formation se concentre sur tous les prérequis pour bien démarrer avec GKE. Elle s’articule autour de quatre thèmes principaux : « Introduction à la création d’applications avec Kubernetes » ; « Créer et configurer des clusters GKE » ; « Déployer à l’échelle dans Kubernetes » ; et, enfin, « Sécuriser GKE et votre accès à la plateforme Google Cloud Platform ».

Voici un bref aperçu des sujets que vous devez connaître pour apprendre à utiliser GKE ainsi que de ce que vous pouvez attendre de ces formations Cloud OnBoard.

Pourquoi Kubernetes ?

Le premier thème, « Introduction à la création d’applications avec Kubernetes », traite des avantages de Kubernetes. Elle explore les défis auxquels les entreprises sont confrontées lorsqu'elles modernisent leurs applications et lorsqu'elles adoptent des technologies et des architectures natives du cloud comme les microservices.

Comment créer des clusters de GKE ?

Dans la deuxième section, « Créer et configurer les clusters GKE », nous commençons par les bases en vous montrant comment faire tourner un cluster en utilisant l'interface de ligne de commande (CLI) gcloud et en explorant les fonctionnalités du Cloud SDK. Puis nous explorons les bases de la configuration et de la gestion d’un cluster.

Cette partie de la formation couvre également les différences entre le mode GKE Standard et le nouveau mode GKE Autopilot. Nous nous appuyons sur un exemple concret d'entreprise ayant choisi le mode GKE Autopilot pour ses besoins.

Exécution d'applications et de services dans GKE

Dans un troisième temps, avec « Déployer et appliquer Kubernetes à l’échelle », nous revenons sur les bases générales concernant la gestion des Workloads dans Kubernetes. Vous découvrirez à cette occasion tout ce qui est essentiel pour déployer vos applications et maîtriser leur montée en charge. Nous explorerons aussi les différents types de workloads et services Kubernetes, les capacités de mise à l’échelle automatique, et nous verrons comment créer vos premières applications et services à exécuter dans GKE.

Sécurité pour GKE

Après avoir appris les bases du pourquoi, du comment et de ce que vous allez utiliser pour exécuter vos workloads, le dernier thème de cette formation est tout aussi fondamental puisqu’il aborde la sécurité et les bonnes pratiques pour sécuriser GKE et accéder en toute sécurité aux services Google Cloud.

Travailler dans le cloud vous permet de bénéficier de nombreux outils pour vous aider à gérer votre entreprise de manière plus sécurisée. Mais cela signifie également qu'il y a beaucoup à apprendre sur ce que ces outils font exactement et comment ils contribuent aux architectures que vous allez construire avec GKE. Cette formation explore les principales fonctionnalités et les avantages de Google Cloud dans le domaine de la sécurité. Elle vous permettra d’optimiser la gestion de vos clusters GKE en toute sécurité. Vous pouvez consulter notre guide de « renforcement de la sécurité sous GKE » avant de regarder la démonstration proposée dans cette formation afin de mieux comprendre la sécurité GKE.

Prêt à faire vos premiers pas sous GKE ? Un seul clic vous sépare de votre séminaire à la demande gratuit : Cloud OnBoard: Getting Started with Google Kubernetes Engine.

Préparez l'avenir avec GKE

Wed, 02 Jun 2021 17:00:00 +0000

Comme l'a dit la poète américaine Maya Angelou : "Si vous ne savez pas d'où vous venez, vous ne savez pas où vous allez". Chez Google, nous sommes bien d'accord. Aujourd'hui, à l'occasion de l'événement Build with Google Kubernetes Engine, qui suit de près le lancement de GKE Autopilot, nous souhaitons revenir sur le parcours de GKE jusqu'à aujourd'hui.En seulement six ans, GKE est devenu l'un des services les plus prisés pour l'exécution d'applications cloud natives, aussi bien par les start-up que les entreprises du classement Fortune 500. L'enthousiasme qu'il suscite nous encourage à maximiser les capacités de Kubernetes afin que vous puissiez rester concentré sur la création de services de qualité pour vos utilisateurs, tandis que nous prenons soin de vos clusters Kubernetes.

Observons le parcours de Kubernetes jusqu'à aujourd'hui et voyons comment construire l'avenir ensemble.

Des innovations continues

Depuis la création de Kubernetes et sa mise à la disposition du public il y a plus de six ans, l'univers de l'orchestration des conteneurs a connu de nombreuses évolutions. Lorsque nous avons conçu la première version de Kubernetes, il n'existait aucune norme concernant la gestion de flottes d'applications conteneurisées à grande échelle. Aujourd'hui, cela n'est plus qu'un lointain souvenir. Nous avions déjà développé de nombreuses innovations techniques pour les conteneurs, comme un système d'exploitation optimisé. C'est donc tout naturellement que nous avons proposé une nouvelle approche de la gestion des conteneurs, basée sur l'expérience que nous avions acquise jusque-là (nous lancions des milliards de conteneurs chaque semaine pour nos propres besoins internes).

En 2015, nous avons participé à la création de la Cloud Native Computing Foundation (CNCF) afin d'héberger le projet Kubernetes sur une plate-forme neutre du point de vue du fournisseur. Depuis, une communauté diversifiée de développeurs du monde entier a contribué au projet et en a bénéficié. Rien que l'année dernière, des développeurs issus de plus de 500 entreprises ont apporté leur pierre à l'édifice Kubernetes. Et tous les principaux fournisseurs cloud nous ont emboîté le pas en offrant un service Kubernetes géré. Cette adoption massive par le secteur de la technologie nous permet de concrétiser notre vision : donner aux clients le choix d'exécuter leurs charges de travail où et quand ils le souhaitent, sans être liés à un ancien fournisseur cloud avec des API propriétaires.

Une communauté au cœur du projet

Depuis sa création en tant que projet interne de Google, nous n'avons jamais cessé d'investir dans Kubernetes. Avec l'appui de la CNCF, nous avons ajouté plus de 680 000 contributions au projet, dont plus de 123 000 en 2020. C'est plus que tous les autres fournisseurs cloud réunis. Lorsque l'on souhaite vraiment exploiter le potentiel de Kubernetes, rien ne surpasse l'expertise de Google, ni GKE.

En outre, nous soutenons activement la CNCF sous forme de crédits d'hébergement Kubernetes sur Google Cloud, qui représentent 100 millions de téléchargements de conteneurs chaque jour et plus de 400 000 tests d'intégration par mois, soit un total de plus de 300 000 heures de temps processeur sur GKE et Google Cloud. Vous avez bien lu : le projet Kubernetes lui-même repose sur GKE et Google Cloud.

Des résultats pour les clients

Le niveau d'excellence de notre service Kubernetes géré n'est pas une surprise, car nous en sommes les créateurs et n'avons jamais cessé d'investir dans le projet. Je pense que nous pouvons même affirmer sans hésiter qu'il s'agit du meilleur service disponible sur le marché.

Les entreprises se tournent en masse vers GKE pour résoudre leurs problèmes de rapidité, d'évolutivité, de sécurité et de disponibilité. Parmi celles du classement Fortune 500, 5 des 10 plus grandes entreprises de télécommunications, médias et jeux utilisent GKE. Elles sont même 6 sur 10 pour le secteur de la santé et des sciences de la vie, et 7 sur 10 pour le secteur de la vente au détail et des produits de grande consommation. Les grandes entreprises technologiques ont également adopté GKE. Par exemple, Databricks permet aux clients d'exploiter dans Google Cloud un service Databricks basé sur Google Kubernetes Engine.

Lorsqu'il s'agit de fournir des services à grande échelle, l'efficacité de GKE est inégalée. Après tout, Google assure le fonctionnement de nombreux services disponibles dans le monde entier tels que Gmail, Drive et YouTube. Nous sommes donc très compétents dans le domaine du déploiement de charges de travail de grande envergure. Nous seuls sommes capables d'appliquer cette expertise à Kubernetes. Par exemple, Bayer Crop Science a utilisé GKE pour faire évoluer ses charges de travail de recherche sans difficulté à plus de 200 reprises et avec 15 000 clusters de nœuds.

GKE propose des fonctionnalités de sécurité natives telles que la journalisation des règles de réseau, le bac à sable renforcé, l'analyse des failles, les nœuds protégés (basés sur la validation cryptographique) et les nœuds confidentiels. Elles sont conçues pour vous aider à adopter des stratégies de sécurité basées sur une défense en profondeur et à sécuriser vos opérations en toutes circonstances. Des clients comme Shopify font confiance à GKE pour les aider à gérer des services à très grande échelle sans aucune interruption. Lors des derniers Black Friday et Cyber Monday, Shopify a traité plus de 5 milliards de dollars de transactions.

GKE propose également une série de fonctionnalités innovantes telles que les canaux de publication, la compatibilité multicluster et l'autoscaling à quatre voies, ainsi que la réparation automatique des nœuds pour améliorer la disponibilité. En plus de ces fonctionnalités, GKE propose un bin packing et un autoscaling efficaces qui permettent d'optimiser les coûts. Par exemple, des clients comme OpenX ont réalisé jusqu'à 45 % d'économies grâce à GKE.

Un nouvel élan avec GKE Autopilot

Cela nous amène à GKE Autopilot, un nouveau mode de fonctionnement pour GKE qui permet de réduire les coûts opérationnels liés à la gestion des clusters, d'optimiser vos clusters pour la production et d'accroître la disponibilité de vos charges de travail. Depuis son lancement le mois dernier, des clients comme Strabag et Via Transportation indiquent avoir déjà constaté une amélioration spectaculaire des performances, de la sécurité et de la résilience de leurs environnements Kubernetes, tout en passant moins de temps à gérer leurs clusters.

En bref, nous avons tout fait pour fournir le service Kubernetes le plus configurable, sécurisé, évolutif et automatisé du marché, et ce n'est pas fini. Cela fait plus de cinq ans que nous investissons dans Kubernetes : vous pouvez donc faire confiance à GKE pour assurer votre réussite et votre développement, aujourd'hui et à l'avenir.

Vous souhaitez partager vos expériences avec GKE ? Participez au hackathon {Code_Love_Hack} Google Cloud pour nous montrer comment vous utilisez GKE, les conteneurs et Cloud Code. Les inscriptions sont ouvertes, et nous attendons avec impatience tous les projets que vous allez coder dans GKE !

Découvrez pourquoi utiliser Migrate for Anthos pour migrer des applis vers des conteneurs

Fri, 05 Feb 2021 11:00:00 +0000

Nous savons pour la plupart qu'il y a un vrai intérêt à moderniser les charges de travail, et de nombreux témoignages de clients satisfaits le prouvent. Mais bien que les avantages d'une migration vers Kubernetes aient été parfaitement documentés, beaucoup d'entreprises n'ont toujours pas pu franchir le pas.

Pour les organisations réticentes, la modernisation manuelle des charges de travail traditionnelles s'exécutant sur des VM en conteneurs représente un projet très complexe, à la fois coûteux et chronophage. Par exemple, certaines offres de refactorisation peuvent s'élever à 100 000 $, voire plus, pour une seule application de petite à moyenne envergure. Multipliez cela par 500 applications, et vous vous retrouvez avec un projet à 50 millions ! Sans parler du temps que cela pourrait prendre. Par ailleurs, certaines charges de travail (par exemple, celles provenant de tiers ou d'éditeurs de logiciels indépendants) ne permettent pas d'accéder au code source, ce qui empêche toute conteneurisation manuelle.

Résultat : de nombreuses entreprises sont bloquées dans la migration de leur centre de données, en particulier celles qui souhaitent aller au-delà de la migration Lift and Shift de leurs charges de travail importantes. Heureusement, il existe une alternative. En exploitant les technologies de conteneurisation automatisées et vous associant aux bons partenaires de solutions, vous pouvez réduire le temps et le coût d'un projet de modernisation jusqu'à 90 %, tout en bénéficiant de la plupart des avantages liés à une refactorisation manuelle.

Dans ce contexte, des outils comme Migrate for Anthos offrent un moyen particulièrement intelligent et efficace de moderniser les applications traditionnelles en passant des machines virtuelles aux conteneurs natifs. Notre approche unique basée sur l'automatisation consiste à extraire les éléments critiques de vos applications d'une VM, pour que vous puissiez les insérer de façon fluide dans des conteneurs hébergés sur Google Kubernetes Engine (GKE) sans les artefacts de VM (comme les couches de système d'exploitation invité) qui ne sont plus nécessaires avec les conteneurs.

Par exemple, Migrate for Anthos génère automatiquement une image de conteneur, un fichier Dockerfile pour les mises à jour de l'image et les révisions de l'application à J+2, des fichiers YAML de déploiement Kubernetes, et le cas échéant un volume de données persistant sur lequel les fichiers de données d'application et l'état persistant sont copiés. Cette extraction automatisée et intelligente est beaucoup plus rapide et plus simple qu'une modernisation manuelle de l'application, en particulier lorsque le code source ou des compétences approfondies en refonte d'applications ne sont pas disponibles. C'est pourquoi l'utilisation de Migrate for Anthos constitue l'une des approches les plus évolutives pour moderniser les applications avec l’'orchestration Kubernetes, la gestion des conteneurs basée sur les images et l'automatisation DevOps.

Un de nos clients, le journal britannique The Telegraph, s'est servi de Migrate for Anthos pour accélérer sa modernisation et éviter les blocages dont nous avons parlé ci-dessus. Voici à ce sujet le témoignage d'Andrew Gregory, Systems Engineer Manager, et d'Amit Lalani, Senior Systems Engineer :

"The Telegraph exploitait un ancien système de gestion de contenu (CMS) dans un autre cloud public sur plusieurs instances. Mettre à niveau le système actuel ou migrer le contenu vers le CMS de notre site Web principal était problématique, mais nous voulions quitter ce cloud public. Avec l'aide de nos partenaires chez Claranet et des ingénieurs de Google, nous avons mis en œuvre Migrate for Anthos, et obtenu des résultats de manière rapide et efficace. Cet ancien (mais très important) système est désormais hébergé en toute sécurité dans GKE et a rejoint ses équivalents plus modernes. Par ailleurs, nous enregistrons déjà d'importantes économies sur l'infrastructure et les coûts opérationnels quotidiens."

Comme pour The Telegraph, tout ce qui peut accélérer et favoriser la modernisation des charges de travail d'entreprise est d'une grande valeur commerciale pour nos clients. Migrate for Anthos accélère et simplifie la transition des VM vers GKE et Anthos en automatisant la conteneurisation et la "kubernétisation" des charges de travail. Tandis qu'une refactorisation manuelle prend généralement plusieurs semaines, voire plusieurs mois, Migrate for Anthos peut effectuer une conteneurisation en quelques jours, voire quelques heures. Et une fois cette conteneurisation mise en œuvre, vous en constatez immédiatement les avantages en termes d'efficacité de l'infrastructure, de productivité opérationnelle et d'expérience pour les développeurs.

Comme l'indique le rapport de Forrester New Technology Projection: The Total Economic Impact™ of Anthos (2019) :

"Lorsque vous êtes prêt à migrer des applications existantes vers le cloud, Migrate for Anthos simplifie et accélère ce processus. Cette organisation hybride devrait accélérer le processus de migration et de modernisation des applications de 58 % à 75 % en cas d'utilisation d'Anthos. Après avoir mis en conteneurs vos applications existantes, vous pouvez profiter d'Anthos GKE, à la fois sur site et dans le cloud, et gérer vos déploiements Kubernetes en toute cohérence."

Examinons de plus près certains avantages de la modernisation de vos charges de travail basées sur des VM en conteneurs s'exécutant sur Kubernetes à l'aide de Migrate for Anthos.

Efficacité de l'infrastructure

Des études Google internes ont montré que le passage de VM à des conteneurs sur Kubernetes pouvait générer entre 30 et 65 % d'économies sur vos coûts d'infrastructure actuels, par le biais de divers facteurs :

● Utilisation et densité plus élevées – Grâce à des fonctionnalités de bin-packing et de scaling automatiques, Kubernetes place les conteneurs de manière optimale dans les nœuds en fonction des ressources requises, tout en évoluant au rythme des besoins et sans affecter la disponibilité. De plus, contrairement aux VM, tous les conteneurs d'un même noyau partagent une copie du système d'exploitation. Ils n'ont pas besoin de leur propre image d'OS ni de leur propre processeur virtuel, ce qui réduit considérablement les exigences en mémoire et en processeur. Autrement dit, plus de charges de travail s'exécutent sur moins de ressources de calcul.

● Provisionnement raccourci – Cela signifie que vous payez moins pour exécuter les mêmes charges de travail, car elles sont prêtes plus tôt/plus facilement.

Productivité opérationnelle

Donner à votre équipe la possibilité de faire plus en moins de temps vous permet également de réaliser des économies d'environ 20 à 55 % grâce à une réduction globale des activités de gestion et d'administration informatiques. Par exemple :

● Gestion simplifiée du système d'exploitation – Dans Anthos, le nœud et son système d'exploitation sont gérés par le système. Vous n'avez donc pas besoin de gérer ni d'intégrer les correctifs et les mises à niveau de sécurité du noyau.

● Encapsulation de la configuration – L'exploitation d'une spécification déclarative (Infrastructure as Code) vous permet de simplifier et d'automatiser votre déploiement, et d'effectuer plus facilement les tâches de maintenance (restauration, mises à niveau, etc.). Tout ceci accélère le cycle de vie informatique et le rend plus agile.

● Temps d'arrêt réduit – Des fonctionnalités de Kubernetes comme l'autoréparation et la mise en échelle dynamique vous permettent de réduire les incidents et facilitent la gestion de l'état souhaité.

● Gestion unifiée – En migrant les anciennes charges de travail vers des conteneurs, les ingénieurs DevOps peuvent utiliser la même méthode pour gérer toutes leurs charges de travail, cloud natives ou "naturalisées" dans le cloud, ce qui accélère et facilite la gestion de votre paysage informatique hybride.

● Parité des environnements – Associée à une visibilité et une surveillance améliorées, cette fonctionnalité simplifie la détection et la résolution des problèmes.

Productivité des développeurs

Lorsque vous disposez d'un environnement informatique plus performant et plus agile, vous donnez à vos développeurs la possibilité de faire plus avec moins. Cette efficacité associée à une réduction de l'infrastructure engendre généralement des économies. Du côté des applications converties en conteneurs, les avantages sont multiples :

● Efficacité des couches – Vous pouvez utiliser des images et des couches Docker (extraites par Migrate for Anthos en même temps que les artefacts de conteneur).

● Rapidité des développeurs – Vous pouvez enfin appliquer le principe consistant à "écrire une fois et exécuter partout" et combiner des pipelines CI/CD automatisés avec des déploiements de test reproductibles à la demande, par le biais de modèles déclaratifs et de l'orchestration Kubernetes.

● Cycle de vie plus rapide – Accélérez la mise sur le marché des produits pour générer des revenus supplémentaires et bénéficier d'avantages concurrentiels, tout en réalisant des économies.

En résumé, la modernisation de vos machines virtuelles en conteneurs s'exécutant sur Kubernetes présente des avantages en termes d'infrastructure, d'opérations et de développement. Bien qu'une telle modernisation puisse sembler intimidante au premier abord, Migrate for Anthos contribue à rendre ce processus fluide et rapide. Vous pouvez en savoir plus en cliquant ici, regarder une courte vidéo sur l'utilisation de Migrate for Anthos avec des charges de travail Linux ou Windows, ou tester le produit par vous-même sur Qwiklabs.

Si vous souhaitez discuter avec un expert de l'utilisation de Migrate for Anthos, veuillez remplir ce formulaire, indiquez "Migrate for Anthos" dans le champ "Votre projet", et nous vous contacterons directement.

Moderniser des applications avec Migrate for Anthos : désormais compatible avec les opérations à J+2

Wed, 22 Apr 2020 14:22:00 +0000

Toutes les stratégies de modernisation d'applications ne se valent pas. Une approche simple consiste à enregistrer une machine virtuelle existante en tant que conteneur. Même si le conteneur résultant fonctionnera, il ne vous assurera pas les avantages des techniques de modernisation plus sophistiquées, en termes d'utilisation de ressources, mais aussi "d'opérations à J+2" avancées rendues possibles grâce à une plate-forme de gestion des conteneurs avancée comme Anthos GKE.

Aujourd'hui, nous avons annoncé plusieurs nouvelles mises à jour pour Anthos, notamment la dernière version de Migrate for Anthos. Notre solution de conteneurisation inclut désormais des capacités améliorées de conversion VM/conteneur qui peuvent vous aider à moderniser vos anciennes charges de travail dans Kubernetes et Anthos. Elle est également étroitement associée à Anthos Service Mesh, compatible avec Anthos sur site et capable de convertir les anciennes applications Windows Server en conteneurs.

Dépassez la migration Lift and Shift avec les images

Les versions antérieures de Migrate for Anthos suivaient une approche de conteneurisation Lift and Shift. Elles extrayaient les charges de travail des machines virtuelles (en omettant le noyau du système d'exploitation et les composants liés à la VM) et les convertissaient en conteneurs avec état. Elles ajoutaient également une couche d'exécution qui intégrait les charges de travail au stockage, à la mise en réseau et à la surveillance Kubernetes.

Dans cette nouvelle version, Migrate for Anthos dissèque le contenu d'une VM et génère une répartition suggérée de son contenu en composants de données et d'images. Ceux-ci peuvent être examinés et testés, et génèrent tous les artefacts requis pour une gestion des conteneurs basée sur les images : image Docker, fichier Dockerfile, fichiers YAML de déploiement et volume de données consolidé pouvant correspondre à n'importe quel type de stockage compatible avec Kubernetes. Le processus de modernisation même est orchestré de manière judicieuse grâce aux composants principaux (CRD, CLI) et aux mécanismes Kubernetes, comme décrit dans cette vidéo et ce schéma.

Cette approche basée sur les images permet d'exploiter les outils modernes de pipeline CI/CD pour concevoir, tester et déployer des applications, ainsi que de tirer profit de Kubernetes pour mettre en place de façon cohérente et efficace de nouvelles images sur l'ensemble de vos déploiements Kubernetes, notamment les clusters, les multiclusters et les différents clouds.

En plus de garantir une expérience moderne aux développeurs, la solution basée sur les images libère la puissance du plan de contrôle Kubernetes et de son API déclarative pour davantage d'efficacité opérationnelle. Par exemple, avec des composants d'application sans état par nature, vous pouvez appliquer l'équilibrage de charge, le scaling dynamique et les autoréparations sans avoir à réécrire l'application.

Cela signifie que Migrate for Anthos est désormais étroitement intégré à Anthos Service Mesh, ce qui apporte l'avantage d'une observabilité améliorée et de l'automatisation de la sécurité et de la gestion des stratégies réseau aux applications anciennes, toujours sans avoir à changer le code de l'application. La technologie de conteneurisation de Migrate for Anthos 1.3 est disponible pour Anthos sur Google Cloud. Cependant, pour les organisations qui souhaitent moderniser leurs charges de travail avec Anthos, mais qui ne sont pas encore prêtes à les transférer vers Google Cloud, Migrate for Anthos 1.3 comprend également un aperçu compatible avec Anthos GKE exécuté sur site.

L'un de nos partenaires, Arctiq, utilise activement Migrate for Anthos et explique que cela l’aide à transformer les opérations de ses clients :

"Migrate for Anthos est un outil unique et puissant pour transformer vos machines virtuelles existantes en conteneurs modernes compatibles avec Google Kubernetes Engine", explique Kyle Bassett, partenaire chez Arctiq. "En général, la conversion de ces VM en conteneurs est compliquée et demande une connaissance approfondie de Kubernetes. C'est pourquoi la plupart des clients ne touchaient pas à leurs VM. Mais avec Migrate for Anthos, vous pouvez extraire les charges de travail des VM et les exécuter sur des conteneurs grâce à un flux de travail fiable et plus automatisé. Grâce à Migrate for Anthos, Arctiq peut aider ses clients à augmenter les performances de leurs charges de travail, tout en réduisant leurs coûts d'infrastructure et de gestion."

Conteneurisation automatisée des serveurs Windows

Plus tôt cette année, nous avons annoncé qu'il était désormais possible d'exécuter des conteneurs Windows Server sur GKE. Cependant, comme il s'agit d'une technologie encore récente, il existe peu de conteneurs natifs Windows pour le moment, et la conteneurisation manuelle d'une application Windows peut être une tâche difficile.

Avec Migrate for Anthos, vous pouvez désormais convertir les anciennes applications Windows Server en conteneurs Windows Server 2019 et les exécuter dans GKE sur Google Cloud. Cela comprend Windows 2008 R2, qui a récemment atteint la date de fin d'assistance de Microsoft. Cette fonctionnalité est disponible en version d'essai et comprend des outils d'évaluation et de découverte entièrement automatisés.

Elle permet de convertir automatiquement des applications basées sur IIS ASP.NET qui fonctionnent sur les VM Google Compute Engine, afin de réduire les coûts d'infrastructure et de licences. Pour les applications IIS et ASP.NET qui fonctionnent sur site ou sur d'autres clouds, vous pouvez d'abord utiliser Migrate for Compute Engine pour les transférer vers des VM Compute Engine, puis utiliser Migrate for Anthos pour les convertir en conteneurs. La compatibilité avec les autres applications sera bientôt disponible.

Une autre alternative est de migrer uniquement des parties d'une pile applicative vers des conteneurs Windows. De cette manière, les éléments qui ne peuvent pas être facilement migrés vers des conteneurs peuvent être exécutés dans des VM Compute Engine et profiter quand même de l'intégration réseau au niveau du VPC avec des conteneurs sur GKE.

Accélérez votre modernisation

Presque tous les clients nous disent qu'ils souhaitent utiliser davantage de conteneurs. Migrate for Anthos peut vous aider à accélérer ce processus en réduisant le temps et les efforts requis avec d'autres processus. Pour participer à ces tests Migrate for Anthos en cours ou à venir, veuillez remplir ce formulaire et indiquer "Migrate for Anthos" dans le champ "Votre projet".

Conteneurs et Kubernetes

Ingénierie de plateforme : tirez parti de l’expérience Google

Faire les bons choix en matière d’ingénierie de plateforme

Planification des workloads GKE : stratégies pour gérer les ressources sous contraintes

Les briques de base de GKE

Scénarios de planification des workloads sous contraintes

Conclusion et pour aller plus loin

Pourquoi il ne faut plus avoir peur de Kubernetes

Kubernetes et la communauté open source

Extensibilité, portabilité et abstraction des complexités opérationnelles

Comment j'ai appris à ne plus m'en faire et à aimer Kubernetes

Tests de montée en charge sur Google Kubernetes Engine : ce qu’il faut savoir avant de se lancer

Avantages des tests de montée en charge

Définir les objectifs des tests de montée en charge

Quantifier le coût des tests de montée en charge

Préparation de l'infrastructure

Exécution des tests

En résumé…

Comprendre la mise en réseau dans GKE

Principes de base de la mise en réseau

L’adressage IP

Les composants clés :

Les services clés :

Le DNS (Système de nom de domaine)

Les Load Balancers

Ingress

Le service de routage

Opérations

En résumé

Pourquoi automatisation et scalabilité sont les deux plus importantes caractéristiques de votre plateforme Kubernetes

Le cloud moderne donne la priorité aux containers

Kubernetes… pour les développeurs « next-gen »

L’open source simplifie les choses

GKE montre la voie

#1 - Une automatisation qui fait la différence

#2 - Des économies d’échelle

Kubernetes : êtes-vous prêts à devenir une star de l’architecture ?

Une nouvelle formation gratuite pour bien démarrer avec GKE !

Pourquoi Kubernetes ?

Comment créer des clusters de GKE ?

Exécution d'applications et de services dans GKE

Sécurité pour GKE

Découvrez pourquoi utiliser Migrate for Anthos pour migrer des applis vers des conteneurs

Préparez l'avenir avec GKE

Des innovations continues

Une communauté au cœur du projet

Des résultats pour les clients

Un nouvel élan avec GKE Autopilot

Découvrez comment tirer parti d’Anthos dans vos projets informatiques

Découvrez pourquoi utiliser Migrate for Anthos pour migrer des applis vers des conteneurs

Efficacité de l'infrastructure

Productivité opérationnelle

Productivité des développeurs

Moderniser des applications avec Migrate for Anthos : désormais compatible avec les opérations à J+2

Dépassez la migration Lift and Shift avec les images

Conteneurisation automatisée des serveurs Windows

Accélérez votre modernisation

Anthos : optimiser l'agilité et l'efficacité des entreprises