このドキュメントでは、Kubernetes DNS ベースのサービス ディスカバリの概要と Kf での使用方法について説明します。
Kf で Kubernetes サービス ディスカバリを使用する場合
Kubernetes サービス ディスカバリは、アプリケーションがデプロイされている場所に関係なく、一貫した方法でバッキング サービスを見つける必要があるアプリケーションで使用できます。たとえば、構成で常にローカル SMTP ゲートウェイを参照する共通の URI を使用して、コードを実行した環境から分離したい場合があります。
アプリケーション チームにとって、サービス ディスカバリは次のような利点があります。
- 環境ごとの構成の量を削減する。
- クライアント アプリケーションとサーバー アプリケーションを分離する。
- アプリケーションを新しい環境に移植できる。
Kubernetes サービス ディスカバリは、次の場合に使用できます。
- アプリケーションがコンテナの DNS 構成を使用してホストを解決する。
- アプリケーションが、バッキング サービスを使用して同じ Kubernetes クラスタまたは Namespace にデプロイされる。
- バッキング サービスに関連する Kubernetes Service がある。Kf はアプリごとにこれらを作成します。
- Kubernetes NetworkPolicies では、通信に必要な Kubernetes Service とアプリケーションの間のトラフィックが許可されます。Kf は、これらのポリシーを各 Kf スペースに作成します。
次のような場合は Kubernetes サービス ディスカバリを使用しないでください。
- アプリケーションを複数のクラスタ間でフェイルオーバーする必要がある。
- アプリケーションで使用される DNS リゾルバをオーバーライドする。
- アプリケーションが特定の種類の負荷分散を必要とする。
Kubernetes サービス ディスカバリの仕組み
Kubernetes サービス ディスカバリは、Kubernetes ノードで実行されているコンテナの DNS 構成を変更することで機能します。アプリケーションが非修飾ドメイン名を検索した場合、ローカル DNS リゾルバが最初にローカル クラスタ内の名前を解決しようとします。
複数のパートのないドメインは、コンテナの名前空間内の Kubernetes Services の名前に解決されます。各 Kf アプリは同じ名前の Kubernetes Services を作成します。2 つの Kf アプリ ping と pong が同じ Kf スペースにデプロイされている場合、ping は URL http://pong を使用してトラフィックを他のサービスに送信できます。
1 つのドットを含むドメインは、ドットの後にラベルと同じ名前を持つ Kubernetes 名前空間内の Kubernetes Services に解決されます。たとえば、database 名前空間に PostgreSQL データベースと customers サービスがある場合、別の名前空間内のアプリケーションは postgres://customers.database を使用して名前を解決できます。
Kf でサービス ディスカバリを使用する方法
Kubernetes DNS ベースのサービス ディスカバリは任意の Kf アプリで使用できます。Kf アプリは同じ名前の Kubernetes Service を作成し、Kf スペースは同じ名前の Kubernetes 名前空間を作成します。
- 現在のスペースの Kf アプリは、
protocol://app-nameを使用して参照します。 - 異なるスペースの Kf アプリは、
protocol://app-name.space-nameを使用して参照します。 - カスタムポートをリッスンする現在のスペースの Kf アプリは、
protocol://app-name:portを使用して参照します。 - カスタムポートをリッスンする別のスペースの Kf アプリは、
protocol://app-name.space-name:portを使用して参照します。
ベスト プラクティス
DNS ベースのサービス ディスカバリの対象になるアプリケーションの場合は、ヘルスチェックを頻繁に行い、接続を受け入れるホストのプールでアプリケーションの追加と削除が迅速に行われるようにします。
DNS ベースのサービス ディスカバリを使用するアプリケーションは、サービスの安定性が保証されません。このため、解決されたサービスの IP アドレスをキャッシュに保存するべきではありません。
環境固有のサービスがクラスタ外部に存在する場合は、ExternalName Kubernetes Services を設定すると、Kubernetes DNS を使用して解決できます。これらの Kubernetes Services は同じ解決機能を備えていますが、CNAME レコードを返してリクエストを外部認証局にリダイレクトします。
Eureka との比較
Eureka は、Netflix によって作成されたオープンソースのクライアント側ロードバランサです。これは、Spring Cloud Services サービス ブローカーの一部として一般的に使用されます。Eureka は、ワークロードが頻繁に中断し、IP アドレスの解決が不安定になる環境で実行されているサービスに対するリージョン ロードバランサとサービス ディスカバリ メカニズムとして構築されています。
Eureka は、クライアント モデル、サーバーモデルとして設計されています。クライアントはサーバーに自身を登録し、ハートビートを定期的に送信します。サーバーは、クライアントに関連付ける名前を提供します。このサーバーにより、接続しているすべてのクライアントが名前を解決されます。
次の理由から、Kubernetes の Eureka ではなく、Kubernetes DNS を使用する必要があります。
- DNS は、ライブラリを必要とせず、あらゆるプログラミング言語とアプリケーションで動作します。
- アプリケーションの既存のヘルスチェックを再利用することで、エラーの組み合わせを減らすことができます。
- Kubernetes が DNS サーバーを管理するため、依存関係を少なくすることができます。
- Kubernetes DNS は、他の Kubernetes と同じポリシーと RBAC の制約に従います。
次のような場合は、Eureka サーバーをデプロイするほうが良いこともあります。
- Kubernetes と VM ベースのアプリケーション全体でサービス ディスカバリが必要である。
- クライアント ベースの負荷分散が必要である。
- 独立したヘルスチェックが必要である。
次のステップ
- GKE のサービス ディスカバリの詳細を確認する。
- Eureka と類似したマネージド サービスである Service Directory について確認する。