目標
ステージング クラスタとテストクラスタを構成する次の基本的なタスクについて学習します。コントロール プレーンと呼ばれる、クラスタの管理サービスへのアクセスを制限します。これにより、権限のないユーザーがクラスタやワークロードの設定を表示したり変更したりすることを防げます。
需要に応じて効率的にスケールアップ / スケールダウンするコンピューティング リソースがアプリに必要なことを指定します。
自動スケーリング(需要が指定したしきい値を超えた場合に Pod を自動的に複製する)をテストします。
必要なログのみを保持するように、ログの保持設定を調整します。
GKE セキュリティ ポスチャー ダッシュボードを有効にします。
これらは、クラスタを開発環境からステージング環境に昇格させるためのタスクの一部にすぎません。考慮すべきタスクの一覧については、GKE のドキュメントをご覧ください。
このタスクの手順をガイドに沿って Google Cloud コンソールで直接行う場合は、「ガイドを表示」をクリックしてください。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
Kubernetes クラスタを作成してワークロードをデプロイします。方法については、クラスタを作成してワークロードをデプロイするをご覧ください。
コントロール プレーンに対するアクセスの制限
セキュリティ ポスチャーを強化するため、承認済みネットワーク、Google Cloud コンソール、Cloud Shell だけがクラスタのコントロール プレーンにアクセスできるようにします。
承認済みネットワークを構成する
Google Cloud コンソールで、GKE の [クラスタ] ページに移動します。
[名前] 列でクラスタ名 [hello-world-cluster] をクリックします。
[ネットワーキング] 表の
[コントロール プレーン承認済みネットワーク] 行で、 [編集] をクリックします。[コントロール プレーン承認済みネットワークの編集] ダイアログで、[コントロール プレーン承認済みネットワークを有効にする] を選択します。
[Google Cloud のパブリック IP アドレスを介したアクセスを許可する] を選択します。
これにより、Google Cloud コンソールと Cloud Shell からクラスタを管理することが可能になります。
[承認済みネットワークを追加] をクリックします。
「My example on-prem network」などの名前を入力します。
[ネットワーク] に、クラスタのコントロール プレーンへのアクセス権を付与する IP アドレスの範囲を入力します。CIDR 表記を使用してください。
たとえば、次の範囲を入力します。
198.51.100.0/24
[完了] をクリックします。
[変更を保存] をクリックします。
この処理が完了するまでに数分かかります。
[
通知 ] ボタンをクリックし、[Kubernetes Engine クラスタ「hello-world-cluster」のコントロール プレーン承認済みネットワーク設定を更新] の横に緑色のチェックマークが表示されるまで待ちます。
これで、承認済みネットワークと Google Cloud のパブリック IP アドレスからのみアクセスできるクラスタ コントロール プレーンを構成できました(これにより、Google Cloud コンソールと Cloud Shell からクラスタを管理することが可能になります)。
クラスタのコントロール プレーンの IP アドレスを表示して、承認済みネットワークのアドレスを確認するには、[次へ] をクリックします。
IP アドレスを表示する
GKE の [クラスタ] ページに移動します。
[名前] 列でクラスタ名 [hello-world-cluster] をクリックします。
[クラスタの基本] 表の [外部エンドポイント] 行に、クラスタのコントロール プレーンの IP アドレスが表示されます。
[ネットワーキング] 表の [コントロール プレーン承認済みネットワーク] 行に、承認済みネットワークの IP アドレスが表示されます。
これで、承認済みネットワーク、Google Cloud コンソール、Cloud Shell からのみ、クラスタのコントロール プレーンにアクセスできます。
コンピューティング クラスの指定
デフォルトでは、GKE Autopilot Pod は汎用ワークロード用に最適化されたコンピューティング リソースを使用します。適切なスケーリングが必要なワークロードやその他の固有の要件があるワークロードの場合は、別のコンピューティング クラスを指定できます。
Deployment の仕様を更新する
Google Cloud コンソールで、GKE の [ワークロード] ページに移動します。
[名前] 列で、デプロイしたアプリの名前 [hello-world-app] をクリックします。
Deployment の仕様を編集するため、[
編集 ] をクリックします。[YAML] タブで、
containers:
で始まる行を見つけます。この行のすぐ上に、次の行を追加します。
nodeSelector: cloud.google.com/compute-class: "Scale-Out"
ファイル内のインデントを次の例のようにしてください。
apiVersion: apps/v1 kind: Deployment ... spec: ... template: ... spec: nodeSelector: cloud.google.com/compute-class: "Scale-Out" containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
このファイルをダウンロードして他のワークロード構成のベースとして使用するため、[
ダウンロード ] をクリックします。[保存] をクリックします。
ワークロードを実行するために作成された Pod レプリカは、指定したコンピューティング クラスを使用します。
自動スケーリングのテスト
ワークロードを効率的にスケーリングできるようになったので、スケールアップがより簡単に発生するように自動スケーリングの設定を更新します。次に、負荷を生成して自動スケーリングをトリガーします。
Pod の自動スケーリングの設定を更新する
GKE の [ワークロード] ページに移動します。
[名前] 列で、Deployment の名前 [hello-world-app] をクリックします。
[
操作 ] をクリックします。[自動スケーリング] を選択し、[水平 Pod 自動スケーリング] をクリックします。
[HorizontalPodAutoscaler の構成] ダイアログの [自動スケーリング指標] で、[CPU] をクリックします。
[ターゲット] の値を 2(構成された CPU リソースを 2% 以上使用したときに Pod が自動的にスケールアップする)に変更します。この低いターゲット値により、次のステップで自動スケーリングを簡単にトリガーできます。
[保存] をクリックします。
自動スケーリングをトリガーするため、[次へ] をクリックします。
負荷を生成して自動スケーリングをトリガーする
[
Cloud Shell ] をクリックして Cloud Shell を開きます。以下のコマンドを Cloud Shell に貼り付けます。
for i in $(seq -s' ' 1 10000); do wget -q -O- <var>external-IP-address</var>; done
external-IP-address は、[
エンドポイント ] 列に表示された IP アドレスに置き換えます。Enter キーを押してコマンドを実行すると、hello-world-app に 10,000 件のリクエストが送信されます。
wget
コマンドの実行が完了してコマンドライン プロンプトが再表示されるまで待ちます。wget
コマンドが完了したら、Cloud Shell を閉じることができます。
トラフィックの増加に応じたワークロードのスケーリングを監視するため、[次へ] をクリックします。
ワークロードのスケーリングを監視する
ワークロードの [デプロイの詳細] ページで
CPU グラフを見て、CPU 使用率が急上昇していることを確認します。急激な増加を確認するまで、最大で 5 分待つ必要があります。
[更新 ] をクリックして、[デプロイの詳細] ページに最新のデータを表示します。[マネージド Pod] 表で、ワークロードのレプリカが 3 つ実行されていることを確認します。
スケジューリング不可能な Pod に関するエラーが最初に表示される場合もありますが、これはレプリカの起動時における一時的なメッセージです。
10 分ほど待ってから
[更新] をクリックし、CPU 使用率が減少して [マネージド Pod] の Pod 数が 1 に戻ったことを確認します。
これで、自動スケーリングをテストしてワークロードのスケーリングを確認できました。
ログの保持設定の調整
デフォルトでは、すべてのログが GKE クラスタから Cloud Logging に取り込まれます。大量のログデータを取り込むと、料金が発生する場合があります。ステージング環境に必要なログデータのみを取り込むように、ログの保持設定を調整します。
ログフィルタを作成する
-
Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。
[
クエリ結果 ] ペインに、プロジェクト内のすべてのリソースのログが表示されます。 クエリ結果の上で、
[
リソース ] をクリックします。[Kubernetes クラスタ] を見つけてクリックします。
[us-central-1] をクリックします。
[hello-world-cluster] をクリックします。
[適用] をクリックします。
[
重大度 ] をクリックして、[情報](カーソルを合わせると [情報以上] に変わります)を選択します。[
クエリを実行 ] をクリックします。[クエリ結果] に、ステージング クラスタの INFO メッセージのみが含まれるようになりました。
クエリエディタからクエリをコピーします。ログシンク用のフィルタを作成するときに、このクエリを貼り付けます。
ログシンクとストレージ バケットを作成するため、[次へ] をクリックします。
ログシンクとストレージ バケットを作成する
Logging の [ログルーター] ページに移動します。
[
シンクを作成 ] をクリックします。[名前] に、次の名前を入力します。
hello-world-cluster-sink
[次へ] をクリックします。
[シンクサービスの選択] で、[Logging バケット] を選択します。
[ログバケットの選択] で、[新しいログバケットを作成] を選択します。
[バケットの詳細] で、次のような一意の名前を入力します。
hello-world-bucket-<var>user-id</var>
[バケットを作成] をクリックします。
[シンクの宛先] の下にある [次へ] をクリックします。
[包含フィルタの作成] で、ログ エクスプローラで作成したクエリを貼り付けます。
[シンクを作成] をクリックします。
作成したログバケットに保存されているクラスタのログを表示するには、[次へ] をクリックします。
クラスタのログを表示する
-
Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。
[
範囲を絞り込む ] をクリックします。[ログビュー] を選択します。
ログバケットの _AllLogs ビューを選択します。
[適用] をクリックします。
[クエリ結果] には、ログバケットに保存されているログのみが表示されます。
ステージング クラスタに DEBUG メッセージが保存されないようにログの保持設定を調整できました。特定のユーザーのみがクラスタのバケット内のログを表示できるように、権限を設定できます。
セキュリティ ポスチャー ダッシュボードの有効化
セキュリティ ポスチャー ダッシュボードでは、GKE クラスタとワークロードがスキャンされ、セキュリティ対策を改善するために活用できる独自の推奨事項が提供されます。
懸念事項を確認する
GKE の [セキュリティ対策] ページに移動します。
Container Security API を有効にするように求められたら、[有効化] をクリックします。
[ダッシュボード] タブに、プロジェクトのクラスタとワークロードに関する懸念事項の要約が表示されます。
[懸念事項] タブをクリックします。
タブに懸念事項が表示された場合は、クリックして詳細を確認します。
これで、アプリのステージングとテストのためにクラスタを構成する基本的なタスクの一部を完了できました。
次のステップ
課金が発生しないようにするため、クリーンアップします。別のチュートリアルを行う場合は、そのチュートリアルが完了するまで待ってから、クリーンアップを行ってください。サンプルの Kubernetes クラスタは、ほとんどの GKE チュートリアルで使用できます。