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つのファイルを順番に実行すると、最終的に次の情報が得られます。

サービスアドレスビュー