Headless Service と Cloud DNS を使用して Apigee を GKE に接続

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

先日、Google Kubernetes Engine（GKE）のバックエンドを Apigee X の背後に置く形で公開したいという案件について、ある組織をサポートさせていただきました。これはかなり一般的なアーキテクチャであり、Google Cloud で最新のウェブ アプリケーションを提供しているユーザーの大半がこのアーキテクチャ上で構築を行う傾向があります。

このシナリオでは、Google の API ゲートウェイである Apigee がリクエストを受信し、L7 ルーティングを行います。ユーザーは、GKE 上で 1 つ以上の Pod として実行されている適切なバックエンド アプリケーションにリダイレクトされます。

Apigee で L7 ルーティングを行うことは、有利なだけではなく、必要なことでもあります。ホスト名、URI（およびその他）の組み合わせに基づいてリクエストをルートし、ネイティブ ポリシーを介して認証と認可のメカニズムを適用するのは、API ゲートウェイの役割です。

GKE アプリケーションを内部的に Apigee に公開する方法を尋ねられたとき、Kubernetes Ingress またはゲートウェイの使用をすすめたのは自然なことでした。このようなオブジェクトを使用することで、複数のアプリケーション間で同じ GCP ロードバランサを共有して L7 ルーティングが行えるようになり、リクエストを適切な Kubernetes の Pod に送ることが可能になります。

すばらしいことではありませんか？サービスごとに複数のロードバランサが割り振りされるため、企業はインフラストラクチャをスケールした後、支出を減らし、容量の上限に達することを回避できます。

一方、システムは L7 ルーティングを 2 回行います。Apigee で 1 回、Kubernetes で 1 回です。これにより、レイテンシが増え、管理オーバーヘッドが増加する可能性があります。一致するホスト名と URI およびバックエンド間のマッピングを 2 回構成する必要があります。Apigee で 1 回、GKE で 1 回です。

これを回避する方法があるでしょうか？Google Cloud で最近リリースされた機能を組み合わせれば、それを実現する前提条件が揃うことがわかりました。

この記事で説明する内容は、現在、概念実証段階にあるため、慎重な評価が必要です。エンドツーエンドのソリューションについて説明する前に、各ビルディング ブロックとその利点について確認しましょう。

VPC ネイティブの GKE クラスタ

Google Cloud は最近、VPC ネイティブの GKE クラスタを導入しました。VPC ネイティブの GKE クラスタの興味深い機能の一つは、Pod とクラスタ IP サービスに VPC IP エイリアス範囲を使用するということです。クラスタ IP は、クラスタ内でのみルートできますが、Pod IP は、VPC 内の他のリソースからも（また、他の VPC やオンプレミスなどの相互接続されたインフラストラクチャからも）到達できるようになります。たとえ可能であっても、クライアントは Pod IP を直接参照するべきではありません。Pod IP は本質的に動的だからです。これに対して、Kubernetes の Service は、はるかに優れた代替手段です。作成されるたびに Kubernetes DNS によって既知の構造化されたレコードが登録されるためです。

Kubernetes Headless Service

先ほど説明したように、Pod IP を直接参照する Kubernetes Service（ひいては DNS エントリ）を作成する必要があります。これはまさに Kubernetes Headless Service が行うことです。Headless Service は他の Kubernetes Service と同じように Pod を参照しますが、クラスタ DNS は、サービス DNS レコードを（ClusterIP Service の場合のように）専用のサービス IP とではなく、Pod IP とバインドします。ここで問題となるのは、内部 Kubernetes DNS を外部クライアントでも利用できるようにして、Headless Service IP レコードをクエリし、（Pod のスケールインとスケールアウトに追随して）適切な Pod IP を正確に指せるようにする方法です。

GKE と Cloud DNS の統合

GKE はデフォルトのクラスタ ドメイン ネーム サービスとして kube-dns を使用しますが、オプションで、GKE を Cloud DNS と統合することもできます。これは通常、kube-dns のスケーリング制限を回避するために行われますが、今回のユースケースにも非常に役立ちました。GKE と Cloud DNS を VPC スコープで設定することで、クラスタの外部のクライアントは、クラスタによって Cloud DNS に登録されたエントリを直接クエリできるようになります。

Apigee DNS ピアリング

パーツの組み合わせ

これまでの内容を要約しましょう。

• （VPC スコープで構成された）DNS サービスとして Cloud DNS を使用する VPC ネイティブ GKE クラスタ

• GKE 上で（1 つ以上の Pod の形式で）実行されているバックエンド アプリケーション

• Pod を指す Headless Service 

• DNS クエリをユーザー VPC に送信するように構成された Apigee

リクエストが届くと、Apigee はターゲット エンドポイントの値を読み取り、Cloud DNS をクエリして、アプリケーション Pod の IP を取得します。Apigee は Pod に直接到達し、K8s クラスタ上でルーティングを追加で構成する必要はありません。

バックエンドを（SSL / TLS 証明書を使用して）安全に Apigee に公開することにご関心がない場合は、ここで読むことを止めて、リポジトリに移動して実際にやってみてください。

安全なバックエンドの公開

クライアントから Apigee までだけでなく、GKE Pod までの通信をエンドツーエンドで暗号化することもできます。つまり、対応するバックエンドにより証明書が Apigee に公開されるということです。

SSL / TLS オフロードは、Ingress オブジェクトおよびゲートウェイ オブジェクトの主要な仕事の一つですが、ソフトウェアの追加レイヤを維持し、クラスタ内で L7 ルーティングの構成を定義するには、追加コストがかかります。これは、まさに避けたかったことであり、この概念実証を提案した理由でもあります。

幸いにも、定評のある Kubernetes API とツールを使うことで、この目的が達せられます。

cert-manager は、証明書のライフサイクルを自動化するためによく使われるオープン ソース ツールです。ユーザーは、内部の認証局（CA）から証明書を作成するか、またはクラスタ外部の別の CA に証明書をリクエストできます。証明書オブジェクトと発行者を介して、ユーザーはクラスタで実行されている Pod の SSL 鍵ペアをリクエストし、更新を管理できます。

Pod に SSL 証明書を公開するには、cert-manager を単独で使用するだけで十分ですが、その場合 Pod に証明書を手動でアタッチする必要があります。これの単純な繰り返し作業は MutatingAdmissionWebhooks を使用することで確実に自動化することができます。

ソリューションの実行可能性をさらに実証するために、今回の例の次の部分は Kubernetes の変更用 Webhook の記述とデプロイからなります。Pod を作成すると、Webhook はサイドカー コンテナを自動的に追加し、アプリケーション TLS 証明書を公開するリバース プロキシを実行します（以前は証明書が cert-manager を介して生成され、Kubernetes Volume としてサイドカー コンテナにマウントされました）。

結論、制限事項、次のステップ

両方のコンポーネントで L7 ルーティングを行う必要がないように、この記事では、Apigee と GKE バックエンドを接続する新たな方法を提案しました。時間の節約（管理対象構成の大幅削減）と、パフォーマンスの向上をもたらすと考えています。

コラボレーションの機会を楽しみにしています。役立つインプットをプロジェクトにもたらすフィードバックや新しいアイデアは本当に大切です。ぜひお試しください。Google は、デモをオープンソースとしてリリースしました。GKE、Apigee、上記で説明したすべてのツールと構成について詳しく知ることができます。

いくつかの制限事項については確かに認識しており、今後、いくつかのコミュニティに貢献できる成果のある仕事を意識しています。

• Cloud DNS が GKE と統合されると、すべてのレコードに 10 秒の有効期間（TTL）がデフォルトとして設定されます。この値を手動で変更しようとすると、Cloud DNS GKE コントローラーが定期的に値を上書きし、デフォルト値に戻します。この値が高いと、クライアントは Kubernetes により最近スケールされた Pod に到達できなくなる可能性があります。この値を構成できるようにする見込みがあるか把握するために、プロダクト チームと協力して取り組んでいます。

• 一方、非常に低い TTL を使用すると、Cloud DNS クエリの数が大幅に増加し、コストが上昇する可能性があります。

• Envoy や Apache HTTP Server などの他のリバース プロキシへのサポートの追加を大いに期待しています。コントリビューションはいつでも大歓迎です。どう始めればよいかわからない場合は、お問い合わせいただくか、リポジトリで直接、イシューを開いていただくようお願いします。

このユースケースは珍しいことではないと考えているため、すぐに取り掛かり試してみることにしました。このジャーニーがどこまで続くのかわかりませんが、間違いなくためになり、楽しいものとなっています。ですから、皆様にとっても同じであることを願っています。

- Google Cloud クラウド コンサルタント Federico Preli
- Google Cloud クラウド コンサルタント Luca Prete