GKE が Kubernetes サービスとして最善である 6 つの理由

※この投稿は米国時間 2021 年 4 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドネイティブ技術は主流になっており、Google が開発した Kubernetes は、最新のソフトウェアを構築および運用するうえで重要な存在となっています。Google は、誰もが Kubernetes サービスを簡単に使えるようにする業界標準やサービスを作るために努力を続けています。前回の KubeCon 以降、Google Cloud の Kubernetes の世界では何が新しくなったのか、また、この基礎的な技術を誰もが簡単に利用してメリットを得られるようにするためにはどうすればよいのかを見てみましょう。

1. 本番環境に向けて準備された K8s をスムーズに実行

Google のマネージド Kubernetes サービスである Google Kubernetes Engine（GKE）は、コンテナ化されたアプリケーションの実行を容易にし、かつ必要な制御を可能にすることを常に念頭に置いています。GKE の新しい動作モードである GKE Autopilot により、本番環境用にクラスタを最適化して、クラスタ管理の運用コストを削減し、ワークロードの高い可用性を実現する自動化された Kubernetes エクスペリエンスを提供します。

「Kubernetes を最大限に活用しながら複雑さを軽減することは重要なことであり、GKE Autopilot はまさにそれを実現してくれます。」 - STRABAG BRVZ

高度な構成の柔軟性を必要とするお客様には、標準的な運用モードで GKE を引き続きご利用いただけます。お客様が本番環境の規模を拡大していく中で、アプリケーションの可用性、爆発半径の縮小、異なる種類のサービスの分散などの要件が高まり、複数のクラスタにまたがって展開する必要が出てきました。最近導入された GKE マルチクラスタ サービスにより、Kubernetes Services オブジェクトは、クラスタ間の相互接続を管理するための最低限の構成またはオーバーヘッドを使用して、ゾーン内の複数のクラスタ、複数のゾーン、もしくは複数のリージョンにわたって展開できるようになりました。GKE マルチクラスタ サービスを利用すると、GKE がマルチクラスタのトポロジーを管理してお客様がアプリケーションのニーズに集中できるようにします。

「これまでは、すべてのマイクロサービスを単一のマルチテナント GKE クラスタで運用してきました。次世代の Kubernetes インフラストラクチャでは、マルチリージョンの同種クラスタと異種クラスタを設計しています。シームレスな東西間のクラスタ内通信が前提条件であり、その提供をマルチクラスタ サービスが約束します。デベロッパーはサービスが実行されている場所を意識する必要がありません。私たちはそのことに対する期待で胸を膨らませています。」 - メルカリ

2. GKE の CI / CD パイプラインの構築とスケーリング

継続的インテグレーションおよび継続的デリバリー（CI / CD）パイプラインのスケーリングは、CI / CD サーバーの設定、構成ファイルの更新の確認、正しい認証情報を持つイメージの Kubernetes クラスタへのデプロイなど、複数の手動ステップを伴う時間のかかるプロセスになります。サーバーレスの CI / CD プラットフォームである Cloud Build には、このプロセスを可能な限り簡単にするためのさまざまな機能が搭載されています。

第一に、Cloud Build はビルドパックをネイティブにサポートしており、Dockerfile なしでコンテナを構築できます。構築ステップの一部として、独自のコンテナ イメージを用意したり、事前構築されたイメージを選択したりして、時間を節約できます。さらに、Cloud Build はサーバーレスであるため、サーバーを事前にプロビジョニングしたり、事前にキャパシティを購入したりする必要はありません。また、組み込みの脆弱性スキャン機能により、CI / CD パイプライン内で詳細なセキュリティ スキャンを実行し、信頼できるアーティファクトのみを本番環境に投入できます。最後に、Cloud Build では、数回のクリックで GKE の継続的デリバリー パイプラインを作成できます。これらのパイプラインには、Kubernetes のデプロイを処理するために Google で開発された、すぐに使えるベスト プラクティスが実装されており、パイプラインの設定と管理のオーバーヘッドをさらに削減します。

「Google Cloud に移行する前は、お客様からの機能リクエストを 24 時間以内に本番環境に投入できるというアイデアは不可能と思えるものでしたが、今では当たり前になっています。」- Gordon Food Service、IT - カスタマーおよびセールス担当ディレクター、Craig Van Arendonk 氏

3. K8s のセキュリティおよびコンプライアンス管理を容易にする

GitHub のリポジトリから入手できるオープンソース版のアップストリーム Kubernetes は、最初からロックダウンされた環境ではありません。セキュリティよりも、柔軟性と使い勝手を優先した拡張性の高い設計になっています。

そのため、Kubernetes のセキュリティは、識別や認可などの他のシステムと統合するための拡張ポイントに依存していますが、問題はありません。これは、Kubernetes が多くのユースケースに適合することを意味します。ですが、アップストリーム Kubernetes のデフォルトがご自身にとって適切だと仮定できないということでもあります。「デフォルトでセキュア」という考え方で Kubernetes をデプロイするのであれば、心に留めておくべきいくつかのコア コンポーネントがあります。ホワイトペーパー「コンテナ セキュリティの基本」で言及している、Kubernetes をより安全にする GKE のネットワーク関連機能をいくつかご紹介します。

• セキュアな Pod ネットワーキング - Dataplane V2（一般提供版）では、クラスタを作成する際に Kubernetes ネットワーク ポリシーを有効にしています。また、ネットワーク ポリシー ロギング（一般提供版）により、クラスタのネットワークを可視化し、誰が誰と通信しているかを確認できます。

• セキュアなサービス ネットワーキング - GKE ゲートウェイ コントローラ（プレビュー版）は、柔軟性とデベロッパーの自主性を犠牲にすることなく、標準的で宣言的な Kubernetes インターフェースを通じて、集中的な制御とセキュリティを提供します。

「K8s にネットワーク ポリシーを実装することは、アプリケーションがネットワーク上でどのように動作するかを理解するために、推測や試行錯誤を伴う大変な作業になります。さらに、多くのコンプライアンスや規制のフレームワークでは、制御構成や違反のロギングという形で、防御態勢の根拠が求められます。GKE のネットワーク ポリシー ロギングを使用すれば、問題を迅速に切り分けて解決することができ、監査の際に必要な根拠を提供することもできます。これにより、ネットワーク ポリシーの実施と運用が大幅に簡素化されます。」 - Credit Karma

4. アラート、SLO、指標、ログを統合的に把握する

アプリケーションとインフラストラクチャの両方に対する詳細な可視性は、本番環境のトラブルシューティングと最適化に不可欠です。GKE ではアプリをデプロイすると、自動的にモニタリングされます。GKE クラスタにはエージェントが事前インストールされており、テレメトリー データを収集して、Cloud Logging や Cloud Monitoring などのオブザーバビリティ サービスに自動的にルーティングします。これらのサービスは、GKE と同様に相互に統合されているため、より良い知見を得て、それに基づいて迅速に行動できます。

たとえば、GKE ダッシュボードでは、クラスタ、名前空間、ノード、ワークロード、サービス、Pod、コンテナの指標をまとめて表示できるほか、それらすべてのエンティティにまたがる Kubernetes のイベントやアラートを統合的に表示できます。アラートもしくはダッシュボードからは、特定のリソースのログに直接アクセスでき、複数のベンダーの未接続ツールを経由することなく、リソース自体にナビゲートできます。

同様に、テレメトリー データは自動的に Google Cloud のオブザーバビリティ スイートにルーティングされるため、Google のサイト信頼性エンジニアリング（SRE）の原則に基づいたツールをすぐに利用できます。たとえば、SLO モニタリングでは、エラー バジェットを作成し、その目標に対してサービスをモニタリングすることで、開発チームと運用チームの間でより大きな説明責任を果たすことができます。また、OpenTelemetry を統合するための継続的な投資により、プラットフォームとアプリケーションの両方のテレメトリー収集が改善されます。

「（GKE 使用の場合）設定は一切不要で、統合によって全体のエラーを見つけることができます。クラウドネイティブな側面と直接統合することで、適時に情報を得られます。」 - Gannett Media Corp.、プラットフォーム エンジニアリング担当ディレクター、Erik Rogneby 氏

5. Anthos を使用してあらゆる場所で Kubernetes を管理して実行する

Anthos を通じて、お客様所有のデータセンターまたは他のクラウドでも GKE の機能を利用できます。Anthos を使用することで、GKE をはじめとする主要なフレームワークやサービスをあらゆるインフラストラクチャに導入し、Google Cloud から一元的に管理できます。

複数のクラウド プラットフォームでセキュアな環境を構築するのは困難なことです。各プラットフォームには、それぞれに異なるセキュリティ機能、ID システム、リスクがあり、追加のクラウド プラットフォームをサポートすることは、しばしばセキュリティ対策を二重に行うことを意味します。Anthos を使用すると、これらの課題の多くが解決されます。導入時点から複数のプラットフォーム上で運用できるため、アプリケーション チームやクラウド インフラストラクチャ チームにそれらに対応したツールの構築を任せる必要がなくなります。Anthos は、Google Cloud、AWS、そして近日中には Azure にも対応し、インフラストラクチャとサービスを導入および運用するためのコア機能を提供します。

最近リリースされた Anthos 1.7 には、マルチクラウドをよりアクセスしやすく持続可能なものにするためのさまざまな機能が搭載されています。Anthos の最新リリースがマルチクラウド導入の成功にどのようにつながるのかをぜひご覧ください。

「Anthos を使用することで開発速度が上がり、新しいサービスをより早く提供できるようになります。」 - PKO Bank Polski

6. 大規模な ML をシンプル化

GKE が柔軟性、自動スケーリング、管理の容易性をもたらすのに対し、GPU は優れた処理能力をもたらします。GKE における複数インスタンス NVIDIA GPU のサポート開始（プレビュー版）により、1 つの NVIDIA A100 GPU を、それぞれが高帯域幅のメモリ、キャッシュ、コンピューティング コアを持つ最大 7 個のインスタンスに分割できるようになりました。各インスタンスは 1 個のコンテナに対して割り振ることができ、1 つの NVIDIA A100 GPU に対して最大 7 個のコンテナをサポートします。さらに、複数インスタンス GPU は、コンテナ間でのハードウェアの分離と、GPU 上で実行中のすべてのコンテナに一貫性のある予測可能なサービス品質（QoS）をもたらします。

「GPU をリソースに接続するために必要な構成の数を減らすことで、Google Cloud と NVIDIA は大きな飛躍を遂げ、機械学習を大規模にデプロイするためのハードルは低くなりました。構成の複雑さが軽減されたことはもちろん、A100 による NVIDIA の完全な GPU 推論パフォーマンスは極めて高速です。Google Cloud と提携することで、当社にとって最適な方法で AI をデプロイするための多数の優れた選択肢を与えてもらいました。」 - Betterview

5 月 3 日（月）に KubeCon EU と同時期に開催された Build with GKE + Anthos を視聴して、Kubernetes 開発の取り組みを始めたり、取り組みを加速させたりしてみませんか。コンテナ化されたアプリケーションをコード化、構築、実行する方法から、それらを運用、管理、セキュリティを確保する方法まで、あらゆることをご紹介します。また、Google の Kubernetes サービス、デベロッパー ツール、オペレーション スイート、セキュリティ ソリューションの詳細を紹介する技術デモもご利用いただけます。Kubernetes に関するお客様の取り組みに、パートナーとして参加できることを楽しみにしております。

-プロダクト＆デザイン担当バイス プレジデント Pali Bhat