Préparer un environnement Google Kubernetes Engine pour la production

Cette solution fournit un plan et une méthodologie permettant d'intégrer vos charges de travail à Google Kubernetes Engine 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.

Structurer des projets, des réseaux VPC (Virtual Private Cloud) et des clusters

Le schéma suivant présente un exemple de structure flexible et à disponibilité élevée pour les projets, les réseaux VPC, les régions, les sous-réseaux, les zones et les clusters.

Structure des projets, réseaux et clusters

Projets

Google Cloud crée toutes ses ressources au sein d'une entité de projet. Un projet représente une unité de facturation et permet aux administrateurs d'associer des rôles IAM (Identity and Access Management) à des utilisateurs. Lorsque vous accordez des rôles au niveau du projet, ceux-ci s'appliquent à toutes les ressources encapsulées dans le projet.

Il est conseillé d'utiliser des projets pour encapsuler divers 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 (test-dev) 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, tout en utilisant des stratégies permissives et flexibles pour les développeurs de l'environnement test-dev.

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. Pour en savoir plus, consultez nos bonnes pratiques sur le choix de la taille et du champ d'application d'un cluster GKE.

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 Internet 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 multizones et régionaux

Par défaut, un cluster crée son maître et ses nœuds dans une seule zone que vous spécifiez au moment de la création. Vous pouvez améliorer la disponibilité et la résilience de vos clusters en créant des clusters multizones ou régionaux. Ces derniers répartissent les ressources Kubernetes sur plusieurs zones d'une même région.

Les clusters multizones :

  • créent un maître de cluster dans une zone ;
  • créent des nœuds dans plusieurs zones.

Les clusters régionaux :

  • créent trois maîtres de cluster répartis sur trois zones ;
  • créent par défaut des nœuds dans trois zones (ou le nombre de zones de votre choix).

La principale différence entre les clusters régionaux et multizones est que les clusters régionaux créent trois maîtres, tandis que les clusters multizones n'en créent qu'un. Notez que dans les deux cas, des frais vous sont facturés pour le trafic nœud à nœud entre les zones.

Vous pouvez choisir de créer des clusters multizones 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 multizone. Notez toutefois que vous ne pouvez pas modifier un cluster existant pour le rendre régional. Vous ne pouvez pas non plus rendre un cluster régional non régional.

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. En outre, le contrat de niveau de service pour GKE garantit une disponibilité mensuelle de 99,5 % pour les maîtres de cluster Kubernetes concernant les clusters zonaux et de 99,95 % concernant les clusters régionaux.

Depuis le 6 juin 2020, GKE facture des frais de gestion de clusters de 0,10 $ par cluster et par heure. Pour plus d'informations, consultez la page des tarifs.

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

Réseaux autorisés maîtres

Une mesure de sécurité supplémentaire que vous pouvez appliquer dans votre cluster consiste à activer les réseaux maîtres autorisés. Cette fonctionnalité bloque l'accès au 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.

Lorsque vous activez cette fonctionnalité, gardez à l'esprit les points suivants :

  • Seules 50 plages CIDR sont autorisées.
  • Si vous utilisez un pipeline CI/CD, vous devez vous assurer que vos outils CI/CD ont accès au serveur d'API du cluster en ajoutant à la liste blanche leurs adresses IP ou leur plage CIDR.

Vous pouvez également utiliser cette fonctionnalité avec Cloud Interconnect ou Cloud VPN pour n'autoriser l'accès au nœud maître qu'à partir de votre centre de données privé.

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 nœud maître en dehors du réseau VPC, vous pouvez utiliser des clusters privés avec des réseaux autorisés maîtres. Lorsque vous activez les réseaux autorisés maîtres, le point de terminaison du maître de cluster obtient 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 maître 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. Les nœuds privés ne possèdent pas d'adresses IP externes et, par défaut, ils ne disposent donc pas d'un accès Internet sortant. Cela signifie également que par défaut, l'environnement d'exécution du conteneur de votre cluster ne peut pas extraire des images de conteneurs d'un registre de conteneurs externe, car cela nécessite une connectivité de sortie (sortante). Vous devriez également envisager d’héberger vos images de conteneurs dans Container Registry et d'y accéder à l'aide de l'accès privé à Google. Vous pouvez également utiliser Cloud NAT ou déployer une passerelle NAT pour fournir un accès sortant à vos nœuds privés.

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.

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

Accès au niveau du projet

Dans la section précédente, nous avons vu que vous pouvez associer des rôles IAM à des utilisateurs au niveau du projet. En plus d'accorder des rôles à 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 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 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é container.viewer
security.admin
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 network.admin 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 concernant 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. La section suivante décrit comment restreindre des utilisateurs à certains espaces de noms.

Contrôle d'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 RoleBinding.

Google Groupes pour GKE (version bêta) vous permet d'utiliser des groupes avec Kubernetes RBAC. Pour utiliser cette fonctionnalité, vous devez configurer des groupes Google Workspace, créer un cluster avec la fonctionnalité activée, puis utiliser des objets RoleBindings pour associer vos groupes aux rôles que vous souhaitez leur associer. 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 (version bêta) sont stockées dans Cloud Storage. Cette section décrit deux manières de les partager. Une méthode consiste à rendre les images publiques, l'autre à les partager entre plusieurs projets.

Rendre des images publiques dans Container Registry

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

Accéder aux images entre plusieurs projets dans Container Registry

Pour partager des images de conteneur entre plusieurs projets, vous devez vous assurer que vos nœuds Kubernetes utilisent un compte de service. Le compte de service par défaut associé à votre projet se présente sous la forme suivante :

project-id-compute@developer.gserviceaccount.com

Une fois que vous disposez de cet identifiant, vous pouvez lui accorder l'accès storage.viewer aux projets pour lesquels vous souhaitez utiliser Container 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. Si vous souhaitez par exemple utiliser le compte de service gke-sa dans le projet my-project, exécutez la commande suivante :

gcloud container clusters create west --service-account \
    gke-sa@my-project.google.com.iam.gserviceaccount.com

Pour plus d'informations sur la migration depuis Container Registry vers Artifact Registry pour vos images de conteneur, consultez la section Effectuer une transition depuis Container Registry.

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

La propriété imagePullPolicy détermine si Kubelet va tenter d'extraire une image lors du démarrage d'un pod. Vous devez définir 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, 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 webhooks d'admission dynamiques pour l'application des stratégies

Les webhooks 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 webhooks 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 webhooks d'admission : les webhooks d'admission de mutation et les webhooks d'admission de validation.

Les webhooks 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 webhooks 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 webhooks 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 webhooks d'admission de validation peuvent rejeter les requêtes afin d'assurer la conformité avec les stratégies définies dans le webhook.

Par exemple, vous pouvez appliquer une stratégie d'extraction d'images en utilisant un webhook 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.

Autres remarques concernant le déploiement d'images

Il est recommandé d'utiliser un registre de conteneurs privé tel que Container Registry pour stocker l'ensemble d'images organisé de votre organisation. Cela permet de réduire le risque d'introduction de failles dans votre pipeline de déploiement et, à terme, dans les charges de travail de l'application. Si possible, vous devez également activer l'analyse des conteneurs, tels que l'analyse des failles, afin de réduire davantage les risques de sécurité.

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). 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.

En outre, veillez à utiliser de bonnes pratiques de gestion des versions d'images, à utiliser de bonnes conventions d'ajouts de tags et à utiliser des condensés au lieu de tags, le cas échéant.

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 (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 est une fonctionnalité GKE qui permet à vos services GKE d'interagir avec l'ensemble de l'écosystème Google Cloud sans avoir à stocker les identifiants du compte de service en tant que secrets Kubernetes. Cette fonctionnalité vous permet de mapper un compte de service Kubernetes à un compte de service Google Cloud à l'aide d'une liaison IAM. Par la suite, lorsque les pods s'exécutent à l'aide du compte de service Kubernetes, ils peuvent supposer l'identité requise pour accéder au service Google Cloud. Notez que cela suppose que vous avez accordé le niveau d'accès requis au service au compte de service Google Cloud.

Pour en savoir plus sur Workload Identity, consultez la documentation GKE.

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

Container Registry peut analyser les images qui lui sont transmises, en recherchant les failles de sécurité connues pour les images basées sur Ubuntu, Alpine, Debian, CentOS et RedHat. Nous vous recommandons de vous servir de cette fonctionnalité pour analyser les images que vous prévoyez d'utiliser dans vos clusters Kubernetes.

Vous pouvez afficher les failles d'une image dans Google Cloud Console ou en exécutant la commande gcloud suivante :

gcloud beta container images describe \
    hostname/project-id/image-id:tag  \
    --show-package-vulnerability

Remplacez l'élément suivant :

  • hostname : l'un des emplacements de nom d'hôte suivants :
    • gcr.io, qui héberge actuellement les images aux États-Unis.
    • us.gcr.io, qui héberge l'image aux États-Unis dans un bucket de stockage distinct des images hébergées par gcr.io.
    • eu.gcr.io, qui héberge les images dans l'Union européenne.
    • asia.gcr.io, qui héberge les images en Asie.
  • project-id : l'ID du projet contenant les images.
  • image-id : l'ID de l'image pour laquelle vous souhaitez afficher les failles.
  • tag : le tag de l'image pour lequel vous souhaitez obtenir des informations.

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 Container 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 Container 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 de Container 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, vous devez identifier 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.

La commande gcloud suivante montre comment créer un pool de nœuds avec GKE Sandbox activé :

gcloud container node-pools create node-pool-name \
    --cluster=cluster \
    --image-type=cos_containerd \
    --sandbox type=gvisor \
    --enable-autoupgrade

Remplacez l'élément suivant :

  • node-pool-name : nom du pool de nœuds à créer.
  • cluster : cluster auquel ajouter le pool de nœuds.

Pour spécifier les pods d'application exécutés avec GKE Sandbox, intégrez gVisor dans la spécification du pod, comme indiqué dans l'exemple suivant :

apiVersion: v1
kind: Pod
metadata:
  name: sample-saas-app
  labels:
    app: saas-v1
spec:
  runtimeClassName: gvisor
  containers:
    - name: sample-node-app-v1
      image: [image]

Pour en savoir plus sur GKE Sandbox, consultez la page GKE Sandbox : Défense approfondie pour vos pods sur le blog Google Cloud. Pour savoir si votre application est adaptée à GKE Sandbox, consultez la documentation GKE.

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 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.

PodSecurityPolicies

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. Les règles PodSecurityPolicies définissent un ensemble de règles dans la spécification du pod qui décrivent les actions autorisées d'un pod. Vous mettez en œuvre une règle PodSecurityPolicy dans Kubernetes en tant que ressource de contrôleur d'admission. Elles vous permettent de 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.

Pour créer un cluster GKE avec PodSecurityPolicy activé, exécutez la commande suivante. Remplacez cluster-name par le nom du cluster auquel vous ajoutez une règle PodSecurityPolicy.

gcloud beta container clusters create cluster-name \
    --enable-pod-security-policy

L'exemple suivant présente une règle PodSecurityPolicy limitant la capacité à créer des pods privilégiés.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: default-pod-security-policy
spec:
  privileged: false
  hostPID: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

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. Le premier est un cluster qui utilise des plages d'adresses IP d'alias pour acheminer le trafic. Il s'agit d'un cluster de VPC natif. Le second est un cluster qui utilise des routes Google Cloud. Il s'agit d'un 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.

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.

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.

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.

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. Pour une présentation détaillée de la mise en réseau GKE, visionnez la conférence Next 2017 sur YouTube.

Services sans adresse IP de cluster

Vous trouverez ci-dessous 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 offrent une défense en profondeur qui permet de renforcer 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.

Les règles de réseau peuvent également servir à isoler des 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 attribuant un espace de noms à chaque locataire. 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.

Pour en savoir plus sur les règles de réseau, consultez la documentation GKE.

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é ci-dessous.

Domaines de simulation

Dans Kubernetes 1.6 et versions ultérieures, 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 devant être exploité par vos pods Kubernetes.

Services de noms externes

Les 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. Il est recommandé d'utiliser cette option si vous ne souhaitez mapper qu'un faible nombre d'enregistrements aux services DNS existants.

Services sans sélecteur

Vous 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.

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 (listes blanches) à 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 documentation GKE.

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 doit être acheminé et réparti entre plusieurs 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 plus d'informations, consultez la page Istio sur Google Kubernetes Engine.

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 command-line tool.

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

Plusieurs options Cloud Interconnect vous permettent de 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 :

  1. Internet pour les charges de travail qui consomment peu de données ou ne requièrent pas une faible latence. Google compte plus de 100 points de présence (PoP) reliés à des fournisseurs de services du monde entier.
  2. 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 à tous les services Google, y compris la suite complète de produits Google Cloud. 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é.
  3. L'appairage opérateur est comparable à l'appairage direct, mais implique un fournisseur de services. Il s'avère une option excellente si vous ne possédez pas de numéro ASN enregistré ou si vous entretenez déjà des relations avec un fournisseur de services.
  4. Cloud VPN est configuré via les options Internet et d'interconnexion de couche 3 (1, 2 et 3) si le chiffrement IPsec est requis ou si vous souhaitez étendre votre réseau privé à votre réseau privé Compute Engine.

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 associées aux pods à exécuter pour 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

Nous vous conseillons de conserver vos clusters Kubernetes sur la solution GKE mise à jour vers la dernière version de Kubernetes qui est adaptée à vos besoins. Cela vous permet d'utiliser les nouvelles fonctionnalités déployées et de vous assurer que le système d'exploitation sous-jacent de vos nœuds de cluster est corrigé et à jour.

Lorsqu'une mise à niveau est nécessaire, vous pouvez envisager les types suivants :

  • Mises à niveau Kubernetes majeures et mineures de votre cluster GKE pour les nœuds maîtres et les nœuds de calcul.
  • Les correctifs et mises à niveau du système d'exploitation des machines virtuelles (nœuds) qui constituent votre cluster.

Mettre à jour la version de Kubernetes

Vous disposez de deux options pour mettre à niveau vos nœuds maîtres GKE. La première consiste à laisser Google Cloud mettre à jour automatiquement votre maître de cluster GKE. La seconde consiste à lancer une mise à niveau manuelle lorsqu'une version plus récente devient disponible.

Vous pouvez consulter les notifications dans la console. Celles-ci s'affichent sur vos clusters GKE lorsque des mises à niveau sont disponibles. Nous vous recommandons de déclencher la mise à niveau de la version après en avoir examiné le contenu, et après avoir testé vos applications dans un cluster en bac à sable exécuté sur la version vers laquelle vous souhaitez effectuer la mise à niveau.

Lorsque le nœud maître d'un cluster zonal est en cours de mise à niveau, le plan de contrôle 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 nœud maître dans votre cluster zonal, vous pouvez rendre ce nœud maître hautement disponible en déployant des clusters GKE régionaux à la place. Avec cette approche, plusieurs nœuds maîtres sont répartis sur plusieurs zones. Lorsqu'un nœud maître 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 l'autre nœud maître (ou les autres nœuds maîtres).

Comme pour les nœuds maîtres, il existe deux options pour mettre à jour vos nœuds de calcul GKE vers la même version que le nœud maître du cluster :

  • Vous pouvez demander à GKE de gérer les mises à niveau des nœuds de calcul à votre place. Pour ce faire, activez la mise à niveau automatique des nœuds pour les pools de nœuds de votre cluster GKE.
  • Vous pouvez mettre à niveau manuellement vos nœuds de calcul GKE. Lorsqu'une mise à niveau est disponible, la console GKE affiche une alerte. Dès l'apparition de cette alerte, vous pouvez appliquer la mise à niveau à vos nœuds de calcul GKE.

Dans les deux cas, 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.

Le processus de réparation de nœuds géré implique le drainage et la recréation du nœud. Si plusieurs nœuds de votre cluster GKE doivent être réparés en même temps, Google Cloud détermine en interne le nombre de nœuds pouvant être réparés en parallèle.

Si vous créez des clusters dans Google Cloud Console, la fonctionnalité de réparation automatique est activée par défaut. Pour les clusters GKE que vous créez à l'aide de l'outil gcloud command-line tool, vous pouvez explicitement activer la réparation automatique en incluant l'option --enable-autorepair dans la commande de création de cluster.

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.

Une combinaison de facteurs influence la manière dont GKE décide de procéder au scaling à la baisse. Si l'utilisation d'un nœud par les pods en cours d'exécution ne dépasse pas les 50 % et si 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.

Autoscaling horizontal des pods (HPA)

Kubernetes vous offre la possibilité de créer un autoscaler horizontal des pods (HPA), 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 HPA base les décisions d'autoscaling sur l'utilisation du processeur. Toutefois, le contrôleur HPA peut également déterminer le scaling des pods en fonction de métriques personnalisées, telles qu'un nombre de requêtes HTTP. Pour qu'un HPA puisse répondre à 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 (VPA)

La fonctionnalité d'autoscaling de pods verticaux (VPA) 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, la fonctionnalité VPA ajuste les allocations de ressources apportées aux conteneurs de votre cluster. La fonctionnalité VPA 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.

VPA 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, la fonctionnalité VPA supprime le pod. Pour en savoir plus, consultez la documentation de GKE et Kubernetes.

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.

Étape suivante

  • 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.
  • Testez d'autres fonctionnalités de Google Cloud. Découvrez nos tutoriels.