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. Cet article suppose que vous savez comment fonctionne l'administration des ressources et des clusters Kubernetes et que vous êtes familier avec les fonctionnalités de mise en réseau de Google Cloud Platform (GCP).

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

Le schéma suivant illustre la meilleure structure 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

GCP 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 Cloud IAM (Cloud 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 opérationnelles, 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 qu'un routeur cloud. 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 ces derniers. Spécifiez l'indicateur --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.

Pour en savoir plus sur les clusters multizones et régionaux, consultez la documentation 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.

Vous trouverez ci-dessous le schéma d'une stratégie IAM qui fournit le principe du moindre privilège à deux projets : un projet de développement conçu pour permettre aux développeurs de créer et de tester leurs nouvelles fonctionnalités et corrections de bugs, et un projet de production accueillant le trafic de production.

Gestion de l'authentification et des accès

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 développement 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 production 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
production 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 production Permet de créer, de modifier et de supprimer des ressources réseau, à l'exception des règles de pare-feu et des certificats SSL.

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

Dans le projet dev, plusieurs développeurs travaillent sur la même application au sein du même cluster. Cette opération est facilitée par les espaces de noms que l'utilisateur du cluster peut créer. Chaque développeur peut générer des ressources au sein de son propre espace de noms, évitant ainsi tout conflit au niveau des noms. Les développeurs peuvent également réutiliser les mêmes fichiers de configuration YAML pour leurs déploiements, ce qui permet à leurs configurations de rester aussi proches que possible au cours des itérations de développement. De plus, les espaces de noms peuvent servir à créer des quotas relatifs à l'utilisation du processeur, de la mémoire et du stockage au sein du cluster. Cela permet de garantir qu'un développeur n'utilisera pas trop de ressources dans le cluster. La section suivante décrit comment restreindre des utilisateurs à certains espaces de noms.

Autorisation RBAC

Les clusters GKE qui exécutent Kubernetes 1.6 ou version ultérieure peuvent tirer parti des restrictions supplémentaires imposées aux utilisateurs au sein de clusters individuels. Cloud 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'interface de ligne de commande kubectl de Kubernetes utilise les identifiants actifs de l'outil gcloud, ce qui permet aux administrateurs de cluster de mapper des rôles à des identités GCP (utilisateurs et comptes de service) en tant que sujets de liaisons de rôle.

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

Autorisation RBAC

Certains rôles IAM au niveau du projet GCP 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. Vous trouverez ci-dessous un exemple de rôle permettant 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/v1beta1
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. Vous trouverez ci-dessous un exemple de liaison de notre 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/v1beta1
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 RBAC, consultez la documentation GKE.

Accès aux images et partage

Les images de Container Registry 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

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.

Partager des images entre plusieurs projets

Pour partager des images de conteneur entre plusieurs projets, vous devez vous assurer que vos nœuds Kubernetes utilisent un compte de service. Le compte de service par défaut associé à votre projet se présente au format [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 exploiter Container Registry. Utilisez toutefois un compte de service personnalisé disposant d'autorisations restreintes, car le compte 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'indicateur --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

Configurer le réseau

Kubernetes fournit l'abstraction de service qui permet d'équilibrer la charge et de rechercher des services sur des ensembles de pods au sein d'un cluster, ainsi que sur d'anciens systèmes s'exécutant en dehors de celui-ci. Les sections ci-dessous décrivent les bonnes pratiques relatives à la communication entre plusieurs pods Kubernetes et avec d'autres systèmes, y compris d'autres clusters Kubernetes.

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 recherche de services dans Kubernetes, consultez la documentation relative à la connexion d'applications avec 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 recherche 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 aux adresses IP des pods sains. 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.

Serviec ClusterIP

Pour en savoir plus sur la mise en œuvre des adresses IP de service, 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 GCP 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

La fonctionnalité d'application de la règle de réseau de Kubernetes Engine 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 Kubernetes Engine, 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 Platform

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 GCP, 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 GCP, 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 version ultérieure, vous pouvez configurer le service DNS interne du cluster (kube-dns) pour qu'il transfère les requêtes DNS d'un domaine spécifique vers un serveur DNS externe. Cette démarche s'avère utile lorsque vous possédez des serveurs DNS primaires qui peuvent être interrogés sur un domaine 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 relative aux pods et services DNS Kubernetes.

Recevoir du trafic provenant d'Internet sur le cluster

Le trafic en provenance d'Internet peut être redirigé vers vos services s'exécutant dans Kubernetes. Vous pouvez pour cela employer deux méthodes : l'équilibrage de charge réseau ou l'équilibrage de charge HTTP(S).

Les services Kubernetes doivent être créés avec le type "LoadBalancer" pour que vous puissiez utiliser l'équilibrage de charge externe TCP/UDP. Kubernetes crée un équilibreur de charge réseau dans votre projet GCP et le mappe aux nœuds de votre cluster Kubernetes Engine. Cette méthode vous permet d'obtenir facilement un équilibrage de charge pour vos charges de travail TCP et UDP, avec un travail de configuration minimal. Comme l'équilibreur de charge réseau s'applique au niveau régional, il ne peut équilibrer le trafic qu'avec les modules qui s'exécutent dans la même région.

Équilibreur de charge réseau dans la région us-west1

Si vous utilisez l'équilibrage de charge HTTP(S), il est conseillé de tirer parti de l'équilibreur de charge HTTP(S) global de Google, qui peut équilibrer le trafic sur plusieurs régions à l'aide d'une seule adresse IP Anycast. Dans Kubernetes, vous pouvez créer des ressources d'entrée qui vous permettent de mapper des noms d'hôte et des chemins d'accès aux services de votre cluster. Pour que les entrées fonctionnent correctement, vos services doivent être créés avec le type type: NodePort.

équilibrage de charge sur plusieurs régions

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'indicateur --tags sur la ligne de commande gcloud.

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

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

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

ajout de tags différents à deux clusters

Se connecter à un centre de données sur site

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

Étape suivante

  • Testez d'autres fonctionnalités de Google Cloud Platform. Découvrez nos tutoriels.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…