Bonnes pratiques pour l'architecture mutualisée d'entreprise

L'architecture mutualisée dans Google Kubernetes Engine (GKE) fait référence à un ou plusieurs clusters partagés entre des locataires. Dans Kubernetes, un locataire peut être défini comme l'un des éléments suivants :

  • Une équipe chargée du développement et du fonctionnement d'une ou de plusieurs charges de travail
  • Un ensemble de charges de travail associées, gérées par une ou plusieurs équipes
  • Une seule charge de travail, telle qu'un déploiement

L'architecture de cluster mutualisée est souvent mise en œuvre pour réduire les coûts ou appliquer systématiquement les règles d'administration à tous les locataires. Toutefois, la configuration incorrecte d'un cluster GKE ou des ressources GKE associées peut entraîner la non-réalisation d'économies, une application incorrecte des règles ou des interactions destructrices entre les charges de travail des différents locataires.

Ce guide présente les bonnes pratiques pour configurer efficacement et en toute sécurité plusieurs clusters mutualisés pour une entreprise.

.

Hypothèses et exigences

Les bonnes pratiques de ce guide sont basées sur un scénario d'architecture mutualisée pour un environnement d'entreprise qui repose sur les hypothèses et conditions suivantes :

  • L'entreprise est une entreprise unique comptant de nombreux locataires (au moins deux équipes chargées des applications et des services) qui utilisent Kubernetes et souhaitent partager des ressources informatiques et administratives.
  • Chaque locataire correspond à une équipe unique qui développe une charge de travail unique.
  • Outre les équipes chargées des applications et des services, d'autres équipes utilisent et gèrent également les clusters, y compris les membres de l'équipe chargée de la plate-forme, les administrateurs des clusters, les auditeurs, etc.
  • L'équipe chargée de la plate-forme est propriétaire des clusters et définit la quantité de ressources que chaque équipe locataire peut utiliser. Chaque locataire peut en demander davantage.
  • Chaque équipe locataire doit être en mesure de déployer son application via l'API Kubernetes sans avoir à communiquer avec l'équipe chargée de la plate-forme.
  • Un locataire ne doit pas pouvoir affecter les autres locataires du cluster partagé, sauf par le biais de décisions de conception explicites, telles que des appels d'API, des sources de données partagées, etc.

Cette configuration sert de modèle à partir duquel nous pouvons démontrer les bonnes pratiques associées à l'architecture mutualisée. Bien que cette configuration ne décrive pas parfaitement toutes les entreprises, elle peut facilement être étendue à des scénarios similaires.

Configurer des dossiers, des projets et des clusters

Pour les entreprises qui déploient des clusters mutualisés dans GKE, une configuration supplémentaire est nécessaire dans les autres systèmes Google Cloud afin de gérer les complexités qui n'existent pas dans des déploiements Kubernetes plus simples contenant une seule application ou une seule équipe. Cela comprend la configuration de projet pour garantir que les tâches administratives sont clairement réparties, la mise en correspondance de la structure de l'entreprise sur les comptes et les identités cloud, ainsi que la gestion d'autres ressources Google Cloud, telles que les bases de données, la journalisation et la surveillance, le stockage et le réseau.

Établir une hiérarchie de dossiers et de projets

Pour savoir comment votre entreprise gère les ressources Google Cloud et pour garantir que chaque tâche est clairement répartie, utilisez des dossiers et des projets. Les dossiers permettent à différentes équipes de définir des règles qui peuvent être appliquées à plusieurs projets, tandis que les projets permettent de séparer les environnements (par exemple, préproduction et production) et les équipes. Par exemple, la plupart des entreprises disposent d'une équipe pour gérer l'infrastructure réseau et d'une autre équipe pour gérer les clusters. Chaque technologie est considérée comme une partie distincte de la pile, nécessitant son propre niveau d'expertise, de dépannage et d'accès.

Un dossier parent peut contenir jusqu'à 300 dossiers ; il est possible d'imbriquer des dossiers jusqu'à 10 niveaux de profondeur. Si vous disposez de plus de 300 locataires, vous pouvez organiser les locataires dans des hiérarchies imbriquées afin de respecter la limite. Pour plus d'informations sur les dossiers, consultez la section Créer et gérer des dossiers.

Attribuer des rôles à l'aide d'IAM

Vous pouvez contrôler l'accès aux ressources Google Cloud à l'aide de stratégies IAM. Commencez par identifier les groupes dont votre entreprise a besoin, ainsi que leur champ d'application, puis attribuez le rôle IAM approprié au groupe. Utilisez Google Groupes pour attribuer et gérer efficacement IAM pour les utilisateurs.

Centraliser le contrôle du réseau

Pour maintenir un contrôle centralisé sur les ressources réseau, telles que les sous-réseaux, les routes et les pare-feu, utilisez des réseaux VPC partagés. Les ressources d'un VPC partagé peuvent communiquer entre elles de manière plus sécurisée et plus efficace sur l'ensemble des limites des projets à l'aide d'adresses IP internes. Chaque réseau VPC partagé est défini et détenu par un projet hôte centralisé, et peut être utilisé par un ou plusieurs projets de service.

Avec un VPC partagé et IAM, vous pouvez séparer l'administration du réseau de l'administration du projet. Cette séparation vous aide à mettre en œuvre le principe du moindre privilège. Par exemple, une équipe réseau centralisée peut administrer le réseau sans disposer d'autorisations sur les projets liés. De même, les administrateurs de projet peuvent gérer leurs ressources de projet sans disposer d'autorisations sur le réseau partagé.

Lorsque vous configurez un VPC partagé, vous devez configurer les sous-réseaux et leurs plages d'adresses IP secondaires dans le VPC. Pour déterminer la taille du sous-réseau, vous devez connaître le nombre attendu de locataires, le nombre de pods et de services qu'ils sont censés exécuter, ainsi que la taille maximale et moyenne du pod. Le calcul de la capacité totale du cluster permet de comprendre la taille d'instance souhaitée, ce qui fournit le nombre total de nœuds. Une fois le nombre total de nœuds obtenu, l'espace d'adresses IP total utilisé peut être calculé, ce qui permet d'obtenir la taille de sous-réseau souhaitée.

Voici quelques facteurs à prendre en compte lors de la configuration de votre réseau :

  • Le nombre maximal de projets de service pouvant être associés à un projet hôte est de 1 000. Le nombre maximal de projets hôtes avec partage de réseaux VPC dans une entreprise unique est de 100.
  • Les plages d'adresses IP des nœuds, des pods et des services doivent toutes être uniques. Vous ne pouvez pas créer de sous-réseau dont les plages d'adresses IP principale et secondaire se chevauchent.
  • Le nombre maximal de pods et de services qu'un cluster GKE donné peut utiliser est limité par la taille des plages d'adresses IP secondaires du cluster.
  • Le nombre maximal de nœuds dans le cluster est limité par la plage d'adresses IP principale du sous-réseau du cluster et la plage d'adresses IP des pods du cluster.
  • Pour plus de flexibilité et un meilleur contrôle de la gestion des adresses IP, vous pouvez configurer le nombre maximal de pods pouvant être exécutés sur un nœud. La réduction du nombre maximal de pods par nœud vous permet également de réduire la plage CIDR allouée par nœud, ce qui nécessite moins d'adresses IP.

Pour calculer les sous-réseaux de vos clusters, vous pouvez utiliser l'outil Open Source GKE IPAM. La gestion des adresses IP permet une utilisation efficace de l'espace IP/des sous-réseaux et évite les chevauchements de plages, ce qui empêche plus tard les options de connectivité. Pour plus d'informations sur les plages réseau dans un cluster VPC, consultez la section Créer un cluster de VPC natif.

Les locataires qui nécessitent une isolation supplémentaire pour les ressources exécutées en dehors des clusters partagés (comme par exemple des VM Compute Engine dédiées) peuvent utiliser leur propre VPC qui est appairé au VPC partagé géré par l'équipe réseau. Cette méthode offre une sécurité supplémentaire au prix d'une complexité accrue et de nombreuses autres limitations. Pour plus d'informations sur l'appairage, consultez la section Utiliser l'appairage de réseaux VPC. Dans l'exemple ci-dessous, tous les locataires ont choisi de partager un seul VPC locataire (par environnement).

Créer des clusters fiables et hautement disponibles

Concevez votre architecture de clusters pour garantir une disponibilité et une fiabilité élevées en mettant en œuvre les recommandations suivantes :

  • Créez un projet d'administration de cluster par cluster pour réduire le risque de configurations au niveau du projet (par exemple, les liaisons IAM) qui peuvent avoir une incidence négative sur de nombreux clusters et pour faciliter la séparation des quotas et de la facturation. Les projets d'administration de cluster sont distincts des projets locataires que les différents locataires utilisent pour gérer, par exemple, leurs ressources Google Cloud.
  • Rendez le cluster de production privé pour désactiver l'accès aux nœuds et gérer l'accès au plan de contrôle. Nous vous recommandons également d'utiliser des clusters privés pour les environnements de développement et de préproduction.
  • Assurez-vous que le plan de contrôle du cluster est régional afin de fournir une haute disponibilité pour l'architecture mutualisée ; toute perturbation au niveau du plan de contrôle aura une incidence sur les locataires. Notez que des implications en termes de coûts sont associées à l'utilisation de clusters régionaux. Les clusters Autopilot sont préconfigurés en tant que clusters régionaux.
  • Assurez-vous que les nœuds de votre cluster couvrent au moins trois zones pour garantir une fiabilité zonale. Pour plus d'informations sur le coût du trafic de sortie entre les zones d'une même région, consultez la documentation Tarifs du réseau.
Cluster régional privé avec plan de contrôle régional couvrant trois zones
Figure 3 : Cluster régional privé avec plan de contrôle régional couvrant trois zones

Effectuer un autoscaling sur les nœuds et les ressources du cluster

Pour répondre à la demande de vos locataires, effectuez un autoscaling sur les nœuds de votre cluster en activant la fonction autoscaling. L'autoscaling permet aux systèmes d'être réactifs et opérationnels lorsque des charges de travail lourdes sont déployées par divers locataires dans leur espace de noms ou pour répondre à des pannes zonales.

Lorsque vous activez l'autoscaling, vous spécifiez le nombre minimal et maximal de nœuds dans un cluster en fonction des tailles de charges de travail attendues. En spécifiant le nombre maximal de nœuds, vous pouvez vous assurer qu'il y a suffisamment d'espace pour tous les pods du cluster, quel que soit l'espace de noms dans lequel ils s'exécutent. L'autoscaling des clusters redimensionne les pools de nœuds en fonction des limites minimale et maximale, réduisant ainsi les coûts opérationnels lorsque la charge du système diminue. Ce processus évite également que les pods passent à un état en attente lorsque les ressources du cluster disponibles sont insuffisantes. Pour déterminer le nombre maximal de nœuds, identifiez la quantité maximale de processeur et de mémoire requise par chaque locataire et additionnez-les pour obtenir la capacité totale que le cluster devrait gérer si tous les locataires avaient atteint leurs limites. En utilisant le nombre maximal de nœuds, vous pouvez alors choisir la taille et le nombre d'instances, en tenant compte de l'espace sous-réseau IP mis à la disposition du cluster.

Utilisez l'autoscaling des pods pour adapter automatiquement les pods en fonction des besoins en ressources. L'autoscaling horizontal des pods permet d'adapter le nombre de pods dupliqués selon l'utilisation du processeur/de la mémoire ou des métriques personnalisées. L'autoscaling vertical des pods peut permettre d'adapter automatiquement les besoins en ressources des pods. Il ne doit pas être utilisé avec l'autoscaling horizontal des pods, sauf si des métriques personnalisées sont disponibles, car les deux autoscalers pourraient sinon entrer en concurrence. Pour cette raison, commencez par l'autoscaling horizontal des pods, puis passez ensuite à l'autoscaling vertical des pods si nécessaire.

Déterminer la taille de votre cluster

Voici quelques facteurs importants à prendre en compte pour déterminer la taille de votre cluster :

  • La taille de votre cluster dépend du type de charge de travail que vous prévoyez d'exécuter. Si vos charges de travail sont plus volumineuses, la rentabilité est plus élevée, mais vous risquez également de créer des conflits au niveau des ressources.
  • La taille minimale d'un cluster est définie par le nombre de zones qu'il couvre : un nœud pour un cluster zonal et trois nœuds pour un cluster régional.
  • Un projet contient un maximum de 50 clusters par zone, plus 50 clusters régionaux par région.
  • Un cluster contient un maximum de 5 000 nœuds par cluster, 1 000 nœuds par pool de nœuds, 1 000 nœuds par cluster (si vous utilisez le contrôleur d'Ingress GKE), 110 pods par nœud et 300 000 conteneurs.

Programmer des intervalles de maintenance

Pour réduire les temps d'arrêt au cours des mises à niveau et de la maintenance du cluster/nœud, programmez des intervalles de maintenance pendant les heures creuses. Lors des mises à niveau, des interruptions temporaires peuvent se produire lorsque des charges de travail sont déplacées pour recréer des nœuds. Pour garantir un impact minimal de ces interruptions, essayez de programmer les mises à niveau pendant les heures creuses et concevez vos déploiements d'applications afin de gérer les interruptions partielles en toute transparence.

Configurer l'équilibrage de charge HTTP(S) avec la ressource Entrée

Pour gérer les services publiés de vos locataires et gérer le trafic entrant vers ces services, créez un équilibreur de charge HTTP(S) afin d'autoriser une seule entrée par cluster, où les services de chaque locataire sont enregistrés auprès de la ressource Entrée du cluster. Vous pouvez créer et configurer un équilibreur de charge HTTP(S) en créant une ressource d'entrée Kubernetes qui définit la manière dont le trafic atteint vos services et comment il est acheminé vers l'application de votre locataire. En enregistrant des services avec la ressource Ingress, la convention de dénomination des services devient cohérente, en affichant une seule entrée, telle que tenanta.example.com et tenantb.example.com.

Sécuriser le cluster pour l'architecture mutualisée

Contrôler la communication du pod avec les règles de réseau

Pour contrôler la communication réseau entre les pods dans chacun des espaces de noms de votre cluster, créez des règles de réseau en fonction des exigences de vos locataires. La première recommandation consiste à bloquer le trafic entre les espaces de noms qui hébergent les applications des différents locataires. Votre administrateur de cluster peut appliquer une règle de réseau deny-all pour refuser tout trafic entrant afin d'éviter que des pods d'un espace de noms envoient par inadvertance du trafic vers des services ou bases de données dans d'autres espaces de noms.

À titre d'exemple, voici une règle de réseau qui limite l'entrée de tous les autres espaces de noms à l'espace de noms tenant-a :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Exécuter des charges de travail avec GKE Sandbox

Les clusters qui exécutent des charges de travail non fiables sont plus exposés aux failles de sécurité que les autres clusters. En utilisant GKE Sandbox, vous pouvez renforcer les limites d'isolation entre les charges de travail de votre environnement mutualisé. Dans le cadre de la gestion de la sécurité, nous vous recommandons de commencer par GKE Sandbox, puis d'utiliser les règles de sécurité relatives aux pods pour combler les lacunes.

GKE Sandbox est basé sur gVisor, un projet de conteneur en bac à sable Open Source qui offre une isolation supplémentaire pour les charges de travail mutualisées en ajoutant une couche supplémentaire entre votre conteneur et le système d'exploitation hôte. L'environnement d'exécution du conteneur fonctionne souvent en tant qu'utilisateur disposant de privilèges sur le nœud et dispose d'un accès à la plupart des appels système dans le noyau hôte. Dans un cluster mutualisé, un locataire malveillant peut accéder au noyau hôte et aux données d'un autre locataire. GKE Sandbox atténue ces menaces en réduisant le besoin d'interaction directe entre un conteneur et son hôte, ce qui limite la surface d'attaque de l'hôte et réduit la marge de manœuvre des acteurs malveillants.

GKE Sandbox fournit deux limites d'isolation entre le conteneur et le système d'exploitation hôte :

  • Un noyau d'espace utilisateur, écrit en Go, qui gère les appels système et limite l'interaction avec le noyau hôte. Chaque pod dispose de son propre noyau d'espace utilisateur.
  • Le noyau d'espace utilisateur s'exécute également dans les espaces de noms et dans les appels système de filtrage seccomp.

Créer des règles de sécurité relatives aux pods

Pour empêcher l'exécution des pods dans un cluster, créez une règle de sécurité relative aux pods qui spécifie les conditions auxquelles les pods doivent répondre dans un cluster. Vous mettez en œuvre la règle de sécurité relative aux pods en activant le contrôleur d'admission et en autorisant le compte de service du pod cible à utiliser la règle. Vous pouvez autoriser l'utilisation de règles associées à un pod via le contrôle des accès basé sur les rôles Kubernetes (RBAC) en associant le pod serviceAccount à un rôle ayant accès aux règles.

Lors de la définition d'une règle relative aux pods, nous vous recommandons de définir la règle la plus restrictive liée à system:authenticated et des règles plus permissives liées si nécessaire aux exceptions.

À titre d'exemple, voici une règle restrictive relative aux pods qui exige que les utilisateurs s'exécutent en tant qu'utilisateurs non privilégiés, bloque l'éventuelle élévation vers la racine et nécessite l'utilisation de plusieurs mécanismes de sécurité :

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # The following is redundant with non-root + disallow privilege
  # escalation, but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
  # Allow core volume types.
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    # Assume that persistentVolumes set up by the cluster admin
    # are safe to use.
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # Assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535

Définissez les paramètres suivants pour éviter les élévations des privilèges sur les conteneurs :

  • Pour vous assurer qu'aucun processus enfant d'un conteneur ne peut obtenir plus de privilèges que son parent, définissez le paramètre allowPrivilegeEscalation sur false.
  • Pour interdire les élévations des privilèges en dehors du conteneur, désactivez l'accès aux composants des espaces de noms d'hôte hostNetwork, hostIPC et hostPID. Cela bloque également la surveillance de l'activité réseau des autres pod sur le même nœud.

Utiliser Workload Identity pour accorder l'accès aux services Google Cloud

Pour accorder aux charges de travail un accès sécurisé aux services Google Cloud, activez Workload Identity dans le cluster. Workload Identity permet aux administrateurs de gérer les comptes de service Kubernetes que les charges de travail Kubernetes utilisent pour accéder aux services Google Cloud. Lorsque vous créez un cluster avec la fonctionnalité Workload Identity activée, un espace de noms d'identité est créé pour le projet dans lequel le cluster est hébergé. L'espace de noms d'identité autorise le cluster à authentifier automatiquement les comptes de service pour les applications GKE en mappant le nom du compte de service Kubernetes sur un descripteur de compte de service Google virtuel, utilisé pour la liaison IAM de comptes de service Kubernetes locataires.

Limiter l'accès réseau au plan de contrôle

Pour protéger votre plan de contrôle, limitez l'accès aux réseaux autorisés. Dans GKE, lorsque vous activez les réseaux autorisés, vous pouvez autoriser jusqu'à 50 plages CIDR et autoriser uniquement les adresses IP de ces plages à accéder à votre plan de contrôle. GKE utilise déjà TLS (Transport Layer Security) et l'authentification afin de fournir un accès sécurisé au point de terminaison du plan de contrôle à partir du réseau Internet public. En utilisant des réseaux autorisés, vous pouvez restreindre davantage l'accès à des ensembles d'adresses IP spécifiés.

Provisionner des locataires

Créer des projets locataires

Pour héberger les ressources non liées aux clusters d'un locataire, créez un projet de service pour chaque locataire. Ces projets de service contiennent des ressources logiques spécifiques aux applications locataires (par exemple, journaux, surveillance, buckets de stockage, comptes de service, etc.). Tous les projets de service locataires sont connectés au VPC partagé dans le projet hôte locataire.

Utiliser RBAC pour affiner l'accès des locataires

Définissez un accès plus précis aux ressources de cluster pour vos locataires à l'aide de Kubernetes RBAC. En plus de l'accès en lecture seule initialement accordé aux groupes de locataires via IAM, définissez les rôles et les liaisons Kubernetes RBAC au niveau de l'espace de noms pour chaque groupe de locataires.

Précédemment, nous avons identifié deux groupes de locataires : les administrateurs de locataires et les développeurs de locataires. Pour ces groupes, nous allons définir les rôles et les accès RBAC suivants :

Groupe Rôle
Kubernetes RBAC
Description
Administrateur de locataire Administrateur d'espace de noms

Fournit un accès permettant de répertorier et de surveiller les déploiements dans leur espace de noms.

Fournit un accès permettant d'ajouter et de supprimer des utilisateurs dans le groupe de locataires.

Développeur de locataire Administrateur d'espace de noms,
Lecteur d'espace de noms
Fournit un accès permettant de créer, modifier et supprimer des pods, des déploiements, des services et des configmaps dans son espace de noms.

En plus de créer des rôles et des liaisons RBAC qui attribuent différentes autorisations à des groupes Google Workspace ou Cloud Identity dans leur espace de noms, les administrateurs de locataires doivent gérer les utilisateurs de chacun de ces groupes. Selon les besoins de votre entreprise, vous pouvez déléguer les autorisations Google Workspace ou Cloud Identity à l'administrateur de locataire pour gérer les membres de ses propres groupes ; l'administrateur de locataire peut également collaborer avec une équipe de votre entreprise disposant des autorisations Google Workspace ou Cloud Identity pour gérer ces modifications.

Utiliser Google Groupes pour lier les autorisations

Pour gérer efficacement les autorisations des locataires dans un cluster, vous pouvez lier les autorisations RBAC à votre service Google Groupes. Les membres de ces groupes étant gérés par vos administrateurs Google Workspace, les administrateurs de votre cluster n'ont pas besoin d'informations détaillées sur vos utilisateurs.

À titre d'exemple, nous disposons d'un groupe Google nommé tenant-admins@mydomain.com ; un utilisateur nommé admin1@mydomain.com est membre de ce groupe. La liaison suivante fournit à l'utilisateur un accès administrateur à l'espace de noms tenant-a :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Créer des espaces de noms

Pour assurer une isolation logique entre les locataires du même cluster, mettez en œuvre des espaces de noms. Dans le cadre du processus Kubernetes RBAC, l'administrateur de cluster crée des espaces de noms pour chaque groupe de locataires. L'administrateur de locataire gère les utilisateurs (développeurs de locataires) au sein de leur espace de noms de locataire respectif. Les développeurs de locataires peuvent ensuite utiliser des ressources spécifiques aux clusters et aux locataires pour déployer leurs applications.

Éviter d'atteindre les limites d'espace de noms

Le nombre maximum théorique d'espaces de noms dans un cluster est de 10 000, bien qu'en pratique, de nombreux facteurs puissent vous empêcher d'atteindre cette limite. Par exemple, vous pouvez atteindre le nombre maximal de pods (150 000) et de nœuds (5 000) au niveau du cluster avant d'atteindre le nombre maximal d'espaces de noms. D'autres facteurs, tels que le nombre de secrets, peuvent réduire davantage les limites effectives. En règle générale, il est recommandé d'essayer d'approcher la limite théorique d'une contrainte à la fois et de conserver un écart d'environ un ordre de grandeur avec les autres limites jusqu'à ce que les tests démontrent que vos cas d'utilisation fonctionnent correctement. Si vous avez besoin de davantage de ressources que celles gérées par un seul cluster, vous devez créer d'autres clusters. Pour plus d'informations sur l'évolutivité de Kubernetes, consultez l'article sur l'évolutivité des seuils Kubernetes.

Standardiser la dénomination des espaces de noms

Pour faciliter les déploiements dans plusieurs environnements hébergés dans des clusters différents, vous devez standardiser la convention de dénomination des espaces de noms que vous utilisez. Par exemple, évitez d'associer le nom de l'environnement (développement, préproduction et production) au nom de l'espace de noms et utilisez le même nom dans tous les environnements. En utilisant le même nom, vous évitez d'avoir à modifier les fichiers de configuration dans les différents environnements.

Créer des comptes de service pour les charges de travail locataires

Créez un compte de service Google propre au locataire pour chaque charge de travail distincte dans un espace de noms de locataire. Cette méthode de sécurité offre aux locataires la possibilité de gérer les comptes de service des charges de travail qu'ils possèdent et déploient dans leurs espaces de noms respectifs. Le compte de service Kubernetes pour chaque espace de noms est mappé à un compte de service Google via Workload Identity.

Appliquer des quotas au niveau des ressources

Pour vous assurer que tous les locataires partageant un cluster ont un accès équitable aux ressources du cluster, appliquez des quotas au niveau des ressources. Créez un quota au niveau des ressources pour chaque espace de noms en fonction du nombre de pods déployés par chaque locataire, et de la quantité de mémoire et de processeur requise par chaque pod.

L'exemple suivant définit un quota de ressources où les pods de l'espace de noms tenant-a peuvent demander jusqu'à 16 processeurs et 64 Go de mémoire, l'utilisation maximale du processeur étant de 32 et la capacité de mémoire maximale étant de 72.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Surveillance, journalisation et utilisation

Effectuer le suivi des métriques d'utilisation

Pour connaître la répartition des coûts sur les espaces de noms et les libellés individuels d'un cluster, vous pouvez activer la mesure de l'utilisation de GKE. La mesure de l'utilisation de GKE permet de suivre les informations relatives aux demandes de ressources et à leur utilisation par les charges de travail de votre cluster. Vous pouvez répartir davantage ces données par espaces de noms et libellés. La mesure de l'utilisation de GKE vous permet d'estimer la répartition des coûts au niveau des départements/équipes qui partagent un cluster, ainsi que de comprendre les modèles d'utilisation au niveau d'applications individuelles (ou même au niveau de composants d'une application unique). Elle permet également aux administrateurs de clusters de trier les pics d'utilisation tout en offrant une meilleure planification et budgétisation de capacité.

Lorsque vous activez la mesure de l'utilisation de GKE sur le cluster mutualisé, les enregistrements d'utilisation des ressources sont écrits dans une table BigQuery. Vous pouvez exporter des métriques spécifiques aux locataires vers des ensembles de données BigQuery dans le projet locataire correspondant que les auditeurs peuvent ensuite analyser pour déterminer les répartitions des coûts. Les auditeurs peuvent visualiser les données relatives à la mesure de l'utilisation de GKE en créant des tableaux de bord à l'aide de modèles Google Data Studio prêts à l'emploi.

Fournir des journaux spécifiques au locataire

Pour fournir aux locataires des données de journaux spécifiques à leurs charges de travail de projet, utilisez le routeur de journaux de Cloud Monitoring. Pour créer des journaux spécifiques au locataire, l'administrateur de cluster crée un récepteur permettant d'exporter les entrées de journal vers un bucket de journal créé dans le projet Google Cloud du locataire. Pour en savoir plus sur la configuration de ces types de journaux, consultez la page Journalisation mutualisée sur GKE.

Effectuer une surveillance spécifique au locataire

Pour effectuer une surveillance spécifique au locataire, l'administrateur de cluster peut utiliser un espace de noms dédié contenant un service Prometheus vers l'adaptateur Stackdriver (prometheus-to-sd) avec une configuration par espace de noms. Cette configuration permet aux locataires de surveiller uniquement leurs propres métriques dans leurs projets. Cependant, l'inconvénient de cette conception réside dans le coût supplémentaire de la gestion de vos propres déploiements Prometheus.

Voici d'autres options que vous pouvez envisager pour fournir une surveillance spécifique aux locataires :

  • Les équipes acceptent une architecture mutualisée au sein de l'environnement Cloud Monitoring et permettent aux locataires d'avoir accès à toutes les métriques du projet.
  • Déployez une seule instance Grafana par locataire qui communique avec l'environnement Cloud Monitoring partagé. Configurez l'instance Grafana pour n'afficher que les métriques d'un espace de noms spécifique. L'inconvénient de cette option réside dans le coût et les frais liés à la gestion de ces déploiements supplémentaires de Grafana.

Checklist

Le tableau suivant récapitule les tâches recommandées pour la création de clusters mutualisés dans une entreprise :

Zone Tâches
Structure de l'organisation
Gestion de l'authentification et des accès
Mise en réseau
Disponibilité et fiabilité élevées
Sécurité
Journalisation et surveillance

Étape suivante