GSP021

概要

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

このラボでは、Kubernetes Engine などのマネージド環境を使用することで、基盤となるインフラストラクチャの設定ではなく、Kubernetes を実際に使用することに焦点が置かれています。Kubernetes Engine は、コンテナ化されたアプリケーションをデプロイするためのマネージド環境です。最新のテクノロジーを利用して、デベロッパーの生産性、リソースの効率性、自動運用、オープンソースの柔軟性の向上を図り、製品化までの時間を短縮します。

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

kelseyhightower/monolith - monolith には、auth Service と hello Service が含まれます。

kelseyhightower/auth - auth マイクロサービス。認証されたユーザーに対して JWT トークンを生成します。

kelseyhightower/hello - hello マイクロサービス。認証されたユーザーに挨拶します。

nginx - auth Service と hello Service のフロントエンドです。

目標

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

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

設定と要件

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

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

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

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

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

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

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

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します）。

   ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] パネルでも [ユーザー名] を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] パネルでも [パスワード] を確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

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

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックします。

Cloud Shell をアクティブにする

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

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

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

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

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

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

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

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Google Kubernetes Engine

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

gcloud config set compute/zone {{{project_0.default_zone|Zone}}}

2. このラボで使用するクラスタを起動します。

gcloud container clusters create io --zone {{{project_0.default_zone|Zone}}} クラスタが作成されると自動的に認証が行われます。なんらかの理由で Cloud Shell への接続が失われた場合は、gcloud container clusters get-credentials io コマンドを実行して再認証してください。 注: Kubernetes Engine がバックグラウンドでいくつかの仮想マシンをプロビジョニングしているため、クラスタの作成にはしばらく時間がかかります。

タスク 1. サンプルコードを取得する

1. Cloud Shell コマンドラインからソースコードをコピーします。

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

2. このラボで必要なディレクトリに移動します。

cd orchestrate-with-kubernetes/kubernetes

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

ls

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

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

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

タスク 2. Kubernetes のクイックデモ

Kubernetes を開始する最も簡単な方法は kubectl create コマンドを使用することです。

1. このコマンドを使用して、nginx コンテナのインスタンスを 1 つ起動します。

kubectl create deployment nginx --image=nginx:1.10.0

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

Kubernetes では、すべてのコンテナが Pod で実行されます。

2. kubectl get pods コマンドを使用して、実行中の nginx コンテナを表示します。

kubectl get pods

3. nginx コンテナのステータスが Running になったら、kubectl expose コマンドを使用して Kubernetes の外部に公開できます。

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

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

4. ここで、kubectl get services コマンドを使用して、Service を一覧表示します。

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

5. 表示された外部 IP を次のコマンドに追加して、リモートから Nginx コンテナをヒットします。

curl http://<External IP>:80

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

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

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

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

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

タスク 3. Pod

Kubernetes の中核にあるのは Pod です。

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

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

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

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

Pod について、さらに詳しく説明します。

タスク 4. Pod を作成する

Pod は、Pod 構成ファイルを使用して作成できます。ここでは、monolith の Pod 構成ファイルを詳しく見てみましょう。

1. 次のディレクトリに移動します。

cd ~/orchestrate-with-kubernetes/kubernetes

2. 以下のコマンドを実行します。

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"

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

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

3. kubectl を使用して monolith Pod を作成します。

kubectl create -f pods/monolith.yaml

4. Pod を調べてみましょう。kubectl get pods コマンドを使用して、デフォルトの Namespace で実行されているすべての Pod を一覧表示します。

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

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

kubectl describe pods monolith

Pod の IP アドレスやイベントログなど、monolith Pod に関する多くの情報を確認できます。これらの情報は、トラブルシューティングで役立ちます。

Kubernetes を利用すると、Pod を構成ファイルに記述することで簡単に作成して、実行時にその情報を簡単に表示できます。この時点で、デプロイに必要なすべての Pod を作成することが可能です。

タスク 5. Pod を操作する

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

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

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

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

kubectl port-forward monolith 10080:80

3. 今度は、最初のターミナルで curl を使用して Pod との通信を開始します。

curl http://127.0.0.1:10080

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

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

curl http://127.0.0.1:10080/secure

こうなりました。

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

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

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

ログインすると JWT トークンが表示されます。

7. Cloud Shell は長い文字列のコピーをうまく処理できないため、トークンの環境変数を作成します。

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

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

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

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

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

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

kubectl logs monolith

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

kubectl logs -f monolith

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

curl http://127.0.0.1:10080

13. kubectl exec コマンドを使用して、monolith Pod 内で対話型シェルを実行します。これは、コンテナ内からトラブルシューティングを行う際に役立つことがあります。

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

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

ping -c 3 google.com

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

exit

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

タスク 6. Service

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

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

そのために Service が必要になります。Service は、Pod に安定したエンドポイントを提供します。

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

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

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

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

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

タスク 7. Service を作成する

Service を作成する前に、まず、HTTPS トラフィックを処理できる安全な Pod を作成します。

1. ディレクトリを移動した場合は、まず ~/orchestrate-with-kubernetes/kubernetes ディレクトリに戻ってください。

cd ~/orchestrate-with-kubernetes/kubernetes

2. monolith の Service 構成ファイルを調べます。

cat pods/secure-monolith.yaml

3. secure-monolith Pod とその構成データを作成します。

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

安全な Pod が用意できたので、Kubernetes Service を作成して secure-monolith Pod を外部に公開します。

4. monolith の Service 構成ファイルを調べます。

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 留意点:

* 「app: monolith」および「secure: enabled」のラベルを持つすべての Pod を自動的に検出して公開するセレクタが存在します。

* これにより、外部トラフィックをポート 31000 から nginx（ポート 443）に転送する方法が決まるため、ここでノードポートを公開する必要があります。

5. kubectl create コマンドを使用して、monolith の Service 構成ファイルから monolith Service を作成します。

kubectl create -f services/monolith.yaml

（出力）:

service/monolith created

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

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

monolith の Pod と Service を作成する

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

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

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

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

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

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

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

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

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

gcloud compute instances list

2. ここで、curl を使用して secure-monolith Service をヒットしてみます。

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

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

注: ここで、簡単な理解度チェックを行います。

次のコマンドを使用して、以下の質問に答えてください。

kubectl get services monolith

kubectl describe services monolith

質問:

monolith Service からレスポンスが得られないのはなぜでしょうか。

monolith Service にはいくつのエンドポイントがありますか。

monolith Service に認識されるためには、Pod にどのラベルが付けられている必要がありますか。

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

タスク 8. Pod にラベルを追加する

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

1. monolith ラベルで実行されている Pod がかなりあることがわかります。

kubectl get pods -l "app=monolith"

2. 「app=monolith」と「secure=enabled」の場合はどうでしょうか。

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

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

3. kubectl label コマンドを使用して、secure-monolith Pod に secure=enabled ラベルを追加し、ラベルが更新されたことを確認します。

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

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

kubectl describe services monolith | grep Endpoints

エンドポイントが 1 つ確認できるはずです。

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

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

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

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

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

Pod にラベルを追加する

タスク 9. Kubernetes でアプリケーションをデプロイする

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

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

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

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

これは良い方法です。

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

タスク 10. Deployment を作成する

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

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

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

1. 最初に、auth の Deployment 構成ファイルを調査します。

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

この Deployment によってレプリカが 1 つ作成されます。使用している auth コンテナのバージョンは 2.0.0 です。

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

2. いずれにしても、Deployment オブジェクトを作成しましょう。

kubectl create -f deployments/auth.yaml

3. auth Deployment の Service を作成します。ここでは、kubectl create コマンドを使用して auth Service を作成します。

kubectl create -f services/auth.yaml

4. 次に、同じ手順で hello Deployment を作成して公開します。

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

5. さらに、同じ手順で frontend Deployment を作成して公開します。

kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml 注: frontend を作成するためのステップはもう 1 つあります。これは、一部の構成データをコンテナで保存する必要があるからです。

6. frontend の外部 IP を取得して curl を実行し、frontend を操作します。

kubectl get services frontend 注: 外部 IP アドレスの生成には 1 分ほどかかることがあります。EXTERNAL-IP 列のステータスが pending である場合は、上記のコマンドをもう一度実行します。 curl -k https://<EXTERNAL-IP>

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

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

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。auth、hello、frontend の各 Deployment が正常に作成されている場合は、評価スコアが表示されます。

Deployment（auth、hello、frontend）を作成する

お疲れさまでした

これで完了です。Kubernetes を使用してマルチサービス アプリケーションを開発しました。ここで習得したスキルは、Deployment と Service のコレクションを使って、Kubernetes に複雑なアプリケーションをデプロイする際に役立つでしょう。

次のステップと詳細情報

• Kubernetes の最新情報は、X やコミュニティのブログでご確認ください。
• Kubernetes は、GitHub でホストされているオープンソース プロジェクトです（http://kubernetes.io/）。フィードバックや投稿をお待ちしております。

Google Cloud トレーニングと認定資格

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

マニュアルの最終更新日: 2024 年 4 月 29 日

ラボの最終テスト日: 2024 年 4 月 29 日

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