# Service
> ワークロードが複数のバックエンドに分散している場合でも、クラスター内で実行されているアプリケーションを、単一の外部向けエンドポイントの背後に公開します。
---
LLMS index: [llms.txt](/llms.txt)
---
Kubernetesにおいて、Serviceとは、 クラスター内で1つ以上のPodとして実行されているネットワークアプリケーションを公開する方法です。
KubernetesにおけるServiceの主要な目的の一つは、既存のアプリケーションを改修することなく、サービスディスカバリの仕組みを利用できるようにすることです。
Pod内で実行するコードは、クラウドネイティブな環境向けに設計されたものでも、コンテナ化した古いアプリケーションでも構いません。
Serviceを使用することで、その複数のPodがネットワーク上でアクセス可能になり、クライアントから通信できるようになります。
Deploymentを使用してアプリケーションを実行する場合、DeploymentはPodを動的に作成、削除します。
常に、どれだけのPodが動作していて健全な状態であるかは分からず、健全なPodの名前すら分からない可能性もあります。
KubernetesのPodは、クラスターの望ましい状態に一致させるために作成、削除されます。
Podは一時的なリソースです(個々のPodに対して、信頼性が高く永続的であるとは期待すべきではありません)。
各Podは独自のIPアドレスを取得します(Kubernetesは、ネットワークプラグインがこれを保証することを期待しています)。
クラスター内の特定のDeploymentで、ある時点で実行されているPodの集合は、少し時が経過すると、異なるPodの集合になっている可能性があります。
これは、とある問題につながります。
Podの集合(「バックエンド」と呼びます)がクラスター内の他のPod(「フロントエンド」と呼びます)に機能を提供する場合、フロントエンドがワークロードのバックエンド部分を使用できるように、どのようにして接続対象のIPアドレスを発見し、追跡するのでしょうか？
ここで _Service_ の登場です。
## KubernetesにおけるService {#services-in-kubernetes}
Kubernetesの一部であるService APIは、Podのグループをネットワーク経由で公開するための抽象化です。
各Serviceオブジェクトは、エンドポイントの論理的な集合(通常、これらのエンドポイントはPodです)および、Podの公開方法についてのポリシーを定義します。
例として、3つのレプリカで実行されているステートレスな画像処理バックエンドについて考えます。
これらのレプリカは互いに代替可能です—フロントエンドはどのバックエンドを使用するかを気にしません。
バックエンドを構成する実際のPodは変化する可能性がありますが、フロントエンドのクライアントはそれを意識する必要はなく、バックエンドの集合を自身で追跡すべきでもありません。
Serviceという抽象化により、この分離が可能になります。
Serviceが対象とするPodは、通常、ユーザーが定義するセレクターによって決定されます。
Serviceのエンドポイントを定義する他の方法については、[セレクター _なし_ のService](#services-without-selectors)を参照してください。
ワークロードがHTTPを使用する場合、[Ingress](/docs/concepts/services-networking/ingress/)を使用して、Webトラフィックがワークロードに到達する方法を制御できます。
IngressはServiceタイプではありませんが、クラスターへのエントリポイントとして機能します。
Ingressを使用すると、ルーティングルールを単一のリソースに統合できるため、クラスター内で個別に実行されている複数のワークロードコンポーネントを、単一のリスナーの背後で公開できます。
Kubernetesの[Gateway](https://gateway-api.sigs.k8s.io/#what-is-the-gateway-api) APIは、IngressやServiceを超える追加機能を提供します。
GatewayはCustomResourceDefinitionを使用して実装された拡張APIの一種であり、クラスターに追加することで、クラスター内で実行されているネットワークサービスへのアクセスを設定できます。
### クラウドネイティブなサービスディスカバリ {#cloud-native-service-discovery}
アプリケーションでサービスディスカバリにKubernetes APIを使用できる場合、APIサーバーに問い合わせて一致するEndpointSliceを取得できます。
KubernetesはService内のPodの集合が変更されるたびに、そのServiceのEndpointSliceを更新します。
ネイティブではないアプリケーションの場合、KubernetesはアプリケーションとバックエンドのPodの間にネットワークポートまたはロードバランサーを配置する方法を提供します。
いずれの場合でも、ワークロードはこれらの[サービスディスカバリ](#discovering-services)の仕組みを使用して、接続先を見つけることができます。
## Serviceの定義方法 {#defining-a-service}
Serviceはオブジェクトです(PodやConfigMapがオブジェクトであるのと同じです)。
Kubernetes APIを使用してServiceの定義を作成、表示、変更できます。
通常は`kubectl`のようなツールを使用して、これらのAPI呼び出しを行います。
例えば、TCPポート9376でリッスンし、`app.kubernetes.io/name=MyApp`というラベルが付けられたPodの集合があるとします。
そのTCPリスナーを公開するServiceを定義できます:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
このマニフェストを適用すると、デフォルトのClusterIP [Serviceタイプ](#publishing-services-service-types)で「my-service」という名前の新しいServiceが作成されます。
このServiceは、`app.kubernetes.io/name: MyApp`ラベルを持つすべてのPodのTCPポート9376を対象とします。
KubernetesはこのServiceに対してIPアドレス(_ClusterIP_)を割り当てます。
このIPアドレスは仮想IPアドレスメカニズムによって使用されます。
このメカニズムの詳細については、[仮想IPとServiceプロキシ](/docs/reference/networking/virtual-ips/)を参照してください。
このServiceのコントローラーは、セレクターに一致するPodを継続的にスキャンし、ServiceのEndpointSliceの集合に対して必要に応じて更新を行います。
Serviceオブジェクト名は、有効な[RFC 1035ラベル名](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names)である必要があります。
備考:
Serviceは 任意の 受信portをtargetPortにマッピングできます。
ただし、デフォルトでは、利便性のためにtargetPortはportフィールドと同じ値に設定されます。
### Serviceオブジェクトの緩和された命名要件 {#relaxed-naming-requirements-for-service-objects}
FEATURE STATE:
Kubernetes v1.36 [beta](デフォルトで有効)
`RelaxedServiceNameValidation`フィーチャーゲートは、Serviceオブジェクト名が数字で始まることを許可します。
このフィーチャーゲートが有効化されている場合、Serviceオブジェクト名は有効な[RFC 1123ラベル名](/docs/concepts/overview/working-with-objects/names/#dns-label-names)である必要があります。
### ポート定義 {#field-spec-ports}
Pod内のポート定義には名前が含まれ、Serviceの`targetPort`属性でこれらの名前を参照できます。
例えば、次のようにServiceの`targetPort`をPodのポートにバインドできます:
```yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
---
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
name: http-web-svc
```
これは、Serviceに異なるポート番号で同じネットワークプロトコルを提供する複数のPodが混在している場合でも、単一の設定された名前を使用して機能します。
これにより、Serviceのデプロイと進化に大きな柔軟性がもたらされます。
たとえば、バックエンドソフトウェアの次のバージョンでPodが公開するポート番号を変更しても、クライアントを壊すことはありません。
Serviceのデフォルトプロトコルは[TCP](/docs/reference/networking/service-protocols/#protocol-tcp)です。
他の[サポートされているプロトコル](/docs/reference/networking/service-protocols/)も使用できます。
多くのServiceは複数のポートを公開する必要があるため、Kubernetesは単一のServiceに対して、[複数のポート定義](#multi-port-services)をサポートしています。
各ポート定義は、同じ`protocol`を持つことも、異なるものを持つことも可能です。
### セレクター無しのService {#services-without-selectors}
Serviceは、セレクターを使ってKubernetes Podへのアクセスを抽象化するのが一般的です。
ただし、セレクター無しで対応するEndpointSliceオブジェクトを使用すれば、クラスター外のバックエンドなど、他の種類のバックエンドも抽象化できます。
例えば:
* 本番環境では外部のデータベースクラスターを使用したいが、テスト環境では独自のデータベースを使用する場合。
* Serviceを別のNamespaceまたは別のクラスター上のServiceに向けたい場合。
* ワークロードをKubernetesに移行中の場合。
移行方法を評価している間は、バックエンドの一部のみをKubernetesで実行する場合。
これらのいずれのシナリオでも、Podに一致するセレクターを指定 _せずに_ Serviceを定義できます。
例えば:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
```
このServiceにはセレクターが含まれないため、対応するEndpointSliceオブジェクトは自動的に作成されません。
EndpointSliceオブジェクトを手動で追加することで、実行されているネットワークアドレスとポートにServiceをマッピングできます。
例えば、次のように定義します:
```yaml
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: my-service-1 # 慣習で、EndpointSliceの名前にプレフィックスとしてService名を使用します
labels:
# "kubernetes.io/service-name"ラベルを設定する必要があります。
# その値はServiceの名前と一致させてください
kubernetes.io/service-name: my-service
addressType: IPv4
ports:
- name: http # 上記で定義したServiceポート名と一致させる必要があります
appProtocol: http
protocol: TCP
port: 9376
endpoints:
- addresses:
- "10.4.5.6"
- addresses:
- "10.1.2.3"
```
#### カスタムEndpointSlice {#custom-endpointslices}
Service用に[EndpointSlice](#endpointslices)オブジェクトを作成する場合、EndpointSliceには任意の名前を使用できます。
ただし、名前空間内の各EndpointSliceは一意の名前である必要があります。
EndpointSliceに`kubernetes.io/service-name`ラベルを設定することで、EndpointSliceをServiceに関連付けられます。
備考:
エンドポイントのIPは次のものであっては いけません: ループバック(IPv4の場合は127.0.0.0/8、IPv6の場合は::1/128)、またはリンクローカル(IPv4の場合は169.254.0.0/16と224.0.0.0/24、IPv6の場合はfe80::/64)。
エンドポイントIPアドレスは、他のKubernetes ServiceのClusterIPにすることはできません。
これは、kube-proxyが宛先として仮想IPをサポートしていないためです。
備考:
Kubernetes APIサーバーは、Podにマッピングされていないエンドポイントへのプロキシを許可しません。
kubectl port-forward service/<service-name> forwardedPort:servicePortのようなアクションは、Serviceにセレクターが無い場合、この制約により失敗します。
これにより、Kubernetes APIサーバーが、呼び出し元に未許可のエンドポイントへのプロキシとして使用されることを防ぐことができます。
`ExternalName` Serviceは、セレクターを持たず、代わりにDNS名を使用するServiceの特殊なケースです。
詳細については、[ExternalName](#externalname)セクションを参照してください。
### EndpointSlice {#endpointslices}
FEATURE STATE:
Kubernetes v1.21 [stable]
[EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)は、Serviceの背後にあるネットワークエンドポイントのサブセット(_スライス_)を表すオブジェクトです。
Kubernetesクラスターは、各EndpointSliceが保持するエンドポイントの数を追跡します。
特定のServiceに紐づくエンドポイント数が多く、しきい値に達した場合、Kubernetesは新しい空のEndpointSliceを追加し、そこに新たなエンドポイント情報を保存します。
デフォルトでは、既存のすべてのEndpointSliceがそれぞれ、少なくとも100個のエンドポイントを含むと、Kubernetesは新しいEndpointSliceを作成します。
Kubernetesは、追加のエンドポイントを追加する必要性が生じるまで、新しいEndpointSliceを作成しません。
このAPIの詳細については、[EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
### Endpoints(非推奨) {#endpoints}
FEATURE STATE:
Kubernetes v1.33 [deprecated]
EndpointSlice APIは、従来の[Endpoints](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) APIの後継です。
非推奨となったEndpoints APIには、EndpointSliceと比較していくつかの問題があります:
- デュアルスタッククラスターをサポートしていません。
- [trafficDistribution](/docs/concepts/services-networking/service/#traffic-distribution)のような新しい機能をサポートするために必要な情報が含まれていません。
- エンドポイントのリストが単一のオブジェクトに収まらないほど長い場合、切り捨てられます。
このため、すべてのクライアントはEndpointsではなくEndpointSlice APIを使用することをお勧めします。
#### 容量超過のEndpoints {#over-capacity-endpoints}
Kubernetesでは、単一のEndpointsオブジェクトに格納できるエンドポイントの数は制限されています。
Serviceに1000個を超えるエンドポイントが存在する場合、KubernetesはEndpointsオブジェクト内のデータを切り捨てます。
Serviceは複数のEndpointSliceにリンクできるため、1000個という制限はレガシーのEndpoints APIにのみ影響します。
その場合、KubernetesはEndpointsオブジェクトに格納する最大1000個のバックエンドエンドポイントを選択し、Endpointsに[`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity)というアノテーションを設定します。
コントロールプレーンはまた、バックエンドのPod数が1000未満に減少した場合、このアノテーションを削除します。
トラフィックは引き続きバックエンドに送信されますが、レガシーのEndpoints APIに依存するロードバランシング機構は、利用可能なバックエンドのエンドポイントのうち最大1000個にのみトラフィックを送信します。
同様に、APIの制限によって、Endpointsを手動で更新して1000個を超えるエンドポイントを持つようにすることはできません。
### アプリケーションプロトコル {#application-protocol}
FEATURE STATE:
Kubernetes v1.20 [stable]
`appProtocol`フィールドは、各Serviceポートに対してアプリケーションプロトコルを指定する方法を提供します。
これは、実装が理解するプロトコルに対して、より高度な動作を提供するためのヒントとして使用されます。
このフィールドの値は、対応するEndpointsおよびEndpointSliceオブジェクトに反映されます。
このフィールドは、標準のKubernetesラベル構文に従います。
有効な値は次のいずれかです:
* [IANA標準サービス名](https://www.iana.org/assignments/service-names)。
* `mycompany.com/my-custom-protocol`のような実装定義のプレフィックス付きの名前。
* Kubernetes定義のプレフィックス付きの名前:
| プロトコル | 説明 |
|----------|-------------|
| `kubernetes.io/h2c` | [RFC 7540](https://www.rfc-editor.org/rfc/rfc7540)で説明されている平文のHTTP/2 |
| `kubernetes.io/ws` | [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455)で説明されている平文のWebSocket |
| `kubernetes.io/wss` | [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455)で説明されているTLS上のWebSocket |
### マルチポートService {#multi-port-services}
一部のServiceでは、複数のポートを公開する必要があります。
Kubernetesでは、単一のServiceオブジェクトに複数のポート定義を設定できます。
Serviceに複数のポートを使用する場合、曖昧さを避けるために、すべてのポートに名前を付ける必要があります。
例えば、下記のように設定します:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
```
備考:
Kubernetesの名前全般と同様に、ポート名は小文字の英数字と-のみを含む必要があります。
ポート名は英数字で始まり、英数字で終わる必要もあります。
例えば、123-abcやwebという名前は有効ですが、123_abcや-webは無効です。
備考:
このServiceは<NodeIP>:spec.ports[*].nodePortおよび.spec.clusterIP:spec.ports[*].portとして表示されます。
kube-proxyの--nodeport-addressesフラグまたはkube-proxy設定ファイルの同等のフィールドが設定されている場合、<NodeIP>はフィルタリングされたノードのIPアドレス(または複数のIPアドレスの可能性)になります。
### `type: LoadBalancer` {#loadbalancer}
外部ロードバランサーをサポートするクラウドプロバイダーでは、`type`フィールドを`LoadBalancer`に設定すると、Service向けにロードバランサーがプロビジョニングされます。
実際のロードバランサーの作成は非同期で行われ、プロビジョニングされたバランサーに関する情報はServiceの`.status.loadBalancer`フィールドで公開されます。
たとえば、次のように設定します:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 192.0.2.127
```
外部ロードバランサーからのトラフィックはバックエンドのPodに転送されます。
負荷分散の方法は、クラウドプロバイダーが決定します。
`type: LoadBalancer`のServiceを実装するために、Kubernetesは通常、まず`type: NodePort`のServiceをリクエストした場合と同等の変更を行います。
その後、cloud-controller-managerコンポーネントが外部ロードバランサーを設定し、割り当てられたNodePortにトラフィックを転送します。
クラウドプロバイダーの実装でサポートされている場合、LoadBalancerタイプのServiceを設定してNodePortの割り当てを[省略](#load-balancer-nodeport-allocation)できます。
一部のクラウドプロバイダーでは`loadBalancerIP`を指定できます。
その場合、ユーザーが指定した`loadBalancerIP`でロードバランサーが作成されます。
`loadBalancerIP`フィールドが指定されていない場合、ロードバランサーは一時的なIPアドレスで設定されます。
`loadBalancerIP`を指定しても、クラウドプロバイダーがこの機能をサポートしていない場合、設定した`loadbalancerIP`フィールドは無視されます。
備考:
Serviceの.spec.loadBalancerIPフィールドはKubernetes v1.24で非推奨になりました。
このフィールドは仕様が不十分で、実装によって意味が異なっていました。
また、デュアルスタックネットワーキングをサポートできません。
このフィールドは将来のAPIバージョンで削除される可能性があります。
(プロバイダー固有の)アノテーションを介してServiceのロードバランサーIPアドレスの指定をサポートするプロバイダーと統合する場合は、その方法に切り替えてください。
Kubernetesとロードバランサーの統合コードを書いている場合は、このフィールドの使用を避けてください。
ServiceではなくGatewayと統合するか、同等の詳細を指定するService上の独自の(プロバイダー固有の)アノテーションを定義できます。
FEATURE STATE:
Kubernetes v1.26 [stable](デフォルトで有効)
デフォルトでは、LoadBalancerタイプのServiceで複数のポートが定義されている場合、すべてのポートは同じプロトコルを持つ必要があり、そのプロトコルはクラウドプロバイダーがサポートするものでなければなりません。
フィーチャーゲート`MixedProtocolLBService`(v1.24以降のkube-apiserverではデフォルトで有効)により、複数のポートが定義されている場合、LoadBalancerタイプのServiceで異なるプロトコルを使用できます。
備考:
ロードバランサーServiceで使用できるプロトコルのセットは、クラウドプロバイダーによって定義されます。
クラウドプロバイダーは、Kubernetes APIが強制する制限を超えた追加の制限を課す場合があります。
#### ロードバランサーによるNodePort割り当ての無効化 {#load-balancer-nodeport-allocation}
FEATURE STATE:
Kubernetes v1.24 [stable]
`spec.allocateLoadBalancerNodePorts`フィールドを`false`に設定することで、`type: LoadBalancer`のServiceに対するNodePort割り当てをオプションで無効にできます。
これは、NodePortを使用せずに、トラフィックをPodに直接ルーティングするロードバランサー実装に対してのみ使用してください。
デフォルトでは、`spec.allocateLoadBalancerNodePorts`は`true`であり、LoadBalancerタイプのServiceは引き続きNodePortを割り当てます。
既に割り当て済みのNodePortを持つ既存のServiceに対して`spec.allocateLoadBalancerNodePorts`を`false`に設定しても、それらのNodePortは自動的に割り当て解除**されません**。
NodePortの割り当てを解除するには、すべてのServiceポートの`nodePorts`エントリを明示的に削除する必要があります。
#### ロードバランサー実装のクラスの指定 {#load-balancer-class}
FEATURE STATE:
Kubernetes v1.24 [stable]
`type`が`LoadBalancer`に設定されたServiceの場合、`.spec.loadBalancerClass`フィールドを使用すると、クラウドプロバイダーのデフォルト以外のロードバランサー実装を使用できます。
デフォルトでは、`.spec.loadBalancerClass`は設定されておらず、クラスターが`--cloud-provider`コンポーネントフラグを使用してクラウドプロバイダーで設定されている場合、`LoadBalancer`タイプのServiceはクラウドプロバイダーのデフォルトロードバランサー実装を使用します。
`.spec.loadBalancerClass`を指定すると、指定されたクラスに一致するロードバランサー実装がServiceを監視していると想定されます。
デフォルトのロードバランサー実装(たとえば、クラウドプロバイダーが提供するもの)は、このフィールドが設定されたServiceを無視します。
`spec.loadBalancerClass`は`LoadBalancer`タイプのServiceにのみ設定できます。
一度設定すると、変更できません。
`spec.loadBalancerClass`の値はラベル形式の識別子である必要があり、"`internal-vip`"や"`example.com/internal-vip`"などのプレフィックスをオプションとして持つことができます。
プレフィックスのない名前はエンドユーザー向けに予約されています。
#### ロードバランサーのIPアドレスモード {#load-balancer-ip-mode}
FEATURE STATE:
Kubernetes v1.32 [stable](デフォルトで有効)
`type: LoadBalancer`のServiceの場合、コントローラーは`.status.loadBalancer.ingress.ipMode`を設定できます。
`.status.loadBalancer.ingress.ipMode`は、ロードバランサーIPの動作方法を指定します。
これは`.status.loadBalancer.ingress.ip`フィールドも指定されている場合にのみ指定できます。
`.status.loadBalancer.ingress.ipMode`には、「VIP」と「Proxy」の2つの値が設定できます。
デフォルト値は「VIP」で、これはトラフィックがロードバランサーのIPとポートを宛先として設定された状態でノードに配信されることを意味します。
「Proxy」に設定する場合、クラウドプロバイダーのロードバランサーがトラフィックを配信する方法に応じて、2つのケースがあります:
- トラフィックがノードに配信されてからPodにDNATされる場合、宛先はノードのIPとNodePortに設定されます。
- トラフィックがPodに直接配信される場合、宛先はPodのIPとポートに設定されます。
Service実装はこの情報を使用してトラフィックルーティングを調整できます。
#### 内部ロードバランサー {#internal-load-balancer}
混在環境では、同じ(仮想)ネットワークアドレスブロック内のServiceからトラフィックをルーティングする必要がある場合があります。
スプリットホライズンDNS環境では、エンドポイントへの外部トラフィックと内部トラフィックの両方をルーティングできるように、2つのServiceが必要です。
内部ロードバランサーを設定するには、使用しているクラウドサービスプロバイダーに応じて、次のいずれかのアノテーションをServiceに追加します:
metadata:
name: my-service
annotations:
networking.gke.io/load-balancer-type: "Internal"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
metadata:
name: my-service
annotations:
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
metadata:
annotations:
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/oci-load-balancer-internal: true
備考:
type: ExternalNameのServiceはIPv4アドレスの文字列を受け入れますが、文字列をIPアドレスとしてではなく、数字で構成されたDNS名として扱います(ただし、インターネットでは、DNSにそのような名前を設定することは許可されていません)。
IPv4アドレスに似た外部名を持つServiceはDNSサーバーによって解決されません。
ServiceをIPアドレスに直接マッピングしたい場合は、ヘッドレスServiceの使用を検討してください。
注意:
ExternalNameを使用すると、HTTPやHTTPSを含む一部の一般的なプロトコルで問題が発生する可能性があります。
ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。
ホスト名を使用するプロトコルの場合、この違いによりエラーや予期しないレスポンスが発生する可能性があります。
HTTPリクエストには、オリジンサーバーが認識しないHost:ヘッダーが含まれることになります。
また、TLSサーバーは、クライアントが接続したホスト名と一致する証明書を提供できなくなります。
備考:
PodがServiceにアクセスする必要があり、環境変数を使用してポートとClusterIPをクライアントPodに公開する場合、クライアントPodが作成される前にServiceを作成する必要があります。
そうしないと、クライアントPodに環境変数が設定されません。
DNSのみを使用してServiceのClusterIPを検出する場合は、この順序の問題を気にする必要はありません。
備考:
KubernetesはexternalIPsの割り当てを管理しません。
これらはクラスター管理者の責任です。
## APIオブジェクト {#api-object}
ServiceはKubernetes REST APIにおいてトップレベルのリソースです。
詳細については、[Service APIオブジェクト](/docs/reference/generated/kubernetes-api/v1.36/#service-v1-core)を参照してください。
## 次の項目
Serviceと、それがKubernetesにどのように適合するかについて、さらに学習してください:
* [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/)のチュートリアルに従ってください。
* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
Ingressは、クラスター外部からクラスター内のServiceへのHTTPおよびHTTPSルートを公開します。
* [Gateway](/docs/concepts/services-networking/gateway/)を参照してください。
GatewayはKubernetesの拡張機能で、Ingressよりも柔軟性を提供します。
さらなる背景情報については、以下を参照してください:
* [仮想IPとServiceプロキシ](/docs/reference/networking/virtual-ips/)
* [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)
* [Service APIのリファレンス](/docs/reference/kubernetes-api/service-resources/service-v1/)
* [EndpointSlice APIのリファレンス](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/)
* [Endpoint APIのリファレンス(レガシー)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
