whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

resolve conflict

Browse Source
This commit is contained in:
inductor
2020-06-15 02:59:15 +09:00
parent c9472ad4b6 ce768c84b7
commit 298382169c
2451 changed files with 127381 additions and 564546 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/concepts/overview/working-with-objects/annotations.md
+14 -16
View File
@@ -1,20 +1,20 @@
---
title: アノテーション(Annotations)
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## オブジェクトにメタデータを割り当てる
ユーザーは、Kubernetesオブジェクトに対してラベルやアノテーションの両方またはどちらか一方を割り当てることができます。
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
ラベルはオブジェクトの選択や、特定の条件を満たしたオブジェクトの集合を探すことに使うことができます。
それと対照的に、アノテーションはオブジェクトを識別、または選択するために使用されません。
アノテーション内のメタデータは大小様々で、構造化されているものや、そうでないものも設定でき、ラベルでは許可されていない文字も含むことができます。
アノテーションは、ラベルと同様に、キーとバリューのマップとなります。
@@ -49,15 +49,15 @@ weight: 50
## 構文と文字セット
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。
プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
_アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。
プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。
名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。
プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。
もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。
エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。
もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。
エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
`kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。
たとえば、`imageregistry: https://hub.docker.com/`というアノテーションが付いたPodの構成ファイルは次のとおりです:
@@ -76,9 +76,7 @@ spec:
- containerPort: 80
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)について学習してください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/common-labels.md
+7 -8
View File
@@ -1,15 +1,15 @@
---
title: 推奨ラベル(Recommended Labels)
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
ユーザーはkubectlやダッシュボード以外に、多くのツールでKubernetesオブジェクトの管理と可視化ができます。共通のラベルセットにより、全てのツールにおいて解釈可能な共通のマナーに沿ってオブジェクトを表現することで、ツールの相互運用を可能にします。
ツール化に対するサポートに加えて、推奨ラベルはクエリ可能な方法でアプリケーションを表現します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
メタデータは、_アプリケーション_ のコンセプトを中心に構成されています。KubernetesはPaaS(Platform as a Service)でなく、アプリケーションの公式な概念を持たず、またそれを強制することはありません。
そのかわり、アプリケーションは、非公式で、メタデータによって表現されています。単一のアプリケーションが有する項目に対する定義は厳密に決められていません。
@@ -49,10 +49,10 @@ metadata:
## アプリケーションとアプリケーションのインスタンス
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
例えば、WordPressは`app.kubernetes.io/name`に`wordpress`と記述され、インスタンス名に関しては`app.kubernetes.io/instance`に`wordpress-abcxzy`と記述されます。この仕組みはアプリケーションと、アプリケーションのインスタンスを特定可能にします。全てのアプリケーションインスタンスは固有の名前を持たなければなりません。
## ラベルの使用例
@@ -86,7 +86,7 @@ metadata:
### データベースを使ったウェブアプリケーション
次にもう少し複雑なアプリケーションについて考えます。データベース(MySQL)を使ったウェブアプリケーション(WordPress)で、Helmを使ってインストールします。
次にもう少し複雑なアプリケーションについて考えます。データベース(MySQL)を使ったウェブアプリケーション(WordPress)で、Helmを使ってインストールします。
下記のスニペットは、このアプリケーションをデプロイするために使うオブジェクト設定の出だし部分です。
はじめに下記の`Deployment`は、WordPressのために使われます。
@@ -153,4 +153,3 @@ metadata:
MySQLの`StatefulSet`と`Service`により、MySQLとWordPressに関するより広範な情報が含まれていることに気づくでしょう。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: Kubernetesオブジェクトを理解する
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 40
---
{{% capture overview %}}
<!-- overview -->
このページでは、KubernetesオブジェクトがKubernetes APIでどのように表現されているか、またそれらを`.yaml`フォーマットでどのように表現するかを説明します。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubernetesオブジェクトを理解する
*Kubernetesオブジェクト* は、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。具体的に言うと、下記のような内容が表現出来ます:
@@ -66,13 +66,14 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/labels.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: ラベル(Labels)とセレクター(Selectors)
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
_ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキーとバリューのペアです。
ラベルはユーザーに関連した意味のあるオブジェクトの属性を指定するために使われることを目的としています。しかしKubernetesのコアシステムに対して直接的にその意味を暗示するものではありません。
@@ -22,10 +22,10 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ
ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。
識別用途でない情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ラベルを使う動機
@@ -240,4 +240,4 @@ selector:
ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。
さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/names.md
+5 -7
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: オブジェクトの名前とID
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。
@@ -13,9 +13,9 @@ weight: 20
ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 名前 {#names}
@@ -74,8 +74,6 @@ spec:
Kubernetes UIDは、UUIDのことを指します。
UUIDは、ISO/IEC 9834-8およびITU-T X.667として標準化されています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Kubernetesの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)についてお読みください。
* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)デザインドキュメントをご覧ください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/namespaces.md
+27 -30
View File
@@ -1,41 +1,41 @@
---
title: Namespace(名前空間)
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
{{% /capture %}}
Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
この仮想クラスターをNamespaceと呼びます。
{{% capture body %}}
<!-- body -->
## 複数のNamespaceを使う時
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。
数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。
Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。
Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。Namespaceは相互にネストすることはできず、各Kubernetesリソースは1つのNamespaceにのみ存在できます。
Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
## Namespaceを利用する
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
### Namespaceの表示
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
```shell
kubectl get namespace
@@ -49,9 +49,9 @@ kube-public Active 1d
Kubernetesの起動時には3つの初期Namespaceが作成されています。
* `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
* `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
* `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
* `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
* `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
* `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。
### Namespaceの設定
@@ -67,7 +67,7 @@ kubectl get pods --namespace=<insert-namespace-name-here>
### Namespace設定の永続化
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。
```shell
kubectl config set-context --current --namespace=<insert-namespace-name-here>
@@ -77,18 +77,18 @@ kubectl config view --minify | grep namespace:
## NamespaceとDNS
ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。
このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり,これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/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](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。
しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。
そして[Node](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。
```shell
# Namespaceに属しているもの
@@ -98,10 +98,7 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [新しいNamespaceの作成](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)について学習してください。
* [Namespaceの削除](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)について学習してください。
{{% /capture %}}
content/ja/docs/concepts/overview/working-with-objects/object-management.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: Kubernetesオブジェクト管理
content_template: templates/concept
content_type: concept
weight: 15
---
{{% capture overview %}}
<!-- overview -->
`kubectl`コマンドラインツールは、Kubernetesオブジェクトを作成、管理するためにいくつかの異なる方法をサポートしています。
このドキュメントでは、それらの異なるアプローチごとの概要を提供します。
Kubectlを使ったオブジェクト管理の詳細は、[Kubectl book](https://kubectl.docs.kubernetes.io)を参照してください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## 管理手法
@@ -157,9 +157,10 @@ kubectl apply -R -f configs/
- 宣言型オブジェクト設定は、デバッグ、そして想定外の結果が出たときに理解するのが困難です
- 差分を利用した一部のみの更新は、複雑なマージ、パッチの操作が必要です
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
@@ -169,4 +170,4 @@ kubectl apply -R -f configs/
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
- [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}