arrow_back

Kubernetes を使った Cloud のオーケストレーション

参加 ログイン

Kubernetes を使った Cloud のオーケストレーション

1時間 15分 クレジット: 1

GSP021

Google Cloud セルフペース ラボ

概要

このラボでは、次の方法について学びます。

  • Kubernetes Engine を使用して完全な Kubernetes クラスタをプロビジョニングする。
  • kubectl を使用して Docker コンテナをデプロイおよび管理する。
  • Kubernetes のデプロイとサービスを使用してアプリケーションをマイクロサービスに分割する。

Kubernetes はアプリケーションを取り扱うプラットフォームです。ラボのこのパートでは、「app」という名前のアプリケーション例を使用して演習を行います。

app は GitHub 上でホストされる、12 要素のサンプル アプリケーションです。このラボでは、次の Docker イメージを使用して作業します。

  • kelseyhightower/monolith - monolith には、auth サービスと hello サービスが含まれます。
  • kelseyhightower/auth - auth マイクロサービス。認証されたユーザーに対して JWT トークンを生成します。
  • kelseyhightower/hello - hello マイクロサービス。認証されたユーザーに挨拶します。
  • ngnix - auth サービスと hello サービスのフロントエンド。

9f35a311fce0abdc.png

Kubernetes はオープンソースのプロジェクト(kubernetes.io から入手可能)で、ノートパソコンから可用性の高いマルチノード クラスタ、パブリック クラウドからオンプレミスのデプロイ、仮想マシンからベアメタルまで、さまざまな環境で実行できます。

このラボでは、Kubernetes Engine などのマネージド環境を使用することで、基盤となるインフラストラクチャの設定ではなく、Kubernetes を体験することに焦点を当てます。

設定と要件

Qwiklabs の設定

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

この Qwiklabs ハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

必要なもの

このラボを完了するためには、下記が必要です。

  • 標準的なインターネット ブラウザ(Chrome を推奨)
  • ラボを完了するために十分な時間

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、ラボでは使用しないでください。

注: Chrome OS デバイスを使用している場合は、シークレット ウィンドウを開いてこのラボを実行してください。

ラボを開始して Google Cloud コンソールにログインする方法

  1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

    • [Google コンソールを開く] ボタン
    • 残り時間
    • このラボで使用する必要がある一時的な認証情報
    • このラボを行うために必要なその他の情報(ある場合)
  2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

    ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

    注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。
  3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

  4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

    重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
  5. その後次のように進みます。

    • 利用規約に同意してください。
    • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
    • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。 ナビゲーション メニュー アイコン

Google Cloud Shell の有効化

Google Cloud Shell は、デベロッパー ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Google Cloud Shell では、コマンドラインで GCP リソースにアクセスできます。

GCP Console の右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

Cloud Shell アイコン

[続行] をクリックします。

cloudshell_continue

環境のプロビジョニングと接続には少し時間がかかります。接続すると、すでに認証されており、プロジェクトは PROJECT_ID に設定されています。例えば:

Cloud Shell 端末

gcloud は Google Cloud Platform のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

ACTIVE: *
ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net
To set the active account, run:
    $ gcloud config set account `ACCOUNT`
	

次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project
	

出力:

[core]
project = <project_ID>
	

出力例:

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

Google Kubernetes Engine

Cloud Shell 環境で次のコマンドを入力して、ゾーンを設定します。

gcloud config set compute/zone us-central1-b

ゾーンを設定後、このラボで使用するクラスタを起動します。

gcloud container clusters create io

注: Kubernetes Engine がバックグラウンドでいくつかの仮想マシンをプロビジョニングしているため、クラスタの作成にはしばらく時間がかかります。

サンプルコードを取得する

次の Cloud Shell コマンドラインで、GitHub レポジトリのクローンを作成します。

gsutil cp -r gs://spls/gsp021/* .

このラボで必要に応じてディレクトリに変更します。

cd orchestrate-with-kubernetes/kubernetes

ファイルを一覧表示して、作業対象を確認します。

ls

サンプルは次のレイアウトになっています。

deployments/  /* デプロイ マニフェスト */
  ...
nginx/        /* nginx 構成ファイル */
  ...
pods/         /* Pod マニフェスト*/
  ...
services/     /* サービス マニフェスト */
  ...
tls/          /* TLS 証明書 */
  ...
cleanup.sh    /* クリーンアップ スクリプト */

コードが入手できたので、今度は Kubernetes を試してみましょう。

Kubernetes のクイックデモ

kubectl create コマンドを使用すると、Kubernetes を簡単に使い始めることができます。このコマンドを使用して、nginx コンテナのインスタンスを 1 つ起動します。

kubectl create deployment nginx --image=nginx:1.10.0

Kubernetes が Deployment を 1 つ作成します。Deployment については後ほど詳しく説明します。ここでは、ポッドが実行されているノードで障害が発生した場合でも、Deployment はポットを稼働状態に保つことを知っていれば十分です。

Kubernetes では、すべてのコンテナがポッドで実行されます。kubectl get pods コマンドを使用して、実行中の nginx コンテナを表示します。

kubectl get pods

nginx コンテナが稼働すると、kubectl expose コマンドを使用して、それを Kubernetes の外部に公開できます。

kubectl expose deployment nginx --port 80 --type LoadBalancer

ここでは、パブリック IP アドレスが関連付けられた外部ロードバランサが、Kubernetes によって背後で作成されました。そのパブリック IP アドレスをヒットするクライアントは、サービスの背後にあるポッドにルーティングされます。この場合は nginx ポッドです。

ここで、kubectl get コマンドを使用して、サービスを一覧表示します。

kubectl get services

注: サービスの ExternalIP フィールドに値が入力されるまでに数秒かかる場合がありますが、これは正常な動作です。このフィールドに値が入力されるまで、数秒ごとに kubectl get services コマンドを再実行してください。

リモートから Nginx コンテナにアクセスできるように、このコマンドに外部 IP を追加します。

curl http://<External IP>:80

このように、Kubernetes はそのまま簡単に使用できるワークフローに対応しており、実行および公開用の kubectl コマンドを使用してすぐに開始できます。

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Kubernetes クラスタの作成と Nginx コンテナのデプロイが正常に行われている場合は、評価スコアが表示されます。

Kubernetes クラスタを作成し、Nginx コンテナを起動する

ここまで kubernetes について簡単に説明してきましたが、ここからは各コンポーネントと要約について見ていきます。

ポッド

Kubernetes の中核はポッドです。

ポッドは、1 つ以上のコンテナのコレクションを表しており、また保持しています。一般に、互いに強い依存関係を持つコンテナが複数存在する場合、それらのコンテナを単一のポッド内にパッケージ化します。

fb02d86798243fcb.png

この例では、monolith コンテナと nginx コンテナを含むポッドがあります。

また、ポッドにはボリュームがあります。ボリュームとはポッドが存在する限り存続するデータディスクで、そのポッド内のコンテナによって使用できます。ポッドは、そのコンテンツに対して共有の名前空間を提供します。これは、この例のポッド内の 2 つのコンテナが互いに通信できることと、接続されたボリュームを共有できることを意味します。

また、ポッドはネットワーク名前空間も共有します。これは、ポッドごとに 1 つの IP アドレスがあることを意味しています。

ポッドについて、さらに詳しく説明します。

ポッドを作成する

ポッドは、ポッド構成ファイルを使用して作成できます。少し時間を取って monolith ポッド構成ファイルを詳しく見てみましょう。以下のコマンドを実行します。

cat pods/monolith.yaml

出力には、開いている構成ファイルが表示されます。

apiVersion: v1
kind: Pod
metadata:
  name: monolith
  labels:
    app: monolith
spec:
  containers:
    - name: monolith
      image: kelseyhightower/monolith:1.0.0
      args:
        - "-http=0.0.0.0:80"
        - "-health=0.0.0.0:81"
        - "-secret=secret"
      ports:
        - name: http
          containerPort: 80
        - name: health
          containerPort: 81
      resources:
        limits:
          cpu: 0.2
          memory: "10Mi"

ここで、いくつか注目すべき点として以下のことがわかります。

  • ポッドは 1 つのコンテナ(monolith)で構成されている。
  • コンテナの起動時に引数がいくつか渡されている。
  • http トラフィック用にポート 80 を開いている。

kubectl を使用して monolith ポッドを作成します。

kubectl create -f pods/monolith.yaml

ポッドを調べてみましょう。kubectl get pods コマンドを使用して、デフォルトの名前空間で動作するすべてのポッドを一覧表示します。

kubectl get pods

注: monolith ポッドが起動して動作するまでに数秒かかることがあります。実行する前に、monolith コンテナ イメージを Docker Hub から pull する必要があります。

ポッドが実行されたら、kubectl describe コマンドを使用して、monolith ポッドに関する情報をさらに取得します。

kubectl describe pods monolith

ポッド IP アドレスやイベントログなど、monolith ポッドに関する情報は多数あります。これらの情報は、トラブルシューティングで役立ちます。

Kubernetes は、ポッドを構成ファイルに記述することで簡単に作成できるようにし、実行時にその情報を簡単に表示できるようにしています。この時点で、デプロイに必要なすべてのポッドを作成できます。

ポッドの操作

デフォルトでは、ポッドにプライベート IP アドレスが割り当てられ、クラスタの外部から到達することはできません。ローカルポートを monolith ポッド内のポートにマッピングするには、kubectl port-forward コマンドを使用します。

ここからは、複数の Cloud Shell タブを使ってポッド間の通信を設定します。第 2 または第 3 のコマンドシェルで実行されるコマンドについては、それぞれの説明の中でその旨が示されています。

2 つの Cloud Shell ターミナルを開きます。1 つで kubectl port-forward コマンドを実行し、もう 1 つで curl コマンドを実行します。

第 2 のターミナルで、次のコマンドを実行してポート転送を設定します。

kubectl port-forward monolith 10080:80

今度は、最初のターミナルcurl を使用してポッドとの通信を開始します。

curl http://127.0.0.1:10080

これで、コンテナから挨拶メッセージ「hello」が返されます。

今度は、curl コマンドを使用して、安全なエンドポイントをヒットするとどうなるか確認します。

curl http://127.0.0.1:10080/secure

こうなりました。

では、ログインして認証トークンを monolith から取得してみましょう。

curl -u user http://127.0.0.1:10080/login

ログイン プロンプトで、秘密のパスワード「password」を使用してログインします。

ログインすると JWT トークンが表示されます。Cloud Shell は長い文字列のコピーをうまく処理できないため、トークンの環境変数を作成します。

TOKEN=$(curl http://127.0.0.1:10080/login -u user|jq -r '.token')

ホスト パスワードの入力を求められたら、秘密のパスワード「password」をもう一度入力します。

このコマンドを使用してトークンをコピーした後、そのトークンを使用して curl で安全なエンドポイントをヒットします。

curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10080/secure

この時点でアプリケーションからレスポンスが返され、すべてが正しく実行されていることがわかります。

kubectl logs コマンドを使用して、monolith ポッドのログを表示します。

kubectl logs monolith

3 つ目のターミナルを開き、-f フラグを使用して、リアルタイムで発生しているログのストリームを取得します。

kubectl logs -f monolith

最初のターミナルcurl を使用して monolith を操作すると、(3 つ目のターミナルで)ログが更新されるのを確認できます。

curl http://127.0.0.1:10080

kubectl exec コマンドを使用して、monolith ポッド内で対話型シェルを実行します。これは、コンテナ内からトラブルシューティングするときに便利な場合があります。

kubectl exec monolith --stdin --tty -c monolith /bin/sh

たとえば、monolith コンテナ内にシェルを設定すると、ping コマンドを使用して外部接続をテストできます。

ping -c 3 google.com

この対話型シェルの作業を完了したら、必ずログアウトしてください。

exit

ご覧のように、ポッドの操作は kubectl コマンドを使用するのと同様に簡単です。リモートでコンテナをヒットする必要がある場合、またはログインシェルを取得する必要がある場合、開始して実行するのに必要なものはすべて Kubernetes から提供されます。

サービス

ポッドは永続的なものではありません。実行チェックや準備チェックに失敗するなど、さまざまな理由で停止または開始することがあり、それによって問題が発生します。

ポッドのセットと通信したい場合にポッドを再起動すると、IP アドレスが変わることがあります。

そのためにサービスが必要になります。サービスは、ポッドに安定したエンドポイントを提供します。

393e02e1d49f3b37.png

サービスはラベルを使用して、どのポッドを操作するかを決定します。ポッドに正しいラベルが付いている場合、サービスによって自動的に取得されて公開されます。

サービスがポッドのセットに提供するアクセスのレベルは、サービスの種類によって異なります。現在、次の 3 つの種類があります。

  • ClusterIP(内部) -- デフォルトの種類です。このサービスはクラスタ内からのみ見えます。
  • NodePort は、クラスタ内の各ノードに外部からアクセス可能な IP を与えます。
  • LoadBalancer は、サービスからのトラフィックをクラスタ内のノードに転送するクラウド プロバイダからロードバランサを追加します。

ここでは、以下の方法を説明します。

  • サービスを作成する

  • ラベルセレクタを使用して、限定されたポッドのセットを外部に公開する

サービスの作成

サービスを作成する前に、まず https トラフィックを処理できる安全なポッドを作成しましょう。

ディレクトリを移動していた場合は、~/orchestrate-with-kubernetes/kubernetes ディレクトリに戻ったことを確認してください。

cd ~/orchestrate-with-kubernetes/kubernetes

monolith サービス構成ファイルを詳しく調べます。

cat pods/secure-monolith.yaml

安全な monolith ポッドとその構成データを作成します。

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-proxy-conf --from-file nginx/proxy.conf
kubectl create -f pods/secure-monolith.yaml

今度は安全なポッドがあるので、安全な monolith ポッドを外部に公開します。そのために、Kubernetes サービスを作成します。

monolith サービス構成ファイルを詳しく調べます。

cat services/monolith.yaml

(出力):

kind: Service
apiVersion: v1
metadata:
  name: "monolith"
spec:
  selector:
    app: "monolith"
    secure: "enabled"
  ports:
    - protocol: "TCP"
      port: 443
      targetPort: 443
      nodePort: 31000
  type: NodePort

留意点:

  1. app: monolith」および「secure: enabled」のラベルを持つすべてのポッドを自動的に検出して公開するセレクタが存在します。
  2. この方法により、外部トラフィックをポート 31000 から nginx (ポート 443 上)にどのように転送できるか決まるため、ここでノードポートを公開する必要があります。

kubectl create コマンドを使用して、monolith サービス構成ファイルから monolith サービスを作成します。

kubectl create -f services/monolith.yaml

(出力):

service/monolith created

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Monolith ポッドとサービスが正常に作成されている場合は、評価スコアが表示されます。

Monolith ポッドとサービスを作成する

サービスはポートを使用して公開します。そのため、別の app がユーザーのいずれかのサーバー上のポート 31000 にバインドしようとすると、ポートの衝突が発生する可能性があります。

通常は、Kubernetes がこのポートの割り当てを処理します。このラボでは、後でヘルスチェックを簡単に構成できるポートを選択します。

gcloud compute firewall-rules コマンドを使用して、公開されたノードポート上の monolith サービスへのトラフィックを許可します。

gcloud compute firewall-rules create allow-monolith-nodeport \
  --allow=tcp:31000

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。TCP トラフィックを 31000 ポートで許可するためのファイアウォール ルールが正常に作成されている場合は、評価スコアが表示されます。

公開されたノードポート上で monolith サービスへのトラフィックを許可する

すべての設定が完了したので、ポート転送を使用せずに、クラスタの外部から安全な monolith サービスをヒットできるはずです。

最初に、1 つのノードの外部 IP アドレスを取得します。

gcloud compute instances list

ここで、curl を使用して安全な monolith サービスをヒットしてみます。

curl -k https://<EXTERNAL_IP>:31000

タイムアウトしました。何が問題でしょうか。

ここで簡単な理解度チェックを行いましょう。次のコマンドを使用して、以下の質問に答えてください。

kubectl get services monolith

kubectl describe services monolith

質問:

  • monolith サービスからレスポンスが得られないのはなぜでしょうか。
  • monolith サービスにはいくつのエンドポイントがありますか。
  • monolith サービスでは、どのラベルによってポッドがピックアップされる必要がありますか。

ヒント: ラベルと関係があります。次のセクションで問題を修正します。

ポッドにラベルを追加する

現在、monolith サービスにはエンドポイントがありません。このような問題をトラブルシューティングする方法の 1 つは、ラベルクエリで kubectl get pods コマンドを使用することです。

monolith ラベルで実行されているポッドがかなりあることがわかります。

kubectl get pods -l "app=monolith"

しかし、「app = monolith」および「secure = enabled」の場合はどうでしょうか。

kubectl get pods -l "app=monolith,secure=enabled"

このラベルクエリでは結果が出力されません。「secure = enabled」ラベルを追加する必要があるようです。

kubectl label コマンドを使用して、安全な monolith ポッドに足りない secure=enabled ラベルを追加します。その後、ラベルが更新されたことを確認します。

kubectl label pods secure-monolith 'secure=enabled'
kubectl get pods secure-monolith --show-labels

ポッドに正しくラベルが付けられたので、monolith サービスのエンドポイントのリストを見てみましょう。

kubectl describe services monolith | grep Endpoints

確かに表示されています。

ノードの 1 つをもう一度ヒットすることで、これをテストしてみましょう。

gcloud compute instances list
curl -k https://<EXTERNAL_IP>:31000

やりました。ヒューストン、コンタクトがありました。

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。monolith ポッドにラベルが正常に追加されている場合は、評価スコアが表示されます。

ポッドにラベルを追加する

Kubernetes でアプリケーションをデプロイする

このラボの目標は、本番環境でコンテナのスケーリングと管理を行えるようにすることですが、ここで必要になるのがデプロイです。デプロイは、実行中のポッド数とユーザーによって指定された必要なポッド数が同じであることを保証する宣言的な方法です。

f96989028fa7d280.pngDeployment の主な利点は、ポッドを管理するときにシステムレベルについて細かく意識する必要がないことです。Deployment は、バックグラウンドでレプリカセットを使ってポッドの開始と停止を管理します。ポッドの更新またはスケーリングが必要な場合は、Deployment がその処理を行います。ポッドがなんらかの理由で停止した場合、デプロイはポッドの再起動も処理します。

簡単な例を見てみましょう。

b2e31eed284e4cfe.png

ポッドは、作成されたノードの存続期間に関連付けられています。上記の例では、Node3 が停止しています(ポッドも停止)。手動で新しいポッドを作成して、そのためのノードを見つける代わりに、デプロイによって新しいポッドが作成されて Node2 で起動されました。

これは良い方法です。

ここで、ポッドとサービスについて学んだことをすべて組み合わせて、デプロイを使って monolith アプリケーションを小さなサービスに分割しましょう。

デプロイを作成する

monolith アプリを次の 3 つの部分に分割します。

  • auth - 認証済みユーザー用に JWT トークンを生成します。
  • hello - 認証されたユーザーに挨拶します。
  • frontend - トラフィックを auth サービスと hello サービスにルーティングします。

サービスごとにデプロイを 1 つ作成する準備が整いました。次に、auth デプロイと hello デプロイのための内部サービスと、フロントエンド デプロイのための外部サービスを定義します。これが完了すると、monolith のみの場合と同様にマイクロサービスを操作して、各部分を個別にスケーリングおよびデプロイできるようになります。

最初に、auth デプロイ構成ファイルを検査します。

cat deployments/auth.yaml

(出力)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
spec:
  selector:
    matchlabels:
      app: auth
  replicas: 1
  template:
    metadata:
      labels:
        app: auth
        track: stable
    spec:
      containers:
        - name: auth
          image: "kelseyhightower/auth:2.0.0"
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
...

デプロイはレプリカを 1 つ作成し、バージョン 2.0.0 の auth コンテナが使用されています。

kubectl create コマンドを使用して auth デプロイを作成すると、デプロイ マニフェスト内のデータに準拠するポッドが 1 つ作成されます。これは、replicas フィールドに指定された数を変更することにより、ポッドの数をスケーリングできることを意味しています。

いずれにしても、デプロイ オブジェクトを作成しましょう。

kubectl create -f deployments/auth.yaml

auth デプロイ用のサービスを作成します。ここでは、kubectl create コマンドを使用して auth サービスを作成します。

kubectl create -f services/auth.yaml

次に、同じ手順で hello デプロイを作成して公開します。

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

もう一度、フロントエンド デプロイを作成して公開します。

kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

フロントエンドを作成するためのステップがもう 1 つあります。一部の構成データをコンテナで保存する必要があるからです。

外部 IP を取得し、それに対して curl を実行してフロントエンドを操作します。

kubectl get services frontend

:外部 IP アドレスが生成されるまでに 1 分ほどかかる場合があります。 [EXTERNAL-IP] 列のステータスが保留中の場合は、上記のコマンドを再度実行してください。

curl -k https://<EXTERNAL-IP>

hello レスポンスが返されます。

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Auth、Hello、およびフロントエンド Deployment が正常に作成されている場合は、評価スコアが表示されます。

Deployment(Auth、Hello、およびフロントエンド)を作成する

これで完了です

Kubernetes を使用してマルチサービス アプリケーションを開発しました。ここで習得したスキルを活用することで、デプロイとサービスのコレクションを使って Kubernetes に複雑なアプリケーションをデプロイできるようになります。

ac89564fa3705b3a.png 6d0798e24a18671b.png

クエストの終了

このセルフペース ラボは、Qwiklabs のクエストである「Cloud Architecture」「Kubernetes in Google Cloud」の一部です。クエストとは学習パスを構成する一連のラボのことで、完了すると成果が認められて上のようなバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、次のクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なその他の Qwiklabs のクエストもご確認ください。

次のラボの受講

次のいずれかのラボでクエストを続行しましょう。

次のステップと詳細情報

Google Cloud Training & Certification

Google Cloud 技術を最大限に活用できるようになります。このクラスでは、必要な技術力とベスト プラクティスを習得し、継続的に学習することができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、仮想環境など、多忙なスケジュールに対応できるオプションが用意されています。認定資格を取得することで、Google Cloud の技術のスキルと知識を証明できます。

マニュアルの最終更新日: 2021 年 8 月 31 日
ラボの最終テスト日: 2021 年 8 月 31 日

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。