diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 0feaa9dc93a71..651e65216ca3f 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -1,15 +1,15 @@ --- -title: ラベル(Labels)とセレクタ(Selectors) +title: ラベル(Labels)とセレクター(Selectors) content_template: templates/concept weight: 40 --- {{% capture overview %}} -_ラベル(Labels)_ は ポッドなどのオブジェクトに割り当てられたキー・バリューペアです。 -ラベルは、ユーザに関連した意味のあるオブジェクトのアトリビュートを指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。 +_ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキーとバリューのペアです。 +ラベルはユーザーに関連した意味のあるオブジェクトの属性を指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。 ラベルはオブジェクトのサブセットを選択し、グルーピングするために使うことができます。また、ラベルはオブジェクトの作成時に割り当てられ、その後いつでも追加、修正ができます。 -各オブジェクトはキー・バリューのラベルのセットを定義できます。各キーは、単一のオブジェクトに対してはユニークである必要があります。 +各オブジェクトはキーとバリューのラベルのセットを定義できます。各キーは、単一のオブジェクトに対してはユニークである必要があります。 ```json "metadata": { "labels": { @@ -19,8 +19,8 @@ _ラベル(Labels)_ は ポッドなどのオブジェクトに割り当てら } ``` -ラベルは効率的な検索・閲覧や、UIやCLI上での利用しやすさを可能にします。 -非識別の情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。 +ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。 +識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。 {{% /capture %}} @@ -29,11 +29,10 @@ _ラベル(Labels)_ は ポッドなどのオブジェクトに割り当てら ## ラベルを使う動機 -ラベルは、クライアントにそのマッピング情報を保存することを要求することなく、ユーザ独自の組織構造をシステムオブジェクト上で疎結合にマッピングできます。 +ラベルは、クライアントにそのマッピング情報を保存することを要求することなく、ユーザー独自の組織構造をシステムオブジェクト上で疎結合にマッピングできます。 -？ -サービスデプロイメントとバッチ処理パイプラインは、たいてい多次元エンティティとなります(例: 複数のパーティション、デプロイメント、リリーストラック、ティアー、ティアー毎のマイクロサービスなど) -管理はたいてい、分野横断的な操作が必要になることが多く、厳密な階層表現、特にユーザによるものでなく、インフラストラクチャによって定義された厳格な階層のカプセル化が破られます。 +サービスデプロイメントとバッチ処理のパイプラインは多くの場合、多次元のエンティティとなります(例: 複数のパーティション、Deployment、リリーストラック、ティアー、ティアー毎のマイクロサービスなど) +管理は分野横断的な操作が必要になることが多く、それによって厳密な階層表現、特にユーザーによるものでなく、インフラストラクチャーによって定義された厳格な階層のカプセル化が破られます。 ラベルの例: @@ -43,47 +42,47 @@ _ラベル(Labels)_ は ポッドなどのオブジェクトに割り当てら * `"partition" : "customerA"`, `"partition" : "customerB"` * `"track" : "daily"`, `"track" : "weekly"` -これらはよく使われるラベル例となります。ユーザは自由に規約を決めることができます。 +これらは単によく使われるラベルの例です。ユーザーは自由に規約を決めることができます。 ラベルのキーは、ある1つのオブジェクトに対してユニークである必要があることは覚えておかなくてはなりません。 ## シンタックスと文字セット -ラベルは、キー/バリューのベアです。正しいラベルキーは2つのセグメントを持ちます。 -`/`によって分割されたオプショナルなプレフィックスと名前です。 -名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。 +ラベルは、キーとバリューのベアです。正しいラベルキーは2つのセグメントを持ちます。 +それは`/`によって分割されたオプショナルなプレフィックスと名前です。 +名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)で、文字列の間ではこれに加えてダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。 プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。 -もしプレフィックスが除外された場合、ラベルキーはそのユーザ対してプライベートであると推定されます。 -エンドユーザのオブジェクトにラベルを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。 +もしプレフィックスが省略された場合、ラベルキーはそのユーザーに対してプライベートであると推定されます。 +エンドユーザーのオブジェクトにラベルを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。 `kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。 -正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)である文字列を使うことができます。 +正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。 -## ラベルセレクタ +## ラベルセレクター [名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 -*ラベルセレクタ* を介して、クライアントとユーザはオブジェクトのセットを指定できます。ラベルセレクタはKubernetesにおいてコアなグルーピング機能となります。 +*ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。 -Kubernetes APIは現在2タイプのセレクタをサポートしています。 -*等価ベース(equality-based)* と*集合ベース(set-based)* です。 -単一のラベルセレクタは、コンマ区切りの複数の*要件(requirements)* で構成されています。 -複数の要件がある場合、コンマセパレータは論理積 _AND_(`&&`)オペレータと同様にふるまい、全ての要件を満たす必要があります。 +Kubernetes APIは現在2タイプのセレクターをサポートしています。 +それは*等価ベース(equality-based)* と*集合ベース(set-based)* です。 +単一のラベルセレクターは、コンマ区切りの複数の*要件(requirements)* で構成されています。 +複数の要件がある場合、コンマセパレーターは論理積 _AND_(`&&`)オペレーターと同様にふるまい、全ての要件を満たす必要があります。 -空文字の場合や、指定なしのセレクタに関するセマンティクスは、コンテキストに依存します。 -そしてセレクタを使うAPIタイプは、それらのセレクタの妥当性とそれらが示す意味をドキュメントに記載するべきです。 +空文字の場合や、指定なしのセレクターに関するセマンティクスは、コンテキストに依存します。 +そしてセレクターを使うAPIタイプは、それらのセレクターの妥当性とそれらが示す意味をドキュメントに記載するべきです。 {{< note >}} -レプリカセットなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクタは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクタがコンフリクトした操作とみなし、いくつのレプリカを稼働させるべきか決めることができなくなります。 +ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。 {{< /note >}} ### *等価ベース(Equality-based)* の要件(requirement) *等価ベース(Equality-based)* もしくは*不等ベース(Inequality-based)* の要件は、ラベルキーとラベル値によるフィルタリングを可能にします。 要件に一致したオブジェクトは、指定されたラベルの全てを満たさなくてはいけませんが、それらのオブジェクトはさらに追加のラベルも持つことができます。 -3つの種類のオペレータの利用が許可されています。`=`,`==`,`!=`。 -最初の2つのオペレータ(`=`,`==`)は*等価(Equality)* を表現し(この2つは単なる同義語)、最後の1つ(`!=`)は*不等(Inequality)* を意味します。 +そして等価ベースの要件においては、3つの種類のオペレーターの利用が許可されています。`=`、`==`、`!=`となります。 +最初の2つのオペレーター(`=`、`==`)は*等価(Equality)* を表現し(この2つは単なる同義語)、最後の1つ(`!=`)は*不等(Inequality)* を意味します。 例えば ``` @@ -93,11 +92,11 @@ tier != frontend 最初の例は、キーが`environment`で、値が`production`である全てのリソースを対象にします。 次の例は、キーが`tier`で、値が`frontend`とは異なるリソースと、`tier`という名前のキーを持たない全てのリソースを対象にします。 -コンマセパレータ`,`を使って、`production`の中から、`frontend`のものを除外するようにフィルターすることもできます。 +コンマセパレーター`,`を使って、`production`の中から、`frontend`のものを除外するようにフィルターすることもできます。 `environment=production,tier!=frontend` -等価ベースのラベル要件の1つの使用シナリオとして、ポッドにおけるノードの選択要件を指定するケースがあります。 -例えば、下記のサンプルポッドは、ラベル`accelerator=nvidia-tesla-p100`をもったノードを選択します。 +等価ベースのラベル要件の1つの使用シナリオとして、PodにおけるNodeの選択要件を指定するケースがあります。 +例えば、下記のサンプルPodは、ラベル`accelerator=nvidia-tesla-p100`をもったNodeを選択します。 ```yaml apiVersion: v1 @@ -118,7 +117,7 @@ spec: ### *集合ベース(Set-based)* の要件(requirement) *集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。 -`in`、`notin`、`exists`の3つのオペレータをサポートしています(キーを特定するのみ)。 +`in`、`notin`、`exists`の3つのオペレーターをサポートしています(キーを特定するのみ)。 例えば: ``` @@ -132,8 +131,8 @@ partition 第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。 第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。 第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。 -同様に、コンマセパレータは、_AND_オペレータと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。 -*集合ベース* のラベルセレクタは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。 +同様に、コンマセパレーターは、_AND_ オペレーターと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。 +*集合ベース* のラベルセレクターは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。 *集合ベース* の要件は、*等価ベース* の要件と混在できます。 例えば: @@ -143,13 +142,13 @@ partition ### LISTとWATCHによるフィルタリング -LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクタを指定できます。 +LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。 *集合ベース* と*等価ベース* のどちらの要件も許可されています(ここでは、URLクエリストリング内で出現します)。 * *等価ベース* での要件: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` * *集合ベース* での要件: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` -上記の2つの形式のラベルセレクタはRESTクライアントを介してリストにしたり、もしくは確認するために使われます。 +上記の2つの形式のラベルセレクターはRESTクライアントを介してリストにしたり、もしくは確認するために使われます。 例えば、`kubectl`によって`apiserver`をターゲットにし、*等価ベース* の要件でフィルターすると以下のように書けます。 ```shell @@ -162,26 +161,26 @@ kubectl get pods -l 'environment in (production),tier in (frontend)' ``` すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。 -例えば、値に対する_OR_ オペレータを実装して以下のように書けます。 +例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。 ```shell kubectl get pods -l 'environment in (production, qa)' ``` -もしくは、_exists_ オペレータを介して、否定マッチングによる制限もできます。 +もしくは、_exists_ オペレーターを介して、否定マッチングによる制限もできます。 ```shell kubectl get pods -l 'environment,environment notin (frontend)' ``` ### APIオブジェクトに参照を設定する -[`サービス`](/docs/user-guide/services) と [`レプリケーションコントローラ`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクタを[ポッド](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。 +[`Service`](/docs/user-guide/services) と [`ReplicationController`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。 -#### サービスとレプリケーションコントローラ -`サービス`が対象とするポッドの集合は、ラベルセレクタによって定義されます。 -同様に、`レプリケーションコントローラ`が管理するべきポッド数についてもラベルセレクタを使って定義されます。 +#### ServiceとReplicationController +`Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。 +同様に、`ReplicationController`が管理するべきPod数についてもラベルセレクターを使って定義されます。 -それぞれのオブジェクトに対するラベルセレクタはマップを使って`json`もしくは`yaml`形式のファイルで定義され、*等価ベース* のセレクタのみサポートされています。 +それぞれのオブジェクトに対するラベルセレクターはマップを使って`json`もしくは`yaml`形式のファイルで定義され、*等価ベース* のセレクターのみサポートされています。 ```json "selector": { @@ -195,11 +194,11 @@ selector: component: redis ``` -このセレクタ(それぞれ`json`または`yaml`形式)は、`component=redis`または`component in (redis)`と等価です。 +このセレクター(それぞれ`json`または`yaml`形式)は、`component=redis`または`component in (redis)`と等価です。 #### *集合ベース* の要件指定をサポートするリソース -[`ジョブ`](/docs/concepts/jobs/run-to-completion-finite-workloads/)や[`デプロイメント`](/docs/concepts/workloads/controllers/deployment/)、[`レプリカセット`](/docs/concepts/workloads/controllers/replicaset/)や[`デーモンセット`](/docs/concepts/workloads/controllers/daemonset/)となどの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 +[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)や[`Deployment`](/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 ```yaml selector: matchLabels: @@ -209,12 +208,12 @@ selector: - {key: environment, operator: NotIn, values: [dev]} ``` -`matchLabels`は、`{key,value}`ペアのマップです。`matchLabels`内の単一の`{key,value}`は、`matchExpressions`の要素と等しく、それは、`key`フィールドがキー名で、`operator`が"In"で、`values`配列は単に"値”を保持します。 -`matchExpressions`はポッドセレクタ要件のリストです。対応しているオペレータは`In`、`NotIn`、`Exists`と`DoesNotExist`です。`values`のセットは、`In`と`NotIn`オペレータにおいては空文字を許容しません。 +`matchLabels`は、`{key,value}`ペアのマップです。`matchLabels`内の単一の`{key,value}`は、`matchExpressions`の要素と等しく、それは、`key`フィールドがキー名で、`operator`が"In"で、`values`配列は単に"値"を保持します。 +`matchExpressions`はPodセレクター要件のリストです。対応しているオペレーターは`In`、`NotIn`、`Exists`と`DoesNotExist`です。`values`のセットは、`In`と`NotIn`オペレーターにおいては空文字を許容しません。 `matchLabels`と`matchExpressions`の両方によって指定された全ての要件指定はANDで判定されます。つまり要件にマッチするには指定された全ての要件を満たす必要があります。 -#### ノードのセットを選択する -ラベルを選択するための1つのユースケースはポッドがスケジュールできるノードのセットを制限することです。 -さらなる情報に関しては、[ノード選定](/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 +#### Nodeのセットを選択する +ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。 +さらなる情報に関しては、[Node選定](/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 {{% /capture %}}