Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

エンドポイント

 

これまでに紹介’したオブジェクトが1つあります。EP、またはエンドポイントです。ここ’では、ラベルセレクターを使用してバックエンドとして特定の pod またはポッドが選択されていることがわかりました。そのため、サービスリクエストトラフィックはそのグループにリダイレクトされます。一致するポッドの IP およびポート情報は、エンドポイントオブジェクトに保持されます。ポッドが消滅して、いつでも生成されることがあります。そのため、pod の mortal の性質により、新しいポッドが新たな IP アドレスで追加される可能性があります。この動的なプロセスでは、エンドポイントは常に更新され、現在のバックエンドポッド IPs が反映されるため、サービストラフィックのリダイレクトが適切に動作するようになります。(CNI プロバイダが独自のサービス実装を保有している場合は、エンドポイントオブジェクトに基づいてサービスのバックエンドを更新します)。

ここでは、サービス、対応するエンドポイント、および pod とラベルが一致することを検証するためのクイックステップをいくつか示します。

サービスを作成するには、次のようにします。

エンドポイントのリストを表示するには

サービスのセレクターによって使用されるラベルを持つ pod を探すには、以下のようにします。

最後に、バックエンドポッドを拡張します。

ここで、エンドポイントを再びチェックして、それに応じて更新されたことを確認します。

セレクターなしのサービス

上記の例では、サービスが作成されるたびに Kubernetes システムによって自動的にエンドポイントオブジェクトが生成され、同じラベルが付いた pod が少なくとも1つ存在します。ただし、別のエンドポイントの使用事例としては、ラベルセレクターが定義されておらず、エンドポイントオブジェクトを手動で追加’することにより、サービスをネットワークアドレスとポートに手動で割り当てることができるサービスがあります。その後、エンドポイントをサービスに接続できます。これは、たとえば、物理サーバー上で実行されているバックエンド web サーバーが存在する設定など、状況によっては、Kubernetes サービスに統合する必要がある場合などに、非常に便利です。そのような場合は、通常どおりにサービスを作成してから、web サーバーを指すアドレスとポートを持つエンドポイントを作成するだけです。それ’だけではないでしょうか。このサービスはバックエンドタイプを気にすることなく、すべてのバックエンドが pod であるかのように、サービスリクエストトラフィックを正確にリダイレクトするだけです。