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

Créer un cluster

Une fois toutes les étapes préalables des sections précédentes terminées, vous pouvez commencer à créer un cluster GKE 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.

• 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 \   --location=CONTROL_PLANE_LOCATION 

  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.
  • CONTROL_PLANE_LOCATION : région Compute Engine du plan de contrôle de votre cluster. Indiquez une région, 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 pour montrer comment GKE 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.7             - 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.7@sha256:6d92f3ce81a389738baf236477c6795831a0802c7a007697d7121f10eab9a2cc           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.

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