Kubernetesのヘッドレスサービスの簡単な概要

Kubernetes には多くの概念があり、その中には難しい名前を持つヘッドレス サービスなど、非常にわかりにくいものもあります。では、ヘッドレス サービスとは何でしょうか。また、その使用シナリオは何でしょうか。一言でまとめると、ヘッドレス サービスは、クラスター内 (ClusterIP なし) でのみアクセス可能な Pod グループで構成されたサービスです。通常、ステートフル アプリケーションをデプロイするには、StatefulSet と組み合わせて使用​​します。

1. サービスとサービス検出

ヘッドレス サービスについて話すときは、まずサービスとサービス検出について話す必要があります。

1.1、サービスの説明

サービスは主に、Pod のグループへのアクセスを実装するために使用されます。サービスは、ラベル セレクターを通じて Pod リソースを関連付けます。サービスは、nodePort と loadbalancer を通じてサービスを公開します。サービスは、アクセスされたポートに基づいて、対応するリクエストをバックエンド Pod のポートに転送します。

Service オブジェクトの IP アドレス (ClusterIP) は、Kubernetes クラスター内でのみアクセス可能で、外部からはアクセスできない仮想 IP アドレスです。一般に、サービスを外部アクセスに公開する方法はいくつかあります。

• hostPort 経由の単一ノード上のポート マッピング
• ワーカーノード上のネットワークを使用するようにポッドのホストネットワークを構成する
• NodePortまたはLoadBalancerサービスを使用する
• Ingressリソースの使用

基本的に、サービス オブジェクトはワーカー ノードのカーネル内のルーティング ルールのセットに対応し、サービス オブジェクトの ClusterIP に到着したトラフィックを、対応する Pod オブジェクトの IP アドレスとポートに転送します。

各作業ノードの kube-proxy コンポーネントは、API サーバーを介して各サービスとそれに関連付けられた Pod オブジェクトを継続的に監視し、サービス オブジェクトの作成または変更を現在の作業ノードのルーティング ルールにリアルタイムで書き込みます。クライアント、サービス、および Pod オブジェクト間の関係を次の図に示します。

1.2 サービスの種類

サービスは一般的に、ClusterIP、NodePort、LoadBalancer の 3 つのタイプに分けられます。

クラスターIP

サービスはクラスターの内部 IP アドレスを通じて公開されます。 CusterIP アドレスはクラスター内でのみアクセス可能であり、クラスター外のクライアントからはアクセスできません。

ノードポート

NodePort タイプは、サービスのポート番号を各ノードのポート番号にマッピングし、バックエンドの Pod に配布して処理します。このタイプのサービスには、クラスター内のクライアントが CIusterIP を介して直接アクセスできるほか、クラスター外のクライアントが nodeIP:nodePort を介してアクセスすることもできます。

ロードバランサー

LoadBalancer タイプは NodePort に基づいており、サービスをロードバランサーの IP アドレスにマッピングします。通常、パブリック クラウド環境で使用されます。

クライアントは、ロード バランサーの IP とサービス ポート番号を通じて特定のサービスにアクセスできます。 kube-proxy が提供する負荷分散メカニズムを介してトラフィックを転送する必要はありません。トラフィックはバックエンド Pod に直接転送できます。

LoadBalancer をローカルに構築する場合は、通常、metallb ソリューションが使用されます。公式ウェブサイトのアドレスは https://metallb.universe.tf/ です。興味のある友達は自分で作ることもできます。

2. ヘッドレスサービスのコンセプト

シナリオによっては、外部アクセス機能を提供する必要がなく、必要な Pod リソースを内部でのみ見つける必要がある場合は、Headless Service を使用してこれを実現できます。

ClusterIP を持たないこのタイプのサービス リソースは、ヘッドレス サービスです。このサービスのリクエスト トラフィックは kube-proxy によって処理される必要がなく、負荷分散およびルーティング ルールはありません。代わりに、ClusterDNS のドメイン名解決メカニズムは、固定された Pod リソースに直接アクセスします。

一般的に、Headless は以下で紹介する StatefulSet と組み合わせて使用​​されます。

3. ヘッドレスでStatefulSetを使用する

3.1 ステートフルセットの概要

StatefulSet は、ステートフル アプリケーションを調整するコントローラーです。ステートフル アプリケーションは、一意の永続データと固定アクセス名を持つ Pod のグループです。 StatefulSet は主に、ZK、Kafka、MySQL、Redis などのステートフル アプリケーションのデプロイに使用されます。

ステートフル リソースは通常、Headless Service と StatefulSet の 2 つのコンポーネントで構成されます。ヘッドレス サービスは、各 Pod リソースに一意の固定識別子を割り当て、DNS 解決レコードを生成するために使用されます。 StatefulSet は、Pod オブジェクトをオーケストレーションし、volumeClaimTemplate の助けを借りて Pod リソース専用のストレージを自動的に作成するために使用されます。

高いデータ可用性は、シナリオがスケールダウンされているかスケールアップされているかに関係なく、StatefulSet が確保しようとしている機能です。 StatefulSet コントローラーは並列スケーリングをサポートしていません。データエラーを回避するために、一度に 1 つの Pod リソースのみを開始または終了します。

StatefulSet、volumeClaimTemplate、PVC、PV の関係を次の図に示します。

3.2 ステートフルセットの機能

秩序

StatefulSet は、Headless Service を使用して、各 Pod リソースに一意の固定識別子を割り当てます。通常は、Pod 名の後に -0、-1、-2 などを追加します。レプリカの数が 2 に設定されていると仮定します。起動するときは、最初に pod-0 を起動し、次に pod-1 を起動します。停止する場合は逆の順序で停止し、最初に pod-1 を停止し、次に pod-0 を停止します。

ステートフル

ステートレス アプリケーションには固定の ID がありません。他のポッドの影響を受けません。同じテンプレートで作成された Pod は、以前の Pod を置き換えることができます。

ステートフル アプリケーションには固定の名前とストレージがあり、同じグループ内の他の Pod の影響を受けます。 Pod オブジェクトが置き換えられても、新しい Pod は同じ ID と同じストレージを持ちます。

StatefulSet は、ストレージ ボリューム テンプレートを使用して各 Pod オブジェクト専用の PVC ストレージ ボリュームを作成し、volumeClaimTemplate を通じて変更なしでバインドされたストレージ PVC を自動的に作成します。

Pod オブジェクトを削除しても、関連する PV リソースは削除されません。ノード障害などの理由により Pod オブジェクトが別のノードに再スケジュールされた場合、以前に同じ名前の Pod インスタンス専用であった PV データは引き続き再利用できます。

安定したサービス検出

ステートフルなので、必要な Pod を見つけたい場合は、pod name.svc name.namespace.svc.cluster.local を介して直接アクセスできます。

4. Yamlの例

この例では、ストレージ付きの nginx サービスのデプロイなど、Headless Service + StatefulSet をデプロイします。この記事では VolumeClaimTemplates が使用され、storageClassName の作成が必要になります。 PV、PVC、StorageClass、Provisioner については後ほど別の記事で解説します。

 apiVersion: v1 kind: Service metadata: name: nginx-statefulset-svc namespace: dev spec: # ClusterIP | NodePort | LoadBalancer type: ClusterIP # headless service 这里的clusterIP使用None clusterIP: None selector: app: nginx-statefulset-tpl ports: - name: http port: 80 targetPort: 80 --- apiVersion: apps/v1 kind: StatefulSet metadata: name: nginx-statefulset namespace: dev labels: app: nginx-statefulset spec: replicas: 2 serviceName: nginx-statefulset-svc selector: matchLabels: app: nginx-statefulset-tpl template: metadata: labels: app: nginx-statefulset-tpl spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent volumeMounts: - name: www mountPath: /usr/share/nginx/html # volumeClaimTemplates是StatefulSet独有的配置，前提要先创建一个storageClassName volumeClaimTemplates: - metadata: name: www spec: resources: requests: storage: 200Mi accessModes: - ReadWriteOnce storageClassName: nfs-client

5. まとめ

一言でまとめると、ヘッドレス サービスは、クラスター内 (ClusterIP なし) でのみアクセス可能な Pod グループで構成されたサービスです。通常、ステートフル アプリケーションをデプロイするには、StatefulSet と組み合わせて使用​​します。

ヘッドレスサービスなので、まずはサービスです。通常、サービスには内部からも外部からもアクセスできます。内部アクセスのみを提供するため、ヘッドレス サービスと呼ばれます。内部アクセスのみであるため、安定したアクセス機能を提供することが絶対に必要であり、そうでなければ役に立ちません。たとえば、Pod 名とストレージは固定されているため、通常は StatefulSet と組み合わせて使用​​してステートフル アプリケーションをデプロイします。