 
始める前に
- ラボでは、Google Cloud プロジェクトとリソースを一定の時間利用します
- ラボには時間制限があり、一時停止機能はありません。ラボを終了した場合は、最初からやり直す必要があります。
- 画面左上の [ラボを開始] をクリックして開始します
Create a Kubernetes cluster
/ 5
Create the monolith pod
/ 5
Create the healthy-monolith pod
/ 5
Create a secret, service, firewall rule and pod with label
/ 5
このラボでは、次の方法について学びます。
kubectl を使用して Docker コンテナをデプロイおよび管理する。Kubernetes Engine と Kubernetes API を使用して、アプリケーションをデプロイ、管理、アップグレードします。「app」という名前のアプリケーションを例として使用し、演習を行います。
各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。
Qwiklabs にシークレット ウィンドウでログインします。
ラボのアクセス時間(例: 1:15:00)に注意し、時間内に完了できるようにしてください。
一時停止機能はありません。必要な場合はやり直せますが、最初からになります。
準備ができたら、[ラボを開始] をクリックします。
ラボの認証情報(ユーザー名とパスワード)をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。
[Google Console を開く] をクリックします。
[別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。
利用規約に同意し、再設定用のリソースページをスキップします。
Cloud Platform Console で次の API が有効になっていることを確認します。
ナビゲーション メニュー()で、[API とサービス] をクリックします。
下にスクロールして、目的の API が有効になっていることを確認します。
API が表示されていない場合は、上部にある [API とサービスの有効化] をクリックし、目的の API を見つけてプロジェクトで利用できるようにします。
Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。
Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。
[続行] をクリックします。
環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。
gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
出力:
出力例:
出力:
出力例:
Git リポジトリからサンプルコードを入手します。
git clone https://github.com/googlecodelabs/orchestrate-with-kubernetes.git
アプリケーションの構成を確認します。
cd orchestrate-with-kubernetes/kubernetes
ls
次の構造が表示されます。
| 
 | 
 | 
| 
 | 
 | 
| 
 | 
 | 
| 
 | 
 | 
| 
 | 
 | 
| 
 | 
 | 
コードの用意ができたので、Kubernetes を使用してみます。
プロジェクトのデフォルトのゾーンを定義します。こうすることで、gcloud コマンドで --zone パラメータを指定する必要がなくなります。
gcloud config set compute/zone us-central1-a
Cloud Shell で次のコマンドを実行して、5 個のノードを実行する bootcamp という Kubernetes クラスタを起動します。
gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"
scopes の引数を指定することで、Project Hosting と、後で使用する Google Cloud Storage API にアクセスできるようになります。
[進捗状況を確認] をクリックして目的を確認します。
クラスタが作成されたら、kubectl version コマンドを使用して、インストール済みの Kubernetes のバージョンを確認します。
kubectl version
kubectl cluster-info を使用して、クラスタの詳細な情報を確認します。
kubectl cluster-info
Cloud Platform Console で実行中のノードを確認します。
[ナビゲーション メニュー] を開き、[Compute Engine] > [VM インスタンス] に移動します。
Kubernetes にはオートコンプリート機能が備わっています。kubectl completion コマンドと組み込みの source コマンドを使用して設定できます。
次のコマンドを実行します。
source <(kubectl completion bash)
Tab キーを押して、利用可能なコマンドのリストを表示します。
次の例を試します。
kubectl <TAB><TAB>
コマンドの一部を入力して補完することもできます。
kubectl co<TAB><TAB>
この機能により、kubectl をより簡単に使用できます。
Kubernetes を開始する最も簡単な方法は kubectl create deployment コマンドを使用することです。
kubectl create deployment を使用して、nginx コンテナのインスタンスを 1 つ起動します。
kubectl create deployment nginx --image=nginx:1.10.0
kubectl get pods コマンドを使用して、nginx コンテナを実行しているポッドを確認します。
kubectl get pods
kubectl expose コマンドを使用して、nginx コンテナを Kubernetes の外部に公開します。
kubectl expose deployment nginx --port 80 --type LoadBalancer
kubectl get コマンドを使用して、新しいサービスを確認します。
kubectl get services
外部 IP が表示されます。この外部 IP を使うと、リモートで nginx コンテナをテストしたりアクセスしたりできます。
kubectl scale コマンドを使用して、サービスで実行中のバックエンド アプリケーション(ポッド)の数を増やします。
kubectl scale deployment nginx --replicas 3
これは、ウェブ アプリケーションの利用者数が増え、ワークロードを強化したい場合に便利です。
もう一度ポッドを取得して、Kubernetes によってポッドの数が更新されていることを確認します。
kubectl get pods
kubectl get services コマンドをもう一度使用して、外部 IP アドレスが変更されていないことを確認します。
kubectl get services
curl コマンドで外部 IP アドレスを使用して、デモ アプリケーションをテストします。
curl http://<External IP>:80
Kubernetes では、kubectl run、expose、scale の各コマンドを使用した、事前設定が不要な簡単なワークフローに対応しています。
次のコマンドを実行して、nginx をクリーンアップします。
kubectl delete deployment nginx
kubectl delete service nginx
ここまで、Kubernetes について簡単に説明してきました。ここからは、各コンポーネントと抽象化について詳しく説明していきます。
ポッドについて詳しく確認します。
ポッドは、ポッド構成ファイルを使用して作成できます。
kubectl explain コマンドを使用して、組み込みのポッドのドキュメントを確認します。
kubectl explain pods
monolith ポッド構成ファイルを確認します。
cat pods/monolith.yaml
kubectl explain コマンドで .spec オプションを使用して、API オブジェクトに関する詳細な情報を確認します。この例では、コンテナについて確認します。
kubectl explain pods.spec.containers
その他の API を確認してから続行します。
kubectl create を使用して monolith ポッドを作成します。
kubectl create -f pods/monolith.yaml
[進捗状況を確認] をクリックして目的を確認します。
kubectl get pods コマンドを使用して、デフォルトの名前空間で実行中のすべてのポッドを一覧表示します。
kubectl get pods
ポッドの実行中に、kubectl describe コマンドを使用して monolith ポッドの詳細情報を取得します。
kubectl describe pods monolith
ポッドの IP アドレスやイベントログなど、monolith ポッドに関する多くの情報を確認できます。この情報はトラブルシューティングの際に役に立ちます。
このように、Kubernetes では、構成ファイルを使ってポッドを作成したり、実行中にポッドの情報を確認したりといった操作を簡単に行えます。この時点で、デプロイに必要なポッドをすべて作成できます。
デフォルトでは、ポッドにはプライベート IP アドレスが割り当てられており、クラスタの外部からはアクセスできません。そこで、kubectl port-forward コマンドを使用して、ローカルポートを monolith ポッド内のポートにマッピングします。
2 つのターミナルを使用します。1 つで kubectl port-forward コマンドを実行し、もう 1 つで curl コマンドを実行します。
Cloud Shell の [+] ボタンをクリックして新しいターミナルを開きます。
次のコマンドを実行して、ローカルポート 10080 からポッドのポート 80(このポートをコンテナがリッスンします)へのポート転送を設定します。
kubectl port-forward monolith 10080:80
ポッドにアクセスするには、1 つ目のターミナル ウィンドウに戻り、次の curl コマンドを実行します。
curl http://127.0.0.1:10080
コンテナから「Hello」というメッセージが返されます。
secure エンドポイントにアクセスするとどうなるかを確認します。
curl http://127.0.0.1:10080/secure
エラーが表示されます。
ログインして、monolith から auth トークンを取得します。
curl -u user http://127.0.0.1:10080/login
ログイン プロンプトで、パスワードに「password」と入力してログインします。
Cloud Shell は長い文字列のコピーをうまく処理できないため、トークンを環境変数にコピーします。
TOKEN=$(curl http://127.0.0.1:10080/login -u user|jq -r '.token')
ログイン プロンプトで、パスワードに「password」と入力してログインします。
secure エンドポイントにもう一度アクセスします。今回は auth トークンを含めます。
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10080/secure
kubectl logs コマンドを使用して、monolith ポッドのログを表示します。
kubectl logs monolith
ターミナルをもう 1 つ開き、-f フラグを使用してログのストリームをリアルタイムで取得します。
3 つ目のターミナルを作成するには、Cloud Shell の [+] ボタンをクリックし、次のコマンドを実行します。
kubectl logs -f monolith
ターミナル 1 で curl を使用して、monolith を操作します。ターミナル 3 でログが更新されるのを確認できます。
curl http://127.0.0.1:10080
kubectl exec コマンドを使用して、monolith ポッド内で対話型シェルを実行します。これは、コンテナ内でトラブルシューティングを行う際に役に立つ場合があります。
kubectl exec monolith --stdin --tty -c monolith /bin/sh
省略可: シェルで ping コマンドを使用して、外部との(外部に向けた)接続をテストできます。
ping -c 3 google.com
シェルからログアウトします。
exit
このように、ポッドの操作は kubectl コマンドを使用するのと同じくらい簡単です。リモートでコンテナをテストしたり、ログインシェルを使用したりする必要がある場合、必要なものはすべて Kubernetes に用意されています。
ターミナル 2 と 3 で kubectl port-forward と kubectl logs を終了するには、Ctrl+C キーを押します。
Kubernetes では、readiness プローブと liveness プローブを使用したアプリケーションのモニタリングに対応しています。ヘルスチェックは、ポッド内の各コンテナで実行できます。readiness プローブは、ポッドがトラフィックに対応する「準備ができている」ことを確認するためのもので、liveness プローブは、コンテナが「正常」であることを確認するためのものです。liveness プローブが複数回失敗すると、コンテナは再起動されます。liveness プローブの失敗が続くと、ポッドがクラッシュ ループに陥る原因となります。readiness のチェックが失敗した場合、コンテナは「準備ができていない」とマークされ、すべてのロードバランサから削除されます。
このラボでは、healthy-monolith という名前の新しいポッドをデプロイします。このポッドは、大部分は monolith ポッドに基づいており、readiness プローブと liveness プローブが追加されています。
このラボでは、次の方法について学びます。
readiness プローブと liveness プローブのあるポッドを作成します。
readiness プローブと liveness プローブが失敗する場合のトラブルシューティングを行います。
healthy-monolith ポッド構成ファイルを確認します。
cat pods/healthy-monolith.yaml
kubectl を使用して healthy-monolith ポッドを作成します。
kubectl create -f pods/healthy-monolith.yaml
[進捗状況を確認] をクリックして目的を確認します。
readiness プローブから HTTP 200 のレスポンスが返されるまで、ポッドは「準備ができている」とマークされません。kubectl describe コマンドを使用して、healthy-monolith ポッドの詳細を確認します。
kubectl describe pod healthy-monolith
readiness プローブが失敗した場合に Kubernetes がどのようなレスポンスを返すかを確認します。monolith コンテナは、readiness プローブと liveness プローブを強制的に失敗させることができます。これにより、healthy-monolith ポッドにおけるプローブの失敗をシミュレートできます。
ターミナル 2 で kubectl port-forward コマンドを使用して、ローカルポートを healthy-monolith ポッドのヘルスチェック用ポートに転送します。
kubectl port-forward healthy-monolith 10081:81
monolith コンテナの readiness プローブを強制的に失敗させます。ターミナル 1 で curl コマンドを使用して、readiness プローブのステータスを切り替えます。このコマンドには出力がない点に注意してください。
curl http://127.0.0.1:10081/readiness/status
kubectl get pods -w コマンドを使用して、healthy-monolith ポッドのステータスを取得します。
kubectl get pods healthy-monolith -w
0/1 ready containers とコンソールに表示されたら、Ctrl+C キーを押します。kubectl describe コマンドを使用して、失敗した readiness プローブに関する詳細な情報を確認します。
kubectl describe pods healthy-monolith
healthy-monolith ポッドのイベントに、失敗した readiness プローブの詳細が表示されます。
monolith コンテナの readiness プローブを強制的に成功させるには、curl コマンドを使用して readiness プローブのステータスを切り替えます。
curl http://127.0.0.1:10081/readiness/status
約 15 秒待ち、kubectl get pods コマンドを使用して healthy-monolith ポッドのステータスを取得します。
kubectl get pods healthy-monolith
ターミナル 2 で Ctrl+C キーを押して、kubectl のプロキシ(port-forward)コマンドを閉じます。
前のチュートリアルで学んだ内容をもとに、kubectl port-forward コマンドと curl コマンドを使用して、monolith コンテナの liveness プローブを強制的に失敗させます。liveness プローブが失敗した場合に Kubernetes がどのようなレスポンスを返すかを確認します。
kubectl port-forward コマンドを使用して、ローカルポートをターミナル 2 の healthy-monolith ポッドのヘルスチェック用ポートに転送します。
kubectl port-forward healthy-monolith 10081:81
monolith コンテナの readiness プローブを強制的に成功させるには、もう 1 つのターミナルで curl コマンドを使用して readiness プローブのステータスを切り替えます。
curl http://127.0.0.1:10081/healthz/status
kubectl get pods -w コマンドを使用して、healthy-monolith ポッドのステータスを取得します。
kubectl get pods healthy-monolith -w
liveness プローブが失敗すると、コンテナは再起動されます。再起動されると、healthy-monolith ポッドは健全な状態に戻ります。ポッドが再起動されたら、Ctrl+C キーを押してコマンドを終了します。再起動の回数を記録しておきます。
kubectl describe コマンドを使用して、失敗した liveness プローブの詳細を確認します。liveness プローブが失敗してポッドが再起動されたときの関連イベントが表示されます。
kubectl describe pods healthy-monolith
終了したら、ターミナル 2 で Ctrl+C キーを押して、kubectl proxy コマンドを閉じます。
次のステップ:
サービスを作成します。
ラベルセレクタを使用して、ポッドの一部を外部に公開します。
サービスを作成する前に、HTTPS トラフィックに対応できる secure-monolith という nginx サーバーで、安全なポッドを作成します。
安全なポッドがデータを取り込む(または消費する)ために使用するボリュームを 2 つ作成します。
secret タイプの 1 つ目のボリュームには、nginx サーバーの TLS 証明書ファイルを保存します。
ターミナル 1 に戻り、次のコマンドを使用して 1 つ目のボリュームを作成します。
kubectl create secret generic tls-certs --from-file tls/
ConfigMap タイプの 2 つ目のボリュームを作成して、nginx の構成ファイルを格納します。
kubectl create configmap nginx-proxy-conf --from-file nginx/proxy.conf
nginx が使用する proxy.conf ファイルを確認します。
cat nginx/proxy.conf
ファイルでは、SSL がオンに指定されています。また、コンテナのファイル システム内での証明書ファイルの場所も指定されています。
secure-monolith ポッド構成ファイルを確認します。
cat pods/secure-monolith.yaml
次のコマンドを実行して、構成データを含む secure-monolith ポッドを作成します。
kubectl create -f pods/secure-monolith.yaml
安全なポッドが用意できたので、Kubernetes サービスを使用して secure-monolith ポッドを外部に公開します。
monolith サービス構成ファイルを確認します。
cat services/monolith.yaml
kubectl create コマンドを使用して、monolith サービス構成ファイルから monolith サービスを作成します。
kubectl create -f services/monolith.yaml
通常は、Kubernetes がこのポートの割り当てを処理します。このラボでは、後で簡単にヘルスチェックを設定できるように自分で選択しました。
gcloud compute firewall-rules コマンドを使用して、公開済みノードポート上の monolith サービスへのトラフィックを許可します。
gcloud compute firewall-rules create allow-monolith-nodeport --allow=tcp:31000
すべての設定が完了したので、ポート転送を使用せずに、クラスタの外部から secure-monolith サービスをテストできます。
いずれかのノードに対応する IP アドレスを取得します。
gcloud compute instances list
ブラウザで次の URL を開いてみます。
https://<EXTERNAL_IP>:31000
現在、monolith サービスにエンドポイントが見つかりません。このような問題をトラブルシューティングする方法のひとつは、ラベルクエリを指定して kubectl get pods コマンドを使用することです。
monolith ラベルが付いた実行中のポッドが複数あることを特定します。
kubectl get pods -l "app=monolith"
app=monolith と secure=enabled の場合はどうでしょうか。
kubectl get pods -l "app=monolith,secure=enabled"
kubectl label コマンドを使用して、不足している secure=enabled ラベルを secure-monolith ポッドに追加します。
kubectl label pods secure-monolith 'secure=enabled'
[進捗状況を確認] をクリックして目的を確認します。
ラベルが更新されたことを確認します。
kubectl get pods secure-monolith --show-labels
monolith サービスのエンドポイントの一覧を確認します。
kubectl get endpoints monolith
いずれかのノードをもう一度テストして確認します。
gcloud compute instances list | grep gke-
ブラウザで次の URL を開きます。secure-monolith で自己署名証明書が使用されているため、先に進むには SSL の警告をクリックする必要があります。
https://<EXTERNAL_IP>:31000
ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。
ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。
星の数は、それぞれ次の評価を表します。
フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。
フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。
Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。
 
 
 
 
このコンテンツは現在ご利用いただけません
利用可能になりましたら、メールでお知らせいたします
 
ありがとうございます。
利用可能になりましたら、メールでご連絡いたします
 
 
1 回に 1 つのラボ
既存のラボをすべて終了して、このラボを開始することを確認してください
