Préparer un environnement Google Kubernetes Engine pour la production

Ce document explique comment intégrer vos charges de travail conteneurisées à Google Kubernetes Engine (GKE) de manière plus sécurisée, plus fiable et plus économique. Elle décrit comment configurer l'accès administratif et l'accès réseau aux clusters. Dans cet article, nous partons du principe que vous savez comment fonctionne l'administration des ressources et des clusters Kubernetes, et que vous disposez de connaissances de base sur les fonctionnalités de mise en réseau de Google Cloud.

Exemple d'architecture

Le schéma suivant présente un exemple de structure flexible et à disponibilité élevée pour le déploiement d'un cluster GKE.

Structure des projets, réseaux et clusters

Projets

Google Cloud crée toutes ses ressources au sein d'une entité de projet.

Vous pouvez utiliser des projets pour représenter vos différents environnements d'exploitation. Vous pouvez par exemple disposer de projets de production et de préproduction (production et staging) pour les équipes chargées des opérations, ainsi que d'un projet de test (development) pour les développeurs. Vous pouvez appliquer des stratégies plus strictes et plus précises aux projets qui contiennent vos données et vos charges de travail les plus critiques et sensibles. Vous pouvez ensuite appliquer des stratégies plus permissives et plus flexibles pour les développeurs de l'environnement development.

Clusters

Un projet peut contenir plusieurs clusters. Si vous devez déployer plusieurs charges de travail, vous pouvez choisir de n'utiliser qu'un cluster partagé ou plusieurs clusters distincts.

Réseaux et sous-réseaux

Les projets peuvent comporter un ou plusieurs réseaux VPC, qui sont des versions virtuelles des réseaux physiques. Chaque réseau VPC est une ressource globale qui contient d'autres ressources liées à la mise en réseau, telles que des sous-réseaux, des adresses IP externes, des règles de pare-feu, des routes, votre VPN ainsi que Cloud Router. Vous pouvez exploiter des sous-réseaux (qui sont des ressources régionales) au sein d'un réseau VPC afin d'isoler et de contrôler le trafic entrant ou sortant de chaque région située entre vos clusters GKE.

Chaque projet ne contient qu'un réseau par défaut. Vous pouvez créer et configurer un réseau supplémentaire à mapper à votre convention de gestion des adresses IP. Vous pouvez ensuite appliquer des règles de pare-feu à ce réseau pour filtrer le trafic à destination et en provenance de vos nœuds GKE. Par défaut, l'ensemble du trafic externe vers vos nœuds GKE est refusé.

Pour contrôler les communications entre les sous-réseaux, vous devez créer des règles de pare-feu permettant au trafic de circuler entre eux. Spécifiez l'option --tags lors de la création d'un cluster ou d'un pool de nœuds pour ajouter les tags adaptés à vos nœuds GKE afin d'activer les règles de pare-feu. Vous pouvez également recourir à des tags pour créer des routes entre vos sous-réseaux, si nécessaire.

Clusters zonaux et régionaux

Vous pouvez créer des clusters standards et Autopilot. Les clusters Autopilot sont des clusters régionaux. Les clusters standards sont des clusters régionaux ou zonaux. Les clusters zonaux peuvent être à zone unique ou multizones. Les clusters multizones et régionaux répartissent les ressources sur plusieurs zones d'une région, ce qui peut améliorer la disponibilité et la résilience de vos clusters.

Les clusters zonaux possèdent les propriétés suivantes:

  • Créer une seule instance dupliquée du plan de contrôle qui s'exécute dans une seule zone.
  • S'ils sont multizones, exécuter des nœuds dans plusieurs zones.

Les clusters régionaux présentent les propriétés suivantes:

  • Répliquer les plans de contrôle sur trois zones.
  • Exécuter des nœuds dans plusieurs zones ou dans une seule zone en fonction des emplacements de nœuds configurés.

Vous pouvez choisir de créer des clusters zonaux ou régionaux au moment de la création du cluster. Vous avez également la possibilité d'ajouter des zones à un cluster existant pour le rendre zonal. Cependant, vous ne pouvez pas modifier un cluster zonal existant pour le rendre régional et vous ne pouvez pas modifier un cluster régional pour le rendre zonal.

La disponibilité du service des nœuds de vos clusters gérés par GKE est couverte par le contrat de niveau de service de Compute Engine.

Pour en savoir plus sur les clusters zonaux et régionaux, consultez la documentation GKE.

Gérer l'authentification et l'accès

Groupes et rôles IAM (Identity and Access Management)

En plus d'accorder des rôles IAM à des utilisateurs individuels, vous pouvez également créer des groupes pour simplifier l'attribution des rôles.

Le schéma suivant de la structure d'une stratégie IAM illustre le principe du moindre privilège avec deux projets : dev, configuré pour permettre aux développeurs de créer et de tester leurs nouvelles fonctionnalités et corrections de bugs, et prod pour le trafic de production :

Cloud Identity and Access Management

Comme le montre le tableau suivant, l'organisation possède quatre groupes d'utilisateurs détenant différents niveaux d'autorisation, accordés via des rôles IAM sur les deux projets :

Équipe Rôle IAM Projet Autorisations
Développeurs roles/container.developer dev Permet de créer des ressources Kubernetes pour les clusters existants du projet. Ne permet pas de créer ni de supprimer des clusters.
Opérations roles/container.admin prod Offre un accès administratif complet aux clusters et aux ressources Kubernetes qui s'exécutent au sein du projet.
Sécurité roles/container.viewer
roles/compute.securityAdmin
prod Permet de créer, de modifier et de supprimer des règles de pare-feu et des certificats SSL. Permet également d'afficher les ressources créées dans chaque cluster, y compris les journaux des pods en cours d'exécution.
Réseau roles/compute.networkAdmin prod Permet de créer, de modifier et de supprimer des ressources réseau, à l'exception des règles de pare-feu et des certificats SSL.

En plus des trois équipes pouvant accéder au projet prod, un compte de service supplémentaire se voit attribuer le rôle container.developer pour prod, ce qui lui permet de créer, de répertorier et de supprimer des ressources au sein du cluster. Grâce aux comptes de service, vous pouvez donner aux scripts d'automatisation ou aux frameworks de déploiement la possibilité d'agir en votre nom. Les déploiements sur votre projet de production et sur vos clusters doivent passer par un pipeline automatisé.

Dans le projet dev, plusieurs développeurs travaillent sur la même application au sein du même cluster. Cette opération est facilitée par les espaces de noms que l'utilisateur du cluster peut créer. Chaque développeur peut générer des ressources au sein de son propre espace de noms, évitant ainsi tout conflit au niveau des noms. Les développeurs peuvent également réutiliser les mêmes fichiers de configuration YAML pour leurs déploiements, ce qui permet à leurs configurations de rester aussi proches que possible au cours des itérations de développement.

De plus, les espaces de noms peuvent servir à créer des quotas relatifs à l'utilisation du processeur, de la mémoire et du stockage au sein du cluster. Cela permet de garantir qu'un développeur n'utilisera pas trop de ressources dans le cluster. Pour en savoir plus sur l'utilisation des espaces de noms, consultez la page Bonnes pratiques Kubernetes: Spécifier des espaces de noms en YAML.

La section suivante décrit comment restreindre des utilisateurs à certains espaces de noms.

Contrôle des accès basé sur les rôles

Les clusters GKE exécutant Kubernetes 1.6 et versions ultérieures peuvent bénéficier de restrictions supplémentaires sur ce que les utilisateurs sont autorisés à faire dans des clusters individuels. IAM peut fournir aux utilisateurs un accès à des clusters complets ainsi qu'aux ressources qu'ils contiennent, mais le contrôle des accès basé sur les rôles (RBAC) de Kubernetes vous permet de limiter davantage les actions qu'ils peuvent entreprendre dans leurs clusters à l'aide de l'API Kubernetes.

Grâce au contrôle RBAC, les administrateurs de cluster appliquent des stratégies précises à des espaces de noms individuels au sein de leurs clusters ou au cluster dans son ensemble. L'outil kubectl de Kubernetes utilise les identifiants actifs de l'outil gcloud, ce qui permet aux administrateurs de cluster de mapper des rôles aux identités Google Cloud (utilisateurs, comptes de service et Google Groupes) en tant que sujets de RoleBindings.

Google Groupes pour RBAC vous permet d'utiliser des groupes avec Kubernetes RBAC. Pour utiliser cette fonctionnalité, vous devez configurer des groupes Google dans Google Workspace, créer un cluster sur lequel cette fonctionnalité est activée, puis utiliser des RoleBindings pour associer vos groupes aux rôles auxquels vous souhaitez les lier. Pour en savoir plus, consultez la page Contrôle des accès basé sur les rôles.

Par exemple, dans la figure suivante, les deux utilisateurs user-a et user-b ont reçu les rôles config-reader et pod-reader sur l'espace de noms app-a.

Autorisation RBAC

Certains rôles IAM au niveau du projet Google Cloud peuvent également permettre à des utilisateurs spécifiques d'accéder à tous les clusters d'un projet. De plus, des liaisons de rôle individuelles au niveau des espaces de noms et des clusters sont ajoutées via le contrôle RBAC. Cela accorde un accès précis aux ressources situées dans des clusters ou des espaces de noms donnés.

Liaisons de rôles IAM

Kubernetes inclut certains rôles par défaut, mais en tant qu'administrateur de cluster, vous pouvez créer un rôle personnalisé qui se rapproche davantage des besoins de votre organisation. L'exemple de rôle suivant permet aux utilisateurs d'afficher, de modifier et de mettre à jour des ConfigMaps, mais pas de les supprimer, car le verbe delete n'est pas inclus :

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Une fois vos rôles définis, vous pouvez les appliquer au cluster ou à l'espace de noms via des liaisons. Les liaisons associent des rôles à des utilisateurs, groupes ou comptes de service. L'exemple suivant montre comment lier un rôle précédemment créé (config-editor) à l'utilisateur bob@example.org et à l'espace de noms development.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

Pour en savoir plus sur le contrôle des accès basé sur les rôles, consultez la documentation GKE.

Accès aux images et partage

Les images de Container Registry ou Artifact Registry sont stockées dans Cloud Storage.

Cette section décrit les méthodes suivantes pour partager des images:

  • Rendre les images publiques.
  • Partager des images entre projets.

Il est important d'utiliser Artifact Registry si vous activez des clusters privés. Dans les clusters privés, l'environnement d'exécution du conteneur de votre cluster ne peut pas extraire directement les images de conteneur à partir d'un registre de conteneurs externe, sauf si vous configurez un Cloud NAT. L'environnement d'exécution du conteneur peut extraire des images d'Artifact Registry dans un cluster privé, sans Cloud NAT ou accès privé à Google. Vous devez placer les nœuds dans un sous-réseau sur lequel l'accès privé à Google est activé si les nœuds doivent communiquer directement avec Artifact Registry (par exemple, les nœuds doivent créer des artefacts et les stocker dans Artifact Registry). Pour en savoir plus, consultez la page Extraire des images de conteneurs d'un registre d'images.

Rendre des images publiques dans Artifact Registry

Pour rendre des images publiques, vous pouvez rendre leurs objets et leurs buckets publics dans Artifact Registry. Pour en savoir plus, consultez la documentation relative au contrôle des accès dans Artifact Registry.

Si vous devez utiliser des images publiques, veillez à ce que l'ensemble des images publiques autorisées puisse être déployé dans vos clusters. (Pour plus d'informations, consultez la section sur l'autorisation binaire).

Accéder aux images dans Artifact Registry entre plusieurs projets

Pour partager des images de conteneur entre plusieurs projets, vous devez vous assurer que vos nœuds Kubernetes utilisent un compte de service. Vous pouvez accorder l'accès au compte de service en tant que storage.viewer sur les projets pour lesquels vous souhaitez utiliser Artifact Registry. Utilisez toutefois un compte de service personnalisé disposant d'autorisations restreintes, car le compte de service par défaut détient un accès d'éditeur sur l'ensemble du projet.

Si vous souhaitez utiliser un autre compte de service, spécifiez son nom lors de la création du cluster ou du pool de nœuds à l'aide de l'option --service- account.

Pour en savoir plus, consultez la section Configurer le contrôle des accès.

Déterminer la stratégie d'extraction d'images appropriée

La propriété imagePullPolicy de Kubernetes détermine si le kubelet tente d'extraire une image lors du démarrage d'un pod. Configurez un paramètre imagePullPolicy approprié pour spécifier vos images de conteneurs. Par exemple, vous pouvez spécifier la stratégie d'extraction d'image suivante :

imagePullPolicy: IfNotPresent

Dans ce cas, le kubelet ne récupère une copie de l'image que si celle-ci n'est pas disponible dans le cache du nœud.

Pour plus d'informations sur les stratégies d'extraction d'images possibles que vous pouvez spécifier, consultez la page Images de conteneurs dans la documentation de Kubernetes.

Utiliser des contrôleurs d'admission dynamiques pour l'application des stratégies

Les contrôleurs d'admission dynamiques font partie du plan de contrôle de Kubernetes. Ils peuvent intercepter les requêtes entrantes adressées au serveur d'API. Les contrôleurs d'admission constituent un outil puissant pouvant vous aider à appliquer des stratégies personnalisées spécifiques à l'entreprise dans vos clusters GKE.

Kubernetes est compatible avec deux types de contrôleurs d'admission : les contrôleurs d'admission de mutation et les contrôleurs d'admission de validation.

Les contrôleurs d'admission de mutation interceptent les requêtes d'admission et peuvent muter (modifier) une requête. La requête est ensuite transmise au serveur d'API.

Les contrôleurs d'admission de validation examinent une requête et déterminent si elle est valide conformément aux règles que vous spécifiez. Si des contrôleurs d'admission de validation sont configurés dans le cluster, ils sont appelés une fois que la requête a été validée par le serveur d'API. Les contrôleurs d'admission de validation peuvent rejeter les requêtes afin d'assurer la conformité avec les stratégies définies dans le contrôleur.

Par exemple, vous pouvez appliquer une stratégie d'extraction d'images en utilisant un contrôleur d'admission de mutation pour vous assurer que la stratégie est définie sur Always, quel que soit le paramètre imagePullPolicy spécifié par les développeurs qui ont envoyé des requêtes de création de pod.

Utiliser des applications préinstallées à partir de Google Cloud Marketplace

Vous pouvez également envisager de déployer des applications Kubernetes préinstallées à partir de Google Cloud Marketplace. Les applications Kubernetes répertoriées sur Google Cloud Marketplace sont testées et validées par Google. Par exemple, elles font l'objet d'analyses des failles et de contrats partenaires pour la maintenance et l'assistance.

Utiliser Workload Identity pour interagir avec les API de service Google Cloud

Souvent, les architectures d'entreprise impliquent des composants architecturaux couvrant des services cloud, tels que des services gérés et hébergés dans le cloud. Il s'agit d'un modèle courant pour que vos applications ou services GKE doivent communiquer avec les services gérés de Google Cloud tels que Cloud Storage et BigQuery. Par exemple, vous devrez peut-être stocker des enregistrements client après leur traitement via tâches par lots dans GKE vers BigQuery pour une analyse ultérieure.

Workload Identity permet à un compte de service Kubernetes de votre cluster GKE d'agir en tant que compte de service IAM. Les pods qui utilisent le compte de service Kubernetes configuré s'authentifient automatiquement en tant que compte de service IAM lorsqu'ils accèdent aux API Google Cloud. Notez que cela suppose que vous avez accordé le niveau d'accès requis au service au compte de service Google Cloud.

Gérer la sécurité d'un cluster

La sécurité est une discipline multiforme d'une importance capitale dans les déploiements de clusters GKE au sein des entreprises. Cette section décrit plusieurs facteurs qui peuvent servir à renforcer la sécurité de votre cluster.

Analyse des images à la recherche de vulnérabilités

Artifact Registry peut analyser les images pour détecter des failles de sécurité connues. Les images compatibles incluent Ubuntu, Debian, RedHat et d'autres (consultez la page Sources des failles pour obtenir la liste complète). Nous vous recommandons d'analyser les images que vous prévoyez d'utiliser dans vos clusters GKE.

Si possible, activez Container Analysis afin de réduire davantage les risques de sécurité.

Pour afficher les failles d'une image, consultez la section Analyser automatiquement les images.

Votre organisation peut bénéficier de l'automatisation du suivi et de la réception des notifications lorsque des modifications sont apportées au dépôt Artifact Registry. Par exemple, vous pouvez recevoir une notification lorsqu'une image est créée ou supprimée. Vous pouvez créer un pipeline dans lequel les écouteurs d'applications sont abonnés à un sujet Pub/Sub sur lequel les événements Artifact Registry sont publiés. Vous pouvez ensuite vous servir de ces événements pour déclencher des builds ou des déploiements automatisés. Pour en savoir plus, consultez la documentation Artifact Registry.

Autorisation binaire

Avec Kubernetes, vous devez déterminer si et quand une image doit être considérée comme valide pour un déploiement dans votre cluster. Pour cette tâche, vous pouvez utiliser l'autorisation binaire. Cette structure de déploiement vous permet de définir un workflow qui applique les signatures (attestations) dont une image a besoin pour pouvoir être déployée sur votre cluster.

Le workflow est défini sous forme de stratégies. Lorsque vous déplacez le code et, par conséquent, votre image de conteneur via un pipeline CI/CD, l'autorisation binaire enregistre des attestations pour chacune de ces étapes, comme défini dans votre stratégie d'autorisation binaire. Ces attestations confirment qu'une image a correctement passé les étapes définies.

L'autorisation binaire s'intègre à l'API de déploiement GKE et permet de garantir que le déploiement d'une image est soumis à l'obtention de toutes les attestations requises. Les tentatives de déploiement ayant échoué sont automatiquement consignées. Les administrateurs du cluster peuvent les examiner et les auditer.

Pour obtenir un tutoriel sur la mise en œuvre de l'autorisation binaire pour GKE avec Cloud Build, consultez la page Mettre en œuvre l'autorisation binaire avec Cloud Build et GKE.

Sécuriser l'accès avec gVisor dans GKE Sandbox

Un conteneur fournit une couche de sécurité et l'isolation du noyau, mais il peut être sensible aux violations qui amènent des pirates informatiques à accéder au système d'exploitation de l'hôte. Une approche plus résiliente en termes d'isolation de sécurité entre un conteneur et son système d'exploitation hôte consiste à créer une autre couche de séparation. Une autre approche consiste à utiliser GKE Sandbox.

GKE Sandbox utilise gVisor, un environnement d'exécution de conteneur Open Source publié par Google. En interne, gVisor crée un noyau virtuel avec lequel les conteneurs peuvent interagir, ce qui supprime l'accès du conteneur au noyau hôte. De plus, il applique un contrôle sur les opérations relatives aux fichiers et aux réseaux que le conteneur peut effectuer.

Étant donné que GKE Sandbox crée une couche d'isolation supplémentaire, cela peut entraîner une surcharge de mémoire et du processeur. Avant d'utiliser GKE Sandbox, identifiez les charges de travail qui nécessitent ce niveau de sécurité supérieur. En règle générale, il s'agit de services basés sur des images externes.

Pour en savoir plus sur la création d'un pool de nœuds avec GKE activé, consultez la page Renforcer l'isolation d'une charge de travail avec GKE Sandbox.

Journaux d'audit

La journalisation d'audit Kubernetes enregistre toutes les requêtes API envoyées au serveur d'API Kubernetes. Cette journalisation permet de détecter les anomalies et les modèles inhabituels dans la définition des accès et de la configuration. Voici quelques exemples d'opérations que vous pourriez avoir envie de vérifier et d'associer à des alertes :

  • Supprimer un déploiement
  • Associer ou utiliser exec pour accéder à un conteneur disposant d'un accès privilégié
  • Modifier des objets ClusterRole ou créer des liaisons de rôles pour les rôles de cluster
  • Créer des comptes de service dans l'espace de noms kube-system

GKE intègre la journalisation d'audit Kubernetes avec les journaux d'audit Cloud et Cloud Logging. Vous pouvez accéder à ces journaux de la même manière que vous accédez aux journaux des ressources exécutées dans votre projet Cloud. Les requêtes API adressées au serveur d'API Kubernetes peuvent être consignées, et vous pouvez vous en servir pour examiner les modèles d'activité de l'API.

Chaque requête (événement) capturée par le serveur d'API Kubernetes est traitée à l'aide d'une ou de plusieurs stratégies que vous définissez. Il peut s'agir de stratégies d'audit Kubernetes qui déterminent les événements consignés ou de stratégies d'audit Google Kubernetes Engine qui déterminent si ces événements sont consignés dans le journal des activités d'administration ou dans le journal des données. Les journaux des activités d'administration sont activés par défaut. Vous pouvez également activer la journalisation des accès aux données si vous avez besoin de consigner des détails sur les métadonnées et les données lues ou écrites dans les clusters. Notez que l'activation de la journalisation des accès aux données peut entraîner des frais supplémentaires. Pour plus d'informations, consultez la documentation sur les tarifs.

Règles de sécurité relatives aux pods

Un vecteur d'attaque courant consiste à déployer des pods ayant connu une élévation de privilèges afin d'obtenir l'accès à un cluster Kubernetes. Gatekeeper est un contrôleur d'admission qui utilise des stratégies décrivant les actions d'un pod. Vous pouvez l'utiliser pour restreindre l'accès à l'utilisation des espaces de noms, à l'utilisation des types de volumes et aux capacités des systèmes d'exploitation sous-jacents.

Considérations de sécurité des conteneurs

Le conteneur constitue un composant fondamental pour les services Kubernetes. Ainsi, la sécurité des conteneurs est un facteur essentiel lorsque vous planifiez la sécurité et les stratégies du cluster. Soyez très attentif aux points suivants :

  • Les images à partir desquelles vous créez vos conteneurs.
  • Les privilèges que vous attribuez aux conteneurs.
  • La manière dont les conteneurs interagissent avec le système d'exploitation hôte et d'autres services
  • La manière dont les conteneurs accèdent aux informations sensibles et les consignent
  • La manière dont vous gérez le cycle de vie des conteneurs dans vos clusters.

Pour en savoir plus et connaître les bonnes pratiques, consultez la documentation sur la création et l'exploitation des conteneurs.

Configurer le réseau

Kubernetes fournit une abstraction de service qui inclut l'équilibrage de charge et la détection de services sur les ensembles de pods d'un cluster, ainsi que sur les anciens systèmes exécutés en dehors du cluster. Les sections suivantes décrivent les bonnes pratiques concernant la communication entre les pods Kubernetes et avec d'autres systèmes, y compris d'autres clusters Kubernetes.

Clusters de VPC natif et clusters basés sur le routage

Selon la manière dont les clusters GKE acheminent le trafic d'un pod à un autre, ils peuvent être classés en deux types.

  • Un cluster qui s'appuie sur des plages d'adresses IP d'alias pour acheminer le trafic, appelé cluster de VPC natif.
  • Un cluster qui utilise des routes Google Cloud, appelé cluster basé sur le routage.

Les clusters de VPC natif utilisent des plages d'adresses IP d'alias pour la mise en réseau des pods. Cela signifie que le plan de contrôle gère automatiquement la configuration de routage pour les pods au lieu de configurer et de maintenir des routes statiques pour chaque nœud du cluster GKE. Les plages d'adresses IP d'alias vous permettent de configurer plusieurs adresses IP internes qui représentent des conteneurs ou des applications hébergées sur une machine virtuelle, sans avoir à définir une interface réseau distincte. Google Cloud installe automatiquement les routes du réseau VPC pour les plages d'adresses IP principales et d'alias pour le sous-réseau de l'interface réseau principale. Cela simplifie considérablement le routage du trafic entre pods.

De plus, les clusters de VPC natif ne sont pas soumis aux quotas de routage. L'utilisation de plages d'adresses IP d'alias dans le cluster vous permet d'accéder directement à des services Google tels que Cloud Storage et BigQuery. Sinon, cet accès ne serait possible qu'à l'aide d'une passerelle NAT.

Les entreprises établissent généralement une connexion sécurisée entre leurs clusters GKE et leur écosystème sur site d'applications et de services. C'est possible grâce aux plages d'adresses IP d'alias, car les adresses IP d'alias sont visibles sur Cloud VPN ou Cloud Interconnect. Cela vous permet de sécuriser la connectivité entre votre infrastructure sur site et Google Cloud.

Vous devez choisir le type de cluster le plus adapté à votre topologie de réseau. Les principaux facteurs sont les suivants : la disponibilité des adresses IP sur votre réseau, les plans d'expansion des clusters (nœuds) au sein de votre entreprise et la connectivité à d'autres applications de l'écosystème. Notez que les clusters de VPC natif ont tendance à consommer davantage d'adresses IP sur le réseau. Toutefois, vous ne pouvez pas migrer un cluster de VPC natif vers un cluster basé sur le routage après la création, ni un cluster basé sur le routage vers un cluster de VPC natif. Il est donc important de comprendre les implications de votre choix avant de la mise en œuvre.

Réseaux autorisés pour l'accès au plan de contrôle

L'option Réseaux autorisés limite l'accès au point de terminaison du plan de contrôle (le serveur d'API) à partir des plages CIDR que vous spécifiez et garantit que seules les équipes de votre réseau soient en mesure d'administrer le cluster.

Cette fonctionnalité présente les exigences suivantes:

  • Seules 50 plages CIDR sont autorisées.
  • Si vous utilisez un pipeline CI/CD, pour permettre à vos outils CI/CD d'accéder au serveur d'API du cluster, vous devez ajouter leurs adresses IP ou leur plage CIDR à la liste d'autorisation (consultez la section Présentation des règles de pare-feu VPC).

Clusters privés

Par défaut, tous les nœuds d'un cluster GKE disposent d'adresses IP publiques. Une bonne pratique consiste à créer des clusters privés, qui ne donnent aux nœuds de calcul que des adresses IP privées RFC 1918. Les clusters privés appliquent l'isolation du réseau, ce qui réduit la surface d'exposition aux risques pour vos clusters. L'utilisation de clusters privés signifie que, par défaut, seuls les clients de votre réseau peuvent accéder aux services du cluster. Pour permettre aux services externes d'accéder aux services de votre cluster, vous pouvez utiliser un équilibreur de charge HTTP(S) ou un équilibreur de charge réseau.

Lorsque vous souhaitez ouvrir l'accès au plan de contrôle en dehors de votre réseau VPC, vous pouvez utiliser des clusters privés avec des réseaux autorisés. Lorsque vous activez les réseaux autorisés, le point de terminaison de votre plan de contrôle dispose de deux adresses IP : une interne (privée) et une publique. L'adresse IP interne peut être utilisée par tout élément interne à votre réseau situé dans la même région. L'adresse IP publique du plan de contrôle peut être utilisée par tout utilisateur ou processus externe à votre réseau, et provenant d'une plage CIDR ou d'une adresse IP autorisées. Vous pouvez également utiliser cette fonctionnalité avec Cloud Interconnect ou Cloud VPN pour n'autoriser l'accès au nœud du plan de contrôle qu'à partir de votre centre de données privé.

Protection contre l'exfiltration de données

De plus, VPC Service Controls peut servir à réduire le risque d'exfiltration de données. VPC Service Controls vous aide à protéger les services Google Cloud gérés dans un ou plusieurs projets en vous permettant de définir un périmètre de service pour l'accès à ces services. Vous pouvez autoriser les applications qui s'exécutent dans vos clusters GKE à accéder à ces services gérés en définissant des niveaux d'accès appropriés. VPC Service Controls permet également de protéger le plan de contrôle de création de clusters GKE.

Communiquer au sein d'un même cluster

Recherche de services

Kubernetes vous permet de définir des services qui regroupent les pods en cours d'exécution dans le cluster grâce à un ensemble de libellés. Vous pouvez rechercher ce groupe de pods dans votre cluster à l'aide d'un DNS. Pour en savoir plus sur la détection de services dans Kubernetes, consultez la documentation sur la connexion d'applications à des services.

DNS

Un serveur DNS local au cluster, kube-dns, est déployé dans chaque cluster GKE qui gère le mappage des noms de service à des adresses IP de pods sains. Par défaut, le serveur DNS Kubernetes renvoie l'adresse IP du cluster du service. Celle-ci reste statique pendant toute la durée de vie du service. Lorsque du trafic est envoyé vers cette adresse IP, les règles iptables du nœud chargent des paquets d'équilibrage dans les pods actifs correspondant aux sélecteurs du service. Ces règles iptables sont automatiquement programmées par le service kube-proxy qui s'exécute sur chaque nœud.

Pour en savoir plus sur kube-dns, consultez la page Détection de services et DNS.

Flux de paquets : ClusterIP

Le schéma ci-dessous illustre la réponse DNS et le flux de paquets d'un service Kubernetes standard. Alors que les adresses IP des pods sont routables depuis l'extérieur du cluster, l'adresse IP du cluster d'un service n'est accessible qu'au sein du cluster. Ces adresses IP virtuelles sont mises en œuvre grâce à la traduction d'adresses réseau de destination (DNAT) dans chaque nœud Kubernetes. Le service kube-proxy qui s'exécute sur chaque nœud maintient les règles de transfert à jour sur les nœuds mappant l'adresse IP du cluster avec les adresses IP des pods sains dans le cluster. Si un pod du service s'exécute sur le nœud local, il est utilisé. Sinon, c'est un pod aléatoire du cluster qui est choisi.

Service ClusterIP

Pour plus d'informations sur la mise en œuvre de ClusterIP, consultez la documentation de Kubernetes.

Services sans adresse IP de cluster

Si vous souhaitez bénéficier de la détection de services et de la surveillance de l'intégrité, mais que le service DNS vous renvoie les adresses IP des pods au lieu d'une adresse IP virtuelle, vous pouvez définir le champ "ClusterIP" du service sur None afin de retirer l'IP.

Dans ce cas, le serveur DNS renvoie une liste d'enregistrements A qui mappent le nom DNS de votre service aux enregistrements A des pods actifs correspondant aux sélecteurs de libellés définis par le service. Les enregistrements de la réponse sont alternés pour faciliter la répartition de la charge entre les différents pods. Certains résolveurs DNS côté client peuvent mettre en cache les réponses DNS, ce qui rend la rotation des enregistrements A inefficace. Les avantages liés à l'utilisation de ClusterIP sont décrits dans la documentation de Kubernetes. Pour en savoir plus sur l'utilisation de ClusterIP dans GKE, consultez la page Exposer des applications à l'aide de services.

Un cas d'utilisation classique de services sans adresse IP de cluster consiste à recourir à des StatefulSets. Ces derniers sont parfaitement adaptés à l'exécution d'applications avec état qui nécessitent un stockage et une mise en réseau stables entre leurs instances dupliquées. Ce type de déploiement provisionne des pods possédant une identité réseau stable, ce qui signifie que leurs noms d'hôte peuvent être résolus dans le cluster. Bien que l'adresse IP du pod puisse changer, l'entrée DNS du nom d'hôte est maintenue à jour et peut être résolue.

Voici un exemple de réponse DNS et de modèle de trafic pour un service sans adresse IP de cluster. Les adresses IP des pods sont routables via les tables de routage du sous-réseau Google Cloud par défaut, et votre application y accède directement.

Exemple de réponse DNS et de modèle de trafic pour un service sans adresse IP de cluster

Règles de réseau

L'application de la règle de réseau de GKE vous permet de contrôler la communication entre les pods et les services de votre cluster. Pour définir une règle de réseau dans GKE, vous pouvez utiliser l'API Network Policy de Kubernetes afin de créer des règles de pare-feu au niveau du pod. Ces règles de pare-feu déterminent quels pods et services peuvent accéder les uns aux autres au sein du cluster.

Les règles de réseau améliorent la sécurité des charges de travail s'exécutant sur votre cluster. Par exemple, vous pouvez créer une règle de réseau pour empêcher un service frontal de votre application qui aurait été piraté de communiquer directement avec un service de facturation ou de comptabilité séparé de celui-ci par plusieurs niveaux.

Vous pouvez également utiliser des règles de réseau pour isoler les charges de travail appartenant à des locataires différents. Par exemple, vous pouvez fournir une architecture mutualisée sécurisée en définissant un modèle dans lequel il existe un locataire pour chaque espace de noms. Dans un tel modèle, les règles de réseau peuvent garantir que les pods et les services d'un espace de noms donné n'ont pas la possibilité d'accéder aux pods ou services d'un autre espace de noms.

Se connecter à un cluster GKE depuis Google Cloud

Pour vous connecter à vos services depuis l'extérieur de votre cluster, mais au sein de l'espace d'adresses IP privées du réseau Google Cloud, vous pouvez utiliser l'équilibrage de charge interne. Lors de la création d'un service avec la spécification type: Load Balancer et l'annotation cloud.google.com/load-balancer-type: Internal dans Kubernetes, un équilibreur de charge réseau interne est créé dans votre projet Google, et configuré de façon à répartir le trafic TCP et UDP entre les pods.

Se connecter à des services externes depuis un cluster

Dans de nombreux cas, vous devez connecter vos applications s'exécutant dans Kubernetes à un service, à une base de données ou à une application hébergée en dehors du cluster. Vous disposez de trois options, comme indiqué dans les sections suivantes.

OptionDescription
Domaines de simulationDans Kubernetes 1.6 et version ultérieure, vous pouvez configurer le service DNS interne du cluster (kube-dns) pour qu'il transfère les requêtes DNS d'un domaine spécifique vers un serveur DNS externe. Cette démarche s'avère utile lorsque vous possédez des serveurs DNS primaires qui peuvent être interrogés sur un domaine que vos pods Kubernetes doivent utiliser.
Services de noms externesLes services de noms externes vous permettent de mapper un enregistrement DNS à un nom de service au sein du cluster. Dans ce cas, les résolutions DNS associées au service du cluster renvoient un enregistrement CNAME de votre choix. Utilisez cette fonctionnalité si vous ne disposez que de quelques enregistrements que vous souhaitez mapper à des services DNS existants.
Services sans sélecteurVous pouvez créer des services sans sélecteur, puis y ajouter manuellement des points de terminaison afin de renseigner les bonnes valeurs pour la recherche de services. Cela vous permet d'utiliser le même mécanisme de recherche pour vos services au sein du cluster, tout en garantissant que les systèmes n'exploitant pas la recherche de services via un DNS restent accessibles. Bien que cette approche soit la plus flexible, elle implique également un travail de configuration et de maintenance supplémentaire sur le long terme.

Pour en savoir plus sur les DNS, consultez la page de documentation sur les pods et services DNS Kubernetes.

Configurer vos services dans Kubernetes pour recevoir le trafic Internet

Les services Kubernetes peuvent être exposés à l'aide de NodePort, ClusterIP et LoadBalancer.

Toutefois, lorsque vous disposez de nombreux services externes, vous pouvez envisager d'utiliser les ressources Ingress de Kubernetes. L'objet Ingress fournit un point d'entrée pour votre cluster et vous permet de définir des règles de routage qui acheminent les requêtes entrantes vers un ou plusieurs services de backend dans votre cluster. Dans GKE, le contrôleur d'entrée GKE met en œuvre une ressource Ingress en tant qu'équilibreur de charge HTTP(S) Google Cloud et la configure en fonction des informations spécifiées dans la ressource Ingress et des services associés. Pour plus d'informations, consultez la page Configurer Ingress pour l'équilibrage de charge externe.

Une ressource d'entrée Kubernetes ne peut être utilisée que lorsque vos applications diffusent du trafic sur HTTP(S). Si vos services de backend utilisent des protocoles TCP ou UDP, vous devez utiliser un équilibreur de charge réseau. Cette opération peut s'avérer nécessaire si vous avez besoin d'exposer votre base de données en tant que service.

Configurer le backend

Un BackendConfig est une définition de ressource personnalisée qui peut fournir une configuration normative supplémentaire utilisée par le contrôleur Ingress Kubernetes. Lorsque vous déployez un objet Ingress dans le cluster GKE, le contrôleur Ingress Kubernetes configure un équilibreur de charge HTTP(S) qui achemine les requêtes entrantes vers les services de backend, comme vous l'avez spécifié dans le fichier manifeste Ingress.

Vous pouvez compléter la configuration de l'équilibreur de charge avec les spécifications suivantes :

  • Activer la mise en cache avec Cloud CDN.
  • Ajouter des adresses IP ou des listes d'autorisations CIDR à l'aide de Google Cloud Armor.
  • Contrôler l'accès au niveau de l'application à l'aide d'Identity-Aware Proxy (IAP).
  • Configurer les délais d'expiration de service et les délais d'expiration de connexion pour les services régis par l'objet Ingress dans un cluster

Pour en savoir plus sur la configuration de la ressource personnalisée BackendConfig dans GKE, consultez la page Fonctionnalités Ingress.

Utiliser un maillage de services

Un maillage de services offre une manière uniforme de connecter, de sécuriser et de gérer les microservices exécutés dans vos clusters Kubernetes. Par exemple, le maillage de services Istio, que vous pouvez ajouter en tant que module complémentaire GKE, peut gérer l'authentification et la communication de service à service, appliquer des stratégies d'accès et collecter des points de données de télémétrie enrichis qui peuvent vous servir à auditer et administrer vos clusters GKE.

Les principales fonctionnalités fournies par un maillage de services sont les suivantes :

  • Gestion du trafic Le maillage de services vous permet de définir des règles précises qui déterminent la manière dont le trafic est acheminé et réparti entre des services ou entre différentes versions d'un même service. Cela facilite les déploiements Canary et bleu-vert.

  • Observabilité intégrée. Le maillage enregistre les métriques de trafic réseau (couche 4 et couche 7) de manière uniforme sans que vous ayez besoin d'écrire du code pour instrumenter vos services.

  • Sécurité. Le maillage permet l'authentification TLS mutuelle (mTLS) entre les services. Il fournit non seulement des canaux sécurisés pour les données en transit, mais vous permet également de gérer l'authentification et l'autorisation des services au sein du maillage.

En résumé, les maillages de services tels qu'Istio vous permettent de déléguer des tâches au niveau du système à l'infrastructure de maillage. Cela permet d'améliorer l'agilité globale, la robustesse et le couplage faible de services exécutés au sein de vos clusters Kubernetes.

Pour en savoir plus sur l'utilisation d'un maillage de services avec Anthos, consultez la page À propos d'Anthos Service Mesh.

Pare-feu

Les nœuds GKE sont provisionnés en tant qu'instances dans Compute Engine. Ils dépendent ainsi du même mécanisme de pare-feu avec état que les autres instances. Ces règles de pare-feu sont appliquées aux instances de votre réseau à l'aide de tags. Chaque pool de nœuds reçoit son propre ensemble de tags que vous pouvez utiliser dans des règles. Par défaut, chaque instance appartenant à un pool de nœuds reçoit un tag qui identifie le cluster Kubernetes Engine spécifique contenant ce pool de nœuds. Ce tag est utilisé dans les règles de pare-feu que Kubernetes Engine crée automatiquement pour vous. Vous pouvez ajouter vos propres tags personnalisés au moment de la création du cluster ou du pool de nœuds en spécifiant l'option --tags sur l'outil gcloud.

Si vous souhaitez, par exemple, permettre à un équilibreur de charge interne d'accéder au port 8080 sur tous vos nœuds, utilisez les commandes suivantes :

gcloud compute firewall-rules create allow-8080-fwr \
    --target-tags allow-8080 \
    --allow tcp:8080 \
    --network gke \
    --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

L'exemple ci-dessous décrit comment ajouter des tags à un cluster pour permettre au trafic d'accéder aux nœuds du port 30000 (tandis que l'autre cluster dispose de tags autorisant le trafic en provenance du VPN vers le port 40000). Cette approche s'avère utile lorsque vous exposez un service via un NodePort qui ne doit être accessible qu'à l'aide de réseaux privilégiés (tels qu'un VPN) vers un centre de données d'entreprise ou depuis un autre cluster de votre projet.

Ajout de tags différents à deux clusters

Se connecter à un centre de données sur site

Vous pouvez utiliser Cloud Interconnect ou Cloud VPN pour vous connecter à des centres de données sur site. Ces options ne sont pas mutuellement exclusives. Vous pouvez donc en combiner plusieurs en fonction de vos charges de travail et de vos exigences. Vous disposez des options suivantes :

  • Utilisez l'interconnexion dédiée pour transférer de grandes quantités de données entre les réseaux, avec une faible latence.

  • Utilisez l'interconnexion partenaire si votre centre de données ne se trouve pas dans une installation hébergée en colocation dédiée à l'interconnexion dédiée. Google compte plus de 100 points de présence (PoP) reliés à des fournisseurs de services du monde entier.

  • Utilisez l'appairage direct pour les charges de travail qui nécessitent une bande passante dédiée, requièrent une faible latence et doivent pouvoir accéder à Google Workspace et aux API Google compatibles. Comme l'appairage direct est une connexion de couche 3 obtenue grâce à un échange de routes BGP, il nécessite un numéro ASN enregistré.

  • Utilisez l'appairage opérateur si vous ne possédez pas de numéro ASN enregistré ou si vous entretenez déjà des relations avec un fournisseur de services. L'appairage opérateur est comparable à l'appairage direct, mais implique un fournisseur de services.

  • Utilisez Cloud VPN si le chiffrement IPSec est requis ou si vous souhaitez étendre votre réseau privé à votre réseau privé Compute Engine. Cloud VPN est configuré via les options Internet et d'interconnexion de couche 3 (1, 2 et 3).

Gérer l'opérabilité des clusters

Cette section traite des facteurs clés à prendre en compte lorsque vous administrez et gérez vos clusters GKE.

Quotas de ressources

Les quotas de ressources Kubernetes définissent des contraintes qui limitent la consommation globale des ressources autorisées pour chaque espace de noms dans un cluster. Si vous disposez de clusters avec des espaces de noms Kubernetes qui isolent des fonctions métier ou des étapes de développement, vous pouvez utiliser des quotas afin de limiter un large éventail de ressources, telles que l'utilisation du processeur, la mémoire, ou le nombre de pods et de services que vous pouvez créer dans un espace de noms. Pour garantir la stabilité du plan de contrôle de vos clusters GKE, Kubernetes applique automatiquement des quotas de ressources non remplaçables par défaut à chaque espace de noms dans n'importe quel cluster GKE comportant cinq nœuds ou moins.

Limites de ressources

L'objet Kubernetes LimitRange permet d'appliquer des contraintes précises aux limites minimales et maximales des ressources avec lesquelles les conteneurs et les pods peuvent être créés. L'exemple suivant montre comment utiliser LimitRange :

apiVersion: v1
kind: LimitRange
metadata:
  name: sample-limits
spec:
  limits:
    - max:
        cpu: "400m"
        memory: "1Gi"
      defaultRequest:
        cpu: "200m"
        memory: "500Mi"
      type: Container

Budgets d'interruption de pod

Les budgets d'interruption de pods (PDB) permettent d'éviter la suppression volontaire ou accidentelle de pods ou de déploiements par votre équipe. Les PDB ne peuvent pas empêcher les interruptions involontaires pouvant être causées par un arrêt ou un redémarrage. En règle générale, un opérateur crée un PDB pour une application qui définit le nombre minimal d'instances dupliquées des pods de l'application.

Dans une entreprise où les développeurs travaillent sur plusieurs applications, des erreurs se produisent et un développeur ou un administrateur peut exécuter accidentellement un script qui supprime des pods ou des déploiements (soit des ressources Kubernetes). Toutefois, en définissant un PDB, vous vous assurez à tout moment de maintenir un ensemble minimal de ressources viables pour vos applications Kubernetes.

Les PDB que vous configurez pour vos clusters GKE sont reconnus lors des mises à niveau GKE. Cela signifie que vous pouvez contrôler la disponibilité de vos applications lors d'une mise à niveau. L'exemple suivant montre comment configurer un PDB.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
  spec:
    minAvailable: 4
    selector:
      matchLabels:
        app: nginx

Gérer les mises à niveau de Kubernetes

Veillez à ce que vos clusters Kubernetes sur GKE soient mis à jour vers la dernière version de Kubernetes adaptée à vos besoins. Vous pouvez choisir de mettre à niveau automatiquement votre plan de contrôle ou vos nœuds, ou de choisir vous-même les mises à niveau.

Vous pouvez consulter les notifications de mise à niveau dans la console, dans les bulletins de sécurité Anthos et dans les notifications de mise à niveau des clusters. Si vous mettez à jour les nœuds manuellement, nous vous recommandons de déclencher la mise à niveau de la version après avoir examiné le contenu de la version et testé vos applications dans un cluster en bac à sable qui exécute la version vers laquelle vous souhaitez effectuer la mise à jour.

Lorsque le plan de contrôle d'un cluster zonal est en cours de mise à niveau, il n'est pas disponible. Cela signifie que vous ne pouvez pas interagir avec le serveur d'API pour ajouter ou supprimer des ressources dans votre cluster. Si vous ne pouvez pas vous permettre de mettre à niveau un plan de contrôle, vous pouvez rendre ce plan hautement disponible en déployant des clusters GKE régionaux à la place. Avec cette approche, plusieurs plans de contrôle sont répartis sur plusieurs zones. Lorsqu'un plan de contrôle est en cours de mise à niveau, toutes les requêtes du plan de contrôle adressées au serveur d'API sont acheminées vers les autres plans de contrôle.

En cas de mise à niveau, GKE applique une mise à jour progressive sur les nœuds de calcul. Il draine, supprime et met à niveau systématiquement un nœud à la fois lorsqu'un nouveau nœud de remplacement devient disponible afin de répondre aux requêtes entrantes.

Réparation automatique des nœuds

La fonctionnalité de réparation automatique des nœuds GKE gère les vérifications d'état de vos nœuds GKE. Si l'un des nœuds n'est pas opérationnel, GKE lance le processus de réparation de nœud.

Si votre cluster GKE comporte plusieurs pools de nœuds, la fonctionnalité de réparation automatique vous permet de contrôler avec précision les pools de nœuds pour lesquels vous souhaitez activer la réparation automatique.

Autoscaling des clusters GKE

Les entreprises connaissent souvent des charges entrantes différentes sur les applications exécutées dans leurs clusters Kubernetes. Pour répondre à ces changements propres à l'entreprise, vous pouvez autoriser vos clusters GKE à répondre automatiquement et à évoluer en fonction des métriques.

L'autoscaling inclut plusieurs dimensions, comme indiqué dans les sections suivantes.

Autoscaler de cluster

L'autoscaler de cluster GKE ajoute et supprime automatiquement les nœuds de votre cluster en fonction de la demande de vos charges de travail. L'autoscaler de cluster est activé pour les pools de nœuds individuels. Pour chaque pool de nœuds, GKE vérifie s'il existe des pods en attente de planification en raison d'un manque de capacité. Si tel est le cas, l'autoscaler de cluster ajoute des nœuds à ce pool de nœuds.

L'autoscaler de cluster évolue à la hausse ou à la baisse en fonction des demandes de ressources. Si un nœud est sous-utilisé et que les pods en cours d'exécution peuvent être planifiés sur d'autres nœuds disposant d'une capacité suffisante, le nœud sous-utilisé est drainé et arrêté.

Vous pouvez définir les limites d'un pool de nœuds en spécifiant le nombre minimal et maximal de nœuds que l'autoscaler peut ajouter.

Provisionnement automatique des nœuds

Le provisionnement automatique des nœuds permet à l'autoscaler de cluster GKE de provisionner automatiquement des pools de nœuds supplémentaires lorsque l'autoscaler détermine qu'ils sont nécessaires. L'autoscaler de cluster peut également supprimer les pools de nœuds provisionnés automatiquement lorsqu'il n'y a aucun nœud dans ces pools.

L'autoscaler de cluster GKE prend des décisions concernant le provisionnement automatique des nœuds en fonction d'un certain nombre de facteurs. Parmi ces facteurs, on retrouve la quantité de ressources demandées par les pods, les affinités entre les pods que vous avez spécifiées, et les rejets et tolérances de nœuds définis dans votre cluster GKE.

Le provisionnement automatique des nœuds est utile si vous possédez plusieurs charges de travail s'exécutant dans vos clusters GKE. Par exemple, si votre cluster GKE dispose d'une charge de travail dépendant de GPU, vous pouvez l'exécuter dans un pool de nœuds dédié, qui est provisionné avec des nœuds compatibles GPU. Vous pouvez définir les limites de scaling du pool de nœuds en spécifiant une taille minimale et maximale de pool de nœuds.

Pour en savoir plus sur le provisionnement automatique des nœuds et sur son activation, consultez la page Utiliser le provisionnement automatique des nœuds.

Autoscaling horizontal des pods

Kubernetes vous offre la possibilité de créer un autoscaler horizontal des pods, qui vous permet de configurer le scaling de vos déploiements Kubernetes ou de vos ReplicaSets, ainsi que les métriques à prendre en compte lors des décisions d'autoscaling. Par défaut, le contrôleur horizontal de l'autoscaler de pods base les décisions d'autoscaling sur l'utilisation du processeur. Toutefois, le contrôleur d'autoscaler horizontal de pods peut également calculer le scaling des pods en fonction de métriques personnalisées, telles qu'un nombre de requêtes HTTP. Pour qu'un autoscaler horizontal de pods réponde à des métriques personnalisées, une instrumentation de surveillance supplémentaire est généralement requise.

Pour en savoir plus, consultez la documentation sur Kubernetes et sur GKE.

Autoscaling de pods verticaux

La fonctionnalité d'autoscaling de pods verticaux des clusters GKE vous permet de décharger la tâche de spécification des requêtes de processeur et de mémoire optimales pour les conteneurs. Si nécessaire, l'autoscaling de pods verticaux ajuste les allocations de ressources apportées aux conteneurs de votre cluster. L'autoscaling de pods verticaux vous permet d'optimiser l'utilisation des ressources au niveau du conteneur sur chaque nœud. Cela permet également de consacrer plus de temps aux tâches administratives plutôt qu'à la gestion des ressources.

L'autoscaling de pods verticaux fonctionne conjointement avec la fonctionnalité de provisionnement automatique des nœuds décrite dans la section suivante.

En raison des limitations de Kubernetes, les demandes de ressources d'un pod ne peuvent être modifiées que lorsqu'un pod est redémarré. Par conséquent, pour effectuer des modifications, l'autoscaling de pods verticaux évince le pod. Pour en savoir plus, consultez la documentation de GKE et Kubernetes.

Autopilot

Autopilot signifie que GKE provisionne et gère l'infrastructure sous-jacente du cluster en votre nom. Avec Autopilot, les éléments suivants sont gérés:

  • Nœuds et pools de nœuds

  • Provisionnement de ressources

  • Types d'images de nœuds

  • Fonctionnalités de mise en réseau telles que le type de cluster et les plages CIDR

  • Fonctionnalités de sécurité telles que Workload Identity ou VM protégée

Autopilot est utile si vous souhaitez réduire votre charge opérationnelle et n'avez pas besoin de configurer des éléments spécifiques pour des charges de travail plus complexes.

Étape suivante

  • Découvrez les bonnes pratiques pour renforcer les clusters.

  • Découvrez les bonnes pratiques concernant la création et l'exploitation des conteneurs.

  • Découvrez comment authentifier les utilisateurs finaux auprès de Cloud Run sur GKE à l'aide d'Istio dans ce tutoriel.

  • Explorez des architectures de référence, des schémas, des tutoriels et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.