Kubernetes におけるサービス登録と検出の原則の分析

k8s についてある程度の知識を持つ技術者は、k8s にサービス登録と検出機能があることだけを知っていればよいはずです。今日は、この原則を分析し、それがどのように実装されるかを見ていきます。

サービス登録と検出とは何ですか?

サービス登録と検出は、クラスター内のさまざまなサービスを動的に検出して接続するためのメカニズムです。たとえば、マイクロサービスを開発するときには、Eureka や Nacos がよく使用されます。

サービス B はサービス レジストリに自身を登録します。これをサービス登録と呼びます。

サービス A は、サービス レジストリからサービス B のノード情報を検出します。これをサービス検出と呼びます。

K8s でサービス検出が必要なのはなぜですか?

動的

K8s クラスターでは、ポッドとサービスの数と場所が動的に変化します。ポッドはスケーリング、再デプロイ、または移行される可能性があります。このような環境では、ハードコードされたサービス アドレスは実現不可能であるため、サービス登録と検出により、システムはそのような変更を自動的に認識できるようになります。

透明性

サービス登録と検出により、システムは特定の IP アドレスやポート番号を気にすることなく、サービス名を使用して他のサービスにアクセスできるようになります。

負荷分散

負荷分散は、サービス登録と検出を通じて実現され、リクエストを複数のバックエンド サービス インスタンスに均等に分散します。

フォールトトレランス

サービス インスタンスに障害が発生したり、利用できなくなったりすると、サービス登録と検出によって、利用できないインスタンスが自動的に検出され、サービス検出メカニズムから削除されます。この方法では、リクエストは利用可能なインスタンスに自動的にルーティングされ、アプリケーションのフォールト トレランスと可用性が向上します。

k8s サービスの登録と検出の原則

上記の紹介に基づいて、K8s の Pod のライフサイクルは短く、IP アドレスは常に変更されることがわかります。サービス コンシューマーがこれらの Pod IP を管理して負荷分散のために Pod を呼び出す場合、非常に複雑になります。外部にサービスを提供する統一された入り口を提供するために、k8s は Service を作成します。内部か外部かを問わず、サービスは一律に呼び出され、その後サービスによってバックエンドのポッドに転送されます。

エンドポイント

Pod のアドレス管理はエンドポイントによって管理されます。エンドポイント情報は、サービス名に従って照会できます。 API を通じてサービス オブジェクトが作成/変更されると、エンドポイント コントローラーはサービス オブジェクトをリッスンし、サービスによって構成されたセレクターに基づいてエンドポイント オブジェクトを作成します。このオブジェクトは、etcd にポッドの IP とコンテナ ポート情報を保存します。

それらの関係は次のとおりです。

同時に、エンドポイント コントローラーは、オンライン イベントやオフライン イベントなど、ポッドに関連するイベントを監視します。エンドポイント コントローラーはこれらのイベントを受信すると、それに応じてエンドポイント リソースを更新し、使用できないポッドをエンドポイント リストから削除します。

ドメイン名解決

サービス IP は変更される可能性があるため、コード内にサービス IP がハードコードされている場合は、後でメンテナンスするのが面倒になります。したがって、サービスを作成するときに、CoreDNS はサービスのドメイン名解決レコードを追加し、サービス名を対応するクラスター IP アドレスに解決します。これにより、他のポッドまたはサービスはサービス名を使用してサービスにアクセスできるようになります。

kubeプロキシ

kube-proxy は、クラスター内の各ノードで実行されるネットワーク プロキシです。クラスター内のサービスを他のポッドまたは外部ネットワークに公開する役割を担います。 Node ノード上でネットワーク ルールと転送ルールを設定することで、サービス リクエストを正しいターゲット Pod に転送します。

同時に、kube-proxy は負荷分散アルゴリズムを実装して、受信したサービス要求をバックエンドの Pod インスタンスに均等に分散します。これにより、サービスは複数のレプリカを使用してバランスよくリクエストを処理できるようになり、可用性とパフォーマンスが向上します。

kube-proxy は、監視を通じてサービスとエンドポイント オブジェクトの作成を学習し、サービスの CLUSTER-IP とポート情報を取得し、転送用の iptables NAT ルールを作成するか、ipvs モジュールを通じて VS サーバーを作成して、CLUSTER-IP を通過するすべてのトラフィックがバックエンド ポッドに転送されるようにします。

サービスのターゲット Pod が同じノード上にある場合、kube-proxy はリクエストをノード間で転送せずに、そのノード上の Pod に直接転送します。この場合、リクエストは他のノードに送信されません。

ただし、サービスのターゲット Pod が複数のノードに分散されている場合、kube-proxy は負荷分散アルゴリズムを通じて他のノード上の Pod にリクエストを転送できます。

サンプルデモ

次に、2 つの構成ファイルに基づいて上記の結論を検証します。

nginx-deployment.yaml

 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 4 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: mirrorgooglecontainers/serve_hostname ports: - containerPort: 80

serve_hostname は、k8s によって公式に提供されるデバッグ イメージです。ホスト名の Web サーバーを返します。ポッドにアクセスすると、ホスト名が返されます。

nginx-サービス.yaml

 apiVersion: v1 kind: Service metadata: name: nginx-service spec: ports: - name: service-port port: 80 protocol: TCP targetPort: 9376 selector: app: nginx type: ClusterIP

サービスのセレクター属性に app: nginx が指定されていることがわかります。これは、デプロイメントで定義されている nginx ポッドと一致します。

上記の2つのファイルを順番に実行すると、最終的に次の情報が得られます。

サービスアドレスビュー

kubectl get svc nginx-service

ポッド情報を表示

kubectl get pods -l app=nginx -o wide

エンドポイント情報ビュー

サービス名によるクエリ

kubectl get ep nginx-service

CoreDNS情報検証

任意の Pod にログインし、ping コマンドを実行します。サービス クラスター IP がサービス名に従って解決されていることがわかります。

負荷分散の検証

任意のポッドにログインし、curl nginx-service を実行し、サービスのポート 80 を要求すると、対象のポッド名が返されます。

上記では、サービス ディスカバリとは何か、そして k8s サービス ディスカバリがどのように実装されるかについて説明しました。お役に立てれば幸いです。