Parcours de formation : Applications évolutives – Créer un cluster

Créer un cluster

Une fois toutes les étapes préalables décrites dans les sections précédentes terminées, vous pouvez maintenant commencer à créer un cluster Google Kubernetes Engine et à déployer un exemple d'application.

GKE est un service Kubernetes géré que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées. Un environnement GKE est constitué de nœuds, qui sont des machines virtuelles (VM) Compute Engine, regroupées pour former un cluster.

Les clusters GKE peuvent également être regroupés dans des parcs : des groupes logiques de clusters pouvant être gérés ensemble. De nombreuses fonctionnalités de GKE Enterprise, y compris celles que vous utiliserez plus tard dans cette série de tutoriels, sont basées sur les parcs et sur les principes d'uniformité et de confiance supposés par les parcs.

• Créez un cluster GKE que vous utiliserez dans les autres tutoriels de cette série :

  gcloud container clusters create-auto scalable-apps \
    --project=PROJECT_ID \
    --region=REGION \
    --enable-fleet
  

  Remplacez les éléments suivants :

  • PROJECT_ID par l'ID généré automatiquement pour le projet que vous avez créé dans la section précédente. L'ID du projet est souvent différent du nom du projet. Par exemple, votre projet peut être scalable-apps, mais votre ID de projet peut être scalable-apps-567123.
  • REGION par la région dans laquelle vous souhaitez créer votre cluster, par exemple us-central1.

  Quelques minutes sont nécessaires pour créer le cluster et vérifier que tout fonctionne correctement.

Dans cet ensemble de tutoriels, vous allez utiliser des clusters en mode Autopilot et certaines plages d'adresses IP par défaut lorsque vous créez des clusters. Un déploiement en production de vos propres applications nécessite une planification plus minutieuse des adresses IP. En mode Autopilot, Google gère la configuration de votre cluster, y compris l'autoscaling, la sécurité et d'autres paramètres préconfigurés. Les clusters en mode Autopilot sont optimisés pour exécuter la plupart des charges de travail de production et provisionner des ressources de calcul en fonction de vos fichiers manifestes Kubernetes.

Déployer Cymbal Bank

Vous empaquetez les applications (également appelées charges de travail) dans des conteneurs. Vous déployez des ensembles de conteneurs en tant que pods sur vos nœuds.

Dans cette série de tutoriels, vous allez déployer un exemple d'application basée sur des microservices nommé Cymbal Bank sur un ou plusieurs clusters GKE. Cymbal Bank utilise Python et Java pour exécuter les différents services et inclut un backend PostgreSQL. Vous n'avez pas besoin d'expérience avec ces langages ou cette plate-forme de base de données pour suivre la série de tutoriels. Cymbal Bank n'est qu'un exemple d'application qui vous montre comment Google Kubernetes Engine (GKE) Enterprise peut répondre aux besoins de votre entreprise.

Lorsque vous utilisez Cymbal Bank dans le cadre de cet ensemble de tutoriels, les services suivants sont déployés dans votre cluster GKE :

Pour déployer Cymbal Bank dans votre cluster GKE, procédez comme suit :

1. Cymbal Bank utilise des jetons Web JSON (JWT) pour gérer l'authentification des utilisateurs. Les jetons JWT utilisent des paires de clés asymétriques pour signer et valider les jetons. Dans Cymbal Bank, userservice crée et signe des jetons avec une clé privée RSA lorsqu'un utilisateur se connecte, et les autres services utilisent la clé publique correspondante pour valider l'utilisateur.

   Créez un jeton JWT RS256 d'une force de 4 096 bits :

   openssl genrsa -out jwtRS256.key 4096
   openssl rsa -in jwtRS256.key -outform PEM -pubout -out jwtRS256.key.pub
   

   Si nécessaire, téléchargez et installez les outils OpenSSL pour votre plate-forme.

2. Un secret Kubernetes peut stocker des données sensibles telles que des clés ou des mots de passe. Les charges de travail exécutées dans votre cluster peuvent ensuite accéder au secret pour obtenir les données sensibles au lieu de les coder en dur dans l'application.

   Créez un secret Kubernetes à partir du fichier de clé que vous avez créé à l'étape précédente afin que Cymbal Bank l'utilise avec les requêtes d'authentification :

   kubectl create secret generic jwt-key --from-file=./jwtRS256.key --from-file=./jwtRS256.key.pub
   

3. Déployez Cymbal Bank sur votre cluster. La commande suivante déploie tous les fichiers manifestes dans le répertoire kubernetes-manifests. Chaque fichier manifeste déploie et configure l'un des services :

   kubectl apply -f kubernetes-manifests/accounts-db.yaml
   kubectl apply -f kubernetes-manifests/balance-reader.yaml
   kubectl apply -f kubernetes-manifests/config.yaml
   kubectl apply -f kubernetes-manifests/contacts.yaml
   kubectl apply -f extras/postgres-hpa/kubernetes-manifests/frontend.yaml
   kubectl apply -f kubernetes-manifests/ledger-db.yaml
   kubectl apply -f kubernetes-manifests/ledger-writer.yaml
   kubectl apply -f extras/postgres-hpa/loadgenerator.yaml
   kubectl apply -f kubernetes-manifests/transaction-history.yaml
   kubectl apply -f kubernetes-manifests/userservice.yaml
   

   Il est possible que des messages s'affichent dans la sortie kubectl lorsque les fichiers manifestes sont appliqués à votre cluster concernant les limites d'Autopilot. Autopilot utilise les requêtes de ressources que vous spécifiez dans la configuration de votre charge de travail pour configurer les nœuds qui les exécutent. Autopilot applique des requêtes de ressources minimales et maximales en fonction de la classe de calcul ou de la configuration matérielle utilisée par vos charges de travail. Si vous ne spécifiez pas de requêtes pour certains conteneurs, Autopilot attribue des valeurs par défaut pour permettre à ces conteneurs de s'exécuter correctement.

   Examinez l'exemple de fichier manifeste suivant pour le service frontend :

   # Copyright 2024 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       application: bank-of-anthos
       environment: development
       team: frontend
       tier: web
     name: frontend
   spec:
     ports:
       - name: http
         port: 80
         targetPort: 8080
     selector:
       app: frontend
       application: bank-of-anthos
       environment: development
       team: frontend
       tier: web
     type: LoadBalancer
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       application: bank-of-anthos
       environment: development
       team: frontend
       tier: web
     name: frontend
   spec:
     selector:
       matchLabels:
         app: frontend
         application: bank-of-anthos
         environment: development
         team: frontend
         tier: web
     template:
       metadata:
         annotations:
           proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
         labels:
           app: frontend
           application: bank-of-anthos
           environment: development
           team: frontend
           tier: web
       spec:
         containers:
           - env:
               - name: VERSION
                 value: v0.6.5
               - name: PORT
                 value: "8080"
               - name: ENABLE_TRACING
                 value: "true"
               - name: SCHEME
                 value: http
               - name: LOG_LEVEL
                 value: info
               - name: DEFAULT_USERNAME
                 valueFrom:
                   configMapKeyRef:
                     key: DEMO_LOGIN_USERNAME
                     name: demo-data-config
               - name: DEFAULT_PASSWORD
                 valueFrom:
                   configMapKeyRef:
                     key: DEMO_LOGIN_PASSWORD
                     name: demo-data-config
               - name: REGISTERED_OAUTH_CLIENT_ID
                 valueFrom:
                   configMapKeyRef:
                     key: DEMO_OAUTH_CLIENT_ID
                     name: oauth-config
                     optional: true
               - name: ALLOWED_OAUTH_REDIRECT_URI
                 valueFrom:
                   configMapKeyRef:
                     key: DEMO_OAUTH_REDIRECT_URI
                     name: oauth-config
                     optional: true
             envFrom:
               - configMapRef:
                   name: environment-config
               - configMapRef:
                   name: service-api-config
             image: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/frontend:v0.6.5@sha256:d72050f70d12383e4434ad04d189b681dc625f696087ddf0b5df641645c9dafa
             livenessProbe:
               httpGet:
                 path: /ready
                 port: 8080
               initialDelaySeconds: 60
               periodSeconds: 15
               timeoutSeconds: 30
             name: front
             readinessProbe:
               httpGet:
                 path: /ready
                 port: 8080
               initialDelaySeconds: 10
               periodSeconds: 5
               timeoutSeconds: 10
             resources:
               limits:
                 cpu: 250m
                 memory: 128Mi
               requests:
                 cpu: 100m
                 memory: 64Mi
             securityContext:
               allowPrivilegeEscalation: false
               capabilities:
                 drop:
                   - all
               privileged: false
               readOnlyRootFilesystem: true
             volumeMounts:
               - mountPath: /tmp
                 name: tmp
               - mountPath: /tmp/.ssh
                 name: publickey
                 readOnly: true
         securityContext:
           fsGroup: 1000
           runAsGroup: 1000
           runAsNonRoot: true
           runAsUser: 1000
         serviceAccountName: bank-of-anthos
         terminationGracePeriodSeconds: 5
         volumes:
           - emptyDir: {}
             name: tmp
           - name: publickey
             secret:
               items:
                 - key: jwtRS256.key.pub
                   path: publickey
               secretName: jwt-key

   Ce fichier manifeste pour le service frontend demande 100m du processeur et 64Mi, et définit des limites de 250m du processeur et de 128Mi par pod.

   Lorsque vous déployez une charge de travail dans un cluster Autopilot, GKE valide la configuration de la charge de travail par rapport aux valeurs minimales et maximales autorisées pour la classe de calcul sélectionnée ou la configuration matérielle (tels que les GPU). Si les requêtes sont inférieures au minimum, Autopilot modifie automatiquement la configuration de votre charge de travail pour que les requêtes soient comprises dans la plage autorisée. Ces messages indiquent que les limites appropriées sont attribuées automatiquement.

4. Attendez que les pods soient prêts. Exécutez la commande kubectl pour vérifier l'état des pods :

   kubectl get pods
   

   La colonne STATUS passe de Pending à ContainerCreating. Il faut quelques minutes pour que tous les pods soient à l'état Running, comme indiqué dans l'exemple de résultat suivant :

   NAME                                  READY   STATUS    RESTARTS   AGE
   accounts-db-6f589464bc-6r7b7          1/1     Running   0          99s
   balancereader-797bf6d7c5-8xvp6        1/1     Running   0          99s
   contacts-769c4fb556-25pg2             1/1     Running   0          98s
   frontend-7c96b54f6b-zkdbz             1/1     Running   0          98s
   ledger-db-5b78474d4f-p6xcb            1/1     Running   0          98s
   ledgerwriter-84bf44b95d-65mqf         1/1     Running   0          97s
   loadgenerator-559667b6ff-4zsvb        1/1     Running   0          97s
   transactionhistory-5569754896-z94cn   1/1     Running   0          97s
   userservice-78dc876bff-pdhtl          1/1     Running   0          96s
   

   Lorsque tous les pods sont à l'état Running, passez à l'étape suivante. De nouveau, il faut quelques minutes pour que tous les pods soient à l'état Running. Il est normal que certains pods indiquent l'état READY de 0/1 jusqu'à ce que Cymbal Bank soit prêt à diffuser correctement le trafic.

5. Le service frontend expose un serveur HTTP pour diffuser le site Web de Cymbal Bank, y compris la page de connexion, la page d'inscription et la page d'accueil. Un objet Ingress définit les règles de routage du trafic HTTP(S) vers des applications exécutées dans un cluster à l'aide d'un équilibreur de charge HTTP(S) Google Cloud.

   Récupérez l'adresse IP externe de l'objet Ingress frontend :

   kubectl get ingress frontend | awk '{print $4}'
   

6. Dans une fenêtre de navigateur Web, ouvrez l'adresse IP affichée dans le résultat de la commande kubectl get ingress pour accéder à votre instance de Cymbal Bank.

   Les identifiants par défaut sont renseignés automatiquement. Vous pouvez donc vous connecter à l'application et explorer certains exemples de transactions et de soldes. Vous n'avez rien à faire, si ce n'est vérifier que Cymbal Bank s'exécute correctement. La communication correcte de tous les services et la connexion à votre service peuvent prendre une ou deux minutes.

Explorer votre déploiement

Après avoir créé un cluster GKE et déployé des charges de travail, vous devrez peut-être modifier des paramètres ou examiner les performances de votre application. Dans cette section, vous allez apprendre à utiliser la console Google Cloud pour examiner les ressources faisant partie de votre cluster et l'exemple d'application Cymbal Bank.

Comme indiqué lors de la création de votre cluster, les fonctionnalités de GKE Enterprise sont basées sur le concept de parc, qui consiste en un regroupement logique de clusters Kubernetes pouvant être gérés ensemble. Par exemple, vous pouvez avoir plusieurs clusters utilisés par différentes équipes, conserver des répliques d'applications dans différentes régions à des fins de latence et de fiabilité, ou segmenter des charges de travail avec des exigences de sécurité différentes. Un parc permet d'organiser des groupes de ces clusters associés.

La page Présentation de GKE Enterprise dans la console Google Cloud vous offre une vue d'ensemble de votre parc. Lorsque vous avez créé votre cluster GKE, il a été automatiquement enregistré dans le parc à l'aide du paramètre --enable-fleet.

Pour afficher les informations sur GKE Enterprise et le parc, accédez à la page Présentation dans la console Google Cloud :

Accéder à la présentation de GKE Enterprise

La page Présentation affiche les informations suivantes :

• Nombre de clusters présents dans votre parc et s'ils sont opérationnels.
• Utilisation des ressources de votre parc, y compris l'utilisation du processeur, de la mémoire et du disque, agrégées par parc et par cluster.
• Les problèmes de sécurité identifiés pour votre parc, la couverture de Policy Controller à l'échelle de votre parc, et l'état de synchronisation de vos packages Config Sync. Vous ajouterez Policy Controller et Config Sync à votre cluster dans les prochains tutoriels de cette série.

La page Clusters GKE affiche tous les clusters dans votre projet. Le parc des clusters enregistrés dans un parc est affiché dans la colonne Parc.

Dans les sections suivantes, vous allez examiner de plus près les ressources GKE de Cymbal Bank.

Clusters

Dans ce tutoriel, vous avez créé un cluster GKE et déployé les charges de travail Cymbal Bank.

1. Sur la page Google Kubernetes Engine de la console Google Cloud, accédez à la page Clusters.

   Accéder à la page "Clusters"

2. Cliquez sur le cluster scalable-apps qui vient d'être déployé. Sur la page "Détails du cluster" qui s'affiche, vous pouvez afficher les détails de base du cluster, ainsi que ses configurations réseau et de sécurité. Vous pouvez également voir quelles fonctionnalités GKE sont activées dans ce cluster dans la section Fonctionnalités.

Observabilité

Vous pouvez afficher des métriques de base sur l'état et les performances de votre cluster. Dans le tutoriel suivant de cette série, vous activerez Google Cloud Managed Service pour Prometheus pour une surveillance et une observabilité plus précises.

1. Sélectionnez votre cluster sur la page Clusters Google Kubernetes Engine de la console Google Cloud, puis accédez à l'onglet Observabilité.

2. Examinez certains graphiques de métriques pour des éléments tels que le processeur et la mémoire. Cette vue vous permet de surveiller les performances des différentes parties des charges de travail de votre cluster sans avoir à déployer de fonctionnalités de surveillance supplémentaires.

3. Pour afficher les journaux diffusés depuis votre cluster, sélectionnez l'onglet Journaux. Vous pouvez filtrer les journaux par Gravité, ou créer vos propres filtres pour afficher des espaces de noms, des services ou des pods spécifiques. Comme pour les avertissements et les événements de pod, cette vue classée des journaux de votre cluster peut vous aider à résoudre rapidement des problèmes à l'aide de la console Google Cloud.

   Il est normal de voir les entrées de journal car Cymbal Bank est déployé pour la première fois lorsque certains services ne peuvent pas encore communiquer.

4. Sélectionnez l'onglet Erreurs de l'application. À mesure que vos charges de travail s'exécutent, vous pouvez afficher les avertissements et les événements classés dans la console Google Cloud. Cette approche permet de déboguer des problèmes sans avoir à vous connecter individuellement au cluster, aux nœuds ou aux pods.

   Encore une fois, il est normal que les événements soient enregistrés lorsque Cymbal Bank est déployé pour la première fois lorsque certains services ne peuvent pas encore communiquer.

Charges de travail

La page GKE de la console Google Cloud comporte une section Charges de travail qui affiche une vue agrégée des charges de travail exécutées sur tous vos clusters GKE.

1. Sur la page Google Kubernetes Engine de la console Google Cloud, accédez à la page Charges de travail.

   Accéder à la page "Charges de travail"

   L'onglet Présentation affiche la liste des charges de travail et des espaces de noms du cluster GKE. Vous pouvez filtrer par espace de noms pour afficher les charges de travail qui s'exécutent dans chaque espace de noms.

Services & Ingress

La vue Services et entrées affiche les ressources "Service" et "Entrée" du projet. Un Service expose un ensemble de pods en tant que service réseau avec un point de terminaison, tandis qu'un Ingress gère l'accès externe aux services dans un cluster.

1. Sur la page Google Kubernetes Engine de la console Google Cloud, accédez à la page Passerelles, services et Ingress.

   Accéder à la page "Passerelles, Services et Ingress"

2. Pour trouver l'entrée Cymbal Bank, cliquez sur l'onglet "Ingress" et recherchez l'entrée nommée frontend. Une entrée gère le trafic entrant pour votre application. Vous pouvez afficher des informations sur l'équilibreur de charge, les ports et les points de terminaison externes.

3. Cliquez sur l'adresse IP pour l'entrée frontend, par exemple 198.51.100.143:80. Cette adresse s'ouvre dans l'interface Web de Cymbal Bank.