First Japanese l10n work for release-1.14 (#16115)
* Translate concepts/workloads/pods/pod/ in Japanese (#13671) * [ja] Copy en/docs/concepts/workloads/pods/pod.md into ja/ * [ja] Translate docs/concepts/workloads/pods/pod/ * [ja] Modify translation of docs/concepts/workloads/pods/pod/ Reflect review - add trailing 'ー' to some technical terms * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * Translated cron-jobs.md in Japanese (#13937) * Translate cron-jobs.md in Japanese (#13392) * Update cron-jobs.md * Create automated-tasks-with-cron-jobs.md in Japanese directory * Fix translation (#13392) * Translate cron-jobs.md in Japanese (#13392) * Update cron-jobs.md * Create automated-tasks-with-cron-jobs.md in Japanese directory * Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory" This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d. * Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory" This reverts commit 739b01489634d749279c38b6ed5b90534bf7d29d. * Fix conflict (#13392) * Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory"" This reverts commit c5fc9d93d6d789a13a0a28ec4b85f9e7aeb81e38. * Revert "Revert "Revert "Create automated-tasks-with-cron-jobs.md in Japanese directory""" This reverts commit 095e760c6deb620da548d06a851c8f7ade71a15d. * Fix that as it was pointed out (#13392) * Delete double same sesntence (#13392) * copy includes directory (#14020) * Translate docs/home/_index.md into Japanese (#14068) (#14074) * Translate concepts/overview/components.md into Japanese (#14067) * Translate glossaries used in concepts/overview/components.md into Japanese (#14044) * Translate concepts/overview/components.md into Japanese (#14044) * Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese (#13668) * Translate tasks/run-application/run-single-instance-stateful-application/ in Japanese * Apply suggestions from code review Co-Authored-By: sotoiwa <sotoiwa@gmail.com> * Better translation from code review * Translate tasks/access-application-cluster/service-access-application-cluster/ in Japanese (#13701) * Update fluentd image (#13661) Signed-off-by: ialidzhikov <i.alidjikov@gmail.com> * update zh kubelet-config-file doc (#13495) * update zh kubelet-config-file doc * change kubelet config types address * add space between en words and zh words * revert en version change * correct container hyperlinks in init container (#12387) * correct container hyperlinks in init container * correct zh trans and update anchor inside page * Incorrect details about startingDeadlineSeconds.. (#13530) On this page, the default value of startingDeadlineSeconds is mentioned as 100 seconds which is not true. So removing this statement. * Fix typos (#13376) * add Nokia case study (#13676) * Fix typo in API page (#13687) Associated with #13686 * fix typo in pod-lifecycle (#13689) Asscociated with #13688 * issue 13383 * modify the link part * Revert "modify the link part" This reverts commit 2ae91dca574b54a14d255320721df4313346de28. * Revert "Revert "modify the link part"" This reverts commit e5b80b6258ce2210fc9a4b46e08fb8c000fe6330. * Revert "Revert "Revert "modify the link part""" This reverts commit 427916e7c6c4d6423222ff76b5fd8c12dc913ce1. * Revert "Merge remote-tracking branch 'origin/master' into issue_13383" This reverts commit 98099d805c7377826cb4d84bd0fece0f6362cb40, reversing changes made to 969e7f3f5cf63622e24137a2e374b0ab9e272514. * modify the link part * Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#14025) * Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese (#13952) * Apply suggestions to /concepts/overview/working-with-objects/kubernetes-objects/ from code review Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate concepts/overview/working-with-objects/names.md into Japanese (#14066) * Translate content/ja/docs/concepts/overview/working-with-objects/names.md into Japanese * Translate docs/reference/glossary/name.md into Japanese * Translate docs/reference/glossary/uid.md into Japanese * Apply suggestions to concepts/overview/working-with-objects/names.md from review comments * Translate concepts/overview/kubernetes-api.md into Japanese (#14343) * Translate concepts/overview/kubernetes-api.md into Japanese * Update translations for concepts/overview/kubernetes-api.md * Translate overview/working-with-objects/labels.md in Japanese (#14183) (#14319) * Translate overview/working-with-objects/labels.md in Japanese (#14183) * Update translations for concepts/overview/working-with-objects/labels.md. * Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) (#14494) * Translate concepts/workloads/pods/pod-overview/ in Japanese (#14426) * Update translation for concepts/workloads/pods/pod-overview.md. * Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) (#14535) * Translate overview/working-with-objects/field-selectors.md in Japanese (#14350) * Update translations for concepts/overview/working-with-objects/field-selectors.md. * Update translation for concepts/overview/working-with-objects/field-selectors.md * Translate overview/working-with-objects/common-labels/ in Japanese (#14397) (#14403) * Translate overview/working-with-objects/common-labels/ in Japanese (#14397) * Update translation for concepts/overview/working-with-objects/common-labels.md * Translate concepts/storage/volume-snapshot-classes/ in Japanese (#14846) (#14849) * ja-trans: tasks/run-application/run-stateless-application-deployment/ (#14955) * ja-trans: tasks/run-application/run-stateless-application-deployment/ * modify "exploring" translation * ja-trans: concepts/containers/container-environment-variables/ (#14116) * ja-trans: concepts/containers/container-environment-variables/ * removed redundant expressions * ja-trans: Translate tasks/debug-application-cluster/get-shell-running… (#14146) * ja-trans: Translate tasks/debug-application-cluster/get-shell-running-container/ #13381 * Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Fix typo Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * ja-trans: concepts/containers/container-lifecycle-hooks/ (#14169) * ja-trans: tasks/debug-application-cluster/debug-init-containers/ (#14488) * ja-trans: tasks/debug-application-cluster/debug-init-containers/ * modified traslation of should * Translate concepts/workloads/controllers/replicaset/ in Japanese (#14634) (#14641) * Translate concepts/workloads/controllers/replicaset.md in Japanese (#14634) * Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634) * Improve japanese translation in concepts/workloads/controllers/replicaset.md (#14634) * Translate concepts/overview/working-with-objects/annotations/ in Japanese (#13382) (#14396) * Translate overview/working-with-objects/annotations.md in Japanese (#13382) * Delete a empty line in concepts/overview/working-with-objects/annotations.md (#13382) * Update translation for concepts/overview/working-with-objects/anotations.md * ja-trans: tasks/run-application/scale-stateful-set/ (#15289) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/run-application/scale-stateful-set/ * Update content/ja/docs/tasks/run-application/scale-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/scale-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * added postpositional particle * ja-trans: tasks/debug-application-cluster/debug-stateful-set/ (#15282) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/debug-application-cluster/debug-stateful-set/ * ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ (#14939) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/debug-application-cluster/determine-reason-pod-failure/ * ja-trans: unify the ending of sentences * follow the master branch update * reflect a suggestion and modify translation of container * ja-trans: tasks/run-application/delete-stateful-set/ (#15293) * [ja] Fix translation of 'Persistent Volumes' (#13848) s/永続化ボリューム/永続ボリューム/g * ja-trans: tasks/run-application/delete-stateful-set/ * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/delete-stateful-set.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * modified traslation of backing * ja-trans: tasks/configure-pod-container/attach-handler-lifecycle-event/ (#14328) * Translate overview/working-with-objects/namespaces.md in Japanese (#14045) (#14161) * Translate overview/working-with-objects/namespaces.md in Japanese (#14045) * Update translations for concepts/overview/working-with-objects/namespaces.md * ja-trans: fix Japanese Translation in concepts/overview/working-with-objects/namespaces.md (#14045) * ja-trans: includes/default-storage-class-prereqs.md (#15376) * ja-trans: includes/default-storage-class-prereqs.md * Update content/ja/includes/default-storage-class-prereqs.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate tasks/run-application/run-replicated-stateful-application/ in Japanese (#15368) * Translate tasks/run-application/run-replicated-stateful-application/ in Japanese * add a base document in english * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/run-replicated-stateful-application.md Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * small fixs 「複製」という言葉を使わず「レプリケーション」と「クローン」に使い分けるように変更。 「ステートフルなアプリケーション」を「ステートフルアプリケーション」に変更。 * small fix * Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) (#14576) * Translate concepts/workloads/pods/init-containers.md in Japanese (#14543) * Improve japanese translation in concepts/workloads/pods/init-containers.md (#14543) * Add new line in ja/concepts/workloads/pods/init-containers.md (#14543) * Add new line in ja/concepts/workloads/pods/init-containers.md (#14543) * translate contribute/_index.md to japanese. (#15406) * translate contribute/_index.md to japanese. * trim spaces. * Add missing translation. * Translate concepts/workloads/controllers/daemonset/ in Japanese #14761 (#14767) * Translate concepts/workloads/controllers/daemonset/ in Japanese (#14761) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/daemonset.md (#14767) * Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) (#14720) * Translate concepts/workloads/controllers/garbage-collection/ in Japanese (#14718) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/garbage-collection.md (#14718) * Translate concepts/workloads/pods/podpreset/ in Japanese (#14544) (#14581) * Translate concepts/workloads/pods/podpreset.md in Japanese (#14544) * Update translation for concepts/workloads/pods/podpreset.md. * ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544) * ja-trans: Improve Japanese translation in concepts/workloads/pods/podpreset (#14544) * ja-trans: Delete translated sentence in concepts/workloads/pods/podpreset (#14544) * ja-trans: Delete duplicated sentence in concepts/workloads/pods/podpreset (#14544) * Translate concepts/containers/runtime-class/ in Japanese (#14670) (#14673) * Translate concepts/containers/runtime-class.md in Japanese (#14670) * ja-trans: Improve Japanese translation in concepts/containers/runtime-class.md (#14670) * Translate concepts/services-networking/dns-pod-service/ in Japanese #14777 (#14805) * Translate concepts/services-networking/dns-pod-service/ in Japanese (#14777) * ja-trans: Improve Japanese translation in concepts/services-networking/dns-pod-service.md (#14777) * Translate concepts/workloads/controllers/statefulset/ in Japanese #14679 (#14696) * Translate concepts/workloads/controllers/statefulset.md in Japanese (#14679) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some Japanese translation in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some titles in concepts/workloads/controllers/statefulset.md (#14679) * ja-trans: Improve some Japanese translations in concepts/workloads/controllers/statefulset.md (#14679) * Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese #14734 (#14735) * Translate concepts/workloads/controllers/ttlafterfinished/ in Japanese (#14734) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/ttlafterfinished.md (#14734) * ja-trans: Delete some Japanese words in concepts/workloads/controllers/ttlafterfinished.md (#14734) * ja-trans: Fix typo in concepts/workloads/controllers/ttlafterfinished.md (#14734) * Translate concepts/storage/dynamic-provisioning/ in Japanese #14847 (#14916) * Translate concepts/storage/dynamic-provisioning/ in Japanese (#14847) * ja-trans: Improve Japanese translation in concepts/storage/dynamic-provisioning.md (#14847) * ja-trans: Improve some Japanese translation in concepts/storage/dynamic-provisioning.md (#14847) * ja-trans: Improve some Japanese translations in concepts/storage/dynamic-provisioning.md (#14847)
This commit is contained in:
Takuya Tokuda
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
6c4a4d8152
commit
abde921399
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Working with Kubernetes Objects"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: アノテーション(Annotations)
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## オブジェクトにメタデータを割り当てる
|
||||
|
||||
ユーザーは、Kubernetesオブジェクトに対してラベルやアノテーションの両方またはどちらか一方を割り当てることができます。
|
||||
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
|
||||
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
|
||||
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
|
||||
|
||||
アノテーションは、ラベルと同様に、キーとバリューのマップとなります。
|
||||
|
||||
```json
|
||||
"metadata": {
|
||||
"annotations": {
|
||||
"key1" : "value1",
|
||||
"key2" : "value2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
下記は、アノテーション内で記録できる情報の例です。
|
||||
|
||||
* 宣言的設定レイヤによって管理されているフィールド。これらのフィールドをアノテーションとして割り当てることで、クライアントもしくはサーバによってセットされたデフォルト値、オートサイジングやオートスケーリングシステムによってセットされたフィールドや、自動生成のフィールドなどと区別することができます。
|
||||
|
||||
* ビルド、リリースやタイムスタンプのようなイメージの情報、リリースID、gitのブランチ、PR番号、イメージハッシュ、レジストリアドレスなど
|
||||
|
||||
* ロギング、監視、分析用のポインタ、もしくは監査用リポジトリ
|
||||
|
||||
* デバッグ目的で使用されるためのクライアントライブラリやツールの情報。例えば、名前、バージョン、ビルド情報など。
|
||||
|
||||
* 他のエコシステムのコンポーネントからの関連オブジェクトのURLなど、ユーザーやツール、システムの出所情報。
|
||||
|
||||
* 軽量ロールアウトツールのメタデータ。 例えば設定やチェックポイントなど。
|
||||
|
||||
* 情報をどこで確認できるかを示すためのもの。例えばチームのウェブサイト、責任者の電話番号や、ページャー番号やディレクトリエンティティなど。
|
||||
|
||||
* システムのふるまいの変更や、標準ではない機能を利用可能にするために、エンドユーザーがシステムに対して指定する値
|
||||
|
||||
アノテーションを使用するかわりに、ユーザーはこのようなタイプの情報を外部のデータベースやディレクトリに保存することもできます。しかし、それによりデプロイ、管理、イントロスペクションを行うためのクライアンライブラリやツールの生成が非常に難しくなります。
|
||||
|
||||
## 構文と文字セット
|
||||
|
||||
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。
|
||||
プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。
|
||||
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
|
||||
プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。
|
||||
|
||||
もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。
|
||||
エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。
|
||||
|
||||
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
[ラベルとセレクター](/docs/concepts/overview/working-with-objects/labels/)について学習してください。
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,156 @@
|
||||
---
|
||||
title: 推奨ラベル(Recommended Labels)
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
ユーザーはkubectlやダッシュボード以外に、多くのツールでKubernetesオブジェクトの管理と可視化ができます。共通のラベルセットにより、全てのツールにおいて解釈可能な共通のマナーに沿ってオブジェクトを表現することで、ツールの相互運用を可能にします。
|
||||
|
||||
ツール化に対するサポートに加えて、推奨ラベルはクエリ可能な方法でアプリケーションを表現します。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
メタデータは、_アプリケーション_ のコンセプトを中心に構成されています。KubernetesはPaaS(Platform as a Service)でなく、アプリケーションの公式な概念を持たず、またそれを強制することはありません。
|
||||
そのかわり、アプリケーションは、非公式で、メタデータによって表現されています。単一のアプリケーションが有する項目に対する定義は厳密に決められていません。
|
||||
|
||||
{{< note >}}
|
||||
ラベルには推奨ラベルというものがあります。それらのラベルはアプリケーションの管理を容易にします。しかしコア機能のツール化において必須のものではありません。
|
||||
{{< /note >}}
|
||||
|
||||
共有されたラベルとアノテーションは、`app.kubernetes.io`という共通のプレフィックスを持ちます。プレフィックスの無いラベルはユーザーに対してプライベートなものになります。その共有されたプレフィックスは、共有ラベルがユーザーのカスタムラベルに干渉しないことを保証します。
|
||||
|
||||
## ラベル
|
||||
|
||||
これらの推奨ラベルの利点を最大限得るためには、全てのリソースオブジェクトに対して推奨ラベルが適用されるべきです。
|
||||
|
||||
| キー | 説明 | 例 | 型 |
|
||||
| ----------------------------------- | --------------------- | -------- | ---- |
|
||||
| `app.kubernetes.io/name` | アプリケーション名 | `mysql` | 文字列 |
|
||||
| `app.kubernetes.io/instance` | アプリケーションのインスタンスを特定するための固有名 | `wordpress-abcxzy` | 文字列 |
|
||||
| `app.kubernetes.io/version` | アプリケーションの現在のバージョン (例: セマンティックバージョン、リビジョンのハッシュなど) | `5.7.21` | 文字列 |
|
||||
| `app.kubernetes.io/component` | アーキテクチャ内のコンポーネント | `database` | 文字列 |
|
||||
| `app.kubernetes.io/part-of` | このアプリケーションによって構成される上位レベルのアプリケーション | `wordpress` | 文字列 |
|
||||
| `app.kubernetes.io/managed-by` | このアプリケーションの操作を管理するために使われているツール | `helm` | 文字列 |
|
||||
|
||||
これらのラベルが実際にどう使われているかを表すために、下記のStatefulSetのオブジェクトを考えましょう。
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: mysql
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/version: "5.7.21"
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
app.kubernetes.io/managed-by: helm
|
||||
```
|
||||
|
||||
## アプリケーションとアプリケーションのインスタンス
|
||||
|
||||
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
|
||||
例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。
|
||||
|
||||
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
|
||||
例えば、WordPressは`app.kubernetes.io/name`に`wordpress`と記述され、インスタンス名に関しては`app.kubernetes.io/instance`に`wordpress-abcxzy`と記述されます。この仕組みはアプリケーションと、アプリケーションのインスタンスを特定可能にします。全てのアプリケーションインスタンスは固有の名前を持たなければなりません。
|
||||
|
||||
## ラベルの使用例
|
||||
ここでは、ラベルの異なる使用例を示します。これらの例はそれぞれシステムの複雑さが異なります。
|
||||
|
||||
### シンプルなステートレスサービス
|
||||
|
||||
`Deployment`と`Service`オブジェクトを使って、シンプルなステートレスサービスをデプロイするケースを考えます。下記の2つのスニペットはラベルが最もシンプルな形式においてどのように使われるかをあらわします。
|
||||
|
||||
下記の`Deployment`は、アプリケーションを稼働させるポッドを管理するのに使われます。
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: myservice
|
||||
app.kubernetes.io/instance: myservice-abcxzy
|
||||
...
|
||||
```
|
||||
|
||||
下記の`Service`は、アプリケーションを公開するために使われます。
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: myservice
|
||||
app.kubernetes.io/instance: myservice-abcxzy
|
||||
...
|
||||
```
|
||||
|
||||
### データベースを使ったウェブアプリケーション
|
||||
|
||||
次にもう少し複雑なアプリケーションについて考えます。データベース(MySQL)を使ったウェブアプリケーション(WordPress)で、Helmを使ってインストールします。
|
||||
下記のスニペットは、このアプリケーションをデプロイするために使うオブジェクト設定の出だし部分です。
|
||||
|
||||
はじめに下記の`Deployment`は、WordPressのために使われます。
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: wordpress
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/version: "4.9.4"
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: server
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
...
|
||||
```
|
||||
|
||||
下記の`Service`は、WordPressを公開するために使われます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: wordpress
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/version: "4.9.4"
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: server
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
...
|
||||
```
|
||||
MySQLは`StatefulSet`として公開され、MySQL自身と、MySQLが属する親アプリケーションのメタデータを持ちます。
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: mysql
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
app.kubernetes.io/version: "5.7.21"
|
||||
...
|
||||
```
|
||||
|
||||
この`Service`はMySQLをWordPressアプリケーションの一部として公開します。
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: mysql
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
app.kubernetes.io/version: "5.7.21"
|
||||
...
|
||||
```
|
||||
|
||||
MySQLの`StatefulSet`と`Service`により、MySQLとWordPressに関するより広範な情報が含まれていることに気づくでしょう。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: フィールドセレクター(Field Selectors)
|
||||
weight: 60
|
||||
---
|
||||
|
||||
_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。
|
||||
フィールドセレクタークエリの例は以下の通りです。
|
||||
|
||||
* `metadata.name=my-service`
|
||||
* `metadata.namespace!=default`
|
||||
* `status.phase=Pending`
|
||||
|
||||
下記の`kubectl`コマンドは、[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。
|
||||
|
||||
```shell
|
||||
kubectl get pods --field-selector status.phase=Running
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
フィールドセレクターは本質的にリソースの*フィルター*となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、下記の2つの`kubectl`クエリが同じであることを意味します。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
kubectl get pods --field-selector ""
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
## サポートされているフィールド
|
||||
サポートされているフィールドセレクターはKubernetesリソースタイプによって異なります。全てのリソースタイプは`metadata.name`と`metadata.namespace`フィールドをサポートしています。サポートされていないフィールドセレクターの使用をするとエラーとなります。
|
||||
例えば以下の通りです。
|
||||
|
||||
```shell
|
||||
kubectl get ingress --field-selector foo.bar=baz
|
||||
```
|
||||
|
||||
```
|
||||
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
|
||||
```
|
||||
|
||||
## サポートされているオペレーター
|
||||
|
||||
ユーザーは、`=`、`==`や`!=`といったオペレーターをフィールドセレクターと組み合わせて使用できます。(`=`と`==`は同義)
|
||||
例として、下記の`kubectl`コマンドは`default`ネームスペースに属していない全てのKubernetes Serviceを選択します。
|
||||
|
||||
```shell
|
||||
kubectl get services --field-selector metadata.namespace!=default
|
||||
```
|
||||
|
||||
## 連結されたセレクター
|
||||
[ラベル](/docs/concepts/overview/working-with-objects/labels)や他のセレクターと同様に、フィールドセレクターはコンマ区切りのリストとして連結することができます。
|
||||
下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。
|
||||
|
||||
```shell
|
||||
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
|
||||
```
|
||||
|
||||
## 複数のリソースタイプ
|
||||
|
||||
ユーザーは複数のリソースタイプにまたがったフィールドセレクターを利用できます。
|
||||
下記の`kubectl`コマンドは、`default`ネームスペースに属していない全てのStatefulSetとServiceを選択します。
|
||||
|
||||
```shell
|
||||
kubectl get statefulsets,services --field-selector metadata.namespace!=default
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: Kubernetesオブジェクトを理解する
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページでは、KubernetesオブジェクトがKubernetes APIでどのように表現されているか、またそれらを`.yaml`フォーマットでどのように表現するかを説明します。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Kubernetesオブジェクトを理解する
|
||||
|
||||
*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:
|
||||
|
||||
* どのようなコンテナ化されたアプリケーションが稼働しているか（またそれらはどのノード上で動いているか）
|
||||
* それらのアプリケーションから利用可能なリソース
|
||||
* アプリケーションがどのように振る舞うかのポリシー、例えば再起動、アップグレード、耐障害性ポリシーなど
|
||||
|
||||
Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。
|
||||
|
||||
Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。
|
||||
|
||||
### オブジェクトのspec（仕様）とstatus（状態）
|
||||
|
||||
全てのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それは *spec* オブジェクトと *status* オブジェクトです。*spec* オブジェクトはあなたが指定しなければならない項目で、オブジェクトの *望ましい状態* を記述し、オブジェクトに持たせたい特徴を表現します。*status* オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetesコントロールプレーンは、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。
|
||||
|
||||
例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
|
||||
|
||||
spec、status、metadataに関するさらなる情報は、[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)をご確認ください。
|
||||
|
||||
### Kubernetesオブジェクトを記述する
|
||||
|
||||
Kubernetesでオブジェクトを作成する場合、オブジェクトの基本的な情報（例えば名前）と共に、望ましい状態を記述したオブジェクトのspecを渡さなければいけません。KubernetesAPIを利用しオブジェクトを作成する場合（直接APIを呼ぶか、`kubectl`を利用するかに関わらず）、APIリクエストはそれらの情報をJSON形式でリクエストのBody部に含んでいなければなりません。
|
||||
|
||||
ここで、KubernetesのDeploymentに必要なフィールドとオブジェクトのspecを記載した`.yaml`ファイルの例を示します:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
上に示した`.yaml`ファイルを利用してDeploymentを作成するには、`kubectl`コマンドラインインターフェースに含まれている[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドに`.yaml`ファイルを引数に指定し、実行します。ここで例を示します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
|
||||
```
|
||||
|
||||
出力結果は、下記に似た形になります:
|
||||
|
||||
```shell
|
||||
deployment.apps/nginx-deployment created
|
||||
```
|
||||
|
||||
### 必須フィールド
|
||||
|
||||
Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場合、下記に示すフィールドに値をセットしておく必要があります:
|
||||
|
||||
* `apiVersion` - どのバージョンのKubernetesAPIを利用してオブジェクトを作成するか
|
||||
* `kind` - どの種類のオブジェクトを作成するか
|
||||
* `metadata` - オブジェクトを一意に特定するための情報、`name`、string、UID、また任意の`namespace`が該当する
|
||||
|
||||
またオブジェクトの`spec`の値も指定する必要があります。`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
|
||||
例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/docs/concepts/workloads/pods/pod-overview/)です。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,219 @@
|
||||
---
|
||||
title: ラベル(Labels)とセレクター(Selectors)
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
_ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキーとバリューのペアです。
|
||||
ラベルはユーザーに関連した意味のあるオブジェクトの属性を指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。
|
||||
ラベルはオブジェクトのサブセットを選択し、グルーピングするために使うことができます。また、ラベルはオブジェクトの作成時に割り当てられ、その後いつでも追加、修正ができます。
|
||||
各オブジェクトはキーとバリューのラベルのセットを定義できます。各キーは、単一のオブジェクトに対してはユニークである必要があります。
|
||||
```json
|
||||
"metadata": {
|
||||
"labels": {
|
||||
"key1" : "value1",
|
||||
"key2" : "value2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。
|
||||
識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## ラベルを使う動機
|
||||
|
||||
ラベルは、クライアントにそのマッピング情報を保存することを要求することなく、ユーザー独自の組織構造をシステムオブジェクト上で疎結合にマッピングできます。
|
||||
|
||||
サービスデプロイメントとバッチ処理のパイプラインは多くの場合、多次元のエンティティとなります(例: 複数のパーティション、Deployment、リリーストラック、ティアー、ティアー毎のマイクロサービスなど)
|
||||
管理は分野横断的な操作が必要になることが多く、それによって厳密な階層表現、特にユーザーによるものでなく、インフラストラクチャーによって定義された厳格な階層のカプセル化が破られます。
|
||||
|
||||
ラベルの例:
|
||||
|
||||
* `"release" : "stable"`, `"release" : "canary"`
|
||||
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
|
||||
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
|
||||
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
||||
* `"track" : "daily"`, `"track" : "weekly"`
|
||||
|
||||
これらは単によく使われるラベルの例です。ユーザーは自由に規約を決めることができます。
|
||||
ラベルのキーは、ある1つのオブジェクトに対してユニークである必要があることは覚えておかなくてはなりません。
|
||||
|
||||
## 構文と文字セット
|
||||
|
||||
ラベルは、キーとバリューのベアです。正しいラベルキーは2つのセグメントを持ちます。
|
||||
それは`/`によって分割されたオプショナルなプレフィックスと名前です。
|
||||
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)で、文字列の間ではこれに加えてダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
|
||||
プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。
|
||||
|
||||
もしプレフィックスが省略された場合、ラベルキーはそのユーザーに対してプライベートであると推定されます。
|
||||
エンドユーザーのオブジェクトにラベルを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。
|
||||
|
||||
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
|
||||
|
||||
正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。
|
||||
|
||||
## ラベルセレクター
|
||||
|
||||
[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。
|
||||
|
||||
*ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。
|
||||
|
||||
Kubernetes APIは現在2タイプのセレクターをサポートしています。
|
||||
それは*等価ベース(equality-based)* と*集合ベース(set-based)* です。
|
||||
単一のラベルセレクターは、コンマ区切りの複数の*要件(requirements)* で構成されています。
|
||||
複数の要件がある場合、コンマセパレーターは論理積 _AND_(`&&`)オペレーターと同様にふるまい、全ての要件を満たす必要があります。
|
||||
|
||||
空文字の場合や、指定なしのセレクターに関するセマンティクスは、コンテキストに依存します。
|
||||
そしてセレクターを使うAPIタイプは、それらのセレクターの妥当性とそれらが示す意味をドキュメントに記載するべきです。
|
||||
|
||||
{{< note >}}
|
||||
ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
|
||||
{{< /note >}}
|
||||
|
||||
### *等価ベース(Equality-based)* の要件(requirement)
|
||||
|
||||
*等価ベース(Equality-based)* もしくは*不等ベース(Inequality-based)* の要件は、ラベルキーとラベル値によるフィルタリングを可能にします。
|
||||
要件に一致したオブジェクトは、指定されたラベルの全てを満たさなくてはいけませんが、それらのオブジェクトはさらに追加のラベルも持つことができます。
|
||||
そして等価ベースの要件においては、3つの種類のオペレーターの利用が許可されています。`=`、`==`、`!=`となります。
|
||||
最初の2つのオペレーター(`=`、`==`)は*等価(Equality)* を表現し(この2つは単なる同義語)、最後の1つ(`!=`)は*不等(Inequality)* を意味します。
|
||||
例えば
|
||||
|
||||
```
|
||||
environment = production
|
||||
tier != frontend
|
||||
```
|
||||
|
||||
最初の例は、キーが`environment`で、値が`production`である全てのリソースを対象にします。
|
||||
次の例は、キーが`tier`で、値が`frontend`とは異なるリソースと、`tier`という名前のキーを持たない全てのリソースを対象にします。
|
||||
コンマセパレーター`,`を使って、`production`の中から、`frontend`のものを除外するようにフィルターすることもできます。
|
||||
`environment=production,tier!=frontend`
|
||||
|
||||
等価ベースのラベル要件の1つの使用シナリオとして、PodにおけるNodeの選択要件を指定するケースがあります。
|
||||
例えば、下記のサンプルPodは、ラベル`accelerator=nvidia-tesla-p100`をもったNodeを選択します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: cuda-test
|
||||
spec:
|
||||
containers:
|
||||
- name: cuda-test
|
||||
image: "k8s.gcr.io/cuda-vector-add:v0.1"
|
||||
resources:
|
||||
limits:
|
||||
nvidia.com/gpu: 1
|
||||
nodeSelector:
|
||||
accelerator: nvidia-tesla-p100
|
||||
```
|
||||
|
||||
### *集合ベース(Set-based)* の要件(requirement)
|
||||
|
||||
*集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。
|
||||
`in`、`notin`、`exists`の3つのオペレーターをサポートしています(キーを特定するのみ)。
|
||||
|
||||
例えば:
|
||||
```
|
||||
environment in (production, qa)
|
||||
tier notin (frontend, backend)
|
||||
partition
|
||||
!partition
|
||||
```
|
||||
|
||||
最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。
|
||||
第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。
|
||||
第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。
|
||||
第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。
|
||||
同様に、コンマセパレーターは、_AND_ オペレーターと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。
|
||||
*集合ベース* のラベルセレクターは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。
|
||||
|
||||
*集合ベース* の要件は、*等価ベース* の要件と混在できます。
|
||||
例えば:
|
||||
`partition in (customerA, customerB),environment!=qa`.
|
||||
|
||||
## API
|
||||
|
||||
### LISTとWATCHによるフィルタリング
|
||||
|
||||
LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。
|
||||
*集合ベース* と*等価ベース* のどちらの要件も許可されています(ここでは、URLクエリストリング内で出現します)。
|
||||
|
||||
* *等価ベース* での要件: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* *集合ベース* での要件: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
|
||||
上記の2つの形式のラベルセレクターはRESTクライアントを介してリストにしたり、もしくは確認するために使われます。
|
||||
例えば、`kubectl`によって`apiserver`をターゲットにし、*等価ベース* の要件でフィルターすると以下のように書けます。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l environment=production,tier=frontend
|
||||
```
|
||||
|
||||
もしくは、*集合ベース* の要件を指定すると以下のようになります。
|
||||
```shell
|
||||
kubectl get pods -l 'environment in (production),tier in (frontend)'
|
||||
```
|
||||
|
||||
すでに言及したように、*集合ベース* の要件は、*等価ベース* の要件より表現力があります。
|
||||
例えば、値に対する_OR_ オペレーターを実装して以下のように書けます。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l 'environment in (production, qa)'
|
||||
```
|
||||
|
||||
もしくは、_exists_ オペレーターを介して、否定マッチングによる制限もできます。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
```
|
||||
|
||||
### APIオブジェクトに参照を設定する
|
||||
[`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
|
||||
"selector": {
|
||||
"component" : "redis",
|
||||
}
|
||||
```
|
||||
もしくは
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
component: redis
|
||||
```
|
||||
|
||||
このセレクター(それぞれ`json`または`yaml`形式)は、`component=redis`または`component in (redis)`と等価です。
|
||||
|
||||
#### *集合ベース* の要件指定をサポートするリソース
|
||||
|
||||
[`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:
|
||||
component: redis
|
||||
matchExpressions:
|
||||
- {key: tier, operator: In, values: [cache]}
|
||||
- {key: environment, operator: NotIn, values: [dev]}
|
||||
```
|
||||
|
||||
`matchLabels`は、`{key,value}`ペアのマップです。`matchLabels`内の単一の`{key,value}`は、`matchExpressions`の要素と等しく、それは、`key`フィールドがキー名で、`operator`が"In"で、`values`配列は単に"値"を保持します。
|
||||
`matchExpressions`はPodセレクター要件のリストです。対応しているオペレーターは`In`、`NotIn`、`Exists`と`DoesNotExist`です。`values`のセットは、`In`と`NotIn`オペレーターにおいては空文字を許容しません。
|
||||
`matchLabels`と`matchExpressions`の両方によって指定された全ての要件指定はANDで判定されます。つまり要件にマッチするには指定された全ての要件を満たす必要があります。
|
||||
|
||||
#### Nodeのセットを選択する
|
||||
ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。
|
||||
さらなる情報に関しては、[Node選定](/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 名前
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明確に識別されます。
|
||||
|
||||
ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/docs/user-guide/labels)と[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を付与します。
|
||||
|
||||
名前とUIDに関する正確な構文については、[識別子デザインドキュメント](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 名前
|
||||
|
||||
{{< glossary_definition term_id="name" length="all" >}}
|
||||
|
||||
慣例的に、Kubernetesリソースの名前は最長253文字で、かつ英小文字、数字、また`-`、`.`から構成します。しかし、特定のリソースはより具体的な制限があります。
|
||||
|
||||
## UID
|
||||
|
||||
{{< glossary_definition term_id="uid" length="all" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: Namespace(名前空間)
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
|
||||
この仮想クラスターをNamespaceと呼びます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 複数のNamespaceを使う時
|
||||
|
||||
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
|
||||
数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。
|
||||
Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
|
||||
|
||||
Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。
|
||||
|
||||
Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
|
||||
|
||||
Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。
|
||||
|
||||
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
|
||||
同一のNamespace内でリソースを区別するためには[ラベル](/docs/user-guide/labels)を使用してください。
|
||||
|
||||
## Namespaceを利用する
|
||||
|
||||
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/admin/namespaces)に記載されています。
|
||||
|
||||
### Namespaceの表示
|
||||
|
||||
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
|
||||
|
||||
```shell
|
||||
kubectl get namespaces
|
||||
```
|
||||
```
|
||||
NAME STATUS AGE
|
||||
default Active 1d
|
||||
kube-system Active 1d
|
||||
kube-public Active 1d
|
||||
```
|
||||
|
||||
Kubernetesの起動時には3つの初期Namespaceが作成されています。
|
||||
|
||||
* `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
|
||||
* `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
|
||||
* `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
|
||||
このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。
|
||||
|
||||
### Namespaceの設定
|
||||
|
||||
一時的な要求のためにNamespaceを設定したい場合、`--namespace`フラグを使用します。
|
||||
例:
|
||||
|
||||
```shell
|
||||
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
|
||||
kubectl --namespace=<insert-namespace-name-here> get pods
|
||||
```
|
||||
|
||||
### Namespace設定の永続化
|
||||
|
||||
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
|
||||
|
||||
```shell
|
||||
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
|
||||
# Validate it
|
||||
kubectl config view | grep namespace:
|
||||
```
|
||||
|
||||
## NamespaceとDNS
|
||||
|
||||
ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/docs/concepts/services-networking/dns-pod-service/)を作成します。
|
||||
このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
|
||||
これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
|
||||
もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
|
||||
|
||||
## すべてのオブジェクトはNamespaceに属しているとは限らない
|
||||
|
||||
ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。
|
||||
しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。
|
||||
そして[Node](/docs/admin/node)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
|
||||
|
||||
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
|
||||
|
||||
```shell
|
||||
# Namespaceに属しているもの
|
||||
kubectl api-resources --namespaced=true
|
||||
|
||||
# Namespaceに属していないもの
|
||||
kubectl api-resources --namespaced=false
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user