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

Bonnes pratiques

Établir une hiérarchie de dossiers et de projets
Attribuer des rôles à l'aide d'IAM.
Centraliser le contrôle du réseau à l'aide des VPC partagés
Créer un projet d'administration de cluster par cluster
Rendre les clusters privés
Vérifier que le plan de contrôle du cluster est régional
Vérifier que les nœuds de votre cluster couvrent au moins trois zones
Procéder à un autoscaling des nœuds et des ressources du cluster
Programmer des intervalles de maintenance pendant les heures creuses
Configurer un équilibreur de charge d'application externe avec Ingress

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.

Avec les clusters Autopilot, le scaling des pools de nœuds s'effectue automatiquement afin de répondre aux exigences de vos charges de travail.

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 15 000 nœuds par cluster (5 000 pour les versions de GKE jusqu'à 1.17), 1 000 nœuds par pool de nœuds, 1 000 nœuds par cluster (si vous utilisez le contrôleur GKE Ingress), 256 pods par nœud (110 pour les versions de GKE antérieures à 1.23.5-gke.1300), 150 000 pods par cluster et 300 000 conteneurs par cluster. Pour en savoir plus, consultez la page Quotas et limites.

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 un équilibreur de charge d'application externe avec Ingress

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

Bonnes pratiques

Contrôler la communication du pod avec les règles de réseau
Exécuter des charges de travail avec GKE Sandbox
Configurer des contrôles d'admission basés sur des règles
Utiliser la fédération d'identité de charge de travail pour GKE afin d'accorder l'accès aux services Google Cloud
Limiter l'accès réseau au plan de contrôle

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 des contrôles d'admission basés sur des règles pour pallier aux éventuels manques en la matière.

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.

Configurer des contrôles d'admission basés sur des règles

Pour empêcher que les pods qui ne respectent pas vos limites de sécurité s'exécutent dans votre cluster, vous pouvez utiliser un contrôleur d'admission. Les contrôleurs d'admission peuvent vérifier les spécifications des pods par rapport à des règles que vous définissez, et empêcher les pods qui ne respectent pas ces règles de s'exécuter dans votre cluster.

GKE est compatible avec les types de contrôle d'admission suivants :

  • Policy Controller : déclarez des règles prédéfinies ou personnalisées et appliquez-les dans des clusters à grande échelle à l'aide de parcs. Policy Controller est une mise en œuvre de l'agent Open Source Open Policy Agent Gatekeeper, et est une fonctionnalité de GKE Enterprise.

Utiliser la fédération d'identité de charge de travail pour GKE afin d'accorder l'accès aux services Google Cloud

Pour accorder aux charges de travail un accès sécurisé aux services Google Cloud, vous devez activer la fédération d'identité de charge de travail pour GKE dans le cluster. La fédération d'identité de charge de travail pour GKE 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 dans lequel vous activez la fédération d'identité de charge de travail pour GKE, 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

Bonnes pratiques

Créer des projets locataires
Utiliser RBAC pour affiner l'accès des locataires
Créer des espaces de noms pour isoler les 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.

Vous pouvez utiliser des autorisations IAM et RBAC avec des espaces de noms pour limiter les interactions des utilisateurs avec les ressources du cluster sur la console Google Cloud. Pour en savoir plus, consultez Activer l'accès et afficher les ressources de cluster par espace de noms.

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 associé à chaque espace de noms est mappé à un compte de service Google via la fédération d'identité de charge de travail pour GKE.

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

Bonnes pratiques :

Effectuer le suivi des métriques d'utilisation.
Fournir des journaux spécifiques au locataire.

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 l'attribution des coûts GKE. L'attribution des coûts GKE permet de suivre les informations relatives aux demandes de ressources et à leur utilisation par les charges de travail de votre cluster. Vous pouvez ventiler ces données de façon plus détaillée par espaces de noms et libellés. L'attribution des coûts 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 améliorant la planification et la budgétisation de la capacité.

Lorsque vous activez l'attribution des coûts GKE, le nom de cluster et l'espace de noms de vos charges de travail GKE apparaissent dans le champ "labels" de l'exportation de facturation vers BigQuery.

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

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

Étapes suivantes