【ITニュース解説】Part-106: 🚀Implementing Headless Services in Google Kubernetes Engine (GKE)

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを自動化するための強力なプラットフォームである。システムエンジニアにとって、現代のアプリケーション開発・運用においてKubernetesの理解は不可欠となっている。その中でも特に重要な概念の一つが「Service（サービス）」であり、今回はその中でも「ClusterIP Service」と「Headless Service」という二つのタイプについて解説する。

まず、Kubernetesにおけるアプリケーションの最小実行単位は「Pod（ポッド）」と呼ばれる。Podの中には一つ以上のコンテナが動作しており、これが実際のアプリケーションの機能を提供する。しかし、Podは一時的な存在であり、何らかの理由で停止したり再起動したりすると、そのIPアドレスが変わってしまう可能性がある。このため、他のアプリケーションやユーザーが安定してPodにアクセスできるようにする仕組みが必要となる。それが「Service」の役割である。

アプリケーションをKubernetesで動かす際、最初に「Deployment（デプロイメント）」という設定を使うことが多い。Deploymentは、同じ設定を持つ複数のPodをまとめて管理するためのリソースである。例えば、一つのアプリケーションに対して「このコンテナイメージを使って、常に4つのPodを動かしておいてほしい」といった指示をDeploymentに与えることができる。もしPodがクラッシュしても、Deploymentが自動的に新しいPodを作成し、常に指定された数のPodを稼働させ続ける。この例では、「myapp1-deployment」という名前で4つのPodを作成し、それぞれが「myapp1-container」という名前のコンテナで、hello-app:2.0というイメージを実行し、内部ポート8080で通信を受け付けるように設定されている。これらのPodには、「app: myapp1」というラベルが付与されており、このラベルがServiceとPodを結びつける鍵となる。

次に、「ClusterIP Service」について詳しく見てみよう。ClusterIP Serviceは、Kubernetesクラスタの内部でのみアクセス可能な固定された仮想IPアドレス（これを「ClusterIP」と呼ぶ）を提供する。クラスタ内の他のPodやServiceは、このClusterIPを使って、対象のアプリケーションに安定してアクセスできる。たとえバックエンドで動作しているPodが入れ替わっても、ServiceのClusterIPは変わらないため、アプリケーションは常に同じIPアドレスとポートでアクセスできる。この例では、「myapp1-cip-service」というClusterIP Serviceが作成されている。このServiceは、「app: myapp1」というラベルを持つPodを対象とし、クラスタ内の80番ポートへの通信を、対象Podの8080番ポートに転送するように設定されている。これにより、他のPodはmyapp1-cip-serviceという名前またはそのClusterIPを使って、安定してmyapp1アプリケーションに接続できる。

一方で、「Headless Service（ヘッドレスサービス）」はClusterIP Serviceとは異なる振る舞いをする。Headless Serviceは、その名の通り「頭（ヘッド）がない」Serviceであり、通常のServiceが持つはずのClusterIPが割り当てられない。この違いは、Serviceの設定ファイルでclusterIP: Noneと指定することで実現される。ClusterIPが割り当てられない代わりに、Headless Serviceの名前を使ってDNS（Domain Name System）名前解決を行うと、関連付けられたPodのIPアドレスが複数、直接返される点が最大の特徴である。

この例では、「myapp1-headless-service」というHeadless Serviceが作成されている。このServiceも「app: myapp1」というラベルを持つPodを対象とし、80番ポートへの通信をPodの8080番ポートに転送する設定はClusterIP Serviceと同じである。しかし、ClusterIPがないため、このService経由で通信する際は、Podが公開しているポート番号（この場合は8080）を直接指定する必要がある場合が多い。

これらのServiceがどのように動作するかを検証するために、いくつかのコマンドを実行する。まず、設定ファイルをKubernetesクラスタに適用し、Deployment、Pod、Serviceの状態を確認する。kubectl get svcコマンドでServiceの一覧を見ると、ClusterIP ServiceにはCLUSTER-IPが割り当てられているのに対し、Headless ServiceのCLUSTER-IP欄はNoneと表示されていることが確認できる。

次に、curl-podというテスト用のPodを作成し、そのPodのシェルに入って実際に各ServiceへのDNS名前解決とアクセスを試みる。 ClusterIP Service (myapp1-cip-service)に対してnslookupコマンドを実行すると、ServiceのClusterIPという単一のIPアドレスが返される。そして、curlコマンドでこのService名にアクセスすると、ClusterIPを経由してバックエンドのPodに接続できる。 一方、Headless Service (myapp1-headless-service)に対してnslookupコマンドを実行すると、ClusterIPは返されず、関連付けられている複数のPodそれぞれのIPアドレスが直接返される。そして、curlコマンドでHeadless Service名にポート番号を加えてアクセスすると、DNS解決されたPodのIPアドレスのいずれかに直接トラフィックが送られ、アプリケーションに接続できる。これは、トラフィックがServiceの仮想IPアドレスを経由せず、直接PodのIPアドレスに送られることを意味する。

このように、ClusterIP Serviceはクラスタ内部に安定した単一のアクセスポイントを提供し、アプリケーションの負荷分散やサービスディスカバリをシンプルに行いたい場合に適している。一方で、Headless ServiceはClusterIPを持たず、DNS名前解決によって直接PodのIPアドレスを公開するため、より高度な制御が必要な場合に利用される。具体的には、データベースのように各Podが独立した状態を持つ「ステートフルなアプリケーション」や、アプリケーション自身が他のサービスのPodのIPアドレスを直接知って通信したい「DNSベースのサービスディスカバリ」、あるいはKubernetesのStatefulSet（ステートフルなPodを管理する特別なコントローラ）と組み合わせて使用されることが多い。例えば、Cassandraのような分散データベースでは、各ノードが他のノードのIPアドレスを直接知る必要があるため、Headless Serviceが非常に有効な手段となる。

KubernetesにおけるServiceの基本的な役割と、ClusterIP ServiceおよびHeadless Serviceそれぞれの特徴と使い分けは、クラスタ内で動作するアプリケーションの安定稼働と効率的な運用を実現するために非常に重要な概念であり、システムエンジニアとしてぜひ習得しておきたい知識である。