
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Create a Kubernetes cluster and launch Nginx container
/ 25
Create Monolith pods and service
/ 25
Allow traffic to the monolith service on the exposed nodeport
/ 5
Adding Labels to Pods
/ 20
Creating Deployments (Auth, Hello and Frontend)
/ 25
Kubernetes はオープンソースのプロジェクト(kubernetes.io から入手可能)で、ノートパソコンから可用性の高いマルチノード クラスタ、パブリック クラウドからオンプレミスのデプロイ、仮想マシンからベアメタルまで、さまざまな環境で実行できます。
このラボでは、Kubernetes Engine などのマネージド環境を使用することで、基盤となるインフラストラクチャの設定ではなく、Kubernetes を実際に使用することに焦点が置かれています。Kubernetes Engine は、コンテナ化されたアプリケーションをデプロイするためのマネージド環境です。最新のテクノロジーを利用して、デベロッパーの生産性、リソースの効率性、自動運用、オープンソースの柔軟性の向上を図り、製品化までの時間を短縮します。
このラボでは、次の方法について学びます。
kubectl
を使用して Docker コンテナをデプロイおよび管理する。こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します)。
ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [ユーザー名] を確認できます。
[次へ] をクリックします。
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [パスワード] を確認できます。
[次へ] をクリックします。
その後次のように進みます。
その後、このタブで Google Cloud コンソールが開きます。
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
[承認] をクリックします。
出力は次のようになります。
出力:
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
gcloud container clusters get-credentials io
コマンドを実行して再認証してください。
このサンプルは次のようなレイアウトになっています。
コードが入手できたので、今度は Kubernetes を試してみましょう。
Kubernetes を開始する最も簡単な方法は kubectl create
コマンドを使用することです。
Kubernetes が Deployment を 1 つ作成します。Deployment については後ほど詳しく説明します。ここでは、Pod が実行されているノードで障害が発生した場合でも、Deployment が Pod を稼働状態に保つことを知っていれば十分です。
Kubernetes では、すべてのコンテナが Pod で実行されます。
kubectl get pods
コマンドを使用して、実行中の nginx コンテナを表示します。kubectl expose
コマンドを使用して Kubernetes の外部に公開できます。ここでは、パブリック IP アドレスが関連付けられた外部ロードバランサが、Kubernetes によってバックグラウンドで作成されました。このパブリック IP アドレスをヒットするクライアントは、Service の背後にある Pod(このケースでは nginx Pod)にルーティングされます。
kubectl get services
コマンドを使用して、Service を一覧表示します。ExternalIP
フィールドに値が表示されるまでに数秒かかる場合がありますが、これは正常な動作です。このフィールドに値が表示されるまで、数秒ごとに kubectl get services
コマンドを再実行してください。
このように、Kubernetes はそのまま簡単に使用できるワークフローに対応しており、実行および公開用の kubectl
コマンドを使用してすぐに開始できます。
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Kubernetes クラスタの作成と Nginx コンテナのデプロイが正常に行われている場合は、評価スコアが表示されます。
ここまで Kubernetes について簡単に説明してきましたが、ここからは各コンポーネントと要約について見ていきます。
Kubernetes の中核にあるのは Pod です。
Pod は、1 つ以上のコンテナのコレクションを表しており、また保持しています。一般に、互いに強い依存関係を持つコンテナが複数存在する場合は、それらのコンテナを単一の Pod 内にパッケージ化します。
この例では、monolith コンテナと nginx コンテナを含む Pod があります。
また、Pod には Volume があります。Volume とは Pod が存在する限り存続するデータディスクで、その Pod 内のコンテナによって使用されます。Pod は、そのコンテンツに対して共有の Namespace を提供します。これは、この例の Pod 内の 2 つのコンテナが互いに通信できることと、接続された Volume を共有できることを意味します。
また、Pod はネットワーク Namespace も共有します。これは、Pod ごとに 1 つの IP アドレスがあることを意味しています。
Pod について、さらに詳しく説明します。
Pod は、Pod 構成ファイルを使用して作成できます。ここでは、monolith の Pod 構成ファイルを詳しく見てみましょう。
出力には、開いている構成ファイルが表示されます。
ここで、いくつか注目すべき点として以下のことがわかります。
kubectl
を使用して monolith Pod を作成します。kubectl get pods
コマンドを使用して、デフォルトの Namespace で実行されているすべての Pod を一覧表示します。kubectl describe
コマンドを使用して、monolith Pod に関する情報をさらに取得します。Pod の IP アドレスやイベントログなど、monolith Pod に関する多くの情報を確認できます。これらの情報は、トラブルシューティングで役立ちます。
Kubernetes を利用すると、Pod を構成ファイルに記述することで簡単に作成して、実行時にその情報を簡単に表示できます。この時点で、デプロイに必要なすべての Pod を作成することが可能です。
デフォルトでは、Pod にプライベート IP アドレスが割り当てられ、クラスタの外部から到達することはできません。ローカルポートを monolith Pod 内のポートにマッピングするには、kubectl port-forward
コマンドを使用します。
2 つ目の Cloud Shell ターミナルを開いて、2 つのターミナルを使用します。1 つで kubectl port-forward
コマンドを実行し、もう 1 つで curl
コマンドを発行します。
2 つ目のターミナルで、次のコマンドを実行してポート転送を設定します。
curl
を使用して Pod との通信を開始します。ここで、コンテナから挨拶メッセージ「hello」が返されます。
curl
コマンドを使用して、安全なエンドポイントをヒットするとどうなるか確認します。こうなりました。
password
」を使用してログインします。ログインすると JWT トークンが表示されます。
ホスト パスワードの入力を求められたら、秘密のパスワード「password
」をもう一度入力します。
このコマンドを使用してトークンをコピーしたら、そのトークンを使用して curl
で安全なエンドポイントをヒットします。
この時点でアプリケーションからレスポンスが返され、すべてが正しく実行されていることがわかります。
kubectl logs
コマンドを使用して、monolith
Pod のログを表示します。-f
フラグを使用して、リアルタイムで発生しているログのストリームを取得します。curl
を使用して monolith を操作すると、(3 つ目のターミナルで)ログが更新されるのを確認できます。kubectl exec
コマンドを使用して、monolith Pod 内で対話型シェルを実行します。これは、コンテナ内からトラブルシューティングを行う際に役立つことがあります。ping
コマンドを使用して外部接続をテストできます。このように、Pod の操作は kubectl
コマンドを使用するのと同じくらい簡単です。リモートでコンテナをヒットする必要がある場合、またはログインシェルを取得する必要がある場合は、開始して実行するのに必要なものがすべて Kubernetes から提供されます。
Pod は永続的なものではありません。実行チェックや準備チェックに失敗するなど、さまざまな理由で停止または開始することがあり、それによって問題が発生します。
Pod のセットと通信したい場合にPod を再起動すると、IP アドレスが変わることがあります。
そのために Service が必要になります。Service は、Pod に安定したエンドポイントを提供します。
Service はラベルを使用して、どの Pod を操作するかを決定します。Pod に正しいラベルが付いている場合は、Service によって自動的に Pod が取得されて公開されます。
Service が Pod のセットに提供するアクセスのレベルは、Service の種類によって異なります。現在、次の 3 つの種類があります。
ClusterIP
(内部) -- デフォルトの種類です。この Service はクラスタ内でのみ表示されます。NodePort
は、クラスタ内の各ノードに外部からアクセス可能な IP を付与します。LoadBalancer
は、Service からのトラフィックをクラスタ内のノードに転送するクラウド プロバイダからロードバランサを追加します。ここでは、以下の方法を説明します。
Service を作成する前に、まず、HTTPS トラフィックを処理できる安全な Pod を作成します。
~/orchestrate-with-kubernetes/kubernetes
ディレクトリに戻ってください。安全な Pod が用意できたので、Kubernetes Service を作成して secure-monolith Pod を外部に公開します。
(出力):
* 「app: monolith」および「secure: enabled」のラベルを持つすべての Pod を自動的に検出して公開するセレクタが存在します。
* これにより、外部トラフィックをポート 31000 から nginx(ポート 443)に転送する方法が決まるため、ここでノードポートを公開する必要があります。
kubectl create
コマンドを使用して、monolith の Service 構成ファイルから monolith Service を作成します。(出力):
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。monolith の Pod と Service が正常に作成されている場合は、評価スコアが表示されます。
Service はポートを使用して公開します。そのため、別のアプリがユーザーのいずれかのサーバー上のポート 31000 にバインドしようとすると、ポートの衝突が発生する可能性があります。
通常は、Kubernetes がこのポートの割り当てを処理します。このラボでは、後でヘルスチェックを簡単に構成できるようにポートを選択しました。
gcloud compute firewall-rules
コマンドを使用して、公開されたノードポート上の monolith Service へのトラフィックを許可します。下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。TCP トラフィックを 31000 ポートで許可するためのファイアウォール ルールが正常に作成されている場合は、評価スコアが表示されます。
すべての設定が完了したので、ポート転送を使用せずに、クラスタの外部から secure-monolith Service をヒットできるはずです。
curl
を使用して secure-monolith Service をヒットしてみます。タイムアウトしました。何が問題なのでしょうか。
注: ここで、簡単な理解度チェックを行います。
次のコマンドを使用して、以下の質問に答えてください。kubectl get services monolith
kubectl describe services monolith
質問:
ヒント: ラベルと関係があります。次のセクションで問題を解消します。
現在、monolith Service にはエンドポイントがありません。このような問題をトラブルシューティングする方法のひとつは、ラベルクエリを指定して kubectl get pods
コマンドを使用することです。
このラベルクエリでは結果が出力されません。「secure=enabled」ラベルを追加する必要があるようです。
kubectl label
コマンドを使用して、secure-monolith Pod に secure=enabled
ラベルを追加し、ラベルが更新されたことを確認します。エンドポイントが 1 つ確認できるはずです。
やりました。ヒューストン、コンタクトがありました。
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。monolith Pod にラベルが正常に追加されている場合は、評価スコアが表示されます。
このラボの目標は、本番環境でコンテナのスケーリングと管理を行えるようにすることですが、ここで必要になるのが Deployment です。Deployment は、実行中の Pod 数とユーザーによって指定された必要な Pod 数が同じであることを保証する宣言的な方法です。
Deployment の主な利点は、Pod を管理するときにシステムレベルについて細かく意識する必要がないことです。Deployment は、バックグラウンドで ReplicaSet を使って Pod の開始と停止を管理します。Pod の更新またはスケーリングが必要な場合は、Deployment がその処理を行います。また、Pod がなんらかの理由で停止した場合は、その再起動にも対応します。
簡単な例を見てみましょう。
Pod は、作成されたノードの存続期間に関連付けられています。上記の例では、Node3 が停止しています(Pod も停止)。手動で新しい Pod を作成して、そのためのノードを見つける代わりに、Deployment によって新しい Pod が作成されて Node2 で起動されました。
これは良い方法です。
ここで、Pod と Service について学んだことをすべて組み合わせ、Deployment を使って monolith アプリケーションを小さなサービスに分割しましょう。
monolith アプリを次の 3 つの部分に分割します。
Service ごとに 1 つの Deployment を作成する準備が整いました。次に、auth Deployment と hello Deployment のための内部 Service と、frontend Deployment のための外部 Service を定義します。これが完了すると、monolith のみの場合と同様にこれらのマイクロサービスを操作して、各部分を個別にスケーリングおよびデプロイできるようになります。
(出力)
この Deployment によってレプリカが 1 つ作成されます。使用している auth コンテナのバージョンは 2.0.0 です。
kubectl create
コマンドを使用して auth Deployment を作成すると、Deployment のマニフェスト内のデータに準拠する Pod が 1 つ作成されます。これは、replicas フィールドに指定された数を変更することで、Pod の数をスケーリングできることを意味しています。
kubectl create
コマンドを使用して auth Service を作成します。EXTERNAL-IP
列のステータスが pending である場合は、上記のコマンドをもう一度実行します。hello レスポンスが返されます。
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。auth、hello、frontend の各 Deployment が正常に作成されている場合は、評価スコアが表示されます。
これで完了です。Kubernetes を使用してマルチサービス アプリケーションを開発しました。ここで習得したスキルは、Deployment と Service のコレクションを使って、Kubernetes に複雑なアプリケーションをデプロイする際に役立つでしょう。
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2024 年 4 月 29 日
ラボの最終テスト日: 2024 年 4 月 29 日
Copyright 2025 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。