チェックポイント
Deploy GKE clusters
/ 30
Deploy Pods to GKE clusters
/ 35
Deploy a new pod using a Yaml file
/ 35
Cloud Shell を使用して GKE Autopilot クラスタをデプロイする
概要
このラボでは、コマンドラインを使用した GKE クラスタの構築と kubeconfig ファイルの検査を行い、クラスタの操作に kubectl
を使用します。
目標
このラボでは、次のタスクについて学びます。
-
kubectl
を使用して GKE クラスタを構築し、操作する -
kubectl
と構成ファイルを使用して Pod をデプロイする - Container Registry を使用してコンテナを保存し、デプロイする
ラボの設定
Qwiklabs にアクセスする
各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。
-
Qwiklabs にシークレット ウィンドウでログインします。
-
ラボのアクセス時間(例:
1:15:00
)に注意し、時間内に完了できるようにしてください。
一時停止機能はありません。必要な場合はやり直せますが、最初からになります。 -
準備ができたら、[ラボを開始] をクリックします。
-
ラボの認証情報(ユーザー名とパスワード)をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。
-
[Google Console を開く] をクリックします。
-
[別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。 -
利用規約に同意し、再設定用のリソースページをスキップします。
最初のログイン手順を完了すると、プロジェクト ダッシュボードが表示されます。
Cloud Shell を開く
ほとんどの作業は、Cloud Shell で行います。Cloud Shell は Google Cloud 上で動作するコマンドライン環境です。Debian ベースの仮想マシンであり、必要となるすべての管理ツール(docker
、gcloud、gsutil
、kubectl
など)と、永続的な 5 GB のホーム ディレクトリが用意されています。
- Google Cloud コンソールのタイトルバーで、Cloud Shell をアクティブにするアイコン()をクリックします。
- [続行] をクリックします。
プロビジョニングされると、Cloud Shell プロンプトが表示されます。
タスク 1. GKE クラスタをデプロイする
このタスクでは、Cloud Shell を使用して GKE クラスタをデプロイします。
- Cloud Shell で次のコマンドを入力して、ゾーンとクラスタ名の環境変数を設定します。
- Cloud Shell で次のコマンドを入力して、Kubernetes クラスタを作成します。
この形式のコマンドでは、ほとんどのオプションがデフォルトに設定されます。有効なオプションの一覧については、gcloud container clusters create リファレンスをご覧ください。
いくつかの警告が表示され、デフォルトの GKE クラスタ設定の変更箇所が示されます。これらは、新しいバージョンの Kubernetes が GKE で採用されたときに導入されたものです。
デプロイが完了すると、Google Cloud コンソールの [Kubernetes Engine] > [クラスタ] ページは、次のスクリーンショットのようになります。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 2. GKE クラスタに接続する
このタスクでは、Cloud Shell を使用して GKE クラスタに対する認証を行ってから、kubectl 構成ファイルの内容を確認します。
Kubernetes での認証は、マスター上で動作している kube-APIserver を介した外部クライアントからクラスタへの通信と、クラスタ内または外部でのクラスタ コンテナの通信の両方に適用されます。
Kubernetes での認証にはいくつかの形式があります。GKE の場合、通常は OAuth2 トークンで認証が処理され、Cloud Identity and Access Management を使用してプロジェクト全体で認証を管理できます。各クラスタ内で定義して構成できる、ロールベースのアクセス制御を使用することもできます。
GKE では、クラスタ コンテナでサービス アカウントを使用して、外部リソースに対する認証とアクセスを行うことができます。
- 現在のユーザーの認証情報で kubeconfig ファイルを作成(認証を許可)し、特定のクラスタのエンドポイント情報を提供(
kubectl
コマンドライン ツールを介した対象クラスタとの通信を許可)するには、次のコマンドを実行します。
ホーム ディレクトリに .kube
ディレクトリがまだ存在しない場合は、このコマンドによって作成されます。.kube
ディレクトリに config
というファイルがまだ存在しない場合、これも作成されます。このファイルは、認証情報と構成情報を格納するために使用されます。構成ファイルは通常、kubeconfig ファイルと呼ばれます。
- nano テキスト エディタで kubeconfig ファイルを開きます。
これで、ファイルに保存されているすべての認証データとエンドポイント構成データを確認できるようになり、クラスタの情報が表示されます。これらの情報はクラスタの作成時に入力されたものです。
- Ctrl+X キーを押して nano エディタを終了します。
kubectl
コマンドが操作しているクラスタ)は、current-context
プロパティで示されます。
同じコンテキスト(同じ環境の同じユーザー)で作成したクラスタについては、クラスタ作成時にすでに詳細が入力されているため、gcloud container clusters get-credentials
コマンドを実行して kubeconfig ファイルに情報を入力する必要はありません。ただし、他のユーザーまたは他の環境で作成されたクラスタに接続するには、このコマンドの実行が必要です。このコマンドを使うと、アクティブなコンテキストを別のクラスタに簡単に切り替えることも可能です。
タスク 3. kubectl を使用して GKE クラスタを検査する
このタスクでは、Cloud Shell と kubectl を使用して GKE クラスタを検査します。
kubeconfig ファイルに情報が入力され、アクティブなコンテキストが特定のクラスタに設定されたら、kubectl
コマンドライン ツールを使用して、対象のクラスタに対してコマンドを実行できます。こうしたコマンドの多くは、最終的にマスター API サーバーに対する REST API 呼び出しをトリガーします。これにより、関連するアクションが実行されます。
- Cloud Shell で次のコマンドを実行して、kubeconfig ファイルの内容を出力します。
証明書の機密データは DATA+OMITTED で置き換えられて表示されます。
- Cloud Shell で次のコマンドを実行して、アクティブ コンテキストのクラスタ情報を出力します。
出力にアクティブ コンテキストのクラスタの情報が示されます。
出力:
- Cloud Shell で次のコマンドを実行して、アクティブ コンテキストを出力します。
出力に、アクティブ コンテキストのクラスタが 1 行で示されます。
出力:
PROJECT_ID
はプロジェクト ID です。この情報は、kubeconfig ファイルの current-context
プロパティの情報と同じです。
- Cloud Shell で次のコマンドを実行して、kubeconfig ファイル内のすべてのクラスタ コンテキストの詳細を出力します。
出力には、作成したクラスタに関する詳細と、どれがアクティブ コンテキスト クラスタであるかを示す内容が数行で表示されます。通常、ユーザーの kubeconfig ファイルに存在するクラスタの詳細(ユーザーが作成した他のクラスタや、kubeconfig ファイルに手動で追加したクラスタの詳細を含む)が示されます。
- Cloud Shell で次のコマンドを実行して、アクティブ コンテキストを変更します。
この例ではクラスタは 1 つのみであるため、このコマンドを実行しても何も変更されません。
しかし、将来的にはプロジェクトのクラスタが複数になる可能性があります。複数のクラスタの認証情報と構成情報が kubeconfig ファイルにすでに入力されている場合、この方法でアクティブ コンテキストを切り替えることができます。この方法では、クラスタの完全な名前(gke
接頭辞、プロジェクト ID、ロケーション、表示名をアンダースコアで連結したもの)を指定する必要があります。
- Cloud Shell で次のコマンドを実行して、
kubectl
の bash のオートコンプリートを有効にします。
このコマンドは出力を生成しません。
- Cloud Shell で「kubectl」と入力し、その後にスペースを 1 つ入力してから、Tab キーを 2 回押します。
使用可能なコマンドがすべて出力されます。
- Cloud Shell に「kubectl co」と入力して、Tab キーを 2 回押します。
「co」で始まるすべてのコマンドが出力されます。他のテキストを入力した場合も同様になります。
タスク 4. GKE クラスタに Pod をデプロイする
このタスクでは、Cloud Shell を使用して GKE クラスタに Pod をデプロイします。
kubectl を使用して GKE に Pod をデプロイする
Kubernetes は Pod を抽象化することで 1 つ以上の関連コンテナを単一のエンティティとしてグループ化し、これらを 1 つのユニットとして同一ノード上でスケジュールしてデプロイします。1 つのコンテナ イメージから作成された 1 つのコンテナを含む Pod をデプロイすることも、複数のコンテナ イメージから作成された複数のコンテナを Pod に含めることも可能です。
- Cloud Shell で次のコマンドを実行して、nginx を nginx-1 という名前の Pod としてデプロイします。
このコマンドでは、nginx イメージを実行するコンテナを含む、nginx という Pod が作成されます。リポジトリが指定されていない場合、デフォルトの動作として、ローカルまたは Docker 一般公開リポジトリにあるイメージが検索されます。この例では、イメージは Docker 一般公開レジストリから pull されます。
- Cloud Shell で次のコマンドを実行して、アクティブなコンテキストのクラスタにデプロイされたすべての Pod を表示します。
出力は次の例のようになりますが、実際の Pod 名は多少異なります。
出力:
- Cloud Shell で次のコマンドを実行して、クラスタのすべてのノードのリソース使用状況を表示します。
出力は次の例のようになります。
出力:
別の top
コマンド(kubectl top pods
)を実行すると、クラスタにデプロイされたすべての Pod に関する同様の情報を表示できます。
- ここで、このラボ全体で使用する変数に Pod 名を入力します。このような変数を使用することで、長い名前を入力する際のミスを最小限に抑えることができます。
[your_pod_name]
の代わりに、一意の Pod 名を入力してください。
例:
- シェルに値をエコーバックさせて、環境変数が適切に設定されたことを確認します。
出力:
- Cloud Shell で次のコマンドを実行して、作成した Pod の詳細をすべて表示します。
出力は次の例のようになります。Pod の詳細、ステータス、状態、ライフサイクルのイベントが表示されます。
出力:
コンテナにファイルを push する
nginx ウェブサーバーを介した静的コンテンツの配信を可能にするには、ファイルを作成してコンテナに配置する必要があります。
- Cloud Shell に次のコマンドを入力し、nano テキスト エディタで
test.html
というファイルを開きます。
- 空の
test.html
ファイルに次のテキスト(シェル スクリプト)を追加します。
-
Ctrl+X キーを押した後、Y キーと Enter キーを押してファイルを保存し、nano エディタを終了します。
-
Cloud Shell で次のコマンドを実行し、nginx Pod の nginx コンテナ内の適切な場所にファイルを配置します。これにより、ファイルが静的に配信されます。
このコマンドを実行すると、test.html
ファイルがローカルのホーム ディレクトリから、nginx Pod 内の最初のコンテナの /usr/share/nginx/html
ディレクトリにコピーされます。-c
オプションに続けてコンテナの名前を入力すると、マルチコンテナの Pod の他のコンテナを指定できます。
テスト用に Pod を公開する
Pod をクラスタの外部のクライアントに公開するには、Service が必要です。Service についてはこのコースで別途説明していますが、他のラボでも広く使用されています。シンプルなコマンドを使用して、Pod を公開する Service を作成できます。
- Cloud Shell で次のコマンドを実行し、nginx Pod を外部に公開する Service を作成します。
このコマンドを実行すると、クラスタ外のインターネット アドレスから nginx Pod へのアクセスを許可する LoadBalancer Service が作成されます。
- Cloud Shell で次のコマンドを実行し、クラスタ内の Service についての詳細を表示します。
出力は次の例のようになります。外部 IP アドレスは次の手順で使用します。
出力:
Kubernetes Service は、クラスタによって作成または使用されるデフォルト Service の一つです。先ほど作成した nginx Service も表示されます。
外部 IP アドレスが表示されない場合は、このコマンドを何度か実行してみてください。
出力:
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
- Cloud Shell で次のコマンドを実行し、コピーした静的 HTML ファイルが nginx コンテナで配信されていることを確認します。
[EXTERNAL_IP] は、前の手順の出力から取得した Service の外部 IP アドレスに置き換えてください。
出力にファイルの内容が表示されます。ブラウザで同じアドレスにアクセスすると、ファイルが HTML としてレンダリングされることを確認できます。
例:
- Cloud Shell で次のコマンドを実行し、nginx Pod で使用されているリソースを表示します。
出力:
タスク 5. GKE Pod をイントロスペクトする
このタスクでは、Pod に接続して設定の調整とファイルの編集を行います。また、Pod に対するその他の変更をライブで行います。
環境を準備する
Pod や他のリソースを Kubernetes にデプロイするには、構成ファイルを使うことをおすすめします。構成ファイルはマニフェスト ファイルとも呼ばれます。構成ファイルは通常 YAML 構文で記述され、リソースの詳細を指定します。構成ファイルでは、長々としたコマンドライン引数を使用するよりも簡単に、複雑なオプションを指定できます。
YAML 構文は JSON 構文と似ていながらもより簡潔で、オブジェクトとプロパティを JSON 構文と同じように階層構造化できます。ラボのソース リポジトリには、サンプル YAML ファイルがあらかじめ用意されています。
- Cloud Shell に次のコマンドを入力して、ラボの Cloud Shell にリポジトリのクローンを作成します。
- 作業ディレクトリへのショートカットとしてソフトリンクを作成します。
- このラボのサンプル ファイルが含まれているディレクトリに移動します。
new-nginx-pod.yaml
という Pod のサンプル YAML マニフェスト ファイルがあらかじめ用意されています。
- 次のコマンドを実行して、マニフェストをデプロイします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
- 次のコマンドを実行して、Pod のリストを表示します。
出力は次のようになります。
出力:
新しい nginx Pod と、ラボですでに作成した Pod が表示されます。
シェル リダイレクトを使用して Pod に接続する
一部のコンテナ イメージにはシェル環境が含まれており、これを起動することができます。場合によっては、こうしたシェル環境を使用するほうが kubectl
で個別のコマンドを実行するよりも便利です。たとえば、nginx イメージには bash シェルが含まれています。このタスクでは、シェル リダイレクトを使用して新しい nginx Pod の bash シェルに接続し、一連のアクションを実行します。
- Cloud Shell で次のコマンドを実行して、nginx コンテナでインタラクティブな bash シェルを起動します。
新しいシェル プロンプトが表示されます。
出力:
new-nginx Pod のコンテナで、インタラクティブな bash シェルを起動しました。Pod にコンテナが複数ある場合は、-c
オプションを使用して 1 つのコンテナを名前で指定できます。
nginx コンテナ イメージにはデフォルトでテキスト編集ツールが含まれていないため、インストールする必要があります。
- Cloud Shell の nginx bash シェルで次のコマンドを実行して、nano テキスト エディタをインストールします。
「Do you want to continue (Y/n)」というメッセージが表示されたら、Y を押して確定します。
nginx コンテナ上で静的に提供されているディレクトリに、test.html
ファイルを作成する必要があります。
- Cloud Shell の nginx bash シェルで次のコマンドを実行し、静的ファイル ディレクトリに切り替えて
test.html
ファイルを作成します。
- Cloud Shell で、nginx bash シェルの nano セッションに次のテキストを入力します。
- Ctrl+X キーを押した後、Y キーと Enter キーを押してファイルを保存し、nano エディタを終了します。
- Cloud Shell の nginx bash シェルで次のコマンドを実行して、nginx bash シェルを終了します。
変更された nginx コンテナに(新しい静的 HTML ファイルを使用して)接続し、テストを行うには、Service を作成する方法もありますが、ポート転送を使用して Cloud Shell から Pod に直接接続する方が簡単です。
- Cloud Shell で次のコマンドを実行して、Cloud Shell から nginx Pod へのポート転送(Cloud Shell VM のポート 10081 から nginx コンテナのポート 80 に転送)を設定します。
出力は次のようになります。
出力:
これはフォアグラウンド プロセスなので、テスト用に別の Cloud Shell インスタンスを開く必要があります。
- Cloud Shell のメニューバーでプラス記号(+)のアイコンをクリックして、新しい Cloud Shell セッションを開始します。
2 つ目の Cloud Shell セッションが Cloud Shell ウィンドウに表示されます。メニューバーのタイトルをクリックすると、セッションを切り替えることができます。
- 2 番目の Cloud Shell セッションで次のコマンドを実行して、ポート転送を介して変更された nginx コンテナをテストします。
test.html
ファイルに配置した HTML テキストが表示されます。
Pod のログを表示する
- Cloud Shell のメニューバーでプラス記号(+)のアイコンをクリックして、別の新しい Cloud Shell セッションを開始します。
3 番目の Cloud Shell セッションが Cloud Shell ウィンドウに表示されます。ここでも、メニューバーでタイトルをクリックするとセッションを切り替えることができます。
- この 3 番目の Cloud Shell ウィンドウで次のコマンドを実行して、ログを表示するとともに、新しく到着した new-nginx Pod のログをストリーミングします(タイムスタンプも追加します)。
- この新しいウィンドウにログ画面が表示されます。
- 2 番目の Cloud Shell ウィンドウに戻り、curl コマンドを再実行して Pod にトラフィックを生成します。
- 3 番目の Cloud Shell ウィンドウに追加のログメッセージが表示されたら、それを確認します。
- 3 番目の Cloud Shell ウィンドウを閉じて、ログメッセージの表示を停止します。
- 元の Cloud Shell ウィンドウを閉じて、ポート転送プロセスを停止します。
ラボを終了する
ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。
ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。
星の数は、それぞれ次の評価を表します。
- 星 1 つ = 非常に不満
- 星 2 つ = 不満
- 星 3 つ = どちらともいえない
- 星 4 つ = 満足
- 星 5 つ = 非常に満足
フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。
フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。
Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。