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,107 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Kubernetesコンポーネント
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、Kubernetesクラスターの機能を提供するために必要になる様々なコンポーネントを説明します。（実行ファイル形式で提供される）
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## マスターコンポーネント
|
||||
|
||||
マスターコンポーネントは、クラスターのコントロールプレーンです。マスターコンポーネントはクラスターに関する全体的な決定を行い（例えばスケジューリングなど）、クラスターのイベントを検知し、それらに応答します（例えば、レプリケーションコントローラーの'replicas'フィールドが充足されていない場合、新しいPodを立ち上げます）。
|
||||
|
||||
マスターコンポーネントは、クラスター内のどのマシン上でも動かすことが出来ます。しかし、話を簡単にするために、環境構築を行うスクリプトは通常、全てのマスターコンポーネントを同じマシン上で稼働させ、ユーザーのコンテナはそのマシンでは稼働させません。複数マスターマシン構成の構築例は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
{{< glossary_definition term_id="kube-apiserver" length="all" >}}
|
||||
|
||||
### etcd
|
||||
|
||||
{{< glossary_definition term_id="etcd" length="all" >}}
|
||||
|
||||
### kube-scheduler
|
||||
|
||||
{{< glossary_definition term_id="kube-scheduler" length="all" >}}
|
||||
|
||||
### kube-controller-manager
|
||||
|
||||
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
|
||||
|
||||
コントローラーには下記のものがあります:
|
||||
|
||||
* ノードコントローラー: ノードがダウンした場合に、通知と応答を行います。
|
||||
* レプリケーションコントローラー: それぞれのレプリケーションコントローラーオブジェクト内に、正しい数のポッドが存在しているかを管理します。
|
||||
* エンドポイントコントローラー: エンドポイントを設定します。（これは、サービスとPodを結合するということです）
|
||||
* サービスアカウント & トークンコントローラー: 新しい名前空間にデフォルトアカウントとAPIアクセストークンを作成します。
|
||||
|
||||
### クラウドコントローラーマネージャー（cloud-controller-manager）
|
||||
|
||||
[クラウドコントローラーマネージャー](/docs/tasks/administer-cluster/running-cloud-controller/)は、基盤となるクラウドサービスと連携するコントローラーを動かします。クラウドコントローラーマネージャーはKubernetes 1.6でリリースされたアルファの機能です。
|
||||
|
||||
クラウドコントローラーマネージャーは、クラウドサービス固有の制御ループのみを動かします。これらの制御ループは kube-controller-manager から無効にしなければなりません。無効にするには、kube-controller-managerの起動時に、`--cloud-provider`フラグに`external`を指定します。
|
||||
|
||||
クラウドコントローラーマネージャーは、クラウドベンダー固有のコードと、Kubernetes本体のコードを独立して開発することを可能にします。以前のリリースでは、Kubernetes本体のコードがクラウドサービス固有のコードに機能的に依存していました。将来のリリースでは、クラウドベンダー固有のコードはクラウドベンダー自身が保持し、Kubernetesが稼働している時にクラウドコントローラーマネージャーに紐付けられるようになっていきます。
|
||||
|
||||
以下のコントローラーがクラウドサービスとの依存関係を持っています:
|
||||
|
||||
* ノードコントローラー: クラウドから応答が無くなった後、ノードが削除されていないかを確認します。
|
||||
* ルートコントローラー: クラウド基盤にルーティング情報を設定します。
|
||||
* サービスコントローラー: クラウドサービス上のロードバランサーを作成、更新、削除します。
|
||||
* ボリュームコントローラー: ボリュームを作成、アタッチ、マウント、またクラウドサービスと連携し、ボリュームを編成します。
|
||||
|
||||
## ノードコンポーネント
|
||||
|
||||
ノードコンポーネントは全てのノード上で稼働し、稼働中Podの管理、Kubernetes実行環境を提供します。
|
||||
|
||||
### kubelet
|
||||
|
||||
{{< glossary_definition term_id="kubelet" length="all" >}}
|
||||
|
||||
### kube-proxy
|
||||
|
||||
[kube-proxy](/docs/admin/kube-proxy/)は、ホスト上のネットワークルールを管理し、コネクションの転送を行うことで、Kubernetesサービスの抽象化を可能にします。
|
||||
|
||||
### コンテナランタイム
|
||||
|
||||
コンテナランタイムは、コンテナを稼働させる責務を持つソフトウェアです。
|
||||
Kubernetesはいくつかのランタイムをサポートしています: [Docker](http://www.docker.com)、[containerd](https://containerd.io)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet)、また[Kubernetes CRI (コンテナランタイムインターフェース)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)の実装があります。
|
||||
|
||||
## アドオン
|
||||
|
||||
アドオンは、クラスターの機能群を実装したPodとサービスです。そのPodは、Deployment、レプリケーションコントローラーなどによって管理されるでしょう。名前空間に属するアドオンオブジェクトは、`kube-system`名前空間に作られます。
|
||||
|
||||
一部のアドオンを下記に示します。その他の利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/)を確認してください。
|
||||
|
||||
### DNS
|
||||
|
||||
厳密には他のアドオンは必須ではありませんが、多数の実例が依存しているため、全てのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。
|
||||
|
||||
クラスターDNSはDNSサーバーで、あなたの環境で動いている他のDNSサーバーに加え、Kubernetesサービスで利用するDNSレコードも扱います。
|
||||
|
||||
Kubernetesから起動されたコンテナは、DNSの検索対象として、自動的にこのDNSサーバーを含めます。
|
||||
|
||||
### Web UI (ダッシュボード)
|
||||
|
||||
[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、汎用のKubernetesのクラスターを管理するためのWebベースのUIです。ユーザーはこれを用いて、クラスター上で稼働しているアプリケーション、またクラスターそのものの管理、トラブルシュートが可能です。
|
||||
|
||||
### コンテナリソース監視
|
||||
|
||||
[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列のメトリクスをセントラルなデータベースに記録し、そのデータを閲覧するUIを提供します。
|
||||
|
||||
### クラスターレベルロギング
|
||||
|
||||
[クラスターレベルロギング](/docs/concepts/cluster-administration/logging/)機構は、コンテナのログを、検索、閲覧のインターフェースを持ったセントラルなログ保管場所に保存します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Kubernetes API
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
card:
|
||||
name: concepts
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/api-conventions.md)に記載されています。
|
||||
|
||||
APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。
|
||||
|
||||
APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。
|
||||
|
||||
Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。
|
||||
|
||||
また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。
|
||||
|
||||
Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## APIの変更
|
||||
|
||||
我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。
|
||||
|
||||
何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md)に詳解されています。
|
||||
|
||||
## OpenAPIとSwaggerの定義
|
||||
|
||||
完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)に記載されています。
|
||||
|
||||
Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポイントを通じて、OpenAPI仕様を提供しています。
|
||||
リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます:
|
||||
|
||||
ヘッダ | 設定可能な値
|
||||
------ | ---------------
|
||||
Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` （デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません）
|
||||
Accept-Encoding | `gzip` （このヘッダーを送信しないことも許容されています）
|
||||
|
||||
1.14より前のバージョンでは、フォーマット分離エンドポイント（`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`）が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
|
||||
|
||||
**OpenAPI仕様の取得サンプル**:
|
||||
|
||||
1.10より前 | Kubernetes1.10以降
|
||||
----------- | -----------------------------
|
||||
GET /swagger.json | GET /openapi/v2 **Accept**: application/json
|
||||
GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
|
||||
GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
|
||||
|
||||
Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
|
||||
|
||||
また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。
|
||||
このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
|
||||
|
||||
## APIバージョニング
|
||||
|
||||
フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/extensions/v1beta1`のように、それぞれ異なるAPIのパスが割り当てられています。
|
||||
|
||||
APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。
|
||||
|
||||
APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。
|
||||
|
||||
異なるバージョンのAPIは、異なるレベル（版）の安定性とサポートを持っています。それぞれのレベル（版）の基準は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)に詳細が記載されています。下記に簡潔にまとめます:
|
||||
|
||||
- アルファレベル（版）:
|
||||
- バージョン名に`alpha`を含みます（例、`v1alpha1`）。
|
||||
- バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。
|
||||
- アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。
|
||||
- ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。
|
||||
- バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。
|
||||
- ベータレベル（版）:
|
||||
- バージョン名に`beta`を含みます（例、`v2beta3`）。
|
||||
- コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。
|
||||
- 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。
|
||||
- オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。
|
||||
- 今後のリリースで、互換性の無い変更が行われる可能性があるため、ビジネスクリティカルな場面以外での利用を推奨します。もし複数のクラスターを持っており、それぞれ個別にアップグレードが可能な場合、この制限の影響を緩和できるかもしれません。
|
||||
- **是非ベータ機能を試して、フィードバックをください！ベータから安定版になってしまうと、より多くの変更を加えることが難しくなってしまいます。**
|
||||
- 安定版:
|
||||
- バージョン名は`vX`のようになっており、`X`は整数です。
|
||||
- 安定版の機能は、今後のリリースバージョンにも適用されます。
|
||||
|
||||
## APIグループ
|
||||
|
||||
KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
|
||||
APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。
|
||||
|
||||
現在、いくつかのAPIグループが利用されています:
|
||||
|
||||
1. *core* グループ（度々、*legacy group* と呼ばれます）は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
|
||||
|
||||
1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`（例、`apiVersion: batch/v1`）を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。
|
||||
|
||||
[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています:
|
||||
|
||||
1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。
|
||||
1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。
|
||||
|
||||
## APIグループの有効化
|
||||
|
||||
いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
|
||||
|
||||
重要: APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。
|
||||
|
||||
## APIグループのリソースの有効化
|
||||
|
||||
DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。
|
||||
その他の拡張リソースは、APIサーバーの`--runtime-config`を設定することで有効化できます。`--runtime-config`はカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`と設定します。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -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