学習プログラム: スケーラブルなアプリケーション - クラスタを作成する

このチュートリアルは、Google Kubernetes Engine（GKE）Enterprise エディションで実行される最新のアプリケーション環境をデプロイ、実行、管理することを目的とする IT 管理者とオペレーターを対象としています。このチュートリアルでは、Cymbal Bank サンプル マイクロサービス アプリケーションを使用して、モニタリングとアラートの設定、ワークロードのスケーリング、障害のシミュレーションの方法を学習します。

  1. クラスタを作成し、サンプル アプリケーションをデプロイする（このチュートリアル）
  2. Google Cloud Managed Service for Prometheus でモニタリングする
  3. ワークロードをスケーリングする
  4. 障害をシミュレートする

概要と目的

Cymbal Bank は、Python と Java を使用してさまざまなサービスを実行し、PostgreSQL バックエンドを備えています。Cymbal Bank は、GKE Enterprise がビジネスのニーズをどのようにサポートできるかを示したサンプル アプリケーションであるため、これらの言語やデータベース プラットフォームの経験がなくても、一連のチュートリアルを完了できます。

このチュートリアルでは、単一の GKE クラスタを作成し、Cymbal Bank という名前のマイクロサービス ベースのサンプル アプリケーションを GKE クラスタにデプロイする方法を学習します。次のタスクを完了する方法を学習します。

  • Autopilot を使用する GKE クラスタを作成します。

  • Cymbal Bank という名前のマイクロサービス ベースのサンプル アプリケーションをデプロイします。

  • Google Cloud コンソールを使用して、Cymbal Bank サンプル アプリケーションで使用される GKE リソースを確認します。

費用

この一連のチュートリアルで GKE Enterprise を有効にして Cymbal Bank サンプル アプリケーションをデプロイすると、GKE Enterprise を無効にするかプロジェクトを削除するまで、料金ページに記載されているように、Google Cloud の GKE Enterprise に対してクラスタごとの料金が発生します。

また、Compute Engine VM やロードバランサの費用など、Cymbal Bank サンプル アプリケーションの実行中に発生した他の Google Cloud の費用もお客様の負担となります。

始める前に

このシリーズの最初のチュートリアルでは、ほとんどの場合、すべての GKE ユーザーが利用できるコア機能を使用しますが、チュートリアルを進めていくと、エンタープライズ ティアでのみ利用可能な追加機能を使用します。

このシリーズの最初のチュートリアルでは、始める前に、次の「始める前に」の設定手順をすべて完了してください。次の「始める前に」の手順は、1 回だけ行う必要があります。

シェルとツールを構成する

このチュートリアル シリーズでは、次のツールを使用して環境をデプロイして管理します。

  • gcloud CLI: GKE クラスタとフリート、その他の Google Cloud サービスを作成して管理します。
  • kubectl: GKE Enterprise で使用されるクラスタ オーケストレーション システムである Kubernetes を管理します。

このページにあるコマンドを実行するには、次のいずれかの開発環境で Google Cloud CLI と kubectl を設定します。

Cloud Shell

gcloud CLI と kubectl がすでに設定されているオンライン ターミナルを使用するには、Cloud Shell をアクティブにします。

このページの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。セッションが初期化されるまで数秒かかることがあります。

ローカルシェル

ローカル開発環境を使用する手順は次のとおりです。

プロジェクトを設定する

次の手順で、請求と GKE サービスの有効化を含めて、Google Cloud プロジェクトを設定します。これは、GKE Enterprise を有効にするプロジェクトです。

プロジェクトを作成または使用し、API を有効にするためのアクセス権を付与するには、組織の Google Cloud 管理者の承認が必要になる場合があります。

  1. Google Cloud コンソールで、Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine ページに移動

  2. プロジェクトを作成または選択します。これは、GKE Enterprise を有効にするプロジェクトです。

  3. プロンプトが表示されたら、GKE Enterprise API を有効にします。

  4. API と関連サービスが有効になるのを待ちます。これには数分かかることがあります。

  5. Google Cloud プロジェクトで課金が有効になっていることを確認します。

GKE を有効にしたら、Google Kubernetes Engine（GKE）Enterprise エディションを有効にします。

  1. Google Cloud コンソールで、[GKE Enterprise] ページに移動します。

    [GKE Enterprise] ページに移動

  2. [Learn about Google Kubernetes Engine (GKE) Enterprise edition] を選択します。

  3. 対象となる場合は、[90 日間の無料試用を開始] チェックボックスをオンにします。

  4. [GKE Enterprise の有効化] を選択し、[確認] を選択します。

IAM ロールを付与する

プロジェクト オーナーの場合（プロジェクトを自分で作成した場合など）は、これらのチュートリアルを完了するために必要なすべての権限がすでに付与されています。オーナーでない場合は、Google Cloud アカウントに、このチュートリアルで選択したプロジェクトに必要な IAM ロールがあることを確認してください。繰り返しになりますが、必要なロールを付与するには、組織の Google Cloud 管理者の承認が必要になる場合があります。

次のコマンドで、PROJECT_ID を、前のセクションで作成または選択したプロジェクトの自動生成された ID に置き換えます。プロジェクト ID は、多くの場合、プロジェクト名とは異なります。たとえば、プロジェクト名は scalable-apps で、プロジェクト ID は scalable-apps-567123 となります。

Google アカウントにロールを付与します。次の IAM ロールごとに次のコマンドを 1 回実行します。 roles/resourcemanager.projectIamAdmin, roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser, roles/iam.securityAdmin, roles/serviceusage.serviceUsageAdmin, roles/container.admin, roles/logging.logWriter, roles/gkehub.admin, roles/viewer, roles/monitoring.viewer 

$ gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS" --role=ROLE
  • PROJECT_ID は、実際のプロジェクト ID に置き換えます。
  • EMAIL_ADDRESS は実際のメールアドレスに置き換えます。
  • ROLE は、個々のロールに置き換えます。

サンプル アプリケーションのクローンを作成する

Cymbal Bank のすべてのサンプル マニフェストが含まれる Git リポジトリのクローンを作成します。

  git clone https://github.com/GoogleCloudPlatform/bank-of-anthos
  cd bank-of-anthos/

クラスタを作成する

前のセクションのすべての前提条件の手順が完了したら、Google Kubernetes Engine クラスタの作成とサンプル アプリケーションのデプロイを開始できます。

GKE は、コンテナ化されたアプリケーションのデプロイと運用に使用できるマネージド Kubernetes サービスです。GKE 環境はノードで構成されます。ノードは Compute Engine 仮想マシン（VM）であり、グループ化されてクラスタを形成します。

GKE クラスタは、フリート（一緒に管理できるクラスタの論理グループ）にグループ化することもできます。このチュートリアル シリーズの後半で使用する機能を含めて、GKE Enterprise の多くの機能は、フリートと、フリートが想定する同一性と信頼の原則に基づいています。

  • このシリーズの残りのチュートリアルで使用する GKE クラスタを作成します。

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

    次のように置き換えます。

    • PROJECT_ID は、前のセクションで作成したプロジェクトの自動生成された ID に置き換えます。プロジェクト ID は、多くの場合、プロジェクト名とは異なります。たとえば、プロジェクト名は scalable-apps で、プロジェクト ID は scalable-apps-567123 となります。
    • REGION は、クラスタを作成するリージョン（us-central1 など）に置き換えます。

    クラスタを作成して、すべてが正しく動作することを確認するまで数分ほどかかります。

このチュートリアルでは、クラスタを作成するときに Autopilot モードのクラスタとデフォルトの IP アドレス範囲を使用します。独自のアプリケーションの本番環境のデプロイでは、IP アドレスを慎重に計画する必要があります。Autopilot モードでは、自動スケーリング、セキュリティなどの事前構成済みの設定を含むクラスタの構成が Google によって管理されます。Autopilot モードのクラスタは、ほとんどの本番環境ワークロードを実行するように最適化されており、Kubernetes マニフェストに基づいてコンピューティング リソースをプロビジョニングします。

Cymbal Bank をデプロイする

アプリ（ワークロードとも呼ばれます）をコンテナにパッケージ化します。コンテナのセットを Pod としてノードにデプロイします。

このチュートリアル シリーズでは、Cymbal Bank という名前のマイクロサービス ベースのサンプル アプリケーションを 1 つ以上の GKE クラスタにデプロイします。Cymbal Bank は、Python と Java を使用してさまざまなサービスを実行し、PostgreSQL バックエンドを備えています。これらの言語やデータベース プラットフォームの経験がなくても、一連のチュートリアルを完了できます。Cymbal Bank は、Google Kubernetes Engine（GKE）Enterprise エディションがビジネスのニーズをどのようにサポートできるかを示したサンプル アプリケーションにすぎません。

このチュートリアル セットの一部として Cymbal Bank を使用すると、次のサービスが GKE クラスタにデプロイされます。

サービス 言語 説明
frontend Python ウェブサイトを提供するための HTTP サーバーを公開します。ログインページ、登録ページ、ホームページが含まれています。
ledger-writer Java 受信トランザクションを受け入れて妥当性を確認した後、台帳に書き込みます。
balance-reader Java ledger-db から読み取られたユーザーの残高を効率的に読み取るためのキャッシュを提供します。
transaction-history Java ledger-db から読み取られた過去のトランザクションを効率的に読み取りためのキャッシュを提供します。
ledger-db PostgreSQL すべてのトランザクションの台帳。デモユーザーのトランザクションを事前入力するオプション。
user-service Python ユーザー アカウントと認証を管理します。他のサービスによる認証に使用される JWT に署名します。
contacts Python ユーザーに関連付けられている他のアカウントのリストを保存します。[Send Payment] フォームと [Deposit] フォームのプルダウンに使用されます。
accounts-db PostgreSQL ユーザー アカウントと関連データ用のデータベース。デモユーザーを事前入力するオプション。
loadgenerator Python / Locust ユーザーを模倣したリクエストをフロントエンドに継続的に送信します。定期的に新しいアカウントを作成し、それらのアカウント間のトランザクションをシミュレートします。

Cymbal Bank を GKE クラスタにデプロイする手順は次のとおりです。

  1. Cymbal Bank は、JSON Web Token（JWT）を使用してユーザー認証を処理します。JWT は、非対称鍵ペアを使用してトークンに署名して検証します。Cymbal Bank では、userservice がユーザーのログイン時に RSA 秘密鍵を使用してトークンを作成して署名し、他のサービスが対応する公開鍵を使用してユーザーを検証します。

    4,096 ビットの強度の RS256 JWT を作成します。

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

    必要に応じて、プラットフォーム用の OpenSSL ツールをダウンロードしてインストールします。

  2. Kubernetes Secret には、鍵やパスワードなどのセンシティブ データを保存できます。クラスタで実行されるワークロードは、アプリケーションにセンシティブ データをハードコードする代わりに、Secret にアクセスしてセンシティブ データを取得できます。

    認証リクエストで Cymbal Bank が使用できるように、前の手順で作成した鍵ファイルから Kubernetes Secret を作成します。

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

  3. Cymbal Bank をクラスタにデプロイします。次のコマンドでは、kubernetes-manifests ディレクトリ内のすべてのマニフェスト ファイルをデプロイします。各マニフェスト ファイルは、次のいずれかのサービスを実装して構成します。

    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

    マニフェストが Autopilot の制限についてクラスタに適用されると、kubectl 出力にメッセージが表示されることがあります。Autopilot は、ワークロード構成に指定したリソース リクエストを使用して、ワークロードを実行するノードを構成します。Autopilot は、ワークロードが使用するコンピューティング クラスまたはハードウェア構成に基づいて、リソースの最小リクエストと最大リクエストを適用します。一部のコンテナのリクエストを指定していない場合、Autopilot は、コンテナが正常に実行されるようにデフォルト値を割り当てます。

    frontend Service 用の次のサンプル マニフェストを確認します。

    # 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.4
            - 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.4@sha256:f25db63509515fb6caf98c8c76e906f3c2868e345767d12565ab3750e52963f0
          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

    frontend Service のこのマニフェストは、CPU の 100m と 64Mi をリクエストし、CPU の 250m と Pod あたりの 128Mi の上限を設定します。

    Autopilot クラスタにワークロードをデプロイすると、選択したコンピューティング クラスまたはハードウェア構成（GPU など）で許容される最小値と最大値に対してワークロード構成が GKE により検証されます。リクエストが最小値未満の場合は、Autopilot がワークロード構成を自動的に変更し、リクエストが許容範囲に収まるようにします。これらのメッセージは、適切な上限が自動的に割り当てられていることを示しています。

  4. Pod の準備が整うまで待ちます。kubectl を使用して Pod のステータスを確認します。

    kubectl get pods

    STATUS 列が Pending から ContainerCreating に変更されます。次の出力例に示すように、すべての Pod が Running 状態になるまで数分かかります。

    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

    すべての Pod が Running 状態になったら、次のステップに進みます。繰り返しになりますが、すべての Pod が Running 状態になるまでには数分ほどかかります。Cymbal Bank がトラフィックを正しく処理できるようになるまで、一部の Pod が READY ステータスを 0/1 と報告するのは正常です。

  5. frontend サービスは、Cymbal Bank のウェブサイト（ログインページ、登録ページ、ホームページを含む）を提供するための HTTP サーバーを公開します。Ingress オブジェクトは、Google Cloud HTTP(S) ロードバランサを使用してクラスタで実行されているアプリケーションに HTTP(S) トラフィックをルーティングするルールを定義します。

    frontend Ingress の外部 IP アドレスを取得します。

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

  6. ウェブブラウザ ウィンドウで、kubectl get ingress コマンドの出力に表示された IP アドレスを開き、Cymbal Bank のインスタンスへのアクセスを開始します。

    デフォルトの認証情報が自動的に入力されます。アプリにログインして、サンプルの取引と残高を確認できます。Cymbal Bank が正常に実行されていることを確認する以外に、特別な操作は必要ありません。すべてのサービスが正しく通信してログインできるようになるまでに 1～2 分かかることがあります。

デプロイを確認する

GKE クラスタを作成してワークロードをデプロイした後、設定の変更やアプリケーションのパフォーマンスの確認を行う必要があります。このセクションでは、Google Cloud コンソールを使用して、クラスタと Cymbal Bank サンプル アプリケーションに含まれるリソースを確認する方法について説明します。

クラスタの作成時に説明したように、GKE Enterprise の機能はフリートという考え方に基づいて構築されています。フリートとは、一緒に管理できる Kubernetes クラスタの論理グループです。Google Cloud コンソールの GKE Enterprise の概要では、フリート全体の概要を確認できます。GKE クラスタを作成すると、--enable-fleet パラメータを使用してフリートに自動的に登録されます。

GKE Enterprise とフリートの情報を確認するには、Google Cloud コンソールの [概要] ページに移動します。

GKE Enterprise の概要に移動する

[概要] ページには、次の情報が表示されます。

  • フリート内のクラスタ数と、それらのクラスタが正常かどうか。
  • フリートのリソース使用率（CPU、メモリ、ディスク使用率など）をフリートとクラスタごとに集計した値。
  • フリートで特定されたセキュリティ上の問題、フリート全体の Policy Controller のカバレッジ、Config Sync パッケージの同期ステータス。このシリーズの以降のチュートリアルでは、Policy Controller と Config Sync をクラスタに追加します。

GKE の [クラスタ] ページには、プロジェクト内のすべてのクラスタが表示されます。フリートに登録されているクラスタは、[フリート] 列に表示されます。

以降のセクションでは、Cymbal Bank の GKE リソースについて詳しく説明します。

クラスタ

このチュートリアルでは、GKE クラスタを 1 つ作成し、Cymbal Bank ワークロードをデプロイしました。

  1. Google Cloud コンソールの [Google Kubernetes Engine] ページで、[クラスタ] ページに移動します。

    [クラスタ] ページに移動

  2. 新しくデプロイされた scalable-apps クラスタをクリックします。表示されたクラスタの詳細ページで、クラスタの基本情報と、クラスタのネットワーク構成とセキュリティ構成を確認できます。このクラスタでどの GKE 機能が有効になっているかは、[機能] セクションで確認できます。

オブザーバビリティ

クラスタの健全性とパフォーマンスに関する基本的な指標を表示できます。このシリーズの次のチュートリアルでは、よりきめ細かいモニタリングとオブザーバビリティを実現するために、Google Cloud Managed Service for Prometheus を有効にします。

  1. Google Cloud コンソールの Google Kubernetes Engine の [クラスタ] ページでクラスタを選択し、[オブザーバビリティ] タブに移動します。

  2. CPU やメモリなどの指標グラフィックをいくつか調べます。このビューを使用すると、追加のモニタリング機能をデプロイすることなく、クラスタ ワークロードのさまざまな部分のパフォーマンスをモニタリングできます。

  3. クラスタからストリーミングされたログを表示するには、[ログ] タブを選択します。ログの重大度でフィルタすることも、独自のフィルタを作成して、特定の名前空間、Service、Pod を表示することもできます。Pod の警告やイベントと同様に、クラスタからのログを集計して表示することで、Google Cloud コンソールで問題を迅速にデバッグできます。

    一部のサービスがまだ通信できないときに Cymbal Bank が最初にデプロイされるため、ログエントリが表示されるのは正常です。

  4. [アプリのエラー] タブを選択します。ワークロードの実行中に、Google Cloud コンソールで収集された警告とイベントを表示できます。このアプローチを使用すると、クラスタ、ノード、Pod に個別に接続することなく、問題のデバッグを行うことができます。

    繰り返しになりますが、一部のサービスがまだ通信できないときに、Cymbal Bank が最初にデプロイされたときにイベントがログに記録されるのは正常です。

ワークロード

Google Cloud コンソールの GKE ページの [ワークロード] セクションには、すべての GKE クラスタで実行されているワークロードの集計ビューが表示されます。

  1. Google Cloud コンソールの [Google Kubernetes Engine] ページで、[ワークロード] ページに移動します。

    [ワークロード] ページに移動

    [概要] タブには、GKE クラスタのワークロードと Namespace のリストが表示されます。Namespace でフィルタして、各 Namespace で実行されているワークロードを確認できます。

Service と Ingress

[Services と Ingress] ビューには、プロジェクトの Service リソースと Ingress リソースが表示されます。Service では一連の Pod がエンドポイントでネットワーク サービスとして公開され、Ingress ではクラスタ内の Service への外部アクセスが管理されます。

  1. Google Cloud コンソールの [Google Kubernetes Engine] ページで、[Gateway、Service、Ingress] ページに移動します。

    [Gateway、Service、Ingress] ページに移動

  2. Cymbal Bank Ingress を見つけるには、[Ingress] タブをクリックし、frontend という名前の Ingress を探します。Ingress は、アプリケーションの受信トラフィックを管理します。ロードバランサ、ポート、外部エンドポイントに関する情報を表示できます。

  3. frontend Ingress の IP アドレス（198.51.100.143:80 など）をクリックします。このアドレスでは、Cymbal Bank のウェブ インターフェースが表示されます。

クリーンアップ

Cymbal Bank のチュートリアル セットは、順番に完了するように設計されています。チュートリアルを進めていくと、新しいスキルを習得し、追加の Google Cloud プロダクトとサービスを使用できるようになります。

次のチュートリアルに進む前に中断する場合、このチュートリアルで使用したリソースについて Google Cloud アカウントに課金されないようにするには、作成したプロジェクトを削除します。

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

次のチュートリアルで、Google Cloud Managed Service for Prometheus と Cloud Monitoring を使用して GKE Enterprise でワークロードをモニタリングする方法を学習する。