Translate concepts/services-networking/endpoint-slices into Japanese.
TAKAHASHI Shuuji
parent
e5cee09476
commit
3cd16e676a
|
|
@ -1,52 +1,28 @@
|
|||
---
|
||||
reviewers:
|
||||
- freehan
|
||||
title: EndpointSlices
|
||||
title: EndpointSlice
|
||||
content_type: concept
|
||||
weight: 15
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
_EndpointSlices_ provide a simple way to track network endpoints within a
|
||||
Kubernetes cluster. They offer a more scalable and extensible alternative to
|
||||
Endpoints.
|
||||
|
||||
|
||||
*EndpointSlice*は、Kubernetesクラスター内にあるネットワークエンドポイントを追跡するための単純な手段を提供します。EndpointSliceは、よりスケーラブルでより拡張可能なEndpointの代わりとなるものです。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Motivation
|
||||
## 動機
|
||||
|
||||
The Endpoints API has provided a simple and straightforward way of
|
||||
tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
|
||||
and Services have gotten larger, limitations of that API became more visible.
|
||||
Most notably, those included challenges with scaling to larger numbers of
|
||||
network endpoints.
|
||||
Endpoints APIは、Kubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
|
||||
|
||||
Since all network endpoints for a Service were stored in a single Endpoints
|
||||
resource, those resources could get quite large. That affected the performance
|
||||
of Kubernetes components (notably the master control plane) and resulted in
|
||||
significant amounts of network traffic and processing when Endpoints changed.
|
||||
EndpointSlices help you mitigate those issues as well as provide an extensible
|
||||
platform for additional features such as topological routing.
|
||||
Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
|
||||
|
||||
## EndpointSlice resources {#endpointslice-resource}
|
||||
## EndpointSliceリソース {#endpointslice-resource}
|
||||
|
||||
In Kubernetes, an EndpointSlice contains references to a set of network
|
||||
endpoints. The EndpointSlice controller automatically creates EndpointSlices
|
||||
for a Kubernetes Service when a {{< glossary_tooltip text="selector"
|
||||
term_id="selector" >}} is specified. These EndpointSlices will include
|
||||
references to any Pods that match the Service selector. EndpointSlices group
|
||||
network endpoints together by unique Service and Port combinations.
|
||||
The name of a EndpointSlice object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
Kubernetes内では、EndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceには、Serviceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceは、ネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
|
||||
As an example, here's a sample EndpointSlice resource for the `example`
|
||||
Kubernetes Service.
|
||||
一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。
|
||||
|
||||
```yaml
|
||||
apiVersion: discovery.k8s.io/v1beta1
|
||||
|
|
@ -71,116 +47,63 @@ endpoints:
|
|||
topology.kubernetes.io/zone: us-west2-a
|
||||
```
|
||||
|
||||
By default, EndpointSlices managed by the EndpointSlice controller will have no
|
||||
more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1
|
||||
with Endpoints and Services and have similar performance.
|
||||
デフォルトでは、EndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceは、EndpointとServiceが1対1対応になり、性能は変わらないはずです。
|
||||
|
||||
EndpointSlices can act as the source of truth for kube-proxy when it comes to
|
||||
how to route internal traffic. When enabled, they should provide a performance
|
||||
improvement for services with large numbers of endpoints.
|
||||
EndpointSliceは、内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
|
||||
|
||||
### Address Types
|
||||
### アドレスの種類
|
||||
|
||||
EndpointSlices support three address types:
|
||||
EndpointSliceは、次の3種類のアドレスをサポートします。
|
||||
|
||||
* IPv4
|
||||
* IPv6
|
||||
* FQDN (Fully Qualified Domain Name)
|
||||
* FQDN (Fully Qualified Domain Name、完全修飾ドメイン名)
|
||||
|
||||
### Topology
|
||||
### トポロジー
|
||||
|
||||
Each endpoint within an EndpointSlice can contain relevant topology information.
|
||||
This is used to indicate where an endpoint is, containing information about the
|
||||
corresponding Node, zone, and region. When the values are available, the
|
||||
following Topology labels will be set by the EndpointSlice controller:
|
||||
EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合には、EndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。
|
||||
|
||||
* `kubernetes.io/hostname` - The name of the Node this endpoint is on.
|
||||
* `topology.kubernetes.io/zone` - The zone this endpoint is in.
|
||||
* `topology.kubernetes.io/region` - The region this endpoint is in.
|
||||
* `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。
|
||||
* `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。
|
||||
* `topology.kubernetes.io/region` - このエンドポイントが存在するリージョン。
|
||||
|
||||
The values of these labels are derived from resources associated with each
|
||||
endpoint in a slice. The hostname label represents the value of the NodeName
|
||||
field on the corresponding Pod. The zone and region labels represent the value
|
||||
of the labels with the same names on the corresponding Node.
|
||||
これらのラベルの値は、スライス内の各エンドポイントと関連するリソースから継承したものです。hostnameラベルは、対応するPod上のNodeNameフィールドの値を表します。zoneとregionラベルは、対応するNode上の同じ名前のラベルの値を表します。
|
||||
|
||||
### Management
|
||||
### 管理
|
||||
|
||||
By default, EndpointSlices are created and managed by the EndpointSlice
|
||||
controller. There are a variety of other use cases for EndpointSlices, such as
|
||||
service mesh implementations, that could result in other entities or controllers
|
||||
managing additional sets of EndpointSlices. To ensure that multiple entities can
|
||||
manage EndpointSlices without interfering with each other, a
|
||||
`endpointslice.kubernetes.io/managed-by` label is used to indicate the entity
|
||||
managing an EndpointSlice. The EndpointSlice controller sets
|
||||
`endpointslice-controller.k8s.io` as the value for this label on all
|
||||
EndpointSlices it manages. Other entities managing EndpointSlices should also
|
||||
set a unique value for this label.
|
||||
EndpointSliceは、デフォルトではEndpointSliceコントローラによって作成・管理されます。EndpointSliceには、他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
|
||||
|
||||
### Ownership
|
||||
### 所有権
|
||||
|
||||
In most use cases, EndpointSlices will be owned by the Service that it tracks
|
||||
endpoints for. This is indicated by an owner reference on each EndpointSlice as
|
||||
well as a `kubernetes.io/service-name` label that enables simple lookups of all
|
||||
EndpointSlices belonging to a Service.
|
||||
ほとんどのユースケースでは、EndpointSliceは、対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと、`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
|
||||
|
||||
## EndpointSlice Controller
|
||||
## EndpointSliceコントローラー
|
||||
|
||||
The EndpointSlice controller watches Services and Pods to ensure corresponding
|
||||
EndpointSlices are up to date. The controller will manage EndpointSlices for
|
||||
every Service with a selector specified. These will represent the IPs of Pods
|
||||
matching the Service selector.
|
||||
EndpointSliceコントローラーは、対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーは、セレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceは、Serviceセレクターに一致するPodのIPを表します。
|
||||
|
||||
### Size of EndpointSlices
|
||||
### EndpointSliceのサイズ
|
||||
|
||||
By default, EndpointSlices are limited to a size of 100 endpoints each. You can
|
||||
configure this with the `--max-endpoints-per-slice` {{< glossary_tooltip
|
||||
text="kube-controller-manager" term_id="kube-controller-manager" >}} flag up to
|
||||
a maximum of 1000.
|
||||
デフォルトでは、それぞれのEndpointSliceのサイズの上限は、100のEndpointsまでに制限されています。この制限は、{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。
|
||||
|
||||
### Distribution of EndpointSlices
|
||||
### EndpointSliceの分散
|
||||
|
||||
Each EndpointSlice has a set of ports that applies to all endpoints within the
|
||||
resource. When named ports are used for a Service, Pods may end up with
|
||||
different target port numbers for the same named port, requiring different
|
||||
EndpointSlices. This is similar to the logic behind how subsets are grouped
|
||||
with Endpoints.
|
||||
それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これは、サービスの部分集合がEndpointsにグループ化される場合と同様です。
|
||||
|
||||
The controller tries to fill EndpointSlices as full as possible, but does not
|
||||
actively rebalance them. The logic of the controller is fairly straightforward:
|
||||
コントローラーは、EndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
|
||||
|
||||
1. Iterate through existing EndpointSlices, remove endpoints that are no longer
|
||||
desired and update matching endpoints that have changed.
|
||||
2. Iterate through EndpointSlices that have been modified in the first step and
|
||||
fill them up with any new endpoints needed.
|
||||
3. If there's still new endpoints left to add, try to fit them into a previously
|
||||
unchanged slice and/or create new ones.
|
||||
|
||||
Importantly, the third step prioritizes limiting EndpointSlice updates over a
|
||||
perfectly full distribution of EndpointSlices. As an example, if there are 10
|
||||
new endpoints to add and 2 EndpointSlices with room for 5 more endpoints each,
|
||||
this approach will create a new EndpointSlice instead of filling up the 2
|
||||
existing EndpointSlices. In other words, a single EndpointSlice creation is
|
||||
preferrable to multiple EndpointSlice updates.
|
||||
1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。
|
||||
2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。
|
||||
3. まだ追加するべき新しいエンドポイントが残っていた場合、これまで変更されなかったスライスに追加を試み、その後、新しいスライスを作成する。
|
||||
|
||||
With kube-proxy running on each Node and watching EndpointSlices, every change
|
||||
to an EndpointSlice becomes relatively expensive since it will be transmitted to
|
||||
every Node in the cluster. This approach is intended to limit the number of
|
||||
changes that need to be sent to every Node, even if it may result with multiple
|
||||
EndpointSlices that are not full.
|
||||
|
||||
In practice, this less than ideal distribution should be rare. Most changes
|
||||
processed by the EndpointSlice controller will be small enough to fit in an
|
||||
existing EndpointSlice, and if not, a new EndpointSlice is likely going to be
|
||||
necessary soon anyway. Rolling updates of Deployments also provide a natural
|
||||
repacking of EndpointSlices with all pods and their corresponding endpoints
|
||||
getting replaced.
|
||||
ここで重要なのは、3番目のステップでEndpointSliceを完全に分散させることよりも、EndpointSliceの更新を制限することを優先していることです。たとえば、もし新しい追加するべきエンドポイントが10個あり、2つのEndpointSliceにそれぞれ5個の空きがあった場合、このアプローチでは、2つの既存のEndpointSliceを充填する代わりに、新しいEndpointSliceが作られます。言い換えれば、1つのEndpointSliceを作成する方が、複数のEndpointSliceを更新するよりも好ましいということです。
|
||||
|
||||
各Node上で実行されているkube-proxyはEndpointSliceを監視しており、EndpointSliceに加えられた変更はクラスター内のすべてのNodeに送信されるため、比較的コストの高い処理になります。先ほどのアプローチは、たとえ複数のEndpointSliceが充填されない結果となるとしても、すべてのNodeへ送信しなければならない変更の数を抑制することを目的としています。
|
||||
|
||||
現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントが、すべて置換されるためです。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue