資料請求
お問い合わせ
  • tech系
13分で読める

Cloud OnAir 第20回 〜「Dive to Google Kubernetes Engine」〜まとめ

こちらの記事は弊社技術ブログに掲載していた内容となります。一部を除き、投稿当時の情報となりますので、紹介内容の最新情報については別途公式情報等をご参照下さい。

こんにちは。クラウドエース編集部です。

2017年10月5日より、【隔週木曜 18:00～18:45】に、Google 社のエンジニアが、Google Cloud Platform の製品、サービスや導入事例等について解説する番組が始まっています。
ユーザー参加型の生放送番組 となっており、視聴者からのリアルタイム Q＆A も受け付けています！

この記事では、動画を見逃した方や、見る時間が無い方向けに、要点をかい摘まんで、クイックに紹介したいと思います。

今回の内容は Google Kubernetes Engine (GKE) についてです。GKE の セキュリティ・デプロイ・パフォーマンス・運用 に関して、機能と活用例を交えながらご紹介いたします。

講師は、Google Cloud カスタマーエンジニアの 村上 大河 さんです。
2017年11月2日放送の No-ops で大量データ処理基盤を簡単に構築する と 2018年2月8日放送の クラウド移行後の最適化方法を伝授。でも最適化ってなんですか？ に続いて３回目の出演です。

今回のテーマ：Dive to Google Kubernetes Engine

今回のアジェンダ

今回は以下のアジェンダに基いて、GKE を利用していく上での活用パターンをご紹介いたします。
利用シーン、メリット＆デメリットといったポイントを交えて、今の GKE 環境をより快適に使っていただくことをお伝えする内容になっています。

  • セキュリティ編
  • デプロイ編
  • パフォーマンス編
  • 運用編

※ベータ版の機能も多くご紹介しますが、本格的なリリースになっていないサービスのため、ご利用の際はよく検証を行って導入をご検討ください。

はじめに

今回の内容をご紹介する前に Google Kubernetes Engine (GKE) についてご紹介します。
下のスライドにあるアイコンが GKE のサービスアイコンになっています。

コンテナオーケストレーション

コンテナを使用するときに、ローカル PC 上では動作にそれほど問題はありませんが、本番環境で複数のサーバーに対してコンテナをデプロイして使っていくとなると色々な問題が出てきます：

  1. デプロイの問題
    毎回一つ一つのサーバーに入ってデプロイをしていくのか？
  2. サーバーが壊れてしまった場合（図でいうところのノード）の問題
    どういう形で復旧をしたらよいのか？

などがあります。

このような作業をまとめて管理をしてくれるものが「コンテナオーケストレーション」といい、実際にやってくれるのが「Kubernetes」となっています。

GKE の3つの特徴

GKE は Google が提供する Kubernetes のサービスになっています。

  • すぐに開始
    • Cloud Console を使うことによって、わずか2ステップで簡単にクラスタを作成できる。
    • Kubernetes の環境の可視化できる。
  • 信頼と可用性
    • 自動リペア、自動アップデート、オートスケールなど、様々な機能によって、本番環境のシステムを動かすのには最適な信頼性と可用性を備えている。
  • GCP との統合
    • 他の GCP サービスとの統合による多くのアドバンテージを得られる。

Kubernetes におけるクラスタとは

次に Kubernetes の全体のイメージを見てみましょう。

  • コンテナ ⇒ 作成したアプリケーションを動かすもの。
  • ノード ⇒ コンテナが動くサーバー。
  • ノードプール（GKE の概念）⇒ 複数のノードを1つの大きなかたまりとするもの。
    ノードプールの中は同じ構成のノードをまとめる。

Kubernetes Best Practices も合わせてご覧ください

今回の OnAir では Google の提供する Google Kunernetes Engine の活用の仕方について説明しています。
Kubernetes 自体のベストプラクティスに関しては別途 こちらの YouTube 動画のプレイリスト（English） をご覧ください。

セキュリティ編

はじめに GKE のセキュリティについてご紹介いたします。GKE の中でセキュリティを重視してどのような活用ができるかをご紹介いたします。

COS (Container-Optimized OS)

ノードのセキュリティを強化したい場合や GKE の機能をフル活用したい場合は、COS を利用の検討をおすすめします。
特徴としては、セキュアであることが挙げられます。また、自動 OS アップデート機能で、セキュリティパッチを自動的に当てることができるので、GKE を活用するという意味でも COS の利用をおすすめします。

限定公開クラスタ（Private Cluster）の活用（ベータ）

限定公開クラスタ（Private Cluster）は、特にエンタープライズ企業で求められるような、プライベートセキュリティモデル（インターネットから隔離された環境）のシステムの構築・運用をしていく場合に利用できる機能になっています。

通常、限定公開クラスタを使わない場合には、ノードや GKE のマスタに外部 IP アドレスが割り当てられて、そこに対してアクセスができる（サービスが提供できる）仕組みになっていますが、限定公開クラスタを使うことによって外部 IP アドレスが割り当てられず、内部 IP アドレスだけが割り当てられるようになります。それによって VPC の中だけや VPC と VPN をつないだ先といった、限定されたネットワークからのみのアクセスができるようになります。

限定公開クラスタは外部 IP アドレスを持っていないためにインターネットのアクセスができない状態になっていますが、インターネットへのアクセスが必要な場合（例：ソフトウェアのインストール・アップデートなど）は NAT サーバーを別途立てて利用できるようにします。立てられた NAT サーバーに対してアクセスをさせる方法としては、Kubernetes で pod を作成する時に環境変数でプロキシサーバーのアドレスを渡したり、ルーティングの設定を変えてデフォルトルートを NAT サーバーに向ける方法があります。

共有 VPC の活用（ベータ）

共有 VPC と組み合わせることによって、GKE を便利に使うことができます。
共有 VPC とは、1つの GCP プロジェクトで持っているネットワークを他のプロジェクトから使用することができる VPC ネットワークの機能です。

特徴としては、メインとなるプロジェクトがネットワークの設定を持ち、他のプロジェクトではネットワークの設定を持たず、メインとなるプロジェクトのネットワークに対してリソースを立てる仕組みを持つことできます。

利用ケースとしては、ネットワークチームによる統制を効かせたい場合の利用に有効です。ユーザーがエンタープライズ企業のネットワークチームに所属している場合に、インターネットに出られない制限をかけたり、特定のプロジェクトに限定したネットワークの許可やある特定の IP アドレスの範囲内に限定したネットワークの許可を与えたりしたい場合には共有 VPC の設定をおすすめします。

共有 VPC を使用する上での注意事項

割り当てと制限

共有 VPC を使用する上で 割り当てと制限 という2つの注意事項があります。以下のスライドをご覧ください。

「割り当て」と示されている項目に関しては、デフォルトで利用できる量が定められています。今後、共有 VPC を使っていく中で定められた利用料では足りなくなる見積もりがあった場合は、なるべく早い段階で利用できる量の 変更申請 するようにしてください。

「制限」と示されている項目に関しては、変更ができないものになっていますので、引っかからないように注意してください。

Role Based Access Control (RBAC)

GKE では IAM 制御できる範囲は GKE のクラスタを作成するといった大きなレベルに限定した制御となっています。実際に Kubernetes を GKE でクラスタを運用していくことになると、クラスタの中で細かく色々なシステムを動かしていくことになります。そこで、ネームスペースという仮想的かつ論理的な空間を切って、そこに対して各チームがアプリケーションをリリースしていく使い方がおすすめになっています。そのような場合には Kubernetes 上でのアクセス制御を IAM ではなく RBAC で制御する必要があります。

以下のスライドにあるのが、設定ファイルになります。

権限をまとめたロール（役割）を定義して、ロールに対してユーザーを紐付けていく仕組みになっています。
G Suite、Cloud Identity 等のアカウントを指定して、GCP のコンソールを触ることができるユーザーを定義できます。

実際にどの様に権限の制御ができるかは デモ をご覧ください。

Role Based Access Control (RBAC) の利用ケース

複数のクラスタをメンテナンスするよりも1つのクラスタを1つの運用チーム共有することでによって、運用コストを抑えることができます。

クラスタを共有する単位・粒度としては、ユーザーの状況によって、開発のステージ単位・マイクロサービス単位・チーム単位・グループ単位で分けていく方法があります。

エンタープライズ企業の場合は1つの大きな開発案件において複数のパートナー企業や委託先企業がクラスタにアクセスする、といった状況が考えられます。そのような状況で、1つのネームスペース（開発、ステージング、本番など）に対して自社の開発メンバーはロール x、会社 A はロール y、というように複数のロールを定義することによって、アクセスの制限をすることができます。

デプロイ編

CI / CD パイプラインの全体像

GKE 中での CI / CD パイプラインの全体像について見てみましょう。


上の青枠で囲ってある、CI / CD のパイプラインの流れについて説明します：

  1. 作成したコンテナやポッドの定義ファイルをソースコードを管理するリポジトリに登録をする（Cloud Source Repository）
  2. 登録したことを検知してビルドとテストを開始する（Cloud Build）
  3. ビルドとテストが終わったものを構成管理用のシステムに登録する（Cloud Container Registry）
  4. 最終的に本番環境にリリースする（Cloud Build）

Cloud Source Repository

GCP のプライベート Git リポジトリです。CI / CD のパイプラインの中ではコンテナの定義ファイルを管理する役割を担っています。

利用ケースとしては、GCP に対するログインアカウントを統合したい時に有効なサービスになっています。また、Stackdriver というモニタリングをするサービスと連携して利用することで、アプリケーションのデバッグを速度を上げられることが考えられます。


Google Source Repository を使うことによってアカウント管理が簡単になる、ということについて詳しくお伝えします。

Source Repository をはじめとした GCP 製品の使用権限を割り当てる時に、ユーザーごとに権限の設定をしてしまうと、チームに新しいメンバーが入った場合やチームから離脱した場合に IAM で毎回権限を変更する必要が出てしまいます。良い管理方法の1つとして、Google グループを作成して、そのグループに対して権限を設定することによって、グループに関する設定は G Suite や Clound Identity といった Google が管理するアカウントを使用して行う方法があります。そうすることによってグループに追加、またはグループから外すだけで簡単にユーザーの権限が管理できるようになります。

Cloud Build

次にビルドとテストとデプロイについてです。Cloud Build に関しては Google Cloud Next ’18 で新しく発表になった製品です。

ビルド・テスト・デプロイを自動化したい、ビルド時間の短縮化をしたいという方のためのサービスです。

マネージドなビルド・テスト・デプロイをするサービスなので、これらを行うためのサーバーをユーザー自身が管理しなくても良いというメリットがあります。GitHub などのサードパーティーのリポジトリにも対応しています。

Google Container Registry

続いて、ビルド・テストした後の流れについてです。

Google Container Registry はコンテナのイメージをプライベート保存ができるサービスです。
便利な機能としては、登録されたコンテナのイメージに対して、セキュリティのスキャンを任意でかけることができます。この機能を使うことによって、自分たちでは気が付くことができなかったコンテナの脆弱性を事前に把握することができます。脆弱性情報が見つかった際に Cloud Pub/Sub にその情報を送ることによって、メールや SNS やチャットと連携して通知をすることができます。

パフォーマンス編

プリエンプティブノード（ベータ）

Compute Engine のプリエンプティブ VM のように、GKE にもプリエンプティブノード（ベータ）というサービスがあります。

ノードの利用料金を下げたい場合に有効なサービスです。大きいバッチジョブを低コストで実行したい場合や、本番環境のシステムにおいて対障害性のあるシステムを低コストで実行したい場合の利用が考えられます。
最大 24 時間しか稼働しませんが、最大 80% コストが削減できます。プリエンプティブノード上の pod は graceful shutdown（正常なシャットダウン）が保証されないので、こちらについてユーザーがコンテナ側で対策をする必要があります。

プリエンプティブノードの活用イメージ

  • バッチジョブ：
    プリエンプティブノードの上に pod を配置して、低価格でジョブを終了させる。
  • 耐障害性システム：
    プリエンプティブノードとノンプリエンプティブノードを使った2つのノードプール（ノードのまとまり）用意して、ノンプリエンプティブノードで最低限処理が実行できるようにしつつ、障害時にはプリエンプティブノードを大量に用意して処理を早く終わらせる。

プリエンプティブノードは 100 % 使える状態が保証されているわけではなく、また 24 時間以内には必ず落ちてしまうので、プリエンプティブノードとノンプリエンプティブノードを併用させて活用することをおすすめします。

GPU の活用（ベータ）

コンテナから GPU を使うことができる機能です。

ローカルで行っている GPU の演算をスケールさせたい場合や、GPU のリソースをチームで共有したい場合に有効です。
また、プリエンプティブノードと組み合わせて料金を安く GUP を利用したり、クラスタオートスケールと組み合わせることによって、GPU のリソースが足りなくなった時にノードを増やすことができます。

運用編

ノードの自動復旧

ノードの自動復旧機能は COS を利用した場合のみに利用可能です。こちらは、ノードを自動的にヘルスチェックして、もし失敗した場合に自動的に修復プロセスを開始する機能となっています。GKE の機能をフル活用する場合は COS の選択してノードの自動復旧機能を利用することをおすすめします。

マルチゾーンクラスタ

マルチゾーンクラスタはその名の通り、複数のゾーンに対してノードを配置できる機能です。
可用性を求められるシステムにはノードを複数のゾーンに配置してシステムを構築することをおすすめします。

クラスタオートスケール

クラスタオートスケールは最低限の数のノードと最大限の数のノードを指定して、その間でノードを増減させられる機能です。CPU 使用率や Stackdriver の指標を元にノードのオートスケールが可能になります。

フェイルオーバーした時にキャパシティを一時的に確保したり、今まで見積もっていたキャパシティより多くのリクエストがクラスタに対して来て、キャパシティが不足してしまうケースに有効です。

クラスタオートスケールの活用

クラスタオートスケールを利用するときには制約があるので確認してください。

制約：

  • 最大 1000 ノードまで管理できる。
  • 各ノードで稼働できる pod 数が 30 に限定される。
  • スケールイン時は最大 10 分間の猶予期間があり、pod を終了させる処理に時間がかかり過ぎてしまうと強制終了されてしまう可能性がある。

予期しないスケールインを防ぐためには PodDisruptionBudget（ある期間において同時に pod が落ちていることを許容する数）を設定することをおすすめします。

サービスを構成する要素に pod が４つあったとして、PodDisruptionBudget が 2 に設定してある場合は、pod を同時に2つ落とすことを許容するという意味を表します。例えば、スケールインする対象の node に pod が３つ乗っていて、他の node に pod が1つ乗っている場合には、スケールインをする対象の node が落ちてしまうと PodDisruptionBudget に設定してある 2 を超えてしまいます。このような場合は制約を違反してしまうことになるので、これを活用してスケールインを起こさせないようにすることができます。

リージョナルクラスタ（ベータ）

リージョナルクラスタは node、特に master を複数のゾーンに配置できる機能です。複数のゾーンに配置することにより、master の冗長性が上げることができます。

リージョナルクラスタを使わない場合は master のソフトウェアをアップデートするときに一時的に master が利用不可能になります。このような場合、GKE 上で動いているサービスが利用不可になるわけではなく、kubectl といったコマンドが発行できなくなります。例えば、CI / CD のシステムを組んでいる時に自動で Kubernetes 上で開発環境をコミットごとに自動的に作成するような形を取った時に、master が利用不可能になっているとジョブがエラーになってしまうことが起こります。master を冗長化することにより常に master とコミュニケーションが取れる状態を実現することができるので、CI / CD のパイプラインを止めることなく実行することができます。

ログ収集

ログ管理を Stackdriver Logging に移譲する機能です。こちらはデフォルトで ON になっています。
Stackdriver Logging にログ管理を集約したい場合やもっと効率的にログ管理をしたい場合に有効です。

ログ収集の活用

コンテナを作成するときのベストプラクティスとして、標準出力、または標準エラー出力にメッセージを出力するやり方が一般的になっています。GKE も同様に標準出力に出力されたメッセージに関しては Stackdriver 上で「INFO」というカテゴリでログが記録され、標準エラー出力されたメッセージに関しては「ERROR」というカテゴリでログが記録されます。単一行の JSON の文字列でメッセージを出力すると、Stackdriver 上でメッセージをカスタマイズすることができ、JSON のようにログを構造化することができます。

また、構造化ログを BigQuery、Pub/Sub などにエクスポートができます。アプリケーションのチームが主体となって、構造化したログを活用できるような仕様でコンテナを作ることで、自動的にログが BigQuery に保存されるような仕組みを作ることが可能になるので、より負担が軽く、かつ、かっこよく GKE を運用ができます。

Stackdriver Logging に飛ばしたログにフィルターをかけて、特定のログが溜まってきたらアラートを通知するというように、ログベースの指標を使用して、Stackdriver Monitoring でアラートを設定ができます。

ログ収集の活用イメージ

GKE から Stackdriver Logging にログを飛ばして BigQuery に直接流したり、または Pub/Sub と Dataflow を経由して BigQuery に流したあと分析をするというような、フルマネージドサービス同士を連携しての活用のイメージです。

まとめ

GKE はすぐに始められて、本番環境で運用するために必要な機能を兼ね備えており、他の GCP のサービスとの統合が可能なサービスになっています。

今回、活用パターンをいくつか紹介しましたが、自分に関連する内容があればまずは検証環境を使って特徴を掴んでいただいて、本番環境に適応していっていただきたいと思います。

最後にひとこと

いかがでしたでしょうか。
以上が「Dive to Google Kubernetes Engine」のまとめでした。

先月の Google Cloud Next ’18 でも GKE に関する発表が多くされましたが、今後様々な新しい機能が GKE で使えるようになっていきます。コンテナを既に運用している方々も、これから始めようと考えている方々も、ぜひ GKE を使ったコンテナ開発の動向に注目していただきたいです。

次回の放送は、「Google Networking Deep Dive ! その技術と設計の紹介」です。
Google のグローバルネットワークについてのテクノロジーや、その思想設計からポリシーまでを紹介する内容になっています。ネットワークに興味がある方は必見です！

それでは、次回も 8/9（木）18:00 にお会いしましょう。

参考リンク

Youtube 視聴

Cloud OnAir の放送は、今回分含め、バックナンバーも全て Youtube で視聴できます。
スライドと合わせて進行する解説を、是非ご覧ください！
Youtube URL：https://www.youtube.com/watch?v=jQHsBrh9KaY

SlideShare

今回の動画で説明に使用されたスライドについても、SlideShare でいつでも閲覧可能です。
登場した用語について振り返りたい、用語同士の関係性を確認したい等、大変参考になります！
スライド URL：https://www.slideshare.net/GoogleCloudPlatformJP/cloud-onair-dive-to-google-kubernetes-engine-201882

この記事を共有する

合わせて読みたい

↑