From 638eaf6f27e3fd32526632f16fff4075e00352ee Mon Sep 17 00:00:00 2001 From: inductor Date: Fri, 27 Mar 2020 16:18:23 +0900 Subject: [PATCH 001/290] fix typo (#19878) --- .../cluster-administration/cluster-administration-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 935edba7a3..3aec349748 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -20,7 +20,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る - **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。 - [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**? - 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。 - - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させるますか? それとも**仮想マシン (VMs)** 上で稼働させますか? + - Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか? - **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。 - **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。 - クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。 From 109e8c5fa248abaf202967c0fa4b75442fa68fb3 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 27 Mar 2020 23:22:23 +0900 Subject: [PATCH 002/290] replace http helm link with https (#19889) --- .../tasks/service-catalog/install-service-catalog-using-helm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md index cac6668f16..15fb801e88 100644 --- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -18,7 +18,7 @@ content_template: templates/task * クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。 * `hack/local-up-cluster.sh`を使用している場合は、環境変数`KUBE_ENABLE_CLUSTER_DNS`が設定されていることを確認し、インストールスクリプトを実行してください。 * [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。 -* v2.7.0以降の[Helm](http://helm.sh/)をインストールしてください。 +* v2.7.0以降の[Helm](https://helm.sh/)をインストールしてください。 * [Helm install instructions](https://helm.sh/docs/intro/install/)を参考にしてください。 * 上記のバージョンのHelmをすでにインストールしている場合は、`helm init`を実行し、HelmのサーバーサイドコンポーネントであるTillerをインストールしてください。 From a315c38000773f8dccf25affffd64daa62492661 Mon Sep 17 00:00:00 2001 From: iaoiui Date: Wed, 1 Apr 2020 08:49:02 +0900 Subject: [PATCH 003/290] Fix typo kubectl exposed -> kubectl expose --- .../services-networking/connect-applications-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md index e1250bbdea..5948d51e88 100644 --- a/content/ja/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md @@ -77,7 +77,7 @@ Kubernetes Serviceは、クラスター内のどこかで実行されるPodの このアドレスはServiceの有効期間に関連付けられており、Serviceが動作している間は変更されません。 Podは、Serviceと通信するように構成でき、Serviceへの通信は、ServiceのメンバーであるPodに自動的に負荷分散されることを認識できます。 -2つのnginxレプリカのサービスを`kubectl exposed`で作成できます: +2つのnginxレプリカのサービスを`kubectl expose`で作成できます: ```shell kubectl expose deployment/my-nginx From 13274fbdd415580de18973846bc9557eb68c3585 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 4 Apr 2020 15:59:34 +0900 Subject: [PATCH 004/290] update link to /ja/docs/concepts/services-networking/dns-pod-service/ --- content/ja/docs/concepts/overview/components.md | 2 +- .../docs/concepts/overview/working-with-objects/namespaces.md | 2 +- .../ja/docs/concepts/services-networking/dns-pod-service.md | 4 ++-- content/ja/docs/concepts/services-networking/service.md | 2 +- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- .../reference/command-line-tools-reference/feature-gates.md | 2 +- .../windows/user-guide-windows-containers.md | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 5a4f894c44..8cee84861a 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -93,7 +93,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー ### DNS -クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。 +クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。 クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 8e21224587..223fec9ce9 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -76,7 +76,7 @@ kubectl config view | grep namespace: ## NamespaceとDNS -ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/docs/concepts/services-networking/dns-pod-service/)を作成します。 +ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 このエントリは`..svc.cluster.local`という形式になり,これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md index fa76965e8e..2700b92ea8 100644 --- a/content/ja/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -25,7 +25,7 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer うまく機能する他のレイアウト、名前、またはクエリーは、実装の詳細を考慮し、警告なしに変更されることがあります。 最新の仕様に関する詳細は、[KubernetesにおけるDNSベースのServiceディスカバリ](https://github.com/kubernetes/dns/blob/master/docs/specification.md)を参照ください。 -## Service +## Service {#services} ### Aレコード @@ -148,7 +148,7 @@ spec: dnsPolicy: ClusterFirstWithHostNet ``` -### PodのDNS設定 +### PodのDNS設定 {#pods-dns-config} PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。 diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index c143b291c5..4bc127b439 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -306,7 +306,7 @@ CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、 Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。 KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。 -[DNS Pods と Service](/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。 +[DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。 ## Headless Service {#headless-service} diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index e16488b5b8..3dd96553fe 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -131,7 +131,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/#how-it-works)がされない限り、`cluster.local`にセットされます。 +クラスタードメインは[その他の設定](/ja/docs/concepts/services-networking/dns-pod-service/#how-it-works)がされない限り、`cluster.local`にセットされます。 {{< /note >}} ### 安定したストレージ diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 582d432e94..1bc72fe65e 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -322,7 +322,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `CSIPersistentVolume`: [CSI(Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。 詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。 - `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。 -- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。 +- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。 - `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 44d136f60b..2e6e7fb5d7 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -93,7 +93,7 @@ Port mapping is also supported, but for simplicity in this example the container * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods - * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services) + * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services) * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec From 65b887f07023c5fda3d03c5848af6a6bd049bf10 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 5 Apr 2020 17:28:07 +0900 Subject: [PATCH 005/290] update link to /ja/docs/concepts/workloads/pods/pod-lifecycle/ --- .../ja/docs/concepts/configuration/overview.md | 2 +- .../docs/concepts/containers/runtime-class.md | 2 +- .../working-with-objects/field-selectors.md | 2 +- .../concepts/services-networking/service.md | 2 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/deployment.md | 4 ++-- .../concepts/workloads/pods/pod-lifecycle.md | 18 +++++++++--------- content/ja/docs/concepts/workloads/pods/pod.md | 2 +- .../feature-gates.md | 4 ++-- 9 files changed, 19 insertions(+), 19 deletions(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 8255db692a..f5939344cc 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -31,7 +31,7 @@ weight: 10 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 - 明示的に[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 + 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 ## Service diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 1acbdcf219..e36d7f9572 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -81,7 +81,7 @@ spec: # ... ``` -これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。 +これは、Kubeletに対してPodを稼働させるためのRuntimeClassを使うように指示します。もし設定されたRuntimeClassが存在しない場合や、CRIが対応するハンドラーを実行できない場合、そのPodは`Failed`という[フェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)になります。 エラーメッセージに関しては対応する[イベント](/docs/tasks/debug-application-cluster/debug-application-introspection/)を参照して下さい。 もし`runtimeClassName`が指定されていない場合、デフォルトのRuntimeHandlerが使用され、これはRuntimeClassの機能が無効であるときのふるまいと同じものとなります。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index 86bce27e07..3247f1b8da 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -10,7 +10,7 @@ _フィールドセレクター(Field Selectors)_ は、1つかそれ以上の * `metadata.namespace!=default` * `status.phase=Pending` -下記の`kubectl`コマンドは、[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。 +下記の`kubectl`コマンドは、[`status.phase`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)フィールドの値が`Running`である全てのPodを選択します。 ```shell kubectl get pods --field-selector status.phase=Running diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index c143b291c5..8bdf67997f 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -183,7 +183,7 @@ kube-proxyは、どのバックエンドPodを使うかを決める際にService kube-proxyがiptablesモードで稼働し、最初に選択されたPodが応答しない場合、そのコネクションは失敗します。 これはuser-spaceモードでの挙動と異なります: user-spaceモードにおいては、kube-proxyは最初のPodに対するコネクションが失敗したら、自動的に他のバックエンドPodに対して再接続を試みます。 -iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。 +iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。 ![iptablesプロキシーのService概要ダイアグラム](/images/docs/services-iptables-overview.svg) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 1edf7636ce..ddd5089c02 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -52,7 +52,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 -DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。 +DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。 ### Podセレクター diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 3146606573..172fe0f25d 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -919,7 +919,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/ Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。 -[`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。 +[`.spec.template.spec.restartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。 ### レプリカ数 @@ -973,7 +973,7 @@ Deploymentのテンプレートが`.spec.template`と異なる場合や、`.spec ### minReadySeconds {#min-ready-seconds} -`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。 +`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。 ### rollbackTo diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 07437b9847..82fdcc31ff 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -13,7 +13,7 @@ weight: 30 {{% capture body %}} -## PodのPhase +## PodのPhase {#pod-phase} Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。 @@ -33,7 +33,7 @@ Podの各フェーズの値と意味は厳重に守られています。 `Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 `Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。 -## Podのconditions +## Podのconditions {#pod-conditions} PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 PodCondition配列の各要素には、次の6つのフィールドがあります。 @@ -57,7 +57,7 @@ PodCondition配列の各要素には、次の6つのフィールドがありま * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 -## コンテナのProbe +## コンテナのProbe {#container-probes} [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。 診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。 @@ -91,7 +91,7 @@ Kubeletは2種類のProbeを実行中のコンテナで行い、また反応す initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 -### livenessProbeとreadinessProbeをいつ使うべきか? +### livenessProbeとreadinessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 @@ -114,13 +114,13 @@ Pod内のコンテナが停止するのを待つ間Podはunhealthyのままで livenessProbeまたはreadinessProbeを設定する方法の詳細については、 [Configure Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)を参照してください -## Podとコンテナのステータス +## Podとコンテナのステータス {#pod-and-container-status} PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。 Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。 -## コンテナのステータス +## コンテナのステータス {#container-states} PodがスケジューラによってNodeに割り当てられると、 kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。 @@ -158,7 +158,7 @@ Pod内のコンテナごとにStateの項目として表示されます。 ... ``` -## PodReadinessGate +## PodReadinessGate {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} @@ -205,14 +205,14 @@ K8s 1.1ではAlpha機能のため"Pod Ready++" 機能は`PodReadinessGates` [fea K8s 1.12ではこの機能はデフォルトで有効になっています。 -## RestartPolicy +## RestartPolicy {#restart-policy} PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。 デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。 `restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。 kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。 -## Podのライフタイム +## Podのライフタイム {#pod-lifetime} 一般にPodは人間またはコントローラーが明示的に削除するまで存在します。 コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。 diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index 48be657bc8..aa6e6f7199 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -34,7 +34,7 @@ Pod内のアプリケーションからアクセスできる共有ボリュー [Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。 個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。 -[Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。 +[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。 Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。 特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。 代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください）。 diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 582d432e94..1d1e7b7df2 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -361,7 +361,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。 - `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 -- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 +- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 - `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 @@ -377,7 +377,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。 -- `StartupProbe`: kubeletで[startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。 +- `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。 - `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。 From 0d8f82180d7ae72abc10eb7a7e8141cb71c151b7 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 6 Apr 2020 18:29:06 +0900 Subject: [PATCH 006/290] update link to /ja/docs/concepts/overview/working-with-objects/labels/ --- content/ja/docs/concepts/configuration/assign-pod-node.md | 2 +- content/ja/docs/concepts/configuration/overview.md | 4 ++-- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- .../concepts/overview/working-with-objects/annotations.md | 2 +- .../ja/docs/concepts/overview/working-with-objects/labels.md | 4 ++-- content/ja/docs/concepts/storage/persistent-volumes.md | 2 +- content/ja/docs/concepts/workloads/controllers/deployment.md | 2 +- content/ja/docs/concepts/workloads/controllers/replicaset.md | 4 ++-- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- content/ja/docs/concepts/workloads/pods/podpreset.md | 2 +- 10 files changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md index 0dbde41861..572d54f4f7 100644 --- a/content/ja/docs/concepts/configuration/assign-pod-node.md +++ b/content/ja/docs/concepts/configuration/assign-pod-node.md @@ -8,7 +8,7 @@ weight: 30 {{% capture overview %}} [Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。 -これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/docs/concepts/overview/working-with-objects/labels/)です。 +これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 8255db692a..2259b6cb6e 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -58,7 +58,7 @@ weight: 10 ## ラベルの使用 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。 @@ -96,7 +96,7 @@ weight: 10 - `kubectl apply -f `を使いましょう。これを使うと、ディレクトリ内のすべての`.yaml`、`.yml`、および`.json`ファイルが`apply`に渡されます。 -- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。 +- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。 {{% /capture %}} diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 6299002ac6..2675eaf0c9 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -34,7 +34,7 @@ Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザ Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。 -[ラベル](/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。 +[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。 さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/annotations.md b/content/ja/docs/concepts/overview/working-with-objects/annotations.md index a169bdee03..c554311b6b 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ja/docs/concepts/overview/working-with-objects/annotations.md @@ -62,6 +62,6 @@ _アノテーション_ はキーとバリューのペアです。有効なア {{% /capture %}} {{% capture whatsnext %}} -[ラベルとセレクター](/docs/concepts/overview/working-with-objects/labels/)について学習してください。 +[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)について学習してください。 {{% /capture %}} diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 9d42742759..7afead6cb0 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -45,7 +45,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ これらは単によく使われるラベルの例です。ユーザーは自由に規約を決めることができます。 ラベルのキーは、ある1つのオブジェクトに対してユニークである必要があることは覚えておかなくてはなりません。 -## 構文と文字セット +## 構文と文字セット {#syntax-and-character-set} ラベルは、キーとバリューのベアです。正しいラベルキーは2つのセグメントを持ちます。 それは`/`によって分割されたオプショナルなプレフィックスと名前です。 @@ -59,7 +59,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ 正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。 -## ラベルセレクター +## ラベルセレクター {#label-selectors} [名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index d7969f7d99..3c0243791d 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -438,7 +438,7 @@ Podと同様に、クレームは特定の量のリソースを要求できま ### セレクター -クレームでは、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。 +クレームでは、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を指定して、ボリュームセットをさらにフィルター処理できます。ラベルがセレクターに一致するボリュームのみがクレームにバインドできます。セレクターは2つのフィールドで構成できます。 * `matchLabels` - ボリュームはこの値のラベルが必要です * `matchExpressions` - キー、値のリスト、およびキーと値を関連付ける演算子を指定することによって作成された要件のリスト。有効な演算子は、In、NotIn、ExistsおよびDoesNotExistです。 diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 3146606573..74b897af64 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -927,7 +927,7 @@ Podの必須フィールドに加えて、Deployment内のPodテンプレート ### セレクター {#selector} -`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)を指定します。 +`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)を指定します。 `.spec.selector`は`.spec.template.metadata.labels`と一致している必要があり、一致しない場合はAPIによって拒否されます。 diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index 3c20e295e6..32e758774a 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -203,7 +203,7 @@ Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが ### Pod セレクター -`.spec.selector`フィールドは[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)です。 +`.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。 [先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。 先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました ```shell @@ -309,7 +309,7 @@ PodをPodそれ自身で停止させたいような場合(例えば、バッチ ### ReplicationController ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/)の後継となるものです。 -この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。 +この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。 このように、ReplicaSetはReplicationControllerよりも好まれます。 {{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 07437b9847..729ddc491e 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -190,7 +190,7 @@ status: ... ``` -新しいPod Conditionは、Kubernetesの[label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 +新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 `kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、 新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。 diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 7638d63acb..1af2514c12 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -14,7 +14,7 @@ weight: 50 ## PodPresetを理解する `PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。 -ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 +ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 From 3e1f709cd3bb4fefab4e0c1a2fd0a1d3afd5a2cc Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 11 Apr 2020 21:36:43 +0900 Subject: [PATCH 007/290] update link to /ja/docs/concepts/overview/kubernetes-api/ --- content/ja/docs/concepts/overview/kubernetes-api.md | 2 +- .../overview/working-with-objects/kubernetes-objects.md | 2 +- content/ja/docs/reference/kubectl/cheatsheet.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index d7851d954b..b6f34cf141 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -86,7 +86,7 @@ APIとソフトウエアのバージョニングは、間接的にしか関連 - バージョン名は`vX`のようになっており、`X`は整数です。 - 安定版の機能は、今後のリリースバージョンにも適用されます。 -## APIグループ +## APIグループ {#api-groups} KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 81bee4ca68..0f5a291cbe 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -22,7 +22,7 @@ card: Kubernetesオブジェクトは"意図の記録"です。一度オブジェクトを作成すると、Kubernetesは常にそのオブジェクトが存在し続けるように動きます。オブジェクトを作成することで、Kubernetesに対し効果的にあなたのクラスターのワークロードがこのようになっていて欲しいと伝えているのです。これが、あなたのクラスターの**望ましい状態**です。 -Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。 +Kubernetesオブジェクトを操作するには、作成、変更、または削除に関わらず[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)を使う必要があるでしょう。例えば`kubectl`コマンドラインインターフェースを使った場合、このCLIが処理に必要なKubernetes API命令を、あなたに代わり発行します。あなたのプログラムから[クライアントライブラリ](/docs/reference/using-api/client-libraries/)を利用し、直接Kubernetes APIを利用することも可能です。 ### オブジェクトのspec（仕様）とstatus（状態） diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 9380b50c07..10827f6762 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -322,7 +322,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### リソースタイプ -サポートされているすべてのリソースタイプを、それらが[API group](/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。 +サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。 ```bash kubectl api-resources From 338763c74a064186200546f78ae4e2475f5c3781 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 12 Apr 2020 21:46:46 +0900 Subject: [PATCH 008/290] update link to /ja/docs/tutorials/stateless-application/expose-external-ip-address/ --- content/ja/docs/tutorials/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md index dfecf9f192..a696f5b705 100644 --- a/content/ja/docs/tutorials/_index.md +++ b/content/ja/docs/tutorials/_index.md @@ -29,7 +29,7 @@ content_template: templates/concept ## ステートレスアプリケーション -* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/ja/docs/tutorials/stateless-application/expose-external-ip-address/) * [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/docs/tutorials/stateless-application/guestbook/) From f4eab243f60eebf99cafffe6ffabbc7eb46c793a Mon Sep 17 00:00:00 2001 From: Pick1a1username <20301273+Pick1a1username@users.noreply.github.com> Date: Sun, 26 Apr 2020 11:43:44 +0900 Subject: [PATCH 009/290] ja translation updated based on 1.17 of en. --- .../working-with-objects/kubernetes-objects.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 0f5a291cbe..ef66f83878 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -26,7 +26,9 @@ Kubernetesオブジェクトを操作するには、作成、変更、または ### オブジェクトのspec（仕様）とstatus（状態） -全てのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それは *spec* オブジェクトと *status* オブジェクトです。*spec* オブジェクトはあなたが指定しなければならない項目で、オブジェクトの *望ましい状態* を記述し、オブジェクトに持たせたい特徴を表現します。*status* オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetesコントロールプレーンは、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。 +ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。 + +`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 @@ -58,15 +60,19 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 * `apiVersion` - どのバージョンのKubernetesAPIを利用してオブジェクトを作成するか * `kind` - どの種類のオブジェクトを作成するか -* `metadata` - オブジェクトを一意に特定するための情報、`name`、string、UID、また任意の`namespace`が該当する +* `metadata` - オブジェクトを一意に特定するための情報、文字列の`name`、`UID`、また任意の`namespace`が該当する +* `spec` - オブジェクトの望ましい状態 -またオブジェクトの`spec`の値も指定する必要があります。`spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関する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 API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。 * 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。 +* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。 {{% /capture %}} From 867f35573a7272b53a08c24a3c95ff825d0e63a7 Mon Sep 17 00:00:00 2001 From: Pick1a1username Date: Sun, 26 Apr 2020 12:58:51 +0900 Subject: [PATCH 010/290] ja translation updated based on 1.17 of en. --- .../overview/working-with-objects/kubernetes-objects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index ef66f83878..7911d3ea94 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -28,7 +28,7 @@ Kubernetesオブジェクトを操作するには、作成、変更、または ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。 -`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。常に、Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう積極的に管理をします。 +`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 From 56dd658391d565d4ebe6b5eaba38466854fe73ec Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 4 May 2020 12:09:01 +0900 Subject: [PATCH 011/290] update link to /ja/docs/concepts/overview/working-with-objects/kubernetes-objects/ --- content/ja/docs/concepts/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index a179d79113..4bddc5e520 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -26,7 +26,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使 ## Kubernetesオブジェクト -Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。 +Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。 基本的なKubernetesのオブジェクトは次のとおりです。 From bc0d46bc91a78cf0444b634bdde38629c6451711 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 5 May 2020 11:35:09 +0900 Subject: [PATCH 012/290] update link to /ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/ --- content/ja/docs/concepts/extend-kubernetes/operator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 08c173ddff..31a798620b 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -83,7 +83,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更 {{% capture whatsnext %}} -* [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます +* [Custom Resources](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます * ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます * 自前のオペレーターを書くために既存のツールを使います、例: * [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います From 0489f791c3c7507436228261d2d629b0a2227778 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 5 May 2020 14:21:50 +0900 Subject: [PATCH 013/290] Fix typo: rollinUpdate -> rollingUpdate in statefulset.md. --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index e16488b5b8..ad5048232f 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -175,9 +175,9 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe `OnDelete`というアップデートストラテジーは、レガシーな(Kubernetes1.6以前)振る舞いとなります。StatefulSetの`.spec.updateStrategy.type`が`OnDelete`にセットされていたとき、そのStatefulSetコントローラーはStatefulSet内でPodを自動的に更新しません。StatefulSetの`.spec.template`項目の修正を反映した新しいPodの作成をコントローラーに支持するためには、ユーザーは手動でPodを削除しなければなりません。 -### RollinUpdate +### RollingUpdate -`RollinUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。 +`RollingUpdate`というアップデートストラテジーは、StatefulSet内のPodに対する自動化されたローリングアップデートの機能を実装します。これは`.spec.updateStrategy`フィールドが未指定の場合のデフォルトのストラテジーです。StatefulSetの`.spec.updateStrategy.type`が`RollingUpdate`にセットされたとき、そのStatefulSetコントローラーは、StatefulSet内のPodを削除し、再作成します。これはPodの停止(Podの番号の降順)と同じ順番で、一度に1つのPodを更新します。コントローラーは、その前のPodの状態がRunningかつReady状態になるまで次のPodの更新を待ちます。 #### パーティション From 03dbe94df3c1b13253f59c42d9ff1ada2f39a51a Mon Sep 17 00:00:00 2001 From: yoshiki0705 Date: Tue, 5 May 2020 21:08:46 +0900 Subject: [PATCH 014/290] tasks/configure-pod-container/configure-pod-configmap/ --- .../configure-pod-configmap.md | 674 ++++++++++++++++++ .../configmap/configmap-multikeys.yaml | 8 + content/ja/examples/configmap/configmaps.yaml | 15 + .../pods/pod-configmap-env-var-valueFrom.yaml | 21 + .../examples/pods/pod-configmap-envFrom.yaml | 13 + .../pod-configmap-volume-specific-key.yaml | 20 + .../examples/pods/pod-configmap-volume.yaml | 18 + .../pod-multiple-configmap-env-variable.yaml | 21 + .../pod-single-configmap-env-variable.yaml | 19 + 9 files changed, 809 insertions(+) create mode 100644 content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md create mode 100644 content/ja/examples/configmap/configmap-multikeys.yaml create mode 100644 content/ja/examples/configmap/configmaps.yaml create mode 100644 content/ja/examples/pods/pod-configmap-env-var-valueFrom.yaml create mode 100644 content/ja/examples/pods/pod-configmap-envFrom.yaml create mode 100644 content/ja/examples/pods/pod-configmap-volume-specific-key.yaml create mode 100644 content/ja/examples/pods/pod-configmap-volume.yaml create mode 100644 content/ja/examples/pods/pod-multiple-configmap-env-variable.yaml create mode 100644 content/ja/examples/pods/pod-single-configmap-env-variable.yaml diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md new file mode 100644 index 0000000000..c0108142d5 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -0,0 +1,674 @@ +--- +title: Podを構成してConfigMapを使用する +content_template: templates/task +weight: 150 +card: + name: tasks + weight: 50 +--- + +{{% capture overview %}} +ConfigMapを使用すると、構成アーティファクトをイメージコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + + +## ConfigMapを作成する +`kubectl create configmap` コマンドまたはConfigMap generatorを`kustomization.yaml`ファイルで使ってConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 + +### kubectl create configmapコマンドを使用してConfigMapを作成する + +`kubectl create configmap`コマンドを使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、 [ファイル](#create-configmaps-from-files)、または [リテラル値](#create-configmaps-from-literal-values)から作成します: + +```shell +kubectl create configmap +``` + +\ の部分はConfigMapに割り当てる名前で、\ はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +ファイルを基にConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 + +[`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用して、ConfigMapに関する情報を取得できます。 + +#### ディレクトリからConfigMapを作成する + +`kubectl create configmap`を使用してConfigMapを同じディレクトリの複数のファイルから作成できます。ディレクトリを基にConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。レギュラーファイル以外のあらゆるディレクトリエントリーは無視されます。(例えば、サブディレクトリ、シンボリックリンク、デバイス、パイプなど). + +例えば: + +```shell +# ローカルディレクトリを作成します +mkdir -p configure-pod-container/configmap/ + +# `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします +wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties +wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties + +# ConfigMapを作成します +kubectl create configmap game-config --from-file=configure-pod-container/configmap/ +``` + +上記のコマンドは各ファイルを、この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化する。 以下のコマンドを使用してConfigMapの詳細を表示できます: + +```shell +kubectl describe configmaps game-config +``` + +出力結果は以下のようになります: +``` +Name: game-config +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +ui.properties: +---- +color.good=purple +color.bad=yellow +allow.textmode=true +how.nice.to.look=fairlyNice +``` + +`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties` ファイルはConfigMapの`data`セクションに表示されます。 + +```shell +kubectl get configmaps game-config -o yaml +``` +出力結果は以下のようになります: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T18:52:05Z + name: game-config + namespace: default + resourceVersion: "516" + uid: b4952dc3-d670-11e5-8cd0-68f728db1985 +data: + game.properties: | + enemies=aliens + lives=3 + enemies.cheat=true + enemies.cheat.level=noGoodRotten + secret.code.passphrase=UUDDLRLRBABAS + secret.code.allowed=true + secret.code.lives=30 + ui.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true + how.nice.to.look=fairlyNice +``` + +#### ファイルからConfigMapを作成する + +`kubectl create configmap`を使用して個別のファイルから、または複数のファイルからConfigMapを作成できます。 + +例えば、 + +```shell +kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties +``` + +以下のConfigMapを表示します: + +```shell +kubectl describe configmaps game-config-2 +``` + +出力結果は以下のようになります: + +``` +Name: game-config-2 +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +``` + +`--from-file`引数を複数回渡し、ConfigMapを複数のデータソースから作成できます。 + +```shell +kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties +``` + +ConfigMap`game-config-2`の詳細を以下のコマンドを使用して表示できます: + +```shell +kubectl describe configmaps game-config-2 +``` + +出力結果は以下のようになります: + +``` +Name: game-config-2 +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +ui.properties: +---- +color.good=purple +color.bad=yellow +allow.textmode=true +how.nice.to.look=fairlyNice +``` + +`--from-env-file`オプションを利用してConfigMapをenv-fileから作成します。例えば: + +```shell +# Env-filesは環境編集のリストを含んでいます。 +# 以下のシンタックスルールが適用されます: +# envファイルの各行はVAR=VALの形式である必要がある。 +# #で始まる行 (例えばコメント)は無視される。 +# 空の行は無視される。 +# クオーテーションマークは特別な扱いは処理をしない (例えばConfigMapの値になる). + +# `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします +wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties + +# env-file `game-env-file.properties`は以下のように見えます +cat configure-pod-container/configmap/game-env-file.properties +enemies=aliens +lives=3 +allowed="true" + +# このコメントと上記の空の行は無視されます +``` + +```shell +kubectl create configmap game-config-env-file \ + --from-env-file=configure-pod-container/configmap/game-env-file.properties +``` + +以下のConfigMapを表示します: + +```shell +kubectl get configmap game-config-env-file -o yaml +``` + +出力結果は以下の様になります: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2017-12-27T18:36:28Z + name: game-config-env-file + namespace: default + resourceVersion: "809965" + uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8 +data: + allowed: '"true"' + enemies: aliens + lives: "3" +``` + +{{< caution >}} +`--from-env-file`を複数回渡してConfigMapを複数のデータソースから作成する場合、最後のenv-fileのみが使用されます。 +{{< /caution >}} + +`--from-env-file`を複数回渡す場合の挙動は以下のように示されます: + +```shell +# `configure-pod-container/configmap/`ディレクトリにサンブルファイルをダウンロードします +wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties + +# ConfigMapを作成します +kubectl create configmap config-multi-env-files \ + --from-env-file=configure-pod-container/configmap/game-env-file.properties \ + --from-env-file=configure-pod-container/configmap/ui-env-file.properties +``` + +以下のConfigMapを表示します: + +```shell +kubectl get configmap config-multi-env-files -o yaml +``` + +出力結果は以下のようになります: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2017-12-27T18:38:34Z + name: config-multi-env-files + namespace: default + resourceVersion: "810136" + uid: 252c4572-eb35-11e7-887b-42010a8002b8 +data: + color: purple + how: fairlyNice + textmode: "true" +``` + +#### ファイルからConfigMap作成する場合は使用するキーを定義する + +`--from-file`引数を使用する場合、ConfigMapの`data` セクションでキーにファイル名以外を定義できます: + +```shell +kubectl create configmap game-config-3 --from-file== +``` + +``の部分はConfigMapで使うキー、`` はキーで表示したいデータソースファイルの場所です。 + +例えば: + +```shell +kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties +``` + +以下のConfigMapを表示します: +``` +kubectl get configmaps game-config-3 -o yaml +``` + +出力結果は以下のようになります: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T18:54:22Z + name: game-config-3 + namespace: default + resourceVersion: "530" + uid: 05f8da22-d671-11e5-8cd0-68f728db1985 +data: + game-special-key: | + enemies=aliens + lives=3 + enemies.cheat=true + enemies.cheat.level=noGoodRotten + secret.code.passphrase=UUDDLRLRBABAS + secret.code.allowed=true + secret.code.lives=30 +``` + +#### リテラル値からConfigMapを作成する + +`kubectl create configmap`を`--from-literal`引数と使用してCLIからリテラル値を定義できます: + +```shell +kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm +``` + +複数のキーバリューペアを渡せます。CLIに提供された各ペアは、ConfigMapの`data`セクションで別のエントリーとして表示されます。 + +```shell +kubectl get configmaps special-config -o yaml +``` + +出力結果は以下のようになります: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T19:14:38Z + name: special-config + namespace: default + resourceVersion: "651" + uid: dadce046-d673-11e5-8cd0-68f728db1985 +data: + special.how: very + special.type: charm +``` + +### ジェネレータからConfigMapを作成する +`kubectl`は`kustomization.yaml`を1.14からサポートしています。 +ジェネレータからConfigMapを作成し、APIサーバー上でオブジェクトを作成できる。ジェネレータはディレクトリ内の`kustomization.yaml`で指定する必要がある。 + +#### ファイルからConfigMapを生成する +例えば、ファイル`configure-pod-container/configmap/game.properties`からConfigMapを生成するには、 +```shell +# ConfigMapGeneratorでkustomization.yamlファイルを作成する +cat <./kustomization.yaml +configMapGenerator: +- name: game-config-4 + files: + - configure-pod-container/configmap/game.properties +EOF +``` + +ConfigMapオブジェクトを作成する為にkustomizationディレクトリを適用し、 +```shell +kubectl apply -k . +configmap/game-config-4-m9dm2f92bt created +``` + +ConfigMapが作成されたことを以下のようにチェックできます: + +```shell +kubectl get configmap +NAME DATA AGE +game-config-4-m9dm2f92bt 1 37s + + +kubectl describe configmaps/game-config-4-m9dm2f92bt +Name: game-config-4-m9dm2f92bt +Namespace: default +Labels: +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p... + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +Events: +``` + +生成されたConfigMapの名前はコンテンツをハッシュさせて追加されたサフィックスを持つことに注意してください。これにより、コンテンツが変更されるたびに新しいConfigMapが生成されます。 + +#### ファイルからConfigMapを生成する場合に使用するキーを定義する +ConfigMapジェネレータで使用するキーはファイルの名前以外を定義できます。 +例えば、 ファイル`configure-pod-container/configmap/game.properties`とキー`game-special-key`を使用してConfigMapを作成する場合 + +```shell +# ConfigMapGeneratorでkustomization.yamlファイルを作成する +cat <./kustomization.yaml +configMapGenerator: +- name: game-config-5 + files: + - game-special-key=configure-pod-container/configmap/game.properties +EOF +``` + +kustomizationディレクトリを適用してConfigMapオブジェクトを作成します。 +```shell +kubectl apply -k . +configmap/game-config-5-m67dt67794 created +``` + +#### リテラルからConfigMapを作成する +To generate a ConfigMap from literals `special.type=charm` and `special.how=very`, +you can specify the ConfigMap generator in `kustomization.yaml` as +```shell +# kustomization.yamlファイルをConfigMapGeneratorと作成する +cat <./kustomization.yaml +configMapGenerator: +- name: special-config-2 + literals: + - special.how=very + - special.type=charm +EOF +``` +kustomizationディレクトリを適用してConfigMapオブジェクトを作成します。 +```shell +kubectl apply -k . +configmap/special-config-2-c92b5mmcf2 created +``` + +## ConfigMapデータを使用してコンテナ環境変数を定義する + +### 単一のConfigMapのデータを使用してコンテナ環境変数を定義する + +1. ConfigMapに環境変数をキーバリューペアとして定義する: + + ```shell + kubectl create configmap special-config --from-literal=special.how=very + ``` + +2. ConfigMapに定義された値`special.how`をPod specificationの環境変数`SPECIAL_LEVEL_KEY`に割り当てる。 + + {{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}} + + Podを作成します: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml + ``` + + すると、Podの出力結果に環境変数`SPECIAL_LEVEL_KEY=very`が含まれています。 + +### 複数のConfigMapのデータを使用してコンテナ環境変数を定義する + + * 先ほどの例の通り、まずはConfigMapを作成します。 + + {{< codenew file="configmap/configmaps.yaml" >}} + + ConfigMapを作成します: + + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml + ``` + +* Pod specificationの環境変数を定義する + + {{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}} + + Podを作成します: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml + ``` + すると、Podの出力結果に環境変数`SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`が含まれています。 + +## ConfigMapの全てのキーバリューペアをコンテナ環境変数として構成する + +{{< note >}} +この機能はKubernetes v1.6以降で利用可能です。 +{{< /note >}} + +* 複数のキーバリューペアを含むConfigMapを作成します。 + + {{< codenew file="configmap/configmap-multikeys.yaml" >}} + + ConfigMapを作成します: + + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml + ``` + +* `envFrom`を利用して全てのConfigMapのデータをコンテナ環境変数として定義します。ConfigMapからのキーがPodの環境変数名になります。 + + {{< codenew file="pods/pod-configmap-envFrom.yaml" >}} + + Podを作成します: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml + ``` + + すると、Podの出力結果は環境変数`SPECIAL_LEVEL=very`と`SPECIAL_TYPE=charm`が含まれています。 + + +## PodのコマンドでConfigMapに定義した環境変数を使用する + +ConfigMapに環境変数を定義し、Pod specificationの`command` セクションで`$(VAR_NAME)`Kubernetes置換構文を介して使用できます。 + +例えば以下のPod specificationは + +{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}} + +以下コマンドの実行で作成され、 + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml +``` + +`test-container`コンテナで以下の出力結果を表示します: + +```shell +very charm +``` + +## ボリュームにConfigMapデータを追加する + +[ファイルからConfigMapを作成する](#create-configmaps-from-files)で説明したように、``--from-file``を使用してConfigMapを作成する場合は、ファイル名がConfigMapの`data`セクションに保存されるキーになり、ファイルのコンテンツがキーの値になります。 + +このセクションの例は以下に示されているspecial-configと名付けれたConfigMapについて言及したものです。 + +{{< codenew file="configmap/configmap-multikeys.yaml" >}} + +ConfigMapを作成します: + +```shell +kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml +``` + +### ConfigMapに保存されているデータをボリュームに入力する + +ConfigMap名をPod specificationの`volumes`セクション配下に追加します。 +これによりConfigMapデータが`volumeMounts.mountPath`で指定されたディレクトリに追加されます (このケースでは、`/etc/config`に)。`command`セクションはConfigMapのキーに合致したディレクトリファイルを名前別でリスト表示します。 + +{{< codenew file="pods/pod-configmap-volume.yaml" >}} + +Podを作成します: + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml +``` + +Podが稼働していると、`ls /etc/config/`コマンドは以下の出力結果を表示します: + +```shell +SPECIAL_LEVEL +SPECIAL_TYPE +``` + +{{< caution >}} +`/etc/config/`ディレクトリに何かファイルがある場合、それらは削除されます。 +{{< /caution >}} + +### ConfigMapデータをボリュームの特定のパスに追加する + +`path`フィルドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。 +このケースでは`SPECIAL_LEVEL`アイテムが`/etc/config/keys`の`config-volume`ボリュームにマウントされます。 + +{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}} + +Podを作成します: + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml +``` + +Podが稼働していると、 `cat /etc/config/keys`コマンドは以下の出力結果を表示します: + +```shell +very +``` + +{{< caution >}} +先ほどのように、`/etc/config/` ディレクトリのこれまでのファイルは全て削除されます +{{< /caution >}} + +### キーを特定のパスとファイルアクセス許可に投影する + +キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。 + +### マウントされたConfigMapは自動的に更新される + +ボリュームで使用されているConfigMapが更新されている場合、投影されているキーも同じく結果的に更新されます。Kubeletは定期的な同期ごとにマウントされているConfigMapが更新されているかチェックします。しかし、これはローカルのttlを基にしたキャッシュでConfigMapの現在の値を取得しています。その結果、新しいキーがPodに投影されてからConfigMapに更新されるまでのトータルの遅延はkubeletで、kubeletの同期期間(デフォルトで1分) + ConfigMapキャッシュのttl(デフォルトで1分)の長さになる可能性があります。Podのアノテーションを1つ更新すると即時のリフレッシュをトリガーできます。 + +{{< note >}} +ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュームとして利用するコンテナはConfigMapの更新を受け取りません。 +{{< /note >}} + +{{% /capture %}} + +{{% capture discussion %}} + +## ConfigMapとPodsを理解する + +ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secrets](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。 + +{{< note >}} +ConfigMapはプロパティファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。 +{{< /note >}} + +ConfigMapの`data`フィールドは構成情報を含みます。下記の例のようにシンプルに`--from-literal`を使用して個別のプロパティーを定義、または複雑に`--from-file`を使用して構成ファイルまたはJSON blobsで定義できます。 + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T19:14:38Z + name: example-config + namespace: default +data: + # --from-literalを使用してシンプルにプロパティーを定義する例 + example.property.1: hello + example.property.2: world + # --from-fileを使用して複雑にプロパティーを定義する例 + example.property.file: |- + property.1=value-1 + property.2=value-2 + property.3=value-3 +``` + +### 制限事項 + +- ConfigMapはPod specificationを参照させる前に作成する必要があります (ConfigMapを"optional"として設定しない限り)。存在しないConfigMapを参照させた場合、Podは起動しません。同様にConfigMapに存在しないキーを参照させた場合も、Podは起動しません。 + +- ConfigMapで`envFrom`を使用して環境変数を定義した場合、無効と判断されたキーはスキップされます。Podは起動されますが、無効な名前はイベントログに(`InvalidVariableNames`)と記録されます。ログメッセージはスキップされたキーごとにリスト表示されます。例えば: + + ```shell + kubectl get events + ``` + + 出力結果は以下のようになります: + ``` + LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE + 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. + ``` + +- ConfigMapは特定の{{< glossary_tooltip term_id="namespace" >}}に属します。ConfigMap同じ名前空間に属するPodからのみ参照できます。 + +- {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていない為、ConfigMapに使用できません。 + +{{% /capture %}} + +{{% capture whatsnext %}} +* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。 + +{{% /capture %}} diff --git a/content/ja/examples/configmap/configmap-multikeys.yaml b/content/ja/examples/configmap/configmap-multikeys.yaml new file mode 100644 index 0000000000..289702d123 --- /dev/null +++ b/content/ja/examples/configmap/configmap-multikeys.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: special-config + namespace: default +data: + SPECIAL_LEVEL: very + SPECIAL_TYPE: charm diff --git a/content/ja/examples/configmap/configmaps.yaml b/content/ja/examples/configmap/configmaps.yaml new file mode 100644 index 0000000000..91b9f29755 --- /dev/null +++ b/content/ja/examples/configmap/configmaps.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: special-config + namespace: default +data: + special.how: very +--- +apiVersion: v1 +kind: ConfigMap +metadata: + name: env-config + namespace: default +data: + log_level: INFO diff --git a/content/ja/examples/pods/pod-configmap-env-var-valueFrom.yaml b/content/ja/examples/pods/pod-configmap-env-var-valueFrom.yaml new file mode 100644 index 0000000000..a72b4335ce --- /dev/null +++ b/content/ja/examples/pods/pod-configmap-env-var-valueFrom.yaml @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: SPECIAL_LEVEL + - name: SPECIAL_TYPE_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: SPECIAL_TYPE + restartPolicy: Never diff --git a/content/ja/examples/pods/pod-configmap-envFrom.yaml b/content/ja/examples/pods/pod-configmap-envFrom.yaml new file mode 100644 index 0000000000..70ae7e5bcf --- /dev/null +++ b/content/ja/examples/pods/pod-configmap-envFrom.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - configMapRef: + name: special-config + restartPolicy: Never diff --git a/content/ja/examples/pods/pod-configmap-volume-specific-key.yaml b/content/ja/examples/pods/pod-configmap-volume-specific-key.yaml new file mode 100644 index 0000000000..72e38fd836 --- /dev/null +++ b/content/ja/examples/pods/pod-configmap-volume-specific-key.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh","-c","cat /etc/config/keys" ] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + name: special-config + items: + - key: SPECIAL_LEVEL + path: keys + restartPolicy: Never diff --git a/content/ja/examples/pods/pod-configmap-volume.yaml b/content/ja/examples/pods/pod-configmap-volume.yaml new file mode 100644 index 0000000000..10bc581ce6 --- /dev/null +++ b/content/ja/examples/pods/pod-configmap-volume.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "ls /etc/config/" ] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + # コンテナに追加するファイルを含むConfigMapの名前を提供する + name: special-config + restartPolicy: Never diff --git a/content/ja/examples/pods/pod-multiple-configmap-env-variable.yaml b/content/ja/examples/pods/pod-multiple-configmap-env-variable.yaml new file mode 100644 index 0000000000..4790a9c661 --- /dev/null +++ b/content/ja/examples/pods/pod-multiple-configmap-env-variable.yaml @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: special.how + - name: LOG_LEVEL + valueFrom: + configMapKeyRef: + name: env-config + key: log_level + restartPolicy: Never diff --git a/content/ja/examples/pods/pod-single-configmap-env-variable.yaml b/content/ja/examples/pods/pod-single-configmap-env-variable.yaml new file mode 100644 index 0000000000..83f6a02b88 --- /dev/null +++ b/content/ja/examples/pods/pod-single-configmap-env-variable.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + # 環境変数を定義します + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + # SPECIAL_LEVEL_KEYに割り当てる値をConfigMapが保持します + name: special-config + # 値に紐付けるキーを指定します + key: special.how + restartPolicy: Never From 389e7b00507e6219651d4753362d42a4c21bc98a Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 6 May 2020 14:42:59 +0900 Subject: [PATCH 015/290] update link to /ja/docs/tasks/run-application/force-delete-stateful-set-pod/ --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- content/ja/docs/concepts/workloads/pods/pod.md | 2 +- content/ja/docs/tasks/run-application/delete-stateful-set.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index e16488b5b8..ad199ae2d7 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -151,7 +151,7 @@ StatefulSetのコントローラーがPodを作成したとき、Podの名前と * Podに対してスケーリングオプションが適用される前に、そのPodの前の順番の全てのPodがRunningかつReady状態になっていなくてはなりません。 * Podが停止される前に、そのPodの番号より大きい番号を持つの全てのPodは完全にシャットダウンされていなくてはなりません。 -StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 +StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。 diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index aa6e6f7199..e0d9c951b4 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -162,7 +162,7 @@ API内のPodは直ちに削除されるため、新しいPodを同じ名前で Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 -StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 +StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 ## Podコンテナの特権モード diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md index d6f7d981e4..d8d6b8c89a 100644 --- a/content/ja/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md @@ -72,13 +72,13 @@ kubectl delete pvc -l app=myapp ### StatefulSet Podの強制削除 -StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 +StatefulSet内の一部のPodが長期間`Terminating`または`Unknown`状態のままになっていることが判明した場合は、手動でapiserverからPodを強制的に削除する必要があります。これは潜在的に危険な作業です。詳細は[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 {{% /capture %}} {{% capture whatsnext %}} -[StatefulSet Podの強制削除](/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細 +[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)の詳細 {{% /capture %}} From ea0997dc9ef60d4629d6703b002e1a04b4bd46a4 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 6 May 2020 14:46:29 +0900 Subject: [PATCH 016/290] update link to /ja/docs/tasks/run-application/run-stateless-application-deployment/ --- content/ja/docs/concepts/services-networking/ingress.md | 2 +- content/ja/docs/setup/production-environment/turnkey/aws.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index 7fd3a81bab..6a8c17587f 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -74,7 +74,7 @@ spec: servicePort: 80 ``` -他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。 +他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。 Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。 [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。 diff --git a/content/ja/docs/setup/production-environment/turnkey/aws.md b/content/ja/docs/setup/production-environment/turnkey/aws.md index 5367103984..28a91ae324 100644 --- a/content/ja/docs/setup/production-environment/turnkey/aws.md +++ b/content/ja/docs/setup/production-environment/turnkey/aws.md @@ -52,7 +52,7 @@ export PATH=/platforms/linux/amd64:$PATH ### 例 -新しいクラスターを試すには、[簡単なnginxの例](/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。 +新しいクラスターを試すには、[簡単なnginxの例](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。 "Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) From 17a1008a5341103ace5913ac79e82dc1e29f87e9 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 6 May 2020 14:48:49 +0900 Subject: [PATCH 017/290] update link to /ja/docs/tasks/configure-pod-container/assign-memory-resource/ --- .../docs/tasks/configure-pod-container/assign-cpu-resource.md | 2 +- .../docs/tasks/configure-pod-container/quality-service-pod.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index f88e5e1f10..f2928bc9f4 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -214,7 +214,7 @@ kubectl delete namespace cpu-example ### アプリケーション開発者向け -* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/) +* [コンテナとPodにメモリーリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) * [PodのQuality of Serviceを設定する](/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md index f2a4edb2ee..c286699744 100644 --- a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md @@ -229,7 +229,7 @@ kubectl delete namespace qos-example ### アプリケーション開発者向け -* [コンテナとPodにメモリーリソースを割り当てる](/docs/tasks/configure-pod-container/assign-memory-resource/) +* [コンテナとPodにメモリーリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) * [コンテナとPodにCPUリソースを割り当てる](/docs/tasks/configure-pod-container/assign-cpu-resource/) From 6ee1a0574a9d5e1491bea9ec4cc07d37573abab3 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 6 May 2020 18:40:55 +0900 Subject: [PATCH 018/290] modify link target page title --- .../docs/tasks/configure-pod-container/assign-cpu-resource.md | 2 +- .../docs/tasks/configure-pod-container/quality-service-pod.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index f2928bc9f4..4c61c05a1c 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -214,7 +214,7 @@ kubectl delete namespace cpu-example ### アプリケーション開発者向け -* [コンテナとPodにメモリーリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) +* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) * [PodのQuality of Serviceを設定する](/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md index c286699744..346ce57a92 100644 --- a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md @@ -229,7 +229,7 @@ kubectl delete namespace qos-example ### アプリケーション開発者向け -* [コンテナとPodにメモリーリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) +* [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) * [コンテナとPodにCPUリソースを割り当てる](/docs/tasks/configure-pod-container/assign-cpu-resource/) From f05cfb2f13192221f711d636527fd863b42f3070 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Thu, 7 May 2020 01:00:32 +0900 Subject: [PATCH 019/290] Revised the points should be better --- .../configure-pod-configmap.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index c0108142d5..22547afa43 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -39,7 +39,7 @@ kubectl create configmap [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用して、ConfigMapに関する情報を取得できます。 -#### ディレクトリからConfigMapを作成する +#### ディレクトリからConfigMapを作成する{#create-configmaps-from-directories} `kubectl create configmap`を使用してConfigMapを同じディレクトリの複数のファイルから作成できます。ディレクトリを基にConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。レギュラーファイル以外のあらゆるディレクトリエントリーは無視されます。(例えば、サブディレクトリ、シンボリックリンク、デバイス、パイプなど). @@ -57,7 +57,7 @@ wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-con kubectl create configmap game-config --from-file=configure-pod-container/configmap/ ``` -上記のコマンドは各ファイルを、この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化する。 以下のコマンドを使用してConfigMapの詳細を表示できます: +上記のコマンドは各ファイルを、この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化します。 以下のコマンドを使用してConfigMapの詳細を表示できます: ```shell kubectl describe configmaps game-config @@ -121,7 +121,7 @@ data: how.nice.to.look=fairlyNice ``` -#### ファイルからConfigMapを作成する +#### ファイルからConfigMapを作成する{#create-configmaps-from-files} `kubectl create configmap`を使用して個別のファイルから、または複数のファイルからConfigMapを作成できます。 @@ -230,7 +230,7 @@ kubectl create configmap game-config-env-file \ kubectl get configmap game-config-env-file -o yaml ``` -出力結果は以下の様になります: +出力結果は以下のようになります: ```yaml apiVersion: v1 kind: ConfigMap @@ -326,7 +326,7 @@ data: secret.code.lives=30 ``` -#### リテラル値からConfigMapを作成する +#### リテラル値からConfigMapを作成する{#create-configmaps-from-literal-values} `kubectl create configmap`を`--from-literal`引数と使用してCLIからリテラル値を定義できます: @@ -357,7 +357,7 @@ data: ### ジェネレータからConfigMapを作成する `kubectl`は`kustomization.yaml`を1.14からサポートしています。 -ジェネレータからConfigMapを作成し、APIサーバー上でオブジェクトを作成できる。ジェネレータはディレクトリ内の`kustomization.yaml`で指定する必要がある。 +ジェネレータからConfigMapを作成し、APIサーバー上でオブジェクトを作成できます。ジェネレータはディレクトリ内の`kustomization.yaml`で指定する必要があリます。 #### ファイルからConfigMapを生成する 例えば、ファイル`configure-pod-container/configmap/game.properties`からConfigMapを生成するには、 @@ -410,7 +410,7 @@ Events: #### ファイルからConfigMapを生成する場合に使用するキーを定義する ConfigMapジェネレータで使用するキーはファイルの名前以外を定義できます。 -例えば、 ファイル`configure-pod-container/configmap/game.properties`とキー`game-special-key`を使用してConfigMapを作成する場合 +例えば、ファイル`configure-pod-container/configmap/game.properties`とキー`game-special-key`を使用してConfigMapを作成する場合 ```shell # ConfigMapGeneratorでkustomization.yamlファイルを作成する @@ -432,7 +432,7 @@ configmap/game-config-5-m67dt67794 created To generate a ConfigMap from literals `special.type=charm` and `special.how=very`, you can specify the ConfigMap generator in `kustomization.yaml` as ```shell -# kustomization.yamlファイルをConfigMapGeneratorと作成する +# kustomization.yamlファイルをConfigMapGeneratorと作成します cat <./kustomization.yaml configMapGenerator: - name: special-config-2 @@ -451,13 +451,13 @@ configmap/special-config-2-c92b5mmcf2 created ### 単一のConfigMapのデータを使用してコンテナ環境変数を定義する -1. ConfigMapに環境変数をキーバリューペアとして定義する: +1. ConfigMapに環境変数をキーバリューペアとして定義します: ```shell kubectl create configmap special-config --from-literal=special.how=very ``` -2. ConfigMapに定義された値`special.how`をPod specificationの環境変数`SPECIAL_LEVEL_KEY`に割り当てる。 +2. ConfigMapに定義された値`special.how`をPod specificationの環境変数`SPECIAL_LEVEL_KEY`に割り当てます。 {{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}} From e46b99218fccef9382f879d37667c4b068d7cd38 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Thu, 7 May 2020 08:35:31 +0900 Subject: [PATCH 020/290] Revised the translation of configuration artifacts --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 22547afa43..8686e0146b 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -8,7 +8,7 @@ card: --- {{% capture overview %}} -ConfigMapを使用すると、構成アーティファクトをイメージコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。 +ConfigMapを使用すると、設定をイメージコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。 {{% /capture %}} From cf377d9cbb8a10efdcab1185d68a66436601653a Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Thu, 7 May 2020 09:44:18 +0900 Subject: [PATCH 021/290] Revised found inappropriate Spaces and desinence --- .../configure-pod-configmap.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 8686e0146b..71df04f399 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -22,7 +22,7 @@ ConfigMapを使用すると、設定をイメージコンテンツから切り ## ConfigMapを作成する -`kubectl create configmap` コマンドまたはConfigMap generatorを`kustomization.yaml`ファイルで使ってConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 +`kubectl create configmap`コマンドまたはConfigMap generatorを`kustomization.yaml`ファイルで使ってConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 ### kubectl create configmapコマンドを使用してConfigMapを作成する @@ -32,7 +32,7 @@ ConfigMapを使用すると、設定をイメージコンテンツから切り kubectl create configmap ``` -\ の部分はConfigMapに割り当てる名前で、\ はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 ファイルを基にConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 @@ -41,7 +41,7 @@ kubectl create configmap #### ディレクトリからConfigMapを作成する{#create-configmaps-from-directories} -`kubectl create configmap`を使用してConfigMapを同じディレクトリの複数のファイルから作成できます。ディレクトリを基にConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。レギュラーファイル以外のあらゆるディレクトリエントリーは無視されます。(例えば、サブディレクトリ、シンボリックリンク、デバイス、パイプなど). +`kubectl create configmap`を使用してConfigMapを同じディレクトリの複数のファイルから作成できます。ディレクトリを基にConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。レギュラーファイル以外のあらゆるディレクトリエントリーは無視されます。(例えば、サブディレクトリ、シンボリックリンク、デバイス、パイプなど)。 例えば: @@ -205,7 +205,7 @@ how.nice.to.look=fairlyNice # envファイルの各行はVAR=VALの形式である必要がある。 # #で始まる行 (例えばコメント)は無視される。 # 空の行は無視される。 -# クオーテーションマークは特別な扱いは処理をしない (例えばConfigMapの値になる). +# クオーテーションマークは特別な扱いは処理をしない(例えばConfigMapの値になる). # `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties @@ -371,7 +371,7 @@ configMapGenerator: EOF ``` -ConfigMapオブジェクトを作成する為にkustomizationディレクトリを適用し、 +ConfigMapオブジェクトを作成する為にkustomizationディレクトリを適用して、 ```shell kubectl apply -k . configmap/game-config-4-m9dm2f92bt created @@ -481,7 +481,7 @@ configmap/special-config-2-c92b5mmcf2 created kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml ``` -* Pod specificationの環境変数を定義する +* Pod specificationの環境変数を定義します {{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}} @@ -557,7 +557,7 @@ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.y ### ConfigMapに保存されているデータをボリュームに入力する -ConfigMap名をPod specificationの`volumes`セクション配下に追加します。 +ConfigMap名をPod specificationの`volumes`セクション配下に追加します。 これによりConfigMapデータが`volumeMounts.mountPath`で指定されたディレクトリに追加されます (このケースでは、`/etc/config`に)。`command`セクションはConfigMapのキーに合致したディレクトリファイルを名前別でリスト表示します。 {{< codenew file="pods/pod-configmap-volume.yaml" >}} @@ -648,7 +648,7 @@ data: ### 制限事項 -- ConfigMapはPod specificationを参照させる前に作成する必要があります (ConfigMapを"optional"として設定しない限り)。存在しないConfigMapを参照させた場合、Podは起動しません。同様にConfigMapに存在しないキーを参照させた場合も、Podは起動しません。 +- ConfigMapはPod specificationを参照させる前に作成する必要があります(ConfigMapを"optional"として設定しない限り)。存在しないConfigMapを参照させた場合、Podは起動しません。同様にConfigMapに存在しないキーを参照させた場合も、Podは起動しません。 - ConfigMapで`envFrom`を使用して環境変数を定義した場合、無効と判断されたキーはスキップされます。Podは起動されますが、無効な名前はイベントログに(`InvalidVariableNames`)と記録されます。ログメッセージはスキップされたキーごとにリスト表示されます。例えば: From 38b08a452455fd437653c39fd3bf2f71938d8a6b Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 11 May 2020 15:17:15 +0900 Subject: [PATCH 022/290] Translate setup/production-environment/tools/kubeadm/ha-topology.md into Japanese. --- .../tools/kubeadm/ha-topology.md | 55 ++++++++----------- 1 file changed, 22 insertions(+), 33 deletions(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md index 429a37f440..a0c5319afe 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -1,69 +1,58 @@ --- -title: Options for Highly Available topology +title: 高可用性トポロジーのためのオプション content_template: templates/concept weight: 50 --- {{% capture overview %}} -This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters. +このページでは、高可用性(HA)Kubernetesクラスターのトポロジーを設定するための2つのオプションについて説明します。 -You can set up an HA cluster: +HAクラスターは次の方法で設定できます。 -- With stacked control plane nodes, where etcd nodes are colocated with control plane nodes -- With external etcd nodes, where etcd runs on separate nodes from the control plane +- 積み重なったコントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。 +- 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。 -You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster. +HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。 {{% /capture %}} {{% capture body %}} -## Stacked etcd topology +## 積み重なったetcdトポロジー -A stacked HA cluster is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed -data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by -kubeadm that run control plane components. +積み重なったHAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 -Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. -The `kube-apiserver` is exposed to worker nodes using a load balancer. +各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。 -Each control plane node creates a local etcd member and this etcd member communicates only with -the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager` -and `kube-scheduler` instances. +各コントロールプレーンノードはローカルのetcdメンバーを作り、このetcdメンバーはそのノードの`kube-apiserver`とだけ通信します。ローカルの`kube-controller-manager`と`kube-scheduler`のインスタンスも同様です。 -This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster -with external etcd nodes, and simpler to manage for replication. +このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。 -However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control -plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes. +しかし、積み重なったクラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。 -You should therefore run a minimum of three stacked control plane nodes for an HA cluster. +そのため、HAクラスターのためには、最低でも3台の積み重なったコントロールプレーンノードを実行しなければなりません。 -This is the default topology in kubeadm. A local etcd member is created automatically -on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`. +これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。 -![Stacked etcd topology](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) +![積み重なったetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) -## External etcd topology +## 外部のetcdトポロジー -An HA cluster with external etcd is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components. +外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 -Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. And the `kube-apiserver` is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the `kube-apiserver` of each control plane node. +積み重なったetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 -This topology decouples the control plane and etcd member. It therefore provides an HA setup where -losing a control plane instance or an etcd member has less impact and does not affect -the cluster redundancy as much as the stacked HA topology. +このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積み重なったHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。 -However, this topology requires twice the number of hosts as the stacked HA topology. -A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology. +しかし、このトポロジーでは積み重なったHAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。 -![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) +![外部のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) {{% /capture %}} {{% capture whatsnext %}} -- [Set up a highly available cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/) +- [kubeadmを使用した高可用性クラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/) {{% /capture %}} From 0c4656779c6e444c74c6760278472f96c04e9608 Mon Sep 17 00:00:00 2001 From: Anorlondo448 Date: Mon, 11 May 2020 15:48:42 +0900 Subject: [PATCH 023/290] fix typo --- content/ja/docs/concepts/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/_index.md b/content/ja/docs/concepts/_index.md index 4bddc5e520..5075258bf2 100644 --- a/content/ja/docs/concepts/_index.md +++ b/content/ja/docs/concepts/_index.md @@ -15,7 +15,7 @@ weight: 40 ## 概要 -Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired sate (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。 +Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired state (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。 一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。 From 7e783a63d82257affd0120dbe8316f7ca200bd76 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 20:54:20 +0900 Subject: [PATCH 024/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 修正内容が凄いしっくりきます！ Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 71df04f399..3465b2fcb3 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -406,7 +406,7 @@ secret.code.lives=30 Events: ``` -生成されたConfigMapの名前はコンテンツをハッシュさせて追加されたサフィックスを持つことに注意してください。これにより、コンテンツが変更されるたびに新しいConfigMapが生成されます。 +生成されたConfigMapの名前は、コンテンツをハッシュ化したサフィックスを持つことに注意してください。これにより、コンテンツが変更されるたびに新しいConfigMapが生成されます。 #### ファイルからConfigMapを生成する場合に使用するキーを定義する ConfigMapジェネレータで使用するキーはファイルの名前以外を定義できます。 From 8c7923520c45ba000ba953e2648baec8df1156e5 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 20:58:06 +0900 Subject: [PATCH 025/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Great！ Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 3465b2fcb3..fa0f5d6b86 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -41,7 +41,7 @@ kubectl create configmap #### ディレクトリからConfigMapを作成する{#create-configmaps-from-directories} -`kubectl create configmap`を使用してConfigMapを同じディレクトリの複数のファイルから作成できます。ディレクトリを基にConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。レギュラーファイル以外のあらゆるディレクトリエントリーは無視されます。(例えば、サブディレクトリ、シンボリックリンク、デバイス、パイプなど)。 +`kubectl create configmap`を使用すると、同一ディレクトリ内にある複数のファイルから1つのConfigMapを作成できます。ディレクトリをベースにConfigMapを作成する場合、kubectlはディレクトリ内でベース名が有効なキーであるファイルを識別し、それらのファイルを新たなConfigMapにパッケージ化します。ディレクトリ内にある通常のファイルでないものは無視されます(例: サブディレクトリ、シンボリックリンク、デバイス、パイプなど)。 例えば: From 3775a1b1df983e052dc455f58d9db2f451517fb0 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 20:58:21 +0900 Subject: [PATCH 026/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index fa0f5d6b86..34fe0a1e4f 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -26,7 +26,7 @@ ConfigMapを使用すると、設定をイメージコンテンツから切り ### kubectl create configmapコマンドを使用してConfigMapを作成する -`kubectl create configmap`コマンドを使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、 [ファイル](#create-configmaps-from-files)、または [リテラル値](#create-configmaps-from-literal-values)から作成します: +`kubectl create configmap`コマンドを使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、[ファイル](#create-configmaps-from-files)、または[リテラル値](#create-configmaps-from-literal-values)から作成します: ```shell kubectl create configmap From 8c0ab9c9b40abdddeddb7aa2451b85d5a8368769 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:02:48 +0900 Subject: [PATCH 027/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit スッキリしてとても良いと思います。 Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 34fe0a1e4f..0328f73c93 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -22,7 +22,7 @@ ConfigMapを使用すると、設定をイメージコンテンツから切り ## ConfigMapを作成する -`kubectl create configmap`コマンドまたはConfigMap generatorを`kustomization.yaml`ファイルで使ってConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 +`kubectl create configmap`コマンドまたは`kustomization.yaml`のConfigMap generatorを使用してConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 ### kubectl create configmapコマンドを使用してConfigMapを作成する From fc721399a17021333e7b43c488243cdbd78cc7be Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:04:27 +0900 Subject: [PATCH 028/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit はい。なりますが自然ですね。 Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 0328f73c93..963456644c 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -210,7 +210,7 @@ how.nice.to.look=fairlyNice # `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties -# env-file `game-env-file.properties`は以下のように見えます +# env-file `game-env-file.properties`は以下のようになります cat configure-pod-container/configmap/game-env-file.properties enemies=aliens lives=3 From 79964217827d81210b8b59681617eb1e7bc3b870 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:06:31 +0900 Subject: [PATCH 029/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit OKです！表示しますに寄せなくて良いと思いました。 Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 963456644c..435148ef03 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -131,7 +131,7 @@ data: kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties ``` -以下のConfigMapを表示します: +は、以下のConfigMapを生成します: ```shell kubectl describe configmaps game-config-2 From 2c663184d94a2cf44789aa18fd7944d3fa117703 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:06:42 +0900 Subject: [PATCH 030/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 435148ef03..e7b1385920 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -205,7 +205,7 @@ how.nice.to.look=fairlyNice # envファイルの各行はVAR=VALの形式である必要がある。 # #で始まる行 (例えばコメント)は無視される。 # 空の行は無視される。 -# クオーテーションマークは特別な扱いは処理をしない(例えばConfigMapの値になる). +# クオーテーションマークは特別な扱いは処理をしない(例えばConfigMapの値の一部になる). # `configure-pod-container/configmap/`ディレクトリにサンプルファイルをダウンロードします wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties From c50f8b1e10a20be5bbd6ca1333002ec7159e6e8a Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:07:17 +0900 Subject: [PATCH 031/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 見落としていました。 Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index e7b1385920..5fb003d6a4 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -604,7 +604,7 @@ very ### キーを特定のパスとファイルアクセス許可に投影する -キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。 +キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secret](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。 ### マウントされたConfigMapは自動的に更新される From d6bf8131699122c711b818c62c8926034486bd4b Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:07:30 +0900 Subject: [PATCH 032/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 5fb003d6a4..62589536a7 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -608,7 +608,7 @@ very ### マウントされたConfigMapは自動的に更新される -ボリュームで使用されているConfigMapが更新されている場合、投影されているキーも同じく結果的に更新されます。Kubeletは定期的な同期ごとにマウントされているConfigMapが更新されているかチェックします。しかし、これはローカルのttlを基にしたキャッシュでConfigMapの現在の値を取得しています。その結果、新しいキーがPodに投影されてからConfigMapに更新されるまでのトータルの遅延はkubeletで、kubeletの同期期間(デフォルトで1分) + ConfigMapキャッシュのttl(デフォルトで1分)の長さになる可能性があります。Podのアノテーションを1つ更新すると即時のリフレッシュをトリガーできます。 +ボリュームで使用されているConfigMapが更新されている場合、投影されているキーも同じく結果的に更新されます。kubeletは定期的な同期ごとにマウントされているConfigMapが更新されているかチェックします。しかし、これはローカルのttlを基にしたキャッシュでConfigMapの現在の値を取得しています。その結果、新しいキーがPodに投影されてからConfigMapに更新されるまでのトータルの遅延はkubeletで、kubeletの同期期間(デフォルトで1分) + ConfigMapキャッシュのttl(デフォルトで1分)の長さになる可能性があります。Podのアノテーションを1つ更新すると即時のリフレッシュをトリガーできます。 {{< note >}} ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュームとして利用するコンテナはConfigMapの更新を受け取りません。 From d0bf763304cfbe1d8fe03270a530e6579be18e32 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:07:42 +0900 Subject: [PATCH 033/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 62589536a7..35c04b0a98 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -620,7 +620,7 @@ ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュー ## ConfigMapとPodsを理解する -ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secrets](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。 +ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secret](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。 {{< note >}} ConfigMapはプロパティファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。 From db0c36c74a6935af81ac78fd1cb7fc25da83baa8 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:08:19 +0900 Subject: [PATCH 034/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 35c04b0a98..e31eec857c 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -662,7 +662,7 @@ data: 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. ``` -- ConfigMapは特定の{{< glossary_tooltip term_id="namespace" >}}に属します。ConfigMap同じ名前空間に属するPodからのみ参照できます。 +- ConfigMapは特定の{{< glossary_tooltip term_id="namespace" >}}に属します。ConfigMapは同じ名前空間に属するPodからのみ参照できます。 - {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていない為、ConfigMapに使用できません。 From a6c88c8ea13aff3398af7ba172096b81168350d7 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:09:17 +0900 Subject: [PATCH 035/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Totally agree！ Co-authored-by: nasa9084 --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index e31eec857c..83089c63b3 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -8,7 +8,7 @@ card: --- {{% capture overview %}} -ConfigMapを使用すると、設定をイメージコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。 +ConfigMapを使用すると、設定をイメージのコンテンツから切り離して、コンテナ化されたアプリケーションの移植性を維持できます。このページでは、ConfigMapを作成し、ConfigMapに保存されているデータを使用してPodを構成する一連の使用例を示します。 {{% /capture %}} From 393751323dea47da99da3509e15014a99a82d701 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:16:05 +0900 Subject: [PATCH 036/290] Unify the expressions of property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit プロバティファイルをプロバティーファイルに。 スタイルガイドに合わせて他のプロバティー表記と統一。 --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 83089c63b3..cd158218e4 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -623,7 +623,7 @@ ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュー ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secret](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。 {{< note >}} -ConfigMapはプロパティファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。 +ConfigMapはプロパティーファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。 {{< /note >}} ConfigMapの`data`フィールドは構成情報を含みます。下記の例のようにシンプルに`--from-literal`を使用して個別のプロパティーを定義、または複雑に`--from-file`を使用して構成ファイルまたはJSON blobsで定義できます。 From f7f267df0583416d57fb9bfe540d05374f5e76e7 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:37:10 +0900 Subject: [PATCH 037/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index cd158218e4..5d5c594d85 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -224,7 +224,7 @@ kubectl create configmap game-config-env-file \ --from-env-file=configure-pod-container/configmap/game-env-file.properties ``` -以下のConfigMapを表示します: +は、以下のConfigMapを生成します: ```shell kubectl get configmap game-config-env-file -o yaml From e6aa5d9de1b02091ec33911abf823464f783f943 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:37:51 +0900 Subject: [PATCH 038/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 5d5c594d85..61ea466944 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -262,7 +262,7 @@ kubectl create configmap config-multi-env-files \ --from-env-file=configure-pod-container/configmap/ui-env-file.properties ``` -以下のConfigMapを表示します: +は、以下のConfigMapを生成します: ```shell kubectl get configmap config-multi-env-files -o yaml From eef40f9773708c8c7f56c9a77432d980088fb547 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:38:16 +0900 Subject: [PATCH 039/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 61ea466944..0937d49c71 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -300,7 +300,7 @@ kubectl create configmap game-config-3 --from-file== kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties ``` -以下のConfigMapを表示します: +は、以下のConfigMapを生成します: ``` kubectl get configmaps game-config-3 -o yaml ``` From 323795514c5c3c136f6ee06bb7b78fb65da85d29 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:40:09 +0900 Subject: [PATCH 040/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 0937d49c71..865a30385e 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -328,7 +328,7 @@ data: #### リテラル値からConfigMapを作成する{#create-configmaps-from-literal-values} -`kubectl create configmap`を`--from-literal`引数と使用してCLIからリテラル値を定義できます: +`--from-literal`引数を指定して`kubectl create configmap`を使用すると、コマンドラインからリテラル値を定義できます: ```shell kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm From 291c3c98c92b9ee8346752643293ba7a991b6e2d Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:40:50 +0900 Subject: [PATCH 041/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 865a30385e..dcbb99f351 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -355,7 +355,7 @@ data: special.type: charm ``` -### ジェネレータからConfigMapを作成する +### ジェネレーターからConfigMapを作成する `kubectl`は`kustomization.yaml`を1.14からサポートしています。 ジェネレータからConfigMapを作成し、APIサーバー上でオブジェクトを作成できます。ジェネレータはディレクトリ内の`kustomization.yaml`で指定する必要があリます。 From fa57d8aaa8345f3cf7ebf43ba2bf5885f2b10b99 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:41:31 +0900 Subject: [PATCH 042/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index dcbb99f351..726c83c0ff 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -357,7 +357,7 @@ data: ### ジェネレーターからConfigMapを作成する `kubectl`は`kustomization.yaml`を1.14からサポートしています。 -ジェネレータからConfigMapを作成し、APIサーバー上でオブジェクトを作成できます。ジェネレータはディレクトリ内の`kustomization.yaml`で指定する必要があリます。 +ジェネレーターからConfigMapを作成して適用すると、APIサーバー上でオブジェクトを作成できます。ジェネレーターはディレクトリ内の`kustomization.yaml`で指定する必要があリます。 #### ファイルからConfigMapを生成する 例えば、ファイル`configure-pod-container/configmap/game.properties`からConfigMapを生成するには、 From c4c82e8c28bd063a2cc87a3fbb133aae50687b79 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:47:19 +0900 Subject: [PATCH 043/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit はい！こちらが正しいと思います。 Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 726c83c0ff..f91efde744 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -362,7 +362,7 @@ data: #### ファイルからConfigMapを生成する 例えば、ファイル`configure-pod-container/configmap/game.properties`からConfigMapを生成するには、 ```shell -# ConfigMapGeneratorでkustomization.yamlファイルを作成する +# ConfigMapGeneratorを含むkustomization.yamlファイルを作成する cat <./kustomization.yaml configMapGenerator: - name: game-config-4 From 46efa1836606a14539bda645d077595df09e4a11 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:48:41 +0900 Subject: [PATCH 044/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 完全同意。 Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index f91efde744..b7b3173e60 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -123,7 +123,7 @@ data: #### ファイルからConfigMapを作成する{#create-configmaps-from-files} -`kubectl create configmap`を使用して個別のファイルから、または複数のファイルからConfigMapを作成できます。 +`kubectl create configmap`を使用して、個別のファイルまたは複数のファイルからConfigMapを作成できます。 例えば、 From 1524ed4e2f67087e156076268e4fef75a1eb092a Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:49:30 +0900 Subject: [PATCH 045/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index b7b3173e60..3969fd7173 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -32,7 +32,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 kubectl create configmap ``` -\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapのオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 ファイルを基にConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 From a25a4fc43cba1fe6455be093249a6a5239ff471a Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:50:12 +0900 Subject: [PATCH 046/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 3969fd7173..bedfa06bdd 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -409,7 +409,7 @@ Events: 生成されたConfigMapの名前は、コンテンツをハッシュ化したサフィックスを持つことに注意してください。これにより、コンテンツが変更されるたびに新しいConfigMapが生成されます。 #### ファイルからConfigMapを生成する場合に使用するキーを定義する -ConfigMapジェネレータで使用するキーはファイルの名前以外を定義できます。 +ConfigMapジェネレーターで使用するキーはファイルの名前以外を定義できます。 例えば、ファイル`configure-pod-container/configmap/game.properties`とキー`game-special-key`を使用してConfigMapを作成する場合 ```shell From 386e929a8037e6559abde05c0576124bf80f1176 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 21:55:08 +0900 Subject: [PATCH 047/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 「使用すると、」の方が私もしっくりくるのでスタイルとして取り入れさせてもらいます〜。 Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index bedfa06bdd..46f8cc2826 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -164,7 +164,7 @@ secret.code.lives=30 kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties ``` -ConfigMap`game-config-2`の詳細を以下のコマンドを使用して表示できます: +以下のコマンドを使用すると、ConfigMap`game-config-2`の詳細を表示できます: ```shell kubectl describe configmaps game-config-2 From 85238c9c2ddbc2f48bb97932acb61933e9349444 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:00:09 +0900 Subject: [PATCH 048/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 46f8cc2826..df605170b9 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -410,7 +410,7 @@ Events: #### ファイルからConfigMapを生成する場合に使用するキーを定義する ConfigMapジェネレーターで使用するキーはファイルの名前以外を定義できます。 -例えば、ファイル`configure-pod-container/configmap/game.properties`とキー`game-special-key`を使用してConfigMapを作成する場合 +例えば、ファイル`configure-pod-container/configmap/game.properties`からキー`game-special-key`を持つConfigMapを作成する場合 ```shell # ConfigMapGeneratorでkustomization.yamlファイルを作成する From b66554f1e4ed4f3b5b6f012ed9a2417f6a58e855 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:02:53 +0900 Subject: [PATCH 049/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index df605170b9..b887f4ec51 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -22,7 +22,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 ## ConfigMapを作成する -`kubectl create configmap`コマンドまたは`kustomization.yaml`のConfigMap generatorを使用してConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 +`kubectl create configmap`または`kustomization.yaml`のConfigMap generatorを使用してConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 ### kubectl create configmapコマンドを使用してConfigMapを作成する From a821f53a02c031453c9116e9603333d27761363c Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:08:07 +0900 Subject: [PATCH 050/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index b887f4ec51..1c9744c190 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -34,7 +34,7 @@ kubectl create configmap \の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapのオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 -ファイルを基にConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 +ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用して、ConfigMapに関する情報を取得できます。 From caeb99e870712c5511d3fe2d20a3f21bb2468797 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:09:33 +0900 Subject: [PATCH 051/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 1c9744c190..ed2a97952d 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -371,7 +371,7 @@ configMapGenerator: EOF ``` -ConfigMapオブジェクトを作成する為にkustomizationディレクトリを適用して、 +ConfigMapオブジェクトを作成する為にkustomizationディレクトリを適用します。 ```shell kubectl apply -k . configmap/game-config-4-m9dm2f92bt created From 4607bc3ee3a9c246d7975077401c82b46fba788b Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:42:14 +0900 Subject: [PATCH 052/290] Revised phrases MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ・使用して→使用すると ・ConfigMapオブジェクト→ConfigMapのオブジェクト ・60行目を以下に変更。 上記のコマンドは各ファイルをパッケージ化します。この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化します。 以下のコマンドを使用すると、ConfigMapの詳細を表示できます: --- .../configure-pod-configmap.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index ed2a97952d..c10c7378ff 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -22,7 +22,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 ## ConfigMapを作成する -`kubectl create configmap`または`kustomization.yaml`のConfigMap generatorを使用してConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 +`kubectl create configmap`または`kustomization.yaml`のConfigMap generatorを使用すると、ConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 ### kubectl create configmapコマンドを使用してConfigMapを作成する @@ -37,7 +37,7 @@ kubectl create configmap ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または -[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用して、ConfigMapに関する情報を取得できます。 +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用すると、ConfigMapに関する情報を取得できます。 #### ディレクトリからConfigMapを作成する{#create-configmaps-from-directories} @@ -57,7 +57,7 @@ wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-con kubectl create configmap game-config --from-file=configure-pod-container/configmap/ ``` -上記のコマンドは各ファイルを、この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化します。 以下のコマンドを使用してConfigMapの詳細を表示できます: +上記のコマンドは各ファイルをパッケージ化します。この場合、`configure-pod-container/configmap/` ディレクトリの`game.properties` と `ui.properties`をgame-config ConfigMapにパッケージ化します。 以下のコマンドを使用すると、ConfigMapの詳細を表示できます: ```shell kubectl describe configmaps game-config @@ -422,7 +422,7 @@ configMapGenerator: EOF ``` -kustomizationディレクトリを適用してConfigMapオブジェクトを作成します。 +kustomizationディレクトリを適用してConfigMapのオブジェクトを作成します。 ```shell kubectl apply -k . configmap/game-config-5-m67dt67794 created @@ -441,7 +441,7 @@ configMapGenerator: - special.type=charm EOF ``` -kustomizationディレクトリを適用してConfigMapオブジェクトを作成します。 +kustomizationディレクトリを適用してConfigMapのオブジェクトを作成します。 ```shell kubectl apply -k . configmap/special-config-2-c92b5mmcf2 created @@ -626,7 +626,7 @@ ConfigMap APIリソースは構成情報をキーバリューペアとして保 ConfigMapはプロパティーファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。 {{< /note >}} -ConfigMapの`data`フィールドは構成情報を含みます。下記の例のようにシンプルに`--from-literal`を使用して個別のプロパティーを定義、または複雑に`--from-file`を使用して構成ファイルまたはJSON blobsで定義できます。 +ConfigMapの`data`フィールドは構成情報を含みます。下記の例のように、シンプルに個別のプロパティーを`--from-literal`で定義、または複雑に構成ファイルまたはJSON blobsを`--from-file`で定義できます。 ```yaml apiVersion: v1 From 273b6acc9f288642298bc2340d90b2dd9f82eb74 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:45:59 +0900 Subject: [PATCH 053/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index c10c7378ff..de05329e64 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -432,7 +432,7 @@ configmap/game-config-5-m67dt67794 created To generate a ConfigMap from literals `special.type=charm` and `special.how=very`, you can specify the ConfigMap generator in `kustomization.yaml` as ```shell -# kustomization.yamlファイルをConfigMapGeneratorと作成します +# ConfigMapGeneratorを含むkustomization.yamlファイルを作成します cat <./kustomization.yaml configMapGenerator: - name: special-config-2 From 5d5335e3caa9ac248370849ce25a7b4b3b60301c Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:46:38 +0900 Subject: [PATCH 054/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index de05329e64..75f4820e22 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -413,7 +413,7 @@ ConfigMapジェネレーターで使用するキーはファイルの名前以 例えば、ファイル`configure-pod-container/configmap/game.properties`からキー`game-special-key`を持つConfigMapを作成する場合 ```shell -# ConfigMapGeneratorでkustomization.yamlファイルを作成する +# ConfigMapGeneratorを含むkustomization.yamlファイルを作成する cat <./kustomization.yaml configMapGenerator: - name: game-config-5 From 153f78edf9f6abb8e0ed7949496970c02839de43 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 22:47:33 +0900 Subject: [PATCH 055/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: Naoki Oketani --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 75f4820e22..ce1423bdc5 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -581,7 +581,7 @@ SPECIAL_TYPE ### ConfigMapデータをボリュームの特定のパスに追加する -`path`フィルドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。 +`path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。 このケースでは`SPECIAL_LEVEL`アイテムが`/etc/config/keys`の`config-volume`ボリュームにマウントされます。 {{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}} From c510ac916390cc55afe642886a33c855b5e33098 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:06:46 +0900 Subject: [PATCH 056/290] Updated MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ・ConfigMapのオブジェクト→ConfigMapに統一。 ・訳漏れ432行目を以下に。 リテラル`special.type=charm`と`special.how=very`からConfigMapを作成する場合は、 以下のように`kustomization.yaml`のConfigMapジェネレーターで指定できます。 --- .../configure-pod-container/configure-pod-configmap.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index ce1423bdc5..3cdedafdae 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -32,7 +32,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 kubectl create configmap ``` -\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapのオブジェクト名は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 @@ -422,15 +422,15 @@ configMapGenerator: EOF ``` -kustomizationディレクトリを適用してConfigMapのオブジェクトを作成します。 +kustomizationディレクトリを適用してConfigMapを作成します。 ```shell kubectl apply -k . configmap/game-config-5-m67dt67794 created ``` #### リテラルからConfigMapを作成する -To generate a ConfigMap from literals `special.type=charm` and `special.how=very`, -you can specify the ConfigMap generator in `kustomization.yaml` as +リテラル`special.type=charm`と`special.how=very`からConfigMapを作成する場合は、 +以下のように`kustomization.yaml`のConfigMapジェネレーターで指定できます。 ```shell # ConfigMapGeneratorを含むkustomization.yamlファイルを作成します cat <./kustomization.yaml @@ -441,7 +441,7 @@ configMapGenerator: - special.type=charm EOF ``` -kustomizationディレクトリを適用してConfigMapのオブジェクトを作成します。 +kustomizationディレクトリを適用してConfigMapを作成します。 ```shell kubectl apply -k . configmap/special-config-2-c92b5mmcf2 created From 4afebf732f1a6dd1a4fbc7352174d0ac1fe4ef44 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:15:08 +0900 Subject: [PATCH 057/290] Delete "command" not written in original document --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 3cdedafdae..671cfc34a6 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -24,7 +24,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 ## ConfigMapを作成する `kubectl create configmap`または`kustomization.yaml`のConfigMap generatorを使用すると、ConfigMapを作成できます。`kubectl`が`kustomization.yaml`をサポートをしているのは1.14からである点に注意してください。 -### kubectl create configmapコマンドを使用してConfigMapを作成する +### kubectl create configmapを使用してConfigMapを作成する `kubectl create configmap`コマンドを使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、[ファイル](#create-configmaps-from-files)、または[リテラル値](#create-configmaps-from-literal-values)から作成します: From 55e66331d7a8e0e19305d7a879a47f67089c54d7 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:21:08 +0900 Subject: [PATCH 058/290] Inappropriate Chinese Character edited --- .../tasks/configure-pod-container/configure-pod-configmap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 671cfc34a6..71f808d70f 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -371,7 +371,7 @@ configMapGenerator: EOF ``` -ConfigMapオブジェクトを作成する為にkustomizationディレクトリを適用します。 +ConfigMapオブジェクトを作成するためにkustomizationディレクトリを適用します。 ```shell kubectl apply -k . configmap/game-config-4-m9dm2f92bt created @@ -664,7 +664,7 @@ data: - ConfigMapは特定の{{< glossary_tooltip term_id="namespace" >}}に属します。ConfigMapは同じ名前空間に属するPodからのみ参照できます。 -- {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていない為、ConfigMapに使用できません。 +- {{< glossary_tooltip text="static pods" term_id="static-pod" >}}はKubeletがサポートしていないため、ConfigMapに使用できません。 {{% /capture %}} From 466075063bdb3514a4a065603be101c98199c4e3 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:24:23 +0900 Subject: [PATCH 059/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 71f808d70f..8732ed6bc5 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -26,7 +26,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 ### kubectl create configmapを使用してConfigMapを作成する -`kubectl create configmap`コマンドを使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、[ファイル](#create-configmaps-from-files)、または[リテラル値](#create-configmaps-from-literal-values)から作成します: +`kubectl create configmap`を使用してConfigMapを[ディレクトリ](#create-configmaps-from-directories)、[ファイル](#create-configmaps-from-files)、または[リテラル値](#create-configmaps-from-literal-values)から作成します: ```shell kubectl create configmap From 8f0af976565ce046cd15378d27961afe71017a7d Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:24:48 +0900 Subject: [PATCH 060/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 8732ed6bc5..fb551c15df 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -568,7 +568,7 @@ Podを作成します: kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml ``` -Podが稼働していると、`ls /etc/config/`コマンドは以下の出力結果を表示します: +Podが稼働していると、`ls /etc/config/`は以下の出力結果を表示します: ```shell SPECIAL_LEVEL From 0d060717bea8361074018b9610809732dd6851d9 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:25:04 +0900 Subject: [PATCH 061/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index fb551c15df..41cb68b2ba 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -592,7 +592,7 @@ Podを作成します: kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml ``` -Podが稼働していると、 `cat /etc/config/keys`コマンドは以下の出力結果を表示します: +Podが稼働していると、 `cat /etc/config/keys`は以下の出力結果を表示します: ```shell very From e4a85ffee2b1082993d6e0b4b02935d298636067 Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Tue, 12 May 2020 23:39:29 +0900 Subject: [PATCH 062/290] Update content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 日本語的にも、意味的にもファイル名のベースにした方が良さそうです〜。 Co-authored-by: inductor(Kohei) --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 41cb68b2ba..520a3a4f3d 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -34,7 +34,7 @@ kubectl create configmap \の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 -ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイルのベース名になり、値はデフォルトでファイルのコンテンツになります。 +ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイル名のベースになり、値はデフォルトでファイルのコンテンツになります。 [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用すると、ConfigMapに関する情報を取得できます。 From 08dc3ad9d369620e4d60e138a6c7bf7d27a3e11b Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Wed, 13 May 2020 14:14:57 +0900 Subject: [PATCH 063/290] Deleted redundant object --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 520a3a4f3d..0b13ece910 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -371,7 +371,7 @@ configMapGenerator: EOF ``` -ConfigMapオブジェクトを作成するためにkustomizationディレクトリを適用します。 +ConfigMapを作成するためにkustomizationディレクトリを適用します。 ```shell kubectl apply -k . configmap/game-config-4-m9dm2f92bt created From d687645682635feb2350068512f3f8b07707cdde Mon Sep 17 00:00:00 2001 From: Yoshiki Fujiwara <40357845+Yoshiki0705@users.noreply.github.com> Date: Wed, 13 May 2020 17:17:21 +0900 Subject: [PATCH 064/290] Improving one phrase by ideas --- .../tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 0b13ece910..f23a98cb6b 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -34,7 +34,7 @@ kubectl create configmap \の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 -ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイル名のベースになり、値はデフォルトでファイルのコンテンツになります。 +ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイル名になり、値はデフォルトでファイルの中身になります。 [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)または [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使用すると、ConfigMapに関する情報を取得できます。 From 8a3b79913f13a1a9ffd21db9354015a6dfcf1630 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 13 May 2020 23:32:29 +0900 Subject: [PATCH 065/290] Change the corresponding word to 'stacked'. --- .../tools/kubeadm/ha-topology.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md index a0c5319afe..2f4ee624ce 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -10,7 +10,7 @@ weight: 50 HAクラスターは次の方法で設定できます。 -- 積み重なったコントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。 +- 積層コントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。 - 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。 HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。 @@ -19,9 +19,9 @@ HAクラスターをセットアップする前に、各トポロジーの利点 {{% capture body %}} -## 積み重なったetcdトポロジー +## 積層のetcdトポロジー -積み重なったHAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 +積層のHAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。 @@ -29,23 +29,23 @@ HAクラスターをセットアップする前に、各トポロジーの利点 このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。 -しかし、積み重なったクラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。 +しかし、積層のクラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。 -そのため、HAクラスターのためには、最低でも3台の積み重なったコントロールプレーンノードを実行しなければなりません。 +そのため、HAクラスターのためには、最低でも3台の積層のコントロールプレーンノードを実行しなければなりません。 これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。 -![積み重なったetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) +![積層のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) ## 外部のetcdトポロジー 外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 -積み重なったetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 +積層のetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 -このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積み重なったHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。 +このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層のHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。 -しかし、このトポロジーでは積み重なったHAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。 +しかし、このトポロジーでは積層のHAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。 ![外部のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) From 89cab4b7b4a4654d8fb5d9e76596713bbb565b6e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 13 May 2020 23:35:34 +0900 Subject: [PATCH 066/290] Translate a missing sentence. --- .../setup/production-environment/tools/kubeadm/ha-topology.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md index 2f4ee624ce..f39e8ae8aa 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -41,7 +41,7 @@ HAクラスターをセットアップする前に、各トポロジーの利点 外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 -積層のetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 +積層のetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。そして、`kube-apiserver`は、ロードバランサーを使用してワーカーノードに公開されます。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層のHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。 From 16160ec9e738ccf0f8d94834001f23ab8aa34bef Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 14 May 2020 00:10:20 +0900 Subject: [PATCH 067/290] Fix words corresponding word to 'stacked'. --- .../tools/kubeadm/ha-topology.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md index f39e8ae8aa..df0549b321 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -19,9 +19,9 @@ HAクラスターをセットアップする前に、各トポロジーの利点 {{% capture body %}} -## 積層のetcdトポロジー +## 積層etcdトポロジー -積層のHAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 +積層HAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。 @@ -29,23 +29,23 @@ HAクラスターをセットアップする前に、各トポロジーの利点 このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。 -しかし、積層のクラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。 +しかし、積層クラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。 -そのため、HAクラスターのためには、最低でも3台の積層のコントロールプレーンノードを実行しなければなりません。 +そのため、HAクラスターのためには、最低でも3台の積層コントロールプレーンノードを実行しなければなりません。 これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。 -![積層のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) +![積層etcdトポロジー](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) ## 外部のetcdトポロジー 外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。 -積層のetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。そして、`kube-apiserver`は、ロードバランサーを使用してワーカーノードに公開されます。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 +積層etcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。そして、`kube-apiserver`は、ロードバランサーを使用してワーカーノードに公開されます。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。 -このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層のHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。 +このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層HAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。 -しかし、このトポロジーでは積層のHAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。 +しかし、このトポロジーでは積層HAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。 ![外部のetcdトポロジー](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) From fab08546d5281cbd5b203dd7c54f494e585193a6 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 15 May 2020 18:13:51 +0900 Subject: [PATCH 068/290] remove non-existent location.hash --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 3dd96553fe..c14ea5c79d 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -131,7 +131,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -クラスタードメインは[その他の設定](/ja/docs/concepts/services-networking/dns-pod-service/#how-it-works)がされない限り、`cluster.local`にセットされます。 +クラスタードメインは[その他の設定](/ja/docs/concepts/services-networking/dns-pod-service/)がされない限り、`cluster.local`にセットされます。 {{< /note >}} ### 安定したストレージ From 49a22136ea8919db457ce7b77fbd050ef1dd1493 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 16 May 2020 18:41:32 +0900 Subject: [PATCH 069/290] Fix note shortcodes in Deployment concept (ja) --- .../workloads/controllers/deployment.md | 140 ++++++++++-------- 1 file changed, 77 insertions(+), 63 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 54b73be6f1..113a89c734 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -46,83 +46,97 @@ Deploymentによって作成されたReplicaSetを管理しないでください * `nginx-deployment`という名前のDeploymentが作成され、`.metadata.name`フィールドで名前を指定します。 * Deploymentは3つのレプリカPodを作成し、`replicas`フィールドによってレプリカ数を指定します。 * `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。このケースにおいて、ユーザーはPodテンプレートにて定義されたラベル(`app: nginx`)を選択します。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。 - {{< note >}} - `matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。 - `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。 - {{< /note >}} + + {{< note >}} + `matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。 + `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。 + {{< /note >}} + * `template`フィールドは、下記のサブフィールドを持ちます。: * Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられる * PodTemplateの仕様もしくは、`.template.spec`フィールドは、このPodは`nginx`という名前のコンテナーを1つ稼働させ、それは`nginx`というさせ、[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.14.2を使うことを示します * 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます - 上記のDeploymentを作成するために、以下に示すステップにしたがってください。 - 作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。 +作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。 +上記のDeploymentを作成するために、以下に示すステップにしたがってください。 - 1. 下記のコマンドを実行してDeploymentを作成してください。 +1. 下記のコマンドを実行してDeploymentを作成してください。 - {{< note >}} - 実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。 - {{< /note >}} - - ```shell - kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml - ``` - - 2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。 - ```shell - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx-deployment 3 0 0 0 1s - ``` - ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。 - - * `NAME` クラスター内のDeploymentの名前を表示する - * `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。 - * `CURRENT` 現在稼働中のレプリカ数 - * `UP-TO-DATE` 理想的な状態にするために、アップデートが完了したレプリカ数 - * `AVAILABLE` ユーザーが利用可能なレプリカ数 - * `AGE` アプリケーションが稼働してからの時間 - - 上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。 - - 3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。コマンドの実行結果は下記のとおりです。 - ```shell - Waiting for rollout to finish: 2 out of 3 new replicas have been updated... - deployment.apps/nginx-deployment successfully rolled out - ``` - - 4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は下記のとおりです。 - ```shell - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx-deployment 3 3 3 3 18s - ``` - Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。 - - 5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。 - - ```shell - NAME DESIRED CURRENT READY AGE - nginx-deployment-75675f5897 3 3 3 18s - ``` - ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。 - - 6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。 - ```shell - NAME READY STATUS RESTARTS AGE LABELS - nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - ``` - 作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。 + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` {{< note >}} - Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。 + 実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。 {{< /note >}} + +2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。 + + Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。 + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 0 0 0 1s + ``` + ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。 + * `NAME` クラスター内のDeploymentの名前を表示する + * `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。 + * `CURRENT` 現在稼働中のレプリカ数 + * `UP-TO-DATE` 理想的な状態にするために、アップデートが完了したレプリカ数 + * `AVAILABLE` ユーザーが利用可能なレプリカ数 + * `AGE` アプリケーションが稼働してからの時間 + + 上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。 + +3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。 + + コマンドの実行結果は下記のとおりです。 + ```shell + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment.apps/nginx-deployment successfully rolled out + ``` + +4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は下記のとおりです。 + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 3 3 3 3 18s + ``` + Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。 + +5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。 + ```shell + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + ReplicaSetの出力には次のフィールドが表示されます: + + * `NAME`は名前空間内のReplicaSetの名前を一覧表示します。 + * `DESIRED`は、アプリケーションの_replicas_の希望数を表示します。これは、Deploymentを作成するときに定義します。これが_desired state_です。 + * `CURRENT`は現在実行されているレプリカの数を表示します。 + * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数を表示します。 + * `AGE`は、アプリケーションが実行されている時間を表示します。 + + ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。 + + +6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。 + ```shell + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + ``` + 作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。 + +{{< note >}} +Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。 +{{< /note >}} + ### pod-template-hashラベル -{{< note >}} +{{< caution >}} このラベルを変更しないでください。 -{{< /note >}} +{{< /caution >}} `pod-template-hash`ラベルはDeploymentコントローラーによってDeploymentが作成し適用した各ReplicaSetに対して追加されます。 From 203ab83f22103f117cd42cca4dc122626719ccc2 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 18 May 2020 12:46:06 +0900 Subject: [PATCH 070/290] update /ja/docs/concepts/overview/working-with-objects/names/ --- .../overview/working-with-objects/names.md | 66 +++++++++++++++++-- 1 file changed, 59 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md index b8762cb33c..903e0ba8fc 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/names.md +++ b/content/ja/docs/concepts/overview/working-with-objects/names.md @@ -1,30 +1,82 @@ --- reviewers: -title: 名前 +title: オブジェクトの名前とID content_template: templates/concept weight: 20 --- {{% capture overview %}} -KubernetesのREST API内の全てのオブジェクトは、名前とUIDで明確に識別されます。 +クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。 +すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。 -ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/docs/user-guide/labels)と[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を付与します。 +たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。 -名前とUIDに関する正確な構文については、[識別子デザインドキュメント](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)を参照してください。 +ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を付与します。 {{% /capture %}} {{% capture body %}} -## 名前 +## 名前 {#names} {{< glossary_definition term_id="name" length="all" >}} -慣例的に、Kubernetesリソースの名前は最長253文字で、かつ英小文字、数字、また`-`、`.`から構成します。しかし、特定のリソースはより具体的な制限があります。 +以下は、リソースに一般的に使用される3つのタイプの名前制約です。 -## UID +### DNSサブドメイン名 {#dns-subdomain-names} + +ほとんどのリソースタイプには、[RFC 1123](https://tools.ietf.org/html/rfc1123)で定義されているDNSサブドメイン名として使用できる名前が必要です。 +つまり、名前は次のとおりでなければなりません: + +- 253文字以内 +- 英小文字、数字、「-」または「.」のみを含む +- 英数字で始まる +- 英数字で終わる + +### DNSラベル名 {#dns-label-names} + +一部のリソースタイプでは、[RFC 1123](https://tools.ietf.org/html/rfc1123)で定義されているDNSラベル標準に従う名前が必要です。 +つまり、名前は次のとおりでなければなりません: + +- 63文字以内 +- 英小文字、数字または「-」のみを含む +- 英数字で始まる +- 英数字で終わる + +### パスセグメント名 {#path-segment-names} + +一部のリソースタイプでは、名前をパスセグメントとして安全にエンコードできるようにする必要があります。 +つまり、名前を「.」や「..」にすることはできず、名前に「/」または「%」を含めることはできません。 + +以下は、`nginx-demo`という名前のPodのマニフェストの例です。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx-demo +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +{{< note >}} +一部のリソースタイプには、名前に追加の制限があります。 +{{< /note >}} + +## UID {#uids} {{< glossary_definition term_id="uid" length="all" >}} +Kubernetes UIDは、普遍的に一意の識別子(UUIDとも呼ばれます)です。 +UUIDは、ISO/IEC 9834-8およびITU-T X.667として標準化されています。 + +{{% /capture %}} +{{% capture whatsnext %}} +* Kubernetesの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)についてお読みください。 +* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)設計ドキュメントをご覧ください。 {{% /capture %}} From 4cfae3b87f8848c68ebc9cf0ee3b110eeac04f38 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 18 May 2020 12:52:44 +0900 Subject: [PATCH 071/290] update link to /ja/docs/concepts/overview/working-with-objects/names/ --- content/ja/docs/reference/glossary/name.md | 6 +++--- .../configure-pod-container/configure-pod-configmap.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/reference/glossary/name.md b/content/ja/docs/reference/glossary/name.md index c9b0bcd5ef..48c4ca4db9 100755 --- a/content/ja/docs/reference/glossary/name.md +++ b/content/ja/docs/reference/glossary/name.md @@ -2,17 +2,17 @@ title: 名前(Name) id: name date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/names +full_link: /ja/docs/concepts/overview/working-with-objects/names short_description: > クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。 -aka: +aka: tags: - fundamental --- クライアントから提供され、リソースURL内のオブジェクトを参照する文字列です。例えば`/api/v1/pods/何らかの名前`のようになります。 - + 同じ種類のオブジェクトは、同じ名前を同時に持つことは出来ません。しかし、オブジェクトを削除することで、旧オブジェクトと同じ名前で新しいオブジェクトを作成できます。 diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index f23a98cb6b..17b39e7e1f 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -32,7 +32,7 @@ ConfigMapを使用すると、設定をイメージのコンテンツから切 kubectl create configmap ``` -\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +\の部分はConfigMapに割り当てる名前で、\はデータを取得するディレクトリ、ファイル、またはリテラル値です。ConfigMapの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 ファイルをベースにConfigMapを作成する場合、\ のキーはデフォルトでファイル名になり、値はデフォルトでファイルの中身になります。 From cc3b3d003223054a1bbb49dc9737473162e3444d Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 20 May 2020 12:21:53 +0900 Subject: [PATCH 072/290] update /ja/docs/concepts/overview/working-with-objects/annotations/ --- .../working-with-objects/annotations.md | 21 +++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/annotations.md b/content/ja/docs/concepts/overview/working-with-objects/annotations.md index c554311b6b..105bf87948 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ja/docs/concepts/overview/working-with-objects/annotations.md @@ -5,7 +5,7 @@ weight: 50 --- {{% capture overview %}} -ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。 +ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。 {{% /capture %}} {{% capture body %}} @@ -52,13 +52,30 @@ weight: 50 _アノテーション_ はキーとバリューのペアです。有効なアノテーションのキーの形式は2つのセグメントがあります。 プレフィックス(オプション)と名前で、それらはスラッシュ`/`で区切られます。 名前セグメントは必須で、63文字以下である必要があり、文字列の最初と最後は英数字(`[a-z0-9A-Z]`)と、文字列の間にダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)を使うことができます。 -プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。 +プレフィックスはオプションです。もしプレフィックスが指定されていた場合、プレフィックスはDNSサブドメイン形式である必要があり、それはドット(`.`)で区切られたDNSラベルのセットで、253文字以下である必要があり、最後にスラッシュ(`/`)が続きます。 もしプレフィックスが除外された場合、アノテーションキーはそのユーザーに対してプライベートであると推定されます。 エンドユーザーのオブジェクトにアノテーションを追加するような自動化されたシステムコンポーネント(例: `kube-scheduler` `kube-controller-manager` `kube-apiserver` `kubectl`やその他のサードパーティツール)は、プレフィックスを指定しなくてはなりません。 `kubernetes.io/`と`k8s.io/`プレフィックスは、Kubernetesコアコンポーネントのために予約されています。 +たとえば、`imageregistry: https://hub.docker.com/`というアノテーションが付いたPodの構成ファイルは次のとおりです: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: annotations-demo + annotations: + imageregistry: "https://hub.docker.com/" +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + {{% /capture %}} {{% capture whatsnext %}} From 43a201d50302f3771e8c5feabca3c56e3fa74ad4 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 20 May 2020 12:38:28 +0900 Subject: [PATCH 073/290] Update content/ja/docs/concepts/overview/working-with-objects/names.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/overview/working-with-objects/names.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md index 903e0ba8fc..b8e1335c58 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/names.md +++ b/content/ja/docs/concepts/overview/working-with-objects/names.md @@ -12,7 +12,7 @@ weight: 20 たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。 -ユーザーが付与する一意ではない属性については、Kubernetesが[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を付与します。 +ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。 {{% /capture %}} From 72fa37e344f302d71e05a4f37947de9f2b9ecb6b Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 20 May 2020 12:41:02 +0900 Subject: [PATCH 074/290] apply review --- .../ja/docs/concepts/overview/working-with-objects/names.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md index b8e1335c58..614e87903e 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/names.md +++ b/content/ja/docs/concepts/overview/working-with-objects/names.md @@ -22,7 +22,7 @@ weight: 20 {{< glossary_definition term_id="name" length="all" >}} -以下は、リソースに一般的に使用される3つのタイプの名前制約です。 +以下は、一般的にリソースに使用される3種類の名前に関する制約です。 ### DNSサブドメイン名 {#dns-subdomain-names} @@ -72,11 +72,11 @@ spec: {{< glossary_definition term_id="uid" length="all" >}} -Kubernetes UIDは、普遍的に一意の識別子(UUIDとも呼ばれます)です。 +Kubernetes UIDは、UUIDのことを指します。 UUIDは、ISO/IEC 9834-8およびITU-T X.667として標準化されています。 {{% /capture %}} {{% capture whatsnext %}} * Kubernetesの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)についてお読みください。 -* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)設計ドキュメントをご覧ください。 +* [Kubernetesの識別子と名前](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)デザインドキュメントをご覧ください。 {{% /capture %}} From 629e77d6b757601168dc66cbaf703d8d517e21e2 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 20 May 2020 12:45:38 +0900 Subject: [PATCH 075/290] update link to /ja/docs/concepts/overview/working-with-objects/annotations/ --- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- .../ja/docs/concepts/overview/working-with-objects/labels.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 2675eaf0c9..a80a785333 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -34,7 +34,7 @@ Kubernetesは、**コンテナを中心とした**管理基盤です。ユーザ Kubernetesが多くの機能を提供すると言いつつも、新しい機能から恩恵を受ける新しいシナリオは常にあります。アプリケーション固有のワークフローを効率化して開発者のスピードを早めることができます。最初は許容できるアドホックなオーケストレーションでも、大規模で堅牢な自動化が必要となることはしばしばあります。これが、Kubernetesがアプリケーションのデプロイ、拡張、および管理を容易にするために、コンポーネントとツールのエコシステムを構築するための基盤としても機能するように設計された理由です。 -[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。 +[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用すると、ユーザーは自分のリソースを整理できます。[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を使用すると、ユーザーは自分のワークフローを容易にし、管理ツールが状態をチェックするための簡単な方法を提供するためにカスタムデータを使ってリソースを装飾できるようになります。 さらに、[Kubernetesコントロールプレーン](/ja/docs/concepts/overview/components/)は、開発者やユーザーが使える[API](/docs/reference/using-api/api-overview/)の上で成り立っています。ユーザーは[スケジューラー](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)などの独自のコントローラーを、汎用の[コマンドラインツール](/docs/user-guide/kubectl-overview/)で使える[独自のAPI](/docs/concepts/api-extension/custom-resources/)を持たせて作成することができます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 7afead6cb0..ec6f9f7201 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -20,7 +20,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ ``` ラベルは効率的な検索・閲覧を可能にし、UIやCLI上での利用に最適です。 -識別用途でない情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。 +識別用途でない情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を用いて記録されるべきです。 {{% /capture %}} From 2a560b906197d43bda0623bbfaecff9f9ee95e41 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Thu, 21 May 2020 09:28:37 +0900 Subject: [PATCH 076/290] apply review --- content/ja/docs/concepts/overview/working-with-objects/names.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md index 614e87903e..7e36d1bd36 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/names.md +++ b/content/ja/docs/concepts/overview/working-with-objects/names.md @@ -22,7 +22,7 @@ weight: 20 {{< glossary_definition term_id="name" length="all" >}} -以下は、一般的にリソースに使用される3種類の名前に関する制約です。 +次の3つの命名規則がよく使われます。 ### DNSサブドメイン名 {#dns-subdomain-names} From 0754e19b8d3430c0fdf0d63f29452e71a69f43cd Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Thu, 21 May 2020 11:12:35 +0900 Subject: [PATCH 077/290] update /ja/docs/concepts/overview/working-with-objects/common-labels/ --- .../overview/working-with-objects/common-labels.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md index 9a6c4508df..1fd5ea64fa 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md @@ -128,11 +128,11 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" app.kubernetes.io/managed-by: helm app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress - app.kubernetes.io/version: "5.7.21" ... ``` @@ -143,14 +143,14 @@ kind: Service metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" 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 %}} \ No newline at end of file +{{% /capture %}} From 3088bc0221a88ad0a1a04fb02a0ce872333652c6 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 22 May 2020 14:45:54 +0900 Subject: [PATCH 078/290] update /ja/docs/concepts/overview/working-with-objects/namespaces/ --- .../working-with-objects/namespaces.md | 21 ++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 223fec9ce9..7cff1892e0 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -20,7 +20,7 @@ Namespaceは、複数のチーム・プロジェクトにまたがる多くの 数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。 Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。 -Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。 +Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。Namespaceは相互にネストすることはできず、各Kubernetesリソースは1つのNamespaceにのみ存在できます。 Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。) @@ -38,7 +38,7 @@ Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメン ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。 ```shell -kubectl get namespaces +kubectl get namespace ``` ``` NAME STATUS AGE @@ -56,12 +56,13 @@ Kubernetesの起動時には3つの初期Namespaceが作成されています。 ### Namespaceの設定 -一時的な要求のためにNamespaceを設定したい場合、`--namespace`フラグを使用します。 +現在のリクエストのNamespaceを設定するには、`--namespace`フラグを使用します。 + 例: ```shell -kubectl --namespace= run nginx --image=nginx -kubectl --namespace= get pods +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= ``` ### Namespace設定の永続化 @@ -69,9 +70,9 @@ kubectl --namespace= get pods ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。 ```shell -kubectl config set-context $(kubectl config current-context) --namespace= +kubectl config set-context --current --namespace= # Validate it -kubectl config view | grep namespace: +kubectl config view --minify | grep namespace: ``` ## NamespaceとDNS @@ -98,3 +99,9 @@ kubectl api-resources --namespaced=false ``` {{% /capture %}} + +{{% capture whatsnext %}} +* [新しいNamespaceの作成](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)について学習してください。 +* [Namespaceの削除](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)について学習してください。 + +{{% /capture %}} From 718e2fe9c8b217809aad53a04f4713cfb8e7baec Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 22 May 2020 14:50:08 +0900 Subject: [PATCH 079/290] update links --- .../concepts/overview/working-with-objects/namespaces.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 7cff1892e0..1c5d729f95 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -27,11 +27,11 @@ Namespaceは、複数のユーザーの間でクラスターリソースを分 Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。 同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。 -同一のNamespace内でリソースを区別するためには[ラベル](/docs/user-guide/labels)を使用してください。 +同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。 ## Namespaceを利用する -Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/admin/namespaces)に記載されています。 +Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。 ### Namespaceの表示 @@ -77,7 +77,7 @@ kubectl config view --minify | grep namespace: ## NamespaceとDNS -ユーザーが[Service](/docs/user-guide/services)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 +ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 このエントリは`..svc.cluster.local`という形式になり,これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 @@ -86,7 +86,7 @@ kubectl config view --minify | grep namespace: ほとんどのKubernetesリソース(例えば、Pod、Service、ReplicationControllerなど)はいくつかのNamespaceにあります。 しかしNamespaceのリソースそれ自体は単一のNamespace内にありません。 -そして[Node](/docs/admin/node)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。 +そして[Node](/ja/docs/concepts/architecture/nodes/)やPersistentVolumeのような低レベルのリソースはどのNamespaceにも属していません。 どのKubernetesリソースがNamespaceに属しているか、属していないかを見るためには、以下のコマンドで確認できます。 From 0f8ad9b65c780fabad5d546f26b07cffe7eb5519 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 22 May 2020 16:40:39 +0900 Subject: [PATCH 080/290] remove new line --- .../ja/docs/concepts/overview/working-with-objects/names.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md index 7e36d1bd36..18c762aea5 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/names.md +++ b/content/ja/docs/concepts/overview/working-with-objects/names.md @@ -7,8 +7,7 @@ weight: 20 {{% capture overview %}} -クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。 -すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。 +クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。 たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。 From fb3ae3efc923121726362a29c552068324bcc96b Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 23 May 2020 13:34:33 +0900 Subject: [PATCH 081/290] Translate tasks/access-application-cluster/web-ui-dashboard/ into Japanese --- .../ja/docs/concepts/workloads/pods/pod.md | 2 +- .../web-ui-dashboard.md | 167 ++++++++++++++++++ 2 files changed, 168 insertions(+), 1 deletion(-) create mode 100644 content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index e0d9c951b4..2fb5aed647 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -164,7 +164,7 @@ Node上では、すぐに終了するように設定されるPodは、強制終 強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 -## Podコンテナの特権モード +## Podコンテナの特権モード {#privileged-mode-for-pod-containers} Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。 これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。 diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md new file mode 100644 index 0000000000..af6050c3fa --- /dev/null +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -0,0 +1,167 @@ +--- +title: Web UI (Dashboard) +content_template: templates/concept +weight: 10 +card: + name: tasks + weight: 30 + title: Web UIダッシュボードを使用する +--- + +{{% capture overview %}} + +ダッシュボードは、WebベースのKubernetesユーザーインターフェイスです。ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。 + +ダッシュボードでは、クラスター内のKubernetesリソースの状態や、発生した可能性のあるエラーに関する情報も提供されます。 + +![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png) + +{{% /capture %}} + + +{{% capture body %}} + +## ダッシュボードUIのデプロイ + +ダッシュボードUIはデフォルトではデプロイされていません。デプロイするには、以下のコマンドを実行します: + +``` +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml +``` + +## ダッシュボードUIへのアクセス + + +クラスタデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。このデモ用のトークンを作成するには、[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。 + +{{< warning >}} +チュートリアルで作成されたサンプルユーザーには管理者権限が与えられ、教育目的のみに使用されます。 +{{< /warning >}} + +### コマンドラインプロキシー +以下のコマンドを実行することで、kubectlコマンドラインツールを使ってダッシュボードにアクセスすることができます: + +``` +kubectl proxy +``` + +kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。 + +UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 + +{{< note >}} +Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。 +{{< /note >}} + +## ウェルカムビュー + +空のクラスターでダッシュボードにアクセスすると、ウェルカムページが表示されます。このページには、このドキュメントへのリンクと、最初のアプリケーションをデプロイするためのボタンが含まれています。さらに、クラスターの`kube-system`[名前空間](/docs/tasks/administer-cluster/namespaces/)でデフォルトで実行されているシステムアプリケーション、たとえばダッシュボード自体を見ることができます。 + +![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png) + +## コンテナ化されたアプリケーションのデプロイ + +ダッシュボードを使用すると、簡単なウィザードでコンテナ化されたアプリケーションをDeploymentとオプションのServiceとして作成してデプロイすることができます。アプリケーションの詳細を手動で指定するか、アプリケーションの設定を含むYAMLまたはJSONファイルをアップロードすることができます。 + +任意のページの右上にある**CREATE**ボタンをクリックして開始します。 + +### Specifying application details + +デプロイウィザードでは、以下の情報を入力する必要があります: + +- **App name** (必須): アプリケーションの名前です。その名前の[label](/ja/docs/concepts/overview/working-with-objects/labels/)は、デプロイされるDeploymentとServiceに追加されます。 + + アプリケーション名は、選択したKubernetes[名前空間](/docs/tasks/administer-cluster/namespaces/)内で一意である必要があります。小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。 + +- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。コンテナイメージの指定はコロンで終わらせる必要があります。 + +- **Number of pods** (必須): アプリケーションをデプロイするPodのターゲット数です。値は正の整数である必要があります。 + + クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。 + +- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。外部サービスの場合は、そのために1つ以上のポートを開放する必要があるかもしれません。詳細は[こちら](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)を参照してください。 + + クラスター内部からしか見えないその他のサービスは、内部サービスと呼ばれます。 + + サービスの種類にかかわらず、サービスを作成し、コンテナがポート(受信)をリッスンする場合は、2つのポートを指定する必要があります。サービスは、ポート(受信)をコンテナから見たターゲットポートにマッピングして作成されます。このサービスは、デプロイされたPodにルーティングされます。サポートされるプロトコルはTCPとUDPです。このサービスの内部DNS名は、上記のアプリケーション名として指定した値になります。 + +必要に応じて、**高度なオプション**セクションを展開して、より多くの設定を指定することができます: + +- **Description**: ここで入力したテキストは、[アノテーション](/ja/docs/concepts/overview/working-with-with-objects/annotations/)としてDeploymentに追加され、アプリケーションの詳細に表示されます。 + +- **Labels**: アプリケーションに使用するデフォルトの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)は、アプリケーション名とバージョンです。リリース、環境、ティア、パーティション、リリーストラックなど、Deployment、Service(存在する場合)、Podに適用する追加のラベルを指定できます。 + + 例: + + ```conf +release=1.0 +tier=frontend +environment=pod +track=stable +``` + +- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。 + + ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。名前空間名には、最大63文字の英数字とダッシュ(-)を含めることができますが、大文字を含めることはできません。 + 名前空間名は数字だけで構成されるべきではありません。名前が10などの数値として設定されている場合、Podはデフォルトの名前空間に配置されます。 + + 名前空間の作成に成功した場合は、デフォルトで選択されます。作成に失敗した場合は、最初の名前空間が選択されます。 + +- **Image Pull Secret**: 指定されたDockerコンテナイメージがプライベートの場合、[pull secret](/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。 + + ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。Secret名は最大253文字で構成されます。 + + イメージプルシークレットの作成に成功した場合は、デフォルトで選択されています。作成に失敗した場合は、シークレットは適用されません。 + +- **CPU requirement (cores)**と**Memory requirement (MiB)**: コンテナの最小[リソース制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)を指定することができます。デフォルトでは、PodはCPUとメモリの制限がない状態で実行されます。 + +- **Run command**と**Run command arguments**: デフォルトでは、コンテナは指定されたDockerイメージのデフォルトの[entrypointコマンド](/docs/tasks/inject-data-application/define-command-argument-container/)を実行します。コマンドのオプションと引数を使ってデフォルトを上書きすることができます。 + +- **Run as privileged**: この設定は、[特権コンテナ](/ja/docs/concepts/workloads/pods/pod/#privileged-mode-for-pod-containers)内のプロセスが、ホスト上でrootとして実行されているプロセスと同等であるかどうかを決定します。特権コンテナは、ネットワークスタックの操作やデバイスへのアクセスなどの機能を利用できます。 + +- **Environment variables**: Kubernetesは[環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)を介してServiceを公開しています。環境変数を作成したり、環境変数の値を使ってコマンドに引数を渡したりすることができます。環境変数の値はServiceを見つけるためにアプリケーションで利用できます。値は`$(VAR_NAME)`構文を使用して他の変数を参照できます。 + +### YAMLまたはJSONファイルのアップロード + +Kubernetesは宣言的な設定をサポートしています。このスタイルでは、すべての設定は Kubernetes [API](/ja/docs/concepts/overview/kubernetes-api/)リソーススキーマを使用してYAMLまたは JSON設定ファイルに格納されます。 + +デプロイウィザードでアプリケーションの詳細を指定する代わりに、YAMLまたはJSONファイルでアプリケーションを定義し、ダッシュボードを使用してファイルをアップロードできます。 + +## ダッシュボードの使用 +以下のセクションでは、Kubernetes Dashboard UIのビュー、それらが提供するものとその使用方法について説明します。 + +### ナビゲーション + +クラスターにKubernetesオブジェクトが定義されている場合、ダッシュボードではそれらのオブジェクトが初期表示されます。デフォルトでは_default_ 名前空間のオブジェクトのみが表示されますが、これはナビゲーションメニューにある名前空間セレクターで変更できます。 + +ダッシュボードにはほとんどのKubernetesオブジェクトの種類が表示され、いくつかのメニューカテゴリーにグループ化されています。 + +#### 管理者の概要 +クラスターと名前空間の管理者向けに、ダッシュボードにはノード、名前空間、永続ボリュームが一覧表示され、それらの詳細ビューが用意されています。ノードリストビューには、すべてのノードにわたって集計されたCPUとメモリーのメトリクスが表示されます。詳細ビューには、ノードのメトリクス、仕様、ステータス、割り当てられたリソース、イベント、ノード上で実行されているPodが表示されます。 + +#### ワークロード +選択した名前空間で実行されているすべてのアプリケーションを表示します。このビューでは、アプリケーションがワークロードの種類(例：Deployment、ReplicaSet、StatefulSetなど)ごとに一覧表示され、各ワークロードの種類を個別に表示することができます。リストには、ReplicaSetの準備ができたPodの数やPodの現在のメモリ使用量など、ワークロードに関する実用的な情報がまとめられています。 + +ワークロードの詳細ビューには、ステータスや仕様情報、オブジェクト間の表面関係が表示されます。たとえば、ReplicaSetが制御しているPodや、新しいReplicaSet、DeploymentのためのHorizontal Pod Autoscalerなどです。 + +#### Service +外部の世界にサービスを公開し、クラスター内でサービスを発見できるようにするKubernetesリソースを表示します。そのため、ServiceとIngressのビューには、それらが対象とするPod、クラスター接続の内部エンドポイント、外部ユーザーの外部エンドポイントが表示されます。 + +#### ストレージ +ストレージビューには、アプリケーションがデータを保存するために使用するPersistentVolumeClaimリソースが表示されます。 + +#### ConfigMapとSecret +クラスターで実行されているアプリケーションのライブ設定に使用されているすべてのKubernetesリソースを表示します。このビューでは、設定オブジェクトの編集と管理が可能で、デフォルトで非表示になっているSecretを表示します。 + +#### ログビューアー +Podのリストと詳細ページは、ダッシュボードに組み込まれたログビューアーにリンクしています。このビューアーでは、単一のPodに属するコンテナからログをドリルダウンすることができます。 + +![Logs viewer](/images/docs/ui-dashboard-logs-view.png) + +{{% /capture %}} + +{{% capture whatsnext %}} + +詳細については[Kubernetes Dashboardプロジェクトページ](https://github.com/kubernetes/dashboard)をご覧ください。 + +{{% /capture %}} From a1503f22e93433b46a1556a9751be596cd8ad41e Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 23 May 2020 13:35:38 +0900 Subject: [PATCH 082/290] update links to /ja/docs/tasks/access-application-cluster/web-ui-dashboard/ --- content/ja/docs/concepts/overview/components.md | 2 +- content/ja/docs/setup/learning-environment/minikube.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 8cee84861a..a1e8d7f7dd 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -102,7 +102,7 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ ### Web UI (ダッシュボード) -[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。 +[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。 ### コンテナリソース監視 diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index c626ae23ed..8758d54379 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -317,7 +317,7 @@ Minikubeはこのコンテキストを自動的にデフォルトに設定しま ### ダッシュボード -[Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください: +[Kubernetes Dashboard](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください: ```shell minikube dashboard From ef18c1afbb939611c6eca2489ae27353311b83e1 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 25 May 2020 09:04:38 +0900 Subject: [PATCH 083/290] update content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html --- content/ja/docs/concepts/workloads/pods/pod-overview.md | 2 +- .../kubernetes-basics/deploy-app/deploy-interactive.html | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 44388337c7..c3646c2100 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -13,7 +13,7 @@ card: {{% capture body %}} -## Podについて理解する +## Podについて理解する {#understanding-pods} *Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。 diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index c73fff32f4..16fb297c7b 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -17,6 +17,13 @@ weight: 20
+
+
+

+ Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。。 +

+
+

From a0a0a1b7c958a68314a6c5ab6fba62fc6fde626f Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 25 May 2020 09:07:37 +0900 Subject: [PATCH 084/290] update link to ja --- .../kubernetes-basics/deploy-app/deploy-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 16fb297c7b..c9d25cd3fb 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20

- Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。。 + Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。。

From 569315f3a43df834acfed5f83e2ea5f34c02118c Mon Sep 17 00:00:00 2001 From: taknakamura Date: Mon, 25 May 2020 17:44:24 +0900 Subject: [PATCH 085/290] Fix typos --- .../docs/concepts/services-networking/service.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index b0497ad567..3328dd5536 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -196,7 +196,7 @@ iptablesモードのkube-proxyが正常なバックエンドPodのみをリダ Serviceにアクセスするとき、IPVSはトラフィックをバックエンドのPodに向けます。 IPVSプロキシーモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。 -これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。　　 +これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。 他のプロキシーモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。 IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。 @@ -219,7 +219,7 @@ kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュー このダイアグラムのプロキシーモデルにおいて、ServiceのIP:Portに対するトラフィックは、クライアントがKubernetesのServiceやPodについて何も知ることなく適切にバックエンドにプロキシーされています。 -特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`を"ClientIP"にセットすることにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。 +特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`に"ClientIP"を設定することにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。 また、`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`を適切に設定することにより、セッションのタイムアウト時間を設定できます(デフォルトではこの値は18,000で、3時間となります)。 ## 複数のポートを公開するService @@ -357,7 +357,7 @@ Ingressは同一のIPアドレスにおいて、複数のServiceを公開する 各Nodeはそのポート(各Nodeで同じポート番号)への通信をServiceに転送します。 作成したServiceは、`.spec.ports[*].nodePort`フィールド内に割り当てられたポートを記述します。 -もしポートへの通信を転送する特定のIPを指定したい場合、特定のIPブロックをkube-proxyの`--nodeport-address`フラグで指定できます。これはKubernetesv1.10からサポートされています。 +もしポートへの通信を転送する特定のIPを指定したい場合、特定のIPブロックをkube-proxyの`--nodeport-address`フラグで指定できます。これはKubernetes v1.10からサポートされています。 このフラグは、コンマ区切りのIPブロックのリスト(例: 10.0.0./8, 192.0.2.0/25)を使用し、kube-proxyがこのNodeに対してローカルとみなすべきIPアドレスの範囲を指定します。 例えば、`--nodeport-addresses=127.0.0.0/8`というフラグによってkube-proxyを起動した時、kube-proxyはNodePort Serviceのためにループバックインターフェースのみ選択します。`--nodeport-addresses`のデフォルト値は空のリストになります。これはkube-proxyがNodePort Serviceに対して全てのネットワークインターフェースを利用可能とするべきということを意味します(これは以前のKubernetesのバージョンとの互換性があります)。 @@ -512,7 +512,7 @@ metadata: 2つ目のアノテーションはPodが利用するプロトコルを指定するものです。HTTPSとSSLの場合、ELBはそのPodが証明書を使って暗号化されたコネクションを介して自分自身のPodを認証すると推測します。 -HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwardef-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。 +HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwarded-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。 TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。 @@ -740,14 +740,14 @@ IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginx IPアドレスをハードコードする場合、[Headless Service](#headless-service)の使用を検討してください。 {{< /note >}} -`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`CNAME`レコードと`my.database.example.com`という値を返します。 +`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`my.database.example.com`という値をもつ`CNAME`レコードを返します。 `my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。 -後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。 +後にユーザーが使用しているデータベースをクラスター内に移行することになった場合は、Podを起動させ、適切なラベルセレクターやEndpointsを追加し、Serviceの`type`を変更します。 {{< warning >}} HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する際に問題が発生する場合があります。ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。 -ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストには、オリジンサーバーが認識しない`Host:`ヘッダーがあります。TLSサーバーは、クライアントが接続したホスト名に一致する証明書を提供できません。 +ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストがオリジンサーバーが認識しない`Host:`ヘッダーを持っていたなら、TLSサーバーはクライアントが接続したホスト名に一致する証明書を提供できません。 {{< /warning >}} {{< note >}} @@ -800,7 +800,7 @@ iptablesプロキシーモードはクラスター内の送信元IPを不明瞭 ### 衝突の回避 Kubernetesの主要な哲学のうちの一つは、ユーザーは、ユーザー自身のアクションによるミスでないものによって、ユーザーのアクションが失敗するような状況に晒されるべきでないことです。 -Serviceリソースの設計のでは、これはユーザーの指定したポートが衝突する可能性がある場合は、そのポートのServiceを作らないことを意味します。これは障害を分離することとなります。 +Serviceリソースの設計において、これはユーザーの指定したポートが衝突する可能性がある場合はそのポートのServiceを作らないことを意味します。これは障害を分離することとなります。 Serviceのポート番号を選択できるようにするために、我々はどの2つのServiceでもポートが衝突しないことを保証します。 Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てることで実現しています。 From 62411bda7682aa677a823e0f935dc031d790943f Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 26 May 2020 09:37:30 +0900 Subject: [PATCH 086/290] rename container-environment-variable to container-environment --- .../cluster-administration/cluster-administration-overview.md | 2 +- ...tainer-environment-variables.md => container-environment.md} | 2 +- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) rename content/ja/docs/concepts/containers/{container-environment-variables.md => container-environment.md} (98%) diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 3aec349748..645193d934 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -39,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る * [Certificates](/docs/concepts/cluster-administration/certificates/)では、異なるツールチェインを使用して証明書を作成する方法を説明します。 -* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment-variables/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。 +* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。 * [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。 diff --git a/content/ja/docs/concepts/containers/container-environment-variables.md b/content/ja/docs/concepts/containers/container-environment.md similarity index 98% rename from content/ja/docs/concepts/containers/container-environment-variables.md rename to content/ja/docs/concepts/containers/container-environment.md index 1057cc0518..c95248420b 100644 --- a/content/ja/docs/concepts/containers/container-environment-variables.md +++ b/content/ja/docs/concepts/containers/container-environment.md @@ -1,5 +1,5 @@ --- -title: コンテナ環境変数 +title: コンテナ環境 content_template: templates/concept weight: 20 --- diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 943e77aae2..da5949374e 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -97,7 +97,7 @@ Events: {{% capture whatsnext %}} -* [コンテナ環境](/docs/concepts/containers/container-environment-variables/)の詳細 +* [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン From 977614aae80eeaab9976f50397761ee52f8446d7 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 26 May 2020 14:20:06 +0900 Subject: [PATCH 087/290] Translate /docs/concepts/containers/overview/ into Japanese --- .../ja/docs/concepts/containers/overview.md | 31 +++++++++++++++++++ .../reference/glossary/container-runtime.md | 8 ++--- 2 files changed, 35 insertions(+), 4 deletions(-) create mode 100644 content/ja/docs/concepts/containers/overview.md diff --git a/content/ja/docs/concepts/containers/overview.md b/content/ja/docs/concepts/containers/overview.md new file mode 100644 index 0000000000..a5960ae116 --- /dev/null +++ b/content/ja/docs/concepts/containers/overview.md @@ -0,0 +1,31 @@ +--- +title: コンテナの概要 +content_template: templates/concept +weight: 1 +--- + +{{% capture overview %}} + +コンテナは、アプリケーションの(コンパイルされた)コードと、実行時に必要な依存関係をパッケージ化するための技術です。実行する各コンテナは再現性があります。依存関係を含めることによる標準化は、どこで実行しても同じ動作が得られることを意味します。 + +コンテナは、基礎となるホストインフラストラクチャからアプリケーションを切り離します。これにより、さまざまなクラウド環境やOS環境でのデプロイが容易になります。 + +{{% /capture %}} + + +{{% capture body %}} + +## コンテナイメージ {#container-images} +[コンテナイメージ](/docs/concepts/containers/images/)は、アプリケーションを実行するために必要なすべてのものを含んだ、すぐに実行可能なソフトウェアパッケージです。コードとそれが必要とする任意のランタイム、アプリケーションとシステムのライブラリ、および必須の設定のデフォルト値が含まれています。 + +設計上、コンテナは不変であるため、すでに実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり、変更を加えたい場合は、変更を含む新しいコンテナをビルドし、コンテナを再作成して更新されたイメージから起動する必要があります。 + +## コンテナランタイム {#container-runtimes} + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +{{% /capture %}} +{{% capture whatsnext %}} +* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。 +* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。 +{{% /capture %}} diff --git a/content/ja/docs/reference/glossary/container-runtime.md b/content/ja/docs/reference/glossary/container-runtime.md index 23cc888ee0..59d9dbb2bc 100644 --- a/content/ja/docs/reference/glossary/container-runtime.md +++ b/content/ja/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: コンテナランタイム id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /ja/docs/setup/production-environment/container-runtimes short_description: > コンテナランタイムは、コンテナの実行を担当するソフトウェアです。 @@ -16,7 +16,7 @@ tags: Kubernetesは次の複数のコンテナランタイムをサポートします。 -[Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), -[rktlet](https://github.com/kubernetes-incubator/rktlet) および全ての +{{< glossary_tooltip term_id="docker">}}、{{< glossary_tooltip term_id="containerd" >}}、{{< glossary_tooltip term_id="cri-o" >}}、 +および全ての [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) -実装。 +実装です。 From 99a96178addf2e8ab0866ba98ff5e0efe13cfedd Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 26 May 2020 18:30:16 +0900 Subject: [PATCH 088/290] update /ja/docs/concepts/storage/dynamic-provisioning/ --- content/ja/docs/concepts/storage/dynamic-provisioning.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/storage/dynamic-provisioning.md b/content/ja/docs/concepts/storage/dynamic-provisioning.md index e2361e5e83..5794451abb 100644 --- a/content/ja/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ja/docs/concepts/storage/dynamic-provisioning.md @@ -8,7 +8,7 @@ weight: 40 {{% capture overview %}} ボリュームの動的プロビジョニングにより、ストレージ用のボリュームをオンデマンドに作成することができます。 -動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。 +動的プロビジョニングなしでは、クラスター管理者はクラウドプロバイダーまたはストレージプロバイダーに対して新規のストレージ用のボリュームと[`PersistentVolume`オブジェクト](/ja/docs/concepts/storage/persistent-volumes/)を作成するように手動で指示しなければなりません。動的プロビジョニングの機能によって、クラスター管理者がストレージを事前にプロビジョンする必要がなくなります。その代わりに、ユーザーによってリクエストされたときに自動でストレージをプロビジョンします。 {{% /capture %}} @@ -20,11 +20,12 @@ weight: 40 ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメータを指定します。 クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメータのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。 -StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/persistent-volumes/#storageclasses)を参照ください。 +StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/storage-classes/)を参照ください。 ## 動的プロビジョニングを有効にする -動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。 +動的プロビジョニングを有効にするために、クラスター管理者はユーザーのために1つまたはそれ以上のStorageClassを事前に作成する必要があります。StorageClassオブジェクトは、動的プロビジョニングが実行されるときに、どのプロビジョナーが使用されるべきか、またどのようなパラメーターをプロビジョナーに渡すべきか定義します。StorageClassオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + 下記のマニフェストでは標準的な永続化ディスクをプロビジョンする"slow"というStorageClassを作成します。 ```yaml From 395235831558ce0aa5587e7d892509d5607aaa61 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 26 May 2020 18:31:37 +0900 Subject: [PATCH 089/290] update link to /ja/docs/concepts/storage/dynamic-provisioning/ --- .../reference/command-line-tools-reference/feature-gates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 506d526873..cf9b218670 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -333,7 +333,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。 - `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。 - `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。 -- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/docs/concepts/storage/dynamic-provisioning/)を有効にします。 +- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。 - `EnableAggregatedDiscoveryTimeout` (*非推奨*): 集約されたディスカバリーコールで5秒のタイムアウトを有効にします。 - `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。 - `EphemeralContainers`: 稼働するPodに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}を追加する機能を有効にします。 From a55ad8b0ad6bfdf4ee06ff7d211cb26922ea3218 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 27 May 2020 08:14:26 +0900 Subject: [PATCH 090/290] update /ja/docs/concepts/workloads/controllers/garbage-collection/ --- .../workloads/controllers/garbage-collection.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md index 0463849cd0..b81ba1a3be 100644 --- a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md @@ -33,7 +33,7 @@ kubectl get pods --output=yaml その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。 -```shell +```yaml apiVersion: v1 kind: Pod metadata: @@ -70,7 +70,7 @@ metadata: 一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。 -注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。 +注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion=true`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。 Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。 もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。 @@ -92,8 +92,8 @@ Kubernetes1.9において、`apps/v1`というグループバージョンにお ```shell kubectl proxy --port=8080 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ --d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ --H "Content-Type: application/json" + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ + -H "Content-Type: application/json" ``` 下記のコマンドは従属オブジェクトをフォアグラウンドで削除する例です。 @@ -101,8 +101,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep ```shell kubectl proxy --port=8080 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ --d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ --H "Content-Type: application/json" + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ + -H "Content-Type: application/json" ``` 下記のコマンドは従属オブジェクトをみなしご状態になった従属オブジェクトの例です。 @@ -110,8 +110,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep ```shell kubectl proxy --port=8080 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ --d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ --H "Content-Type: application/json" + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ + -H "Content-Type: application/json" ``` kubectlもまたカスケード削除をサポートしています。 From 65f558e9b9a7739168ea0c78cfadc970a3454e42 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 27 May 2020 08:16:46 +0900 Subject: [PATCH 091/290] update link to /ja/docs/concepts/workloads/controllers/garbage-collection/ --- .../docs/concepts/workloads/controllers/garbage-collection.md | 2 +- content/ja/docs/concepts/workloads/controllers/replicaset.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md index b81ba1a3be..d3f6cac7d4 100644 --- a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md @@ -12,7 +12,7 @@ Kubernetesのガベージコレクターの役割は、かつてオーナーが {{% capture body %}} -## オーナーとその従属オブジェクト +## オーナーとその従属オブジェクト {#owners-and-dependents} いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。 diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index 32e758774a..6e4b5a1734 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -18,7 +18,7 @@ ReplicaSetの目的は、どのような時でも安定したレプリカPodの ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。 -ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。 +ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/ja/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。 ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値がコントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 @@ -228,7 +228,7 @@ matchLabels: ### ReplicaSetとPodの削除 ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。 -[ガーベージコレクター](/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。 +[ガーベージコレクター](/ja/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。 REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。 例えば下記のように実行します。 From 039b5c715a9995cfc93383ec96ed1520283cdd46 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 27 May 2020 08:37:20 +0900 Subject: [PATCH 092/290] update /ja/docs/concepts/storage/volume-snapshot-classes/ --- .../storage/volume-snapshot-classes.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/storage/volume-snapshot-classes.md b/content/ja/docs/concepts/storage/volume-snapshot-classes.md index 829bde8a2e..a43ccf1fae 100644 --- a/content/ja/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ja/docs/concepts/storage/volume-snapshot-classes.md @@ -21,28 +21,35 @@ weight: 30 ## VolumeSnapshotClass リソース -各`VolumeSnapshotClass`は`snapshotter`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。 +各`VolumeSnapshotClass`は`driver`、`deletionPolicy`と`parameters`フィールドを含み、それらは、そのクラスに属する`VolumeSnapshot`が動的にプロビジョンされるときに使われます。 `VolumeSnapshotClass`オブジェクトの名前は重要であり、それはユーザーがどのように特定のクラスをリクエストできるかを示したものです。管理者は初めて`VolumeSnapshotClass`オブジェクトを作成するときに、その名前と他のパラメーターをセットし、そのオブジェクトは一度作成されるとそのあと更新することができません。 管理者は、バインド対象のクラスを1つもリクエストしないようなVolumeSnapshotのために、デフォルトの`VolumeSnapshotClass`を指定することができます。 ```yaml -apiVersion: snapshot.storage.k8s.io/v1alpha1 +apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -snapshotter: csi-hostpath +driver: hostpath.csi.k8s.io +deletionPolicy: Delete parameters: ``` -### Snapshotter +### Driver -VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`snapshotter`フィールドを持っています。このフィールドは必須となります。 +VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何のCSIボリュームプラグインを使うか決定するための`driver`フィールドを持っています。このフィールドは必須となります。 + +### DeletionPolicy + +VolumeSnapshotClassにはdeletionPolicyがあります。これにより、バインドされている `VolumeSnapshot`オブジェクトが削除されるときに、`VolumeSnapshotContent`がどうなるかを設定することができます。VolumeSnapshotのdeletionPolicyは、`Retain`または`Delete`のいずれかです。このフィールドは指定しなければなりません。 + +deletionPolicyが`Delete`の場合、基礎となるストレージスナップショットは `VolumeSnapshotContent`オブジェクトとともに削除されます。deletionPolicyが`Retain`の場合、基礎となるスナップショットと`VolumeSnapshotContent`の両方が残ります。 ## Parameters VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。 -`snapshotter`に応じて様々なパラメータを使用できます。 +`driver`に応じて様々なパラメータを使用できます。 {{% /capture %}} From dd28833b13d7a6af0446f9370a08d3a3f648f8ac Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 27 May 2020 08:52:35 +0900 Subject: [PATCH 093/290] update /ja/docs/tasks/debug-application-cluster/get-shell-running-container/ --- .../debug-application-cluster/get-shell-running-container.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 40f903789f..8795f53eb0 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -30,7 +30,7 @@ content_template: templates/task Podを作成します: ```shell -kubectl create -f https://k8s.io/examples/application/shell-demo.yaml +kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml ``` コンテナが実行中であることを確認します: From 417e5797ee98cfdadf4e3ade2f3cd33d78cb1842 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Wed, 27 May 2020 14:33:29 +0900 Subject: [PATCH 094/290] Translate /docs/tasks/inject-data-application/define-environment-variable-container/ into Japanese --- .../tasks/inject-data-application/_index.md | 4 + .../define-environment-variable-container.md | 113 ++++++++++++++++++ 2 files changed, 117 insertions(+) create mode 100644 content/ja/docs/tasks/inject-data-application/_index.md create mode 100644 content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md diff --git a/content/ja/docs/tasks/inject-data-application/_index.md b/content/ja/docs/tasks/inject-data-application/_index.md new file mode 100644 index 0000000000..52c5ca5128 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/_index.md @@ -0,0 +1,4 @@ +--- +title: "アプリケーションへのデータ注入" +weight: 30 +--- diff --git a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md new file mode 100644 index 0000000000..b32b002f90 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -0,0 +1,113 @@ +--- +title: コンテナの環境変数の定義 +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} + +このページでは、Kubernetes Podでコンテナの環境変数を定義する方法を説明します。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## コンテナの環境変数を定義する {#define-an-environment-variable-for-a-container} + +Podを作成するとき、そのPodで実行するコンテナに環境変数を設定することができます。環境変数を設定するには、設定ファイルに `env` または `envFrom` フィールドを含めます。 + +この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定ファイルを以下に示します: + +{{< codenew file="pods/inject/envars.yaml" >}} + +1. YAML設定ファイルに基づいてPodを作成します: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml + ``` + +1. 実行中のPodを一覧表示します: + + ```shell + kubectl get pods -l purpose=demonstrate-envars + ``` + + 出力は以下のようになります: + + ``` + NAME READY STATUS RESTARTS AGE + envar-demo 1/1 Running 0 9s + ``` + +1. Podで実行しているコンテナのシェルを取得します: + + ```shell + kubectl exec -it envar-demo -- /bin/bash + ``` + +1. シェルで`printenv`コマンドを実行すると、環境変数の一覧が表示されます。 + + ```shell + root@envar-demo:/# printenv + ``` + + 出力は以下のようになります: + + ``` + NODE_VERSION=4.4.2 + EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 + HOSTNAME=envar-demo + ... + DEMO_GREETING=Hello from the environment + DEMO_FAREWELL=Such a sweet sorrow + ``` + +1. シェルを終了するには、`exit`と入力します。 + +{{< note >}} +`env`または`envFrom`フィールドを使用して設定された環境変数は、コンテナイメージで指定された環境変数を上書きします。 +{{< /note >}} + +## 設定の中で環境変数を使用する {#using-environment-variables-inside-of-your-config} + +Podの設定で定義した環境変数は、Podのコンテナに設定したコマンドや引数など、設定の他の場所で使用することができます。以下の設定例では、環境変数`GREETING`、`HONORORIFIC`、`NAME`にそれぞれ `Warm greetings to`、`The Most Honorable`、`Kubernetes`を設定しています。これらの環境変数は、`env-print-demo`コンテナに渡されるCLI引数で使われます。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: print-greeting +spec: + containers: + - name: env-print-demo + image: bash + env: + - name: GREETING + value: "Warm greetings to" + - name: HONORIFIC + value: "The Most Honorable" + - name: NAME + value: "Kubernetes" + command: ["echo"] + args: ["$(GREETING) $(HONORIFIC) $(NAME)"] +``` + +作成されると、コンテナ上で`echo Warm greetings to The Most Honorable Kubernetes`というコマンドが実行されます。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細 +* [Secretを環境変数として使用する](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細 +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)をご覧ください。 + +{{% /capture %}} From 6154e75626535c1646aa6257fa9854b36cdb7388 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Thu, 28 May 2020 20:15:47 +0900 Subject: [PATCH 095/290] Update content/ja/docs/concepts/storage/volume-snapshot-classes.md Co-authored-by: bells17 --- content/ja/docs/concepts/storage/volume-snapshot-classes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/volume-snapshot-classes.md b/content/ja/docs/concepts/storage/volume-snapshot-classes.md index a43ccf1fae..6248b728c1 100644 --- a/content/ja/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ja/docs/concepts/storage/volume-snapshot-classes.md @@ -45,7 +45,7 @@ VolumeSnapshotClassは、VolumeSnapshotをプロビジョンするときに何 VolumeSnapshotClassにはdeletionPolicyがあります。これにより、バインドされている `VolumeSnapshot`オブジェクトが削除されるときに、`VolumeSnapshotContent`がどうなるかを設定することができます。VolumeSnapshotのdeletionPolicyは、`Retain`または`Delete`のいずれかです。このフィールドは指定しなければなりません。 -deletionPolicyが`Delete`の場合、基礎となるストレージスナップショットは `VolumeSnapshotContent`オブジェクトとともに削除されます。deletionPolicyが`Retain`の場合、基礎となるスナップショットと`VolumeSnapshotContent`の両方が残ります。 +deletionPolicyが`Delete`の場合、元となるストレージスナップショットは `VolumeSnapshotContent`オブジェクトとともに削除されます。deletionPolicyが`Retain`の場合、元となるスナップショットと`VolumeSnapshotContent`の両方が残ります。 ## Parameters From 61419d413bc1cd063b1d373eccd0540f2fe167c2 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Thu, 28 May 2020 20:18:21 +0900 Subject: [PATCH 096/290] Update content/ja/docs/concepts/workloads/controllers/replicaset.md Co-authored-by: bells17 --- content/ja/docs/concepts/workloads/controllers/replicaset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index 6e4b5a1734..dbbba89a8e 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -228,7 +228,7 @@ matchLabels: ### ReplicaSetとPodの削除 ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。 -[ガーベージコレクター](/ja/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。 +[ガベージコレクター](/ja/docs/concepts/workloads/controllers/garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。 REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。 例えば下記のように実行します。 From c40ab29f79c5c4af7dfc8c7a9ebf7af1c57bceeb Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Tue, 26 May 2020 10:02:41 +0900 Subject: [PATCH 097/290] Fix translation Recycle reclaim policy is deprecated, but not removed yet --- content/ja/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 3c0243791d..6e0b25877e 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -131,7 +131,7 @@ Events: #### リサイクル {{< warning >}} -`Recycle`再クレームポリシーは廃止されました。代わりに、動的プロビジョニングを使用することをおすすめします。 +`Recycle`再クレームポリシーは非推奨になりました。代わりに、動的プロビジョニングを使用することをおすすめします。 {{< /warning >}} 基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。 From 6b69b82ce6e152dcda20c90ab2f3a38108fea658 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 29 May 2020 08:16:20 +0900 Subject: [PATCH 098/290] update content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md --- .../api-extension/apiserver-aggregation.md | 20 +++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 5338d3071d..668fec2f34 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -1,24 +1,31 @@ --- title: アグリゲーションレイヤーを使ったKubernetes APIの拡張 content_template: templates/concept -weight: 10 +weight: 20 --- {{% capture overview %}} -アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。 +アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。追加のAPIは、[service-catalog](/docs/concepts/extend-kubernetes/service-catalog/)のような既製のソリューション、または自分で開発したAPIのいずれかです。 + +アグリゲーションレイヤーは、[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。 {{% /capture %}} {{% capture body %}} -## 概要 +## アグリゲーションレイヤー -アグリゲーションレイヤーを使用すると、クラスターにKubernetesスタイルのAPIを追加でインストールできます。これらは、[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)や、[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)のようなユーザーが作成したAPIなど、出来合いのもの、また既存のサードパーティソリューションに関わらず使い始めることができます。 +アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシーします。 -バージョン1.7において、アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、APIServiceオブジェクトを追加しなければなりません。それを追加すると、アグリゲーションレイヤーはAPIパス（例、/apis/myextension.mycompany.io/v1/…）への全てのアクセスを、登録されたAPIServiceにプロキシします。 +APIServiceを実装する最も一般的な方法は、クラスター内で実行されるPodで*拡張APIサーバー* を実行することです。クラスター内のリソース管理に拡張APIサーバーを使用している場合、拡張APIサーバー("extension-apiserver"とも呼ばれます)は通常、1つ以上の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}とペアになっています。apiserver-builderライブラリは、拡張APIサーバーと関連するコントローラーの両方にスケルトンを提供します。 -通常、APIServiceは、クラスター上で動いているPod内の *extension-apiserver* で実装されます。このextension-apiserverは、追加されたリソースに対するアクティブな管理が必要な場合、通常、1つか複数のコントローラーとペアになっている必要があります。そのため、実際にapiserver-builderはextension-apiserverとコントローラーの両方のスケルトンを提供します。一例として、service-catalogがインストールされると、extension-apiserverと提供するサービスのコントローラーの両方を提供します。 +### 応答遅延 + +拡張APIサーバーは、kube-apiserverとの間の低遅延ネットワーキングが必要です。 +kube-apiserverとの間を5秒以内に往復するためには、ディスカバリーリクエストが必要です。 + +拡張APIサーバーがそのレイテンシ要件を達成できない場合は、その要件を満たすように変更することを検討してください。また、kube-apiserverで`EnableAggregatedDiscoveryTimeout=false` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を設定することで、タイムアウト制限を無効にすることができます。この非推奨のフィーチャーゲートは将来のリリースで削除される予定です。 {{% /capture %}} @@ -27,6 +34,7 @@ weight: 10 * アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します * そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します * また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい +* [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい {{% /capture %}} From f442005c559979dc2ca0d27c65286f57aaf470aa Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 29 May 2020 08:47:02 +0900 Subject: [PATCH 099/290] update /ja/docs/concepts/storage/volume-pvc-datasource/ --- .../concepts/storage/volume-pvc-datasource.md | 28 +++++++++++-------- 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index 7b6cb90601..b277d7ad50 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -6,16 +6,9 @@ weight: 30 {{% capture overview %}} -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.16" state="beta" >}} このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。 -この機能を使用するにはVolumePVCDataSourceのフィーチャーゲートを有効にする必要があります。 - -``` ---feature-gates=VolumePVCDataSource=true -``` - - {{% /capture %}} @@ -27,14 +20,17 @@ weight: 30 複製は既存のKubernetesボリュームの複製として定義され、標準のボリュームと同じように使用できます。唯一の違いは、プロビジョニング時に「新しい」空のボリュームを作成するのではなく、バックエンドデバイスが指定されたボリュームの正確な複製を作成することです。 -複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のバインドされていないPVCをdataSourceとして指定する機能を追加するだけです。 +複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のPVCをdataSourceとして指定する機能を追加するだけです。ソースPVCはバインドされており、使用可能でなければなりません(使用中ではありません)。 この機能を使用する場合、ユーザーは次のことに注意する必要があります: * 複製のサポート(`VolumePVCDataSource`)はCSIドライバーのみです。 * 複製のサポートは動的プロビジョニングのみです。 * CSIドライバーはボリューム複製機能を実装している場合としていない場合があります。 -* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます（複製元と複製先は同じ名前空間になければなりません）。 +* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます(複製元と複製先は同じ名前空間になければなりません)。 +* 複製は同じストレージクラス内でのみサポートされます。 + - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。 + - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。 ## プロビジョニング @@ -48,13 +44,21 @@ metadata: name: clone-of-pvc-1 namespace: myns spec: - capacity: - storage: 10Gi + accessModes: + - ReadWriteOnce + storageClassName: cloning + resources: + requests: + storage: 5Gi dataSource: kind: PersistentVolumeClaim name: pvc-1 ``` +{{< note >}} +`spec.resources.requests.storage`に容量の値を指定する必要があります。指定する値は、ソースボリュームの容量と同じかそれ以上である必要があります。 +{{< /note >}} + このyamlの作成結果は指定された複製元である`pvc-1`と全く同じデータを持つ`clone-of-pvc-1`という名前の新しいPVCです。 ## 使い方 From 7a39e1a537cd0e97af48c58e07bbbd673b676bd0 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 29 May 2020 08:47:41 +0900 Subject: [PATCH 100/290] update link to /ja/docs/concepts/storage/volume-pvc-datasource/ --- content/ja/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 3c0243791d..acc4f662b5 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -624,7 +624,7 @@ spec: {{< feature-state for_k8s_version="v1.16" state="beta" >}} -ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/docs/concepts/storage/volume-pvc-datasource/)を参照してください。 +ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)を参照してください。 PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。 From f9c8f4910859e561ba17e84689232057721a38f7 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Fri, 29 May 2020 16:57:09 +0900 Subject: [PATCH 101/290] update /ja/docs/home/ --- content/ja/docs/home/_index.md | 9 ++- content/ja/training/_index.html | 118 ++++++++++++++++++++++++++++++++ 2 files changed, 126 insertions(+), 1 deletion(-) create mode 100644 content/ja/training/_index.html diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index c0f9abdb4c..fda3c24817 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -4,7 +4,7 @@ title: Kubernetesドキュメント noedit: true cid: docsHome layout: docsportal_home -class: gridPage +class: gridPage gridPageHome linkTitle: "ホーム" main_menu: true weight: 10 @@ -15,6 +15,8 @@ menu: weight: 20 post: >

チュートリアル、サンプルやドキュメントのリファレンスを使って Kubernetes の利用方法を学んでください。あなたはドキュメントへコントリビュートをすることもできます!

+description: > + Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。 overview: > Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています（CNCF）。 cards: @@ -38,6 +40,11 @@ cards: description: "一般的なタスク、そのタスクを短い手順でどのように実行するかを見てみます。" button: "タスクを見る" button_path: "/docs/tasks" +- name: training + title: "トレーニング" + description: "Kubernetesの資格を取得して、クラウドネイティブプロジェクトを成功させます！" + button: "トレーニングを見る" + button_path: "/training" - name: reference title: "リファレンス情報を調べる" description: "用語、コマンドラインの構文、APIリソースタイプ、そして構築ツールのドキュメントを見て回ります。" diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html new file mode 100644 index 0000000000..c966543062 --- /dev/null +++ b/content/ja/training/_index.html @@ -0,0 +1,118 @@ +--- +title: Training +bigheader: Kubernetes Training and Certification +abstract: Training programs, certifications, and partners. +layout: basic +cid: training +class: training +--- + +
+
+
+
+ +
+
+ +
+
+

Build your cloud native career

+

Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.

+
+
+
+
+ +
+
+
+

Take a free course on edX

+
+
+
+
+
+ Introduction to Kubernetes
  +
+

Want to learn Kubernetes? Get an in-depth primer on this powerful system for managing containerized applications.

+
+ Go to Course +
+
+
+
+
+ Introduction to Cloud Infrastructure Technologies +
+

Learn the fundamentals of building and managing cloud technologies directly from The Linux Foundation, the leader in open source.

+
+ Go to Course +
+
+
+
+
+ Introduction to Linux +
+

Never learned Linux? Want a refresh? Develop a good working knowledge of Linux using both the graphical interface and command line across the major Linux distribution families.

+
+ Go to Course +
+
+
+
+ +
+
+
+

Learn with the Linux Foundation

+

The Linux Foundation offers instructor-led and self-paced courses for all aspects of the Kubernetes application development and operations lifecycle.

+

+ See Courses +
+
+
+ +
+
+
+

Get Kubernetes Certified

+
+
+
+
+
+ Certified Kubernetes Application Developer (CKAD) +
+

The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.

+
+ Go to Certification +
+
+
+
+
+ Certified Kubernetes Administrator (CKA) +
+

The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.

+
+ Go to Certification +
+
+
+
+
+ +
+
+
+

Kubernetes Training Partners

+

Our network of Kubernetes Training Partners provide training services for Kubernetes and cloud native projects.

+
+
+
+ + +
+
\ No newline at end of file From d74236c1207a83a6c39ac1fbb122166bba75168a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=88=B8=E3=83=B6=E9=87=8C=E5=81=A5=E6=99=9F?= Date: Sat, 30 May 2020 15:18:42 +0900 Subject: [PATCH 102/290] add glossary_tooltip and change word --- content/ja/docs/reference/glossary/persistent-volume-claim.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/persistent-volume-claim.md b/content/ja/docs/reference/glossary/persistent-volume-claim.md index 641b23eb8d..35b8c9b46b 100644 --- a/content/ja/docs/reference/glossary/persistent-volume-claim.md +++ b/content/ja/docs/reference/glossary/persistent-volume-claim.md @@ -11,9 +11,9 @@ tags: - core-object - storage --- - コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。 + {{< glossary_tooltip text="container" term_id="container" >}}内でボリュームとしてマウントするために {{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。 -ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeの仕様にあります。 +ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。 From fd983d10464835387082c2a6b0dba81a94963562 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 30 May 2020 15:19:11 +0900 Subject: [PATCH 103/290] update /ja/docs/setup/best-practices/multiple-zones/ --- content/ja/docs/setup/best-practices/multiple-zones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 64e28a2762..bf657ce266 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -184,7 +184,7 @@ kubernetes-minion-wf8i Ready 2m v1.13.0 Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity): -```json +```bash kubectl apply -f - < Date: Sat, 30 May 2020 15:46:59 +0900 Subject: [PATCH 104/290] author From a88c4aa9a8cb4908cef59e1233349927d68d3208 Mon Sep 17 00:00:00 2001 From: Bo0km4n Date: Sat, 30 May 2020 15:55:21 +0900 Subject: [PATCH 105/290] Add glossary_tooltip and change word --- content/ja/docs/reference/glossary/kubelet.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/kubelet.md b/content/ja/docs/reference/glossary/kubelet.md index a9d02ce0ad..56256d07db 100755 --- a/content/ja/docs/reference/glossary/kubelet.md +++ b/content/ja/docs/reference/glossary/kubelet.md @@ -11,8 +11,7 @@ tags: - fundamental - core-object --- - クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。 + クラスター内の{{< glossary_tooltip text="node" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="containers" term_id="container" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}で実行されていることを保証します。 - -kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態に保ちます。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。 +kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態を保証します。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。 From 2071649889b643e615efaa557b62f44a3eecb394 Mon Sep 17 00:00:00 2001 From: kenseitogari <40294304+kenseitogari@users.noreply.github.com> Date: Sat, 30 May 2020 16:14:06 +0900 Subject: [PATCH 106/290] Update content/ja/docs/reference/glossary/persistent-volume-claim.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/persistent-volume-claim.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/persistent-volume-claim.md b/content/ja/docs/reference/glossary/persistent-volume-claim.md index 35b8c9b46b..7366429a24 100644 --- a/content/ja/docs/reference/glossary/persistent-volume-claim.md +++ b/content/ja/docs/reference/glossary/persistent-volume-claim.md @@ -11,9 +11,8 @@ tags: - core-object - storage --- - {{< glossary_tooltip text="container" term_id="container" >}}内でボリュームとしてマウントするために {{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。 + {{< glossary_tooltip text="コンテナ" term_id="container" >}}内でボリュームとしてマウントするために{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}内で定義されたストレージリソースを要求します。 ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeオブジェクトに記載されています。 - From 5708f38eb84660773e67e856f677d2667e00d24c Mon Sep 17 00:00:00 2001 From: Bo0km4n Date: Sat, 30 May 2020 16:25:27 +0900 Subject: [PATCH 107/290] Translate text to ja in glossary text --- content/ja/docs/reference/glossary/kubelet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/kubelet.md b/content/ja/docs/reference/glossary/kubelet.md index 56256d07db..147de13074 100755 --- a/content/ja/docs/reference/glossary/kubelet.md +++ b/content/ja/docs/reference/glossary/kubelet.md @@ -11,7 +11,7 @@ tags: - fundamental - core-object --- - クラスター内の{{< glossary_tooltip text="node" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="containers" term_id="container" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}で実行されていることを保証します。 + クラスター内の各{{< glossary_tooltip text="ノード" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="コンテナ" term_id="container" >}}が{{< glossary_tooltip text="ポッド" term_id="pod" >}}で実行されていることを保証します。 kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態を保証します。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。 From 5aa6a4946656e5907b433ae95c9f18a2e55d8ccd Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 30 May 2020 17:02:28 +0900 Subject: [PATCH 108/290] update /ja/docs/setup/best-practices/node-conformance/ --- content/ja/docs/setup/best-practices/node-conformance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index d4719288b0..129bd762ba 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -82,7 +82,7 @@ sudo docker run -it --rm --privileged --net=host \ k8s.gcr.io/node-test:0.2 ``` -Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md). +Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). By default, it runs all conformance tests. Theoretically, you can run any node e2e test if you configure the container and From a647204a0423c410fbf0aa748adcad32495218f6 Mon Sep 17 00:00:00 2001 From: Bo0km4n Date: Sat, 30 May 2020 18:00:17 +0900 Subject: [PATCH 109/290] Fix 'node' glossary text --- content/ja/docs/reference/glossary/kubelet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/kubelet.md b/content/ja/docs/reference/glossary/kubelet.md index 147de13074..55492ceeff 100755 --- a/content/ja/docs/reference/glossary/kubelet.md +++ b/content/ja/docs/reference/glossary/kubelet.md @@ -11,7 +11,7 @@ tags: - fundamental - core-object --- - クラスター内の各{{< glossary_tooltip text="ノード" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="コンテナ" term_id="container" >}}が{{< glossary_tooltip text="ポッド" term_id="pod" >}}で実行されていることを保証します。 + クラスター内の各{{< glossary_tooltip text="ノード" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="コンテナ" term_id="container" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}で実行されていることを保証します。 kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態を保証します。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。 From e09e0367eacda339063be951036381a041afa325 Mon Sep 17 00:00:00 2001 From: nishipy Date: Sat, 30 May 2020 18:37:58 +0900 Subject: [PATCH 110/290] add glossary_tooltip and change word --- content/ja/docs/reference/glossary/selector.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/selector.md b/content/ja/docs/reference/glossary/selector.md index c46b47e42c..24d6bcdf53 100755 --- a/content/ja/docs/reference/glossary/selector.md +++ b/content/ja/docs/reference/glossary/selector.md @@ -10,8 +10,8 @@ aka: tags: - fundamental --- - ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。 + ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。 -セレクターは、リソースのリストを照会して{{< glossary_tooltip text="ラベル" term_id="label" >}}でフィルターするときに適用されます。 +セレクターは、リソースのリストを照会してラベルでフィルターするときに適用されます。 From f3f0a0a6888f9bce7a5113c7a44c53850884499d Mon Sep 17 00:00:00 2001 From: Tomoya AMACHI Date: Sat, 30 May 2020 19:57:06 +0900 Subject: [PATCH 111/290] update sig docs(Ja) --- content/ja/docs/reference/glossary/sig.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/sig.md b/content/ja/docs/reference/glossary/sig.md index 79a5b67453..ffc3b5ab70 100755 --- a/content/ja/docs/reference/glossary/sig.md +++ b/content/ja/docs/reference/glossary/sig.md @@ -15,7 +15,7 @@ tags: SIGのメンバーは、アーキテクチャ、API machinery、ドキュメンテーションといった、特定のエリアの改善に共通の関心をもっています。 -SIGは[SIGガバナンス](https://github.com/kubernetes/community/blob/master/sig-governance.md)ガイドラインに準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。 +SIGは[ガバナンスガイドライン](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md)に準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。 さらなる情報は[コミュニティ (kubernetes/community)](https://github.com/kubernetes/community)リポジトリと[SIGとワーキンググループ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照して下さい。 From 332a99a47f737ff3e309d58b48cb45847ebe00be Mon Sep 17 00:00:00 2001 From: TAKAHASHI Yuto Date: Sat, 30 May 2020 20:51:07 +0900 Subject: [PATCH 112/290] Make glossary/kube-scheduler.md follow v1.17 of the original text --- content/ja/docs/reference/glossary/kube-scheduler.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/kube-scheduler.md b/content/ja/docs/reference/glossary/kube-scheduler.md index a83f64aafe..26cc473556 100755 --- a/content/ja/docs/reference/glossary/kube-scheduler.md +++ b/content/ja/docs/reference/glossary/kube-scheduler.md @@ -4,14 +4,14 @@ id: kube-scheduler date: 2018-04-12 full_link: /docs/reference/generated/kube-scheduler/ short_description: > - マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。 + コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。 aka: tags: - architecture --- - マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。 + コントロールプレーン上で動作するコンポーネントで、新しく作られた{{< glossary_tooltip term_id="pod" text="Pod" >}}に{{< glossary_tooltip term_id="node" text="ノード" >}}が割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。 -スケジューリング決定で考慮される要素には、個々および集団のリソース要件、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉と有効期限が含まれます。 +スケジューリングの決定は、PodあるいはPod群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。 From 0a60e461394733209b82f37382c0b7ac25defe86 Mon Sep 17 00:00:00 2001 From: chez-shanpu Date: Sat, 30 May 2020 21:15:24 +0900 Subject: [PATCH 113/290] update ja glossary kube-apiserver --- .../ja/docs/reference/glossary/kube-apiserver.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/reference/glossary/kube-apiserver.md b/content/ja/docs/reference/glossary/kube-apiserver.md index 501333c850..29885884fe 100755 --- a/content/ja/docs/reference/glossary/kube-apiserver.md +++ b/content/ja/docs/reference/glossary/kube-apiserver.md @@ -1,18 +1,22 @@ --- -title: kube-apiserver +title: APIサーバー id: kube-apiserver date: 2018-04-12 full_link: /docs/reference/generated/kube-apiserver/ short_description: > - Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。 + Kubernetes APIを提供するコントロールプレーンのコンポーネントです。 -aka: +aka: +- kube-apiserver tags: - architecture - fundamental --- - Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。 + APIサーバーは、Kubernetes APIを外部に提供するKubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}のコンポーネントです。 + APIサーバーはKubernetesコントロールプレーンのフロントエンドになります。 - + -このコンポーネントは、水平スケールするように設計されています。つまり追加でインスタンスを足すことでスケール可能です。さらなる情報は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。 +Kubernetes APIサーバーの主な実装は[kube-apiserver](/docs/reference/generated/kube-apiserver/)です。 +kube-apiserverは水平方向にスケールするように設計されています—つまり、インスタンスを追加することでスケールが可能です。 +複数のkube-apiserverインスタンスを実行することで、インスタンス間でトラフィックを分散させることが可能です。 \ No newline at end of file From 3fd9bfbf59b3dd963efc5e53b2d4f8ac5d9d5a28 Mon Sep 17 00:00:00 2001 From: kondo takeshi Date: Sat, 30 May 2020 23:02:34 +0900 Subject: [PATCH 114/290] Transrate glossary/cluster.md to Japanese --- content/ja/docs/reference/glossary/cluster.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/cluster.md b/content/ja/docs/reference/glossary/cluster.md index e88814a730..d933f1c4ce 100644 --- a/content/ja/docs/reference/glossary/cluster.md +++ b/content/ja/docs/reference/glossary/cluster.md @@ -5,14 +5,15 @@ date: 2019-06-15 full_link: short_description: > - Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。 + コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。 aka: tags: - fundamental - operation --- -Kubernetesが管理するコンテナ化されたアプリケーションを実行する、ノードと呼ばれるマシンの集合です。クラスターには、少なくとも1つのワーカーノードと少なくとも1つのマスターノードがあります。 +コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。 -ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。 \ No newline at end of file +ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。 +ワーカーノードは、アプリケーションワークロードのコンポーネントであるPodをホストします。コントロールプレーンは、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピュータを使用し、クラスターは複数のノードを使用し、フォールトトレランスや高可用性を提供します。 From e704167fd2b6272b85b97329079a1f0b95a228a7 Mon Sep 17 00:00:00 2001 From: Takamichi Omori Date: Sat, 30 May 2020 23:09:13 +0900 Subject: [PATCH 115/290] Make glossary/kube-proxy.md follow v1.17 of the original text --- content/ja/docs/reference/glossary/kube-proxy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/kube-proxy.md b/content/ja/docs/reference/glossary/kube-proxy.md index 0f36361539..ed06dd2f2f 100755 --- a/content/ja/docs/reference/glossary/kube-proxy.md +++ b/content/ja/docs/reference/glossary/kube-proxy.md @@ -11,10 +11,10 @@ tags: - fundamental - networking --- - [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) はクラスター内の各Nodeで動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。 + kube-proxy はクラスター内の各{{< glossary_tooltip text="node" term_id="node" >}}で動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。 -kube-proxyは、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。 +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)は、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。 kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。 From c4bdfc01d671e76d15f8cc46a1730c006aa80247 Mon Sep 17 00:00:00 2001 From: Takamichi Omori Date: Sat, 30 May 2020 23:35:05 +0900 Subject: [PATCH 116/290] remove a space behind a word --- content/ja/docs/reference/glossary/kube-proxy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/kube-proxy.md b/content/ja/docs/reference/glossary/kube-proxy.md index ed06dd2f2f..011decd4d5 100755 --- a/content/ja/docs/reference/glossary/kube-proxy.md +++ b/content/ja/docs/reference/glossary/kube-proxy.md @@ -11,7 +11,7 @@ tags: - fundamental - networking --- - kube-proxy はクラスター内の各{{< glossary_tooltip text="node" term_id="node" >}}で動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。 + kube-proxyはクラスター内の各{{< glossary_tooltip text="node" term_id="node" >}}で動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。 From edf0eccd47ee586e9cd6cc33f81d488a993bd11e Mon Sep 17 00:00:00 2001 From: ytakaya Date: Sun, 31 May 2020 00:04:37 +0900 Subject: [PATCH 117/290] update volume docs(Ja) --- content/ja/docs/reference/glossary/volume.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 7d7235e20e..1006697c82 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -11,8 +11,10 @@ tags: - core-object - fundamental --- - {{< glossary_tooltip text="ポッド" term_id="pod" >}}内のコンテナからアクセス可能なデータを含むディレクトリ。 + {{< glossary_tooltip text="ポッド" term_id="pod" >}}内の{{< glossary_tooltip text="containers" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 -Kubernetesボリュームはボリュームを含む{{< glossary_tooltip text="ポッド" term_id="pod" >}}が存在する限り有効です。そのためボリュームは{{< glossary_tooltip text="ポッド" term_id="pod" >}}内で実行されるすべての{{< glossary_tooltip text="コンテナ" term_id="container" >}}よりも長持ちし、{{< glossary_tooltip text="コンテナ" term_id="container" >}}の再起動後もデータは保持されます。 +Kubernetesボリュームはボリュームを含むポッドが存在する限り有効です。そのためボリュームはポッド内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。 + +詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。 \ No newline at end of file From 485fecc80001607d53111918ea4bbc168f967265 Mon Sep 17 00:00:00 2001 From: KJ Date: Sun, 31 May 2020 01:14:54 +0900 Subject: [PATCH 118/290] Make glossary/kube-controller-manager.md follow v1.17 of the original text --- .../ja/docs/reference/glossary/kube-controller-manager.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/kube-controller-manager.md b/content/ja/docs/reference/glossary/kube-controller-manager.md index e79840204b..f2e2816d72 100755 --- a/content/ja/docs/reference/glossary/kube-controller-manager.md +++ b/content/ja/docs/reference/glossary/kube-controller-manager.md @@ -4,15 +4,15 @@ id: kube-controller-manager date: 2018-04-12 full_link: /docs/reference/generated/kube-controller-manager/ short_description: > - マスター上に存在し、コントローラーを実行するコンポーネントです。 + コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。 aka: tags: - architecture - fundamental --- - マスター上に存在し、{{< glossary_tooltip text="controllers" term_id="controller" >}}を実行するコンポーネントです。 + コントロールプレーン上で動作するコンポーネントで、複数の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}プロセスを実行します。 -論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は個別のプロセスですが、複雑になるのを避けるために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。 +論理的には、各{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は個別のプロセスですが、複雑さを減らすために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。 From 10b656a9e08672078637875e9527a0620942da89 Mon Sep 17 00:00:00 2001 From: Takeshi Kondo <10370988+chaspy@users.noreply.github.com> Date: Sun, 31 May 2020 05:54:07 +0900 Subject: [PATCH 119/290] Update content/ja/docs/reference/glossary/cluster.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/cluster.md b/content/ja/docs/reference/glossary/cluster.md index d933f1c4ce..17437bdfbe 100644 --- a/content/ja/docs/reference/glossary/cluster.md +++ b/content/ja/docs/reference/glossary/cluster.md @@ -16,4 +16,4 @@ tags: ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。 -ワーカーノードは、アプリケーションワークロードのコンポーネントであるPodをホストします。コントロールプレーンは、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピュータを使用し、クラスターは複数のノードを使用し、フォールトトレランスや高可用性を提供します。 +ワーカーノードは、アプリケーションワークロードのコンポーネントである{{< glossary_tooltip text="Pod" term_id="pod" >}}をホストします。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピューターを使用し、クラスターは複数のノードを使用し、耐障害性や高可用性を提供します。 From 0a96c4b01aa33e883f854df94d5eb6d427d381e7 Mon Sep 17 00:00:00 2001 From: Takeshi Kondo <10370988+chaspy@users.noreply.github.com> Date: Sun, 31 May 2020 05:54:22 +0900 Subject: [PATCH 120/290] Update content/ja/docs/reference/glossary/cluster.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/cluster.md b/content/ja/docs/reference/glossary/cluster.md index 17437bdfbe..bf2450aeb9 100644 --- a/content/ja/docs/reference/glossary/cluster.md +++ b/content/ja/docs/reference/glossary/cluster.md @@ -12,7 +12,7 @@ tags: - fundamental - operation --- -コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。 +コンテナ化されたアプリケーションを実行する、{{< glossary_tooltip text="ノード" term_id="node" >}}と呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。 ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。 From 113a27e7bbfca43e4f85b82fa7bb5b46a2c7885a Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 06:37:49 +0900 Subject: [PATCH 121/290] Update full_link content/ja/docs/reference/glossary/kube-controller-manager.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/kube-controller-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/kube-controller-manager.md b/content/ja/docs/reference/glossary/kube-controller-manager.md index f2e2816d72..69c145b477 100755 --- a/content/ja/docs/reference/glossary/kube-controller-manager.md +++ b/content/ja/docs/reference/glossary/kube-controller-manager.md @@ -2,7 +2,7 @@ title: kube-controller-manager id: kube-controller-manager date: 2018-04-12 -full_link: /docs/reference/generated/kube-controller-manager/ +full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ short_description: > コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。 From 261aba0bc94119711779169ca4ebd0d452b84e5f Mon Sep 17 00:00:00 2001 From: KJ Date: Sun, 31 May 2020 09:44:36 +0900 Subject: [PATCH 122/290] Translate /docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ into Japanese --- ...igure-liveness-readiness-startup-probes.md | 339 ++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md new file mode 100644 index 0000000000..c652c06ea8 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -0,0 +1,339 @@ +--- +title: Liveness Probe、Readiness Probe および Startup Probeを使用する +content_template: templates/task +weight: 110 +--- + +{{% capture overview %}} + +このページでは、Liveness Probe、Readiness Probe および Startup Probeの使用方法について説明します。 + +[kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。 +例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。 +このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。 + +kubeletは、Readiness Probeを使用して、コンテナがトラフィックを受け入れられる状態であるかを認識します。 +Podが準備ができていると見なされるのは、Pod内の全てのコンテナの準備が整ったときです。 +一例として、このシグナルはServiceのバックエンドとして使用されるPodの制御するときに使用されます。 +Podの準備ができていない場合、そのPodはServiceのロードバランシングから切り離されます。 + +kubeletは、Startup Probeを使用して、コンテナアプリケーションの起動が完了したかを認識します。 +Startup Probeを使用している場合、Startup Probeが成功するまでは、Liveness Probeと +Readiness Probeによるチェックを無効にし、これらがアプリケーションの起動に干渉しないようにします。 +例えば、これを起動が遅いコンテナの起動チェックとして使用することで、kubeletによって起動する前に +強制終了されることを防ぐことができます。 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## コマンド実行によるLiveness Probeを定義する {#define-a-liveness-command} + +多くのアプリケーションは、長期間実行されている場合に、再起動されるまで回復できないような異常な状態になることがあります。 +Kubernetesは、このような状況を検知し、回復するためのLiveness Probeを提供します。 + +この演習では、`k8s.gcr.io/busybox`イメージのコンテナを起動するPodを作成します。 +Podの構成ファイルは次の通りです。 + +{{< codenew file="pods/probe/exec-liveness.yaml" >}} + +この構成ファイルでは、Podは一つの`Container`を起動します。 +`periodSeconds`フィールドは、kubeletがLiveness Probeを5秒おきに行うように指定しています。 +`initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に5秒間待機するように指示しています。 +Probeの動作としては、kubeletは`cat /tmp/healthy`を目標となるコンテナ内で実行します。 +このコマンドが成功し、リターンコード0が返ると、kubeletはコンテナが問題なく動いていると判断します。 +リターンコードとして0以外の値が返ると、kubeletはコンテナを終了し、再起動を行います。 + +コンテナが起動すると、次のコマンドを実行します: + +```shell +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +``` + +コンテナが起動してから初めの30秒間は`/tmp/healthy`ファイルがコンテナ内に存在します。 +そのため初めの30秒間は`cat /tmp/healthy`コマンドは成功し、正常なリターンコードが返ります。 +その後30秒が経過すると、`cat /tmp/healthy`コマンドは異常なリターンコードを返します。 + +このPodを起動してください: + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml +``` + +30秒間以内に、Podのイベントを確認します。 + +```shell +kubectl describe pod liveness-exec +``` + +この出力結果は、Liveness Probeがまだ失敗していないことを示しています。 + +``` +FirstSeen LastSeen Count From SubobjectPath Type Reason Message +--------- -------- ----- ---- ------------- -------- ------ ------- +24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] +23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e +``` + +35秒後に、Podのイベントをもう一度確認します: + +```shell +kubectl describe pod liveness-exec +``` + +出力結果の最後に、Liveness Probeが失敗していることを示すメッセージがあります。 + +``` +FirstSeen LastSeen Count From SubobjectPath Type Reason Message +--------- -------- ----- ---- ------------- -------- ------ ------- +37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] +36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e +2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory +``` + +さらに30秒後、コンテナが再起動していることを確認します: + +```shell +kubectl get pod liveness-exec +``` + +出力結果から、`RESTARTS`がインクリメントされていることを確認します: + +``` +NAME READY STATUS RESTARTS AGE +liveness-exec 1/1 Running 1 1m +``` + +## HTTPリクエストによるLiveness Probeを定義する {#define-a-liveness-http-request} + +別の種類のLiveness Probeでは、HTTP GETリクエストを使用します。 +次の構成ファイルは、`k8s.gcr.io/liveness`イメージを使用したコンテナを起動するPodを作成します。 + +{{< codenew file="pods/probe/http-liveness.yaml" >}} + +この構成ファイルでは、Podは一つの`Container`を起動します。 +`periodSeconds`フィールドは、kubeletがLiveness Probeを3秒おきに行うように指定しています。 +`initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に3秒間待機するように指示しています。 +Probeの動作としては、kubeletは8080ポートをリッスンしているコンテナ内のサーバーに対してHTTP GETリクエストを送ります。 +サーバー内の`/healthz`パスに対するハンドラーが正常なリターンコードを応答した場合、 +kubeletはコンテナが問題なく動いていると判断します。 +異常なリターンコードを応答すると、kubeletはコンテナを終了し、再起動を行います。 + +200以上400未満のコードは成功とみなされ、その他のコードは失敗とみなされます。 + +[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go) +にてサーバーのソースコードを確認することができます。 + +コンテナが生きている初めの10秒間は、`/healthz`ハンドラーが200ステータスを返します。 +その後、ハンドラーは500ステータスを返します。 + +```go +http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { + duration := time.Now().Sub(started) + if duration.Seconds() > 10 { + w.WriteHeader(500) + w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) + } else { + w.WriteHeader(200) + w.Write([]byte("ok")) + } +}) +``` + +kubeletは、コンテナが起動してから3秒後からヘルスチェックを行います。 +そのため、初めのいくつかのヘルスチェックは成功します。しかし、10秒経過するとヘルスチェックは失敗し、kubeletはコンテナを終了し、再起動します。 + +HTTPリクエストのチェックによるLiveness Probeを試すには、以下のようにPodを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml +``` + +10秒後、Podのイベントを表示し、Liveness Probeが失敗し、コンテナが再起動されていることを確認します。 + +```shell +kubectl describe pod liveness-http +``` + +v1.13以前（v1.13を含む）のリリースにおいては、Podが起動しているノードにおいて、環境変数`http_proxy` +（または `HTTP_PROXY`）が設定されている場合、HTTPリクエストのLiveness Probeは、設定されたプロキシを使用します。 +v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定は、HTTPリクエストのLiveness Probeに影響しません。 + +## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe} + +3つ目のLiveness Probeは、TCPソケットを使用するタイプです。 +この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。 +コネクションを確立できる場合、コンテナを正常とみなし、失敗する場合は、異常とみなします。 + +{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} + +見ての通り、TCPによるチェックの構成は、HTTPによるチェックと非常に似ています。 +この例では、Readiness ProbeとLiveness Probeを両方使用しています。 +kubeletは、コンテナが起動してから5秒後に、最初のReadiness Probeを開始します。 +これは、`goproxy`コンテナの8080ポートに対して、接続を試みます。 +このProbeが成功する、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 + +この構成では、Readiness Probeに加えて、Liveness Probeが含まれています。 +kubeletは、コンテナが起動してから15秒後に、最初のLiveness Probeを行います。 +Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して、接続を試みます。 +Liveness Probeが失敗した場合、コンテナは再起動されます。 + +TCPのチェックによるLiveness Probeを試すには、以下のようにPodを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml +``` + +15秒後、Podのイベントを表示し、Liveness Probeが行われていることを確認します: + +```shell +kubectl describe pod goproxy +``` + +## 名前付きポートを使用する {#use-a-named-port} + +HTTPまたはTCPによるProbeにおいて、[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core) +で定義した名前付きポートを使用することができます。 + +```yaml +ports: +- name: liveness-port + containerPort: 8080 + hostPort: 8080 + +livenessProbe: + httpGet: + path: /healthz + port: liveness-port +``` + +## Startup Probeを使用して、起動の遅いコンテナを保護する {#define-startup-probes} + +場合によっては、最初の初期化において、追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。 +そのような場合において、デッドロックに対する迅速な反応を損なうことなく、Liveness Probeのパラメーターを設定することは難しい場合があります。 + +これに対する解決策の一つは、Liveness Probeと同じ構成のコマンド、HTTPまたはTCPによるチェックを使用した、Startup Probeをセットアップすることです。 +その際、`failureThreshold * periodSeconds`で計算される時間を、起動時間として想定される最も遅いケースをカバーできる十分な長さに設定します。 + +上記の例は、次のようになります: + +```yaml +ports: +- name: liveness-port + containerPort: 8080 + hostPort: 8080 + +livenessProbe: + httpGet: + path: /healthz + port: liveness-port + failureThreshold: 1 + periodSeconds: 10 + +startupProbe: + httpGet: + path: /healthz + port: liveness-port + failureThreshold: 30 + periodSeconds: 10 +``` + +Startup Probeにより、アプリケーションは起動が完了するまでに最大5分間の猶予（30 * 10 = 300秒）が与えられます。 +Startup Probeに一度成功すると、その後はLiveness Probeが引き継ぎ、コンテナのデッドロックに対して迅速に反応します。 +Startup Probeが成功しない場合、コンテナは300秒後に終了し、その後はPodの`restartPolicy`に従います。 + +## Readiness Probeを定義する {#define-readiness-probes} + +アプリケーションは、一時的にトラフィックを処理できないことが起こり得ます。 +例えば、アプリケーションは、起動時に大きなデータまたは構成ファイルを読み込む必要がある場合や、起動後に外部サービスに依存する可能性があります。 +このような場合、アプリケーションを終了させたくありませんが、リクエストを受けたくないと思います。 +Kubernetesは、これらの状況を検知して緩和するための機能として、Readiness Probeを提供します。 +準備できていないことを報告するコンテナを含むPodは、KubernetesのServiceからトラフィックを受信しないようにできます。 + +{{< note >}} +Readiness Probeは、コンテナの全てのライフサイクルにおいて実行されます。 +{{< /note >}} + +Readiness Probeは、Liveness Probeと同様に構成します。 +唯一の違いは、`readinessProbe`フィールドを`livenessProbe` フィールドの代わりに利用することだけです。 + +```yaml +readinessProbe: + exec: + command: + - cat + - /tmp/healthy + initialDelaySeconds: 5 + periodSeconds: 5 +``` + +HTTPおよびTCPによるReadiness Probeの構成も、Liveness Probeと同じです。 + +Readiness ProbeとLiveness Probeは、同じコンテナで同時に使用できます。 +両方使用することで、準備できていないコンテナへのトラフィックが到達しないようにし、コンテナが失敗したときに再起動することができます。 + +## Probeの構成 {#configure-probes} + +{{< comment >}} +Eventually, some of this section could be moved to a concept topic. +{{< /comment >}} + +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) には、 +Liveness ProbeおよびReadiness Probeのチェック動作を、より正確に制御するために使用できるいくつかのフィールドがあります: + +* `initialDelaySeconds`: コンテナが起動してから、Liveness ProbeまたはReadiness Probeが開始されるまでの秒数。デフォルトは0秒。最小値は0。 +* `periodSeconds`: Probeが実行される頻度（秒数）。デフォルトは0秒。最小値は1。 +* `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 +* `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 +デフォルトは1。Liveness Probeには、1にする必要があります。最小値は1。 +* `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 +Liveness Probeにおいて、試行回数に到達することは、コンテナを再起動することを意味します。 +Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。 + +[HTTPによるProbe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) +は、`httpGet`にて設定できる複数の追加フィールドがあります: + +* `host`: 接続先ホスト名。デフォルトはPod IP。おそらくはこのフィールドの代わりに`httpHeaders`内の"Host"を代わりに使用することになります。 +* `scheme`: ホストへの接続で使用するスキーマ（HTTP または HTTPS）。デフォルトは HTTP。 +* `path`: HTTPサーバーへアクセスする際のパス +* `httpHeaders`: リクエスト内のカスタムヘッダー。HTTPでは、repeated headerが許可されています。 +* `port`: コンテナにアクセスする際のポートの名前または番号。ポート番号の場合、1から65535の範囲内である必要があります。 + +HTTPによるProbeの場合、kubeletは、指定したパスとポートに対するHTTPリクエストを送ることで、チェックを行います。 +kubeletは、`httpGet`のオプションである`host`フィールドでアドレスが上書きされない限り、PodのIPアドレスに対してProbeを送ります。 +`scheme`フィールドに`HTTPS`がセットされている場合、kubeletは、証明書の検証を行わずに、HTTPSリクエストを送ります。 +ほとんどのシナリオにおいては、`host`フィールドを使用する必要はありません。次のシナリオは、使用する場合の一例です。 +仮に、コンテナが127.0.0.1をリッスンしており、かつPodの`hostNetwork`フィールドがtrueだとします。 +その場合では、`httpGet`フィールド内の`host`には、127.0.0.1をセットする必要があります。 +より一般的なケースにおいてPodが仮想ホストに依存している場合は、おそらく`host`フィールドではなく、`httpHeaders`フィールド内の`Host`ヘッダーを使用する必要があります。 + +TCPによるProbeの場合、kubeletはPodの中ではなく、Nodeに対してコネクションを確立するProbeを実行します。 +kubeletはServiceの名前を解決できないため、`host`パラメーター内でServiceの名前を使用することはできません。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)についてもっと学ぶ + +また、次のAPIリファレンスも参考にしてください: + +* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) + +{{% /capture %}} + + From 94b72dab009e8dcebd9b56a2568343b99e0c02ca Mon Sep 17 00:00:00 2001 From: ytakaya Date: Sun, 31 May 2020 13:15:28 +0900 Subject: [PATCH 123/290] =?UTF-8?q?fix=20the=20term:=20=E3=83=9D=E3=83=83?= =?UTF-8?q?=E3=83=89=20->=20Pod?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/reference/glossary/volume.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 1006697c82..7351bbc4f9 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -4,17 +4,17 @@ id: volume date: 2018-04-12 full_link: /docs/concepts/storage/volumes/ short_description: > - ポッド内のコンテナからアクセス可能なデータを含むディレクトリ。 + Pod内のコンテナからアクセス可能なデータを含むディレクトリ。 aka: tags: - core-object - fundamental --- - {{< glossary_tooltip text="ポッド" term_id="pod" >}}内の{{< glossary_tooltip text="containers" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 + {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="containers" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 -Kubernetesボリュームはボリュームを含むポッドが存在する限り有効です。そのためボリュームはポッド内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。 +Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。 詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。 \ No newline at end of file From 29d6ee6fc7ef60f66076d5ba53f637517516bcdd Mon Sep 17 00:00:00 2001 From: takaya Date: Sun, 31 May 2020 13:43:51 +0900 Subject: [PATCH 124/290] =?UTF-8?q?fix=20the=20term:=20containers=20->=20?= =?UTF-8?q?=E3=82=B3=E3=83=B3=E3=83=86=E3=83=8A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/volume.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 7351bbc4f9..8ea7702e4c 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -11,10 +11,10 @@ tags: - core-object - fundamental --- - {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="containers" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 + {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリ。 Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。 -詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。 \ No newline at end of file +詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。 From a05262a68abfc326447ad010a209debf022bc198 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:45:01 +0900 Subject: [PATCH 125/290] Remove spaces between Japanese and English in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index c652c06ea8..d9c895a160 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -1,5 +1,5 @@ --- -title: Liveness Probe、Readiness Probe および Startup Probeを使用する +title: Liveness Probe、Readiness ProbeおよびStartup Probeを使用する content_template: templates/task weight: 110 --- @@ -336,4 +336,3 @@ kubeletはServiceの名前を解決できないため、`host`パラメーター {{% /capture %}} - From 62409ba0e3e053fe95faee6b42f513ed522b893b Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:49:25 +0900 Subject: [PATCH 126/290] Fix grammar content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index d9c895a160..648aeaffd3 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -14,7 +14,7 @@ weight: 110 kubeletは、Readiness Probeを使用して、コンテナがトラフィックを受け入れられる状態であるかを認識します。 Podが準備ができていると見なされるのは、Pod内の全てのコンテナの準備が整ったときです。 -一例として、このシグナルはServiceのバックエンドとして使用されるPodの制御するときに使用されます。 +一例として、このシグナルはServiceのバックエンドとして使用されるPodを制御するときに使用されます。 Podの準備ができていない場合、そのPodはServiceのロードバランシングから切り離されます。 kubeletは、Startup Probeを使用して、コンテナアプリケーションの起動が完了したかを認識します。 @@ -335,4 +335,3 @@ kubeletはServiceの名前を解決できないため、`host`パラメーター * [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) {{% /capture %}} - From a63947d14bd2b8492bc9361e97aacb2c3d660473 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:50:12 +0900 Subject: [PATCH 127/290] Remove spaces between Japanese and English in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 648aeaffd3..6a34f0e528 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -6,7 +6,7 @@ weight: 110 {{% capture overview %}} -このページでは、Liveness Probe、Readiness Probe および Startup Probeの使用方法について説明します。 +このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。 [kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。 例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。 From f08c35b415132674416b0f110daf9f51f1a4e9d4 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:51:19 +0900 Subject: [PATCH 128/290] Fix grammar in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 6a34f0e528..58ab10fdcf 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -20,7 +20,7 @@ Podの準備ができていない場合、そのPodはServiceのロードバラ kubeletは、Startup Probeを使用して、コンテナアプリケーションの起動が完了したかを認識します。 Startup Probeを使用している場合、Startup Probeが成功するまでは、Liveness Probeと Readiness Probeによるチェックを無効にし、これらがアプリケーションの起動に干渉しないようにします。 -例えば、これを起動が遅いコンテナの起動チェックとして使用することで、kubeletによって起動する前に +例えば、これを起動が遅いコンテナの起動チェックとして使用することで、起動する前にkubeletによって 強制終了されることを防ぐことができます。 {{% /capture %}} From 4ab200a128fe370efd362e6a831af7cbc36e6ec5 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:52:04 +0900 Subject: [PATCH 129/290] Update translation in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 58ab10fdcf..601c083f67 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -46,7 +46,7 @@ Podの構成ファイルは次の通りです。 この構成ファイルでは、Podは一つの`Container`を起動します。 `periodSeconds`フィールドは、kubeletがLiveness Probeを5秒おきに行うように指定しています。 `initialDelaySeconds`フィールドは、kubeletが最初のProbeを実行する前に5秒間待機するように指示しています。 -Probeの動作としては、kubeletは`cat /tmp/healthy`を目標となるコンテナ内で実行します。 +Probeの動作としては、kubeletは`cat /tmp/healthy`を対象のコンテナ内で実行します。 このコマンドが成功し、リターンコード0が返ると、kubeletはコンテナが問題なく動いていると判断します。 リターンコードとして0以外の値が返ると、kubeletはコンテナを終了し、再起動を行います。 From 05234b95adb647c3abb83a475d296328f6544c68 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:53:36 +0900 Subject: [PATCH 130/290] Fix () match to style guide in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 601c083f67..583eb48a2d 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -167,7 +167,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml kubectl describe pod liveness-http ``` -v1.13以前（v1.13を含む）のリリースにおいては、Podが起動しているノードにおいて、環境変数`http_proxy` +v1.13以前(v1.13を含む)のリリースにおいては、Podが起動しているノードにおいて、環境変数`http_proxy` （または `HTTP_PROXY`）が設定されている場合、HTTPリクエストのLiveness Probeは、設定されたプロキシを使用します。 v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定は、HTTPリクエストのLiveness Probeに影響しません。 From b20c2320ae9de944a6ca429cb0348f78ebd57dcc Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:53:54 +0900 Subject: [PATCH 131/290] Remove spaces between Japanese and English in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 583eb48a2d..69c9944fd0 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -267,7 +267,7 @@ Readiness Probeは、コンテナの全てのライフサイクルにおいて {{< /note >}} Readiness Probeは、Liveness Probeと同様に構成します。 -唯一の違いは、`readinessProbe`フィールドを`livenessProbe` フィールドの代わりに利用することだけです。 +唯一の違いは、`readinessProbe`フィールドを`livenessProbe`フィールドの代わりに利用することだけです。 ```yaml readinessProbe: From 1cca6f00a89119eefa0dd88b375cf2e3e75af744 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:57:43 +0900 Subject: [PATCH 132/290] Fix wrong defaults of periodSeconds in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 69c9944fd0..49aa0a7afc 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -294,7 +294,7 @@ Eventually, some of this section could be moved to a concept topic. Liveness ProbeおよびReadiness Probeのチェック動作を、より正確に制御するために使用できるいくつかのフィールドがあります: * `initialDelaySeconds`: コンテナが起動してから、Liveness ProbeまたはReadiness Probeが開始されるまでの秒数。デフォルトは0秒。最小値は0。 -* `periodSeconds`: Probeが実行される頻度（秒数）。デフォルトは0秒。最小値は1。 +* `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 デフォルトは1。Liveness Probeには、1にする必要があります。最小値は1。 From 350bd63f630e35d65bf1e2fbfe4803ca9d3cf6b9 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 18:59:28 +0900 Subject: [PATCH 133/290] =?UTF-8?q?Fix=20expression=20from=20'Node'=20to?= =?UTF-8?q?=20'=E3=83=8E=E3=83=BC=E3=83=89'=20in=20content/ja/docs/tasks/c?= =?UTF-8?q?onfigure-pod-container/configure-liveness-readiness-startup-pro?= =?UTF-8?q?bes.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 49aa0a7afc..a92772fd1b 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -319,7 +319,7 @@ kubeletは、`httpGet`のオプションである`host`フィールドでアド その場合では、`httpGet`フィールド内の`host`には、127.0.0.1をセットする必要があります。 より一般的なケースにおいてPodが仮想ホストに依存している場合は、おそらく`host`フィールドではなく、`httpHeaders`フィールド内の`Host`ヘッダーを使用する必要があります。 -TCPによるProbeの場合、kubeletはPodの中ではなく、Nodeに対してコネクションを確立するProbeを実行します。 +TCPによるProbeの場合、kubeletはPodの中ではなく、ノードに対してコネクションを確立するProbeを実行します。 kubeletはServiceの名前を解決できないため、`host`パラメーター内でServiceの名前を使用することはできません。 {{% /capture %}} From 49aa7dbbe39b0941d9cc3123d8a971a80aedf428 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 19:00:00 +0900 Subject: [PATCH 134/290] Fix () match to style guide content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index a92772fd1b..a38e9e8a86 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -250,7 +250,7 @@ startupProbe: periodSeconds: 10 ``` -Startup Probeにより、アプリケーションは起動が完了するまでに最大5分間の猶予（30 * 10 = 300秒）が与えられます。 +Startup Probeにより、アプリケーションは起動が完了するまでに最大5分間の猶予(30 * 10 = 300秒)が与えられます。 Startup Probeに一度成功すると、その後はLiveness Probeが引き継ぎ、コンテナのデッドロックに対して迅速に反応します。 Startup Probeが成功しない場合、コンテナは300秒後に終了し、その後はPodの`restartPolicy`に従います。 From 264ebd80df7c2d4e19e37e9210fd52581a171dfe Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 19:00:27 +0900 Subject: [PATCH 135/290] Fix grammar in content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index a38e9e8a86..dc631c11e0 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -183,7 +183,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 この例では、Readiness ProbeとLiveness Probeを両方使用しています。 kubeletは、コンテナが起動してから5秒後に、最初のReadiness Probeを開始します。 これは、`goproxy`コンテナの8080ポートに対して、接続を試みます。 -このProbeが成功する、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 +このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 この構成では、Readiness Probeに加えて、Liveness Probeが含まれています。 kubeletは、コンテナが起動してから15秒後に、最初のLiveness Probeを行います。 From 46d8970f99d88bca91e1d7d8a3097be92361d5ec Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 19:01:02 +0900 Subject: [PATCH 136/290] Fix () match to style guide content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Naoki Oketani --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index dc631c11e0..977cdf3b16 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -168,7 +168,7 @@ kubectl describe pod liveness-http ``` v1.13以前(v1.13を含む)のリリースにおいては、Podが起動しているノードにおいて、環境変数`http_proxy` -（または `HTTP_PROXY`）が設定されている場合、HTTPリクエストのLiveness Probeは、設定されたプロキシを使用します。 +(または `HTTP_PROXY`)が設定されている場合、HTTPリクエストのLiveness Probeは、設定されたプロキシを使用します。 v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定は、HTTPリクエストのLiveness Probeに影響しません。 ## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe} From 04516f1b12dd17becdf098fec0dc52ab516782a5 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 19:52:01 +0900 Subject: [PATCH 137/290] Fix lack of translation --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 977cdf3b16..3578010232 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -90,7 +90,7 @@ FirstSeen LastSeen Count From SubobjectPath Type kubectl describe pod liveness-exec ``` -出力結果の最後に、Liveness Probeが失敗していることを示すメッセージがあります。 +出力結果の最後に、Liveness Probeが失敗していることを示すメッセージが表示され、コンテナが強制終了して再作成されています。 ``` FirstSeen LastSeen Count From SubobjectPath Type Reason Message From dbc4530d3b1069d5e87a75101dcada8dc27c4ad0 Mon Sep 17 00:00:00 2001 From: jinu Date: Sun, 31 May 2020 19:54:24 +0900 Subject: [PATCH 138/290] Update translation of 'repeated header' --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 3578010232..f9145405cc 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -308,7 +308,7 @@ Readiness Probeの場合は、Podが準備できていない状態として通 * `host`: 接続先ホスト名。デフォルトはPod IP。おそらくはこのフィールドの代わりに`httpHeaders`内の"Host"を代わりに使用することになります。 * `scheme`: ホストへの接続で使用するスキーマ（HTTP または HTTPS）。デフォルトは HTTP。 * `path`: HTTPサーバーへアクセスする際のパス -* `httpHeaders`: リクエスト内のカスタムヘッダー。HTTPでは、repeated headerが許可されています。 +* `httpHeaders`: リクエスト内のカスタムヘッダー。HTTPでは重複したヘッダーが許可されています。 * `port`: コンテナにアクセスする際のポートの名前または番号。ポート番号の場合、1から65535の範囲内である必要があります。 HTTPによるProbeの場合、kubeletは、指定したパスとポートに対するHTTPリクエストを送ることで、チェックを行います。 From 39509b7f8fd6696200d38b6acaea642535107df6 Mon Sep 17 00:00:00 2001 From: Keishi Asai Date: Sun, 31 May 2020 17:36:07 -0700 Subject: [PATCH 139/290] update the outdated ja tutorials/_index.md based on the v1.17 en page --- content/ja/docs/tutorials/_index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md index a696f5b705..a960977004 100644 --- a/content/ja/docs/tutorials/_index.md +++ b/content/ja/docs/tutorials/_index.md @@ -17,8 +17,6 @@ content_template: templates/concept * [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)は、Kubernetesのシステムを理解し、基本的な機能を試すのに役立つ、詳細な対話式のチュートリアルです。 -* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) - * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) * [Hello Minikube](/ja/docs/tutorials/hello-minikube/) From ef91b3f8093e7d527914c6393df26091ece87178 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:03:35 +0900 Subject: [PATCH 140/290] ja: Make tutorials/kubernetes-basics/deploy-app/deploy-intro.html follow v1.17 of the original text --- content/ja/docs/tutorials/hello-minikube.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 428175e21e..d4cd03a36d 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -82,8 +82,8 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 出力: ```shell - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - hello-node 1 1 1 1 1m + NAME READY UP-TO-DATE AVAILABLE AGE + hello-node 1/1 1 1 1m ``` 3. Podを確認します: From c6beb18f1cc2c0c1904a9f9082f3e560bd8535cc Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:32:22 +0900 Subject: [PATCH 141/290] change URL for Minikube setup --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index d4cd03a36d..4bf7c80485 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -15,7 +15,7 @@ card: {{% capture overview %}} -このチュートリアルでは、[Minikube](/docs/getting-started-guides/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 +このチュートリアルでは、[Minikube](/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 {{< note >}} [Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。 From 1748e5e70056a4d009cf200c1481d9787bb0cd37 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:36:31 +0900 Subject: [PATCH 142/290] delete unnecessary blank and fix simple wording --- content/ja/docs/tutorials/hello-minikube.md | 23 +++++++++++---------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 4bf7c80485..1a6f796c12 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -61,7 +61,7 @@ card: 3. Katacoda環境のみ：ターミナルペーン上部の+ボタンをクリックしてから **Select port to view on Host 1** をクリックしてください。 -4. Katacoda環境のみ：`30000`を入力し、**Display Port**をクリックしてください。 +4. Katacoda環境のみ：`30000`を入力し、**Display Port**をクリックしてください。 ## Deploymentの作成 @@ -79,7 +79,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ kubectl get deployments ``` - 出力: + 出力は下記のようになります: ```shell NAME READY UP-TO-DATE AVAILABLE AGE @@ -91,7 +91,8 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ ```shell kubectl get pods ``` - 出力: + + 出力は下記のようになります: ```shell NAME READY STATUS RESTARTS AGE @@ -109,7 +110,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ ```shell kubectl config view ``` - + {{< note >}} `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。{{< /note >}} ## Serviceの作成 @@ -121,7 +122,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - + `--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。 2. 作成したServiceを確認します: @@ -130,7 +131,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ kubectl get services ``` - 出力: + 出力は下記のようになります: ```shell NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE @@ -163,7 +164,7 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ minikube addons list ``` - 出力: + 出力は下記のようになります: ```shell addon-manager: enabled @@ -182,14 +183,14 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ registry-creds: disabled storage-provisioner: enabled ``` - + 2. ここでは例として`heapster`のアドオンを有効化します: ```shell minikube addons enable heapster ``` - - 出力: + + 出力は下記のようになります: ```shell heapster was successfully enabled @@ -226,7 +227,7 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ minikube addons disable heapster ``` - 出力: + 出力は下記のようになります: ```shell heapster was successfully disabled From 583a05a09485a95370cd4f66e045c58ef2e811ac Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:40:29 +0900 Subject: [PATCH 143/290] =?UTF-8?q?fix=20=E3=83=9D=E3=83=83=E3=83=89->Pod?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/tutorials/hello-minikube.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 1a6f796c12..3d83e30a36 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -115,7 +115,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ ## Serviceの作成 -通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてポッドを公開する必要があります。 +通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します: @@ -196,7 +196,7 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ heapster was successfully enabled ``` -3. 作成されたポッドとサービスを確認します: +3. 作成されたPodとサービスを確認します: ```shell kubectl get pod,svc -n kube-system From c43af3ab50f5bc25602ec053e4e5ccdb83cacb02 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:42:34 +0900 Subject: [PATCH 144/290] fix section 3 of 'Enable addons' --- content/ja/docs/tutorials/hello-minikube.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 3d83e30a36..6f13b7ddf4 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -206,17 +206,21 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ ```shell NAME READY STATUS RESTARTS AGE - pod/heapster-9jttx 1/1 Running 0 26s + pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m + pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m + pod/metrics-server-67fb648c5 1/1 Running 0 26s + pod/etcd-minikube 1/1 Running 0 34m pod/influxdb-grafana-b29w8 2/2 Running 0 26s pod/kube-addon-manager-minikube 1/1 Running 0 34m - pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m - pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m + pod/kube-apiserver-minikube 1/1 Running 0 34m + pod/kube-controller-manager-minikube 1/1 Running 0 34m + pod/kube-proxy-rnlps 1/1 Running 0 34m + pod/kube-scheduler-minikube 1/1 Running 0 34m pod/storage-provisioner 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - service/heapster ClusterIP 10.96.241.45 80/TCP 26s + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m - service/kubernetes-dashboard NodePort 10.109.29.1 80:30000/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s ``` From 271aa41c43057fdad6645728cde8eca676ddf30b Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:39:14 +0900 Subject: [PATCH 145/290] fix section 4. of 'Enable addons', Disable `heapster` to `metrics-server` --- content/ja/docs/tutorials/hello-minikube.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 6f13b7ddf4..7c9f4d4c41 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -225,16 +225,16 @@ Minikubeはビルトインのアドオンがあり、有効化、無効化、あ service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s ``` -4. `heapster`を無効化します: +4. `metrics-server`を無効化します: ```shell - minikube addons disable heapster + minikube addons disable metrics-server ``` 出力は下記のようになります: ```shell - heapster was successfully disabled + etrics-server was successfully disabled ``` ## クリーンアップ From d089d158212c060e2f399014be4e2db1e13af5b9 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:50:04 +0900 Subject: [PATCH 146/290] fix section 5 of 'Create a Deployment' --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 7c9f4d4c41..2b6e3609a2 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -150,7 +150,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。 -5. Katacoda環境のみ：`30369`(Service出力に表示されている`8080`の反対側のポートを参照)を入力し、クリックしてください。 +5. Katacoda環境のみ：サービスの出力で5桁のポート番号が`8080`の反対側に表示されます。このポート番号はランダムに生成されるため、ここでの記載と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックします。前の例の場合は、「30369」と入力します。 "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。 From 8a60cb6b282c66f4dc6f3707ac46ef1f40e52b45 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:52:54 +0900 Subject: [PATCH 147/290] fix first part of 'Enable addons' --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 2b6e3609a2..41fb08e1c9 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -156,7 +156,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ ## アドオンの有効化 -Minikubeはビルトインのアドオンがあり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。 +Minikubeはビルトインの{{< glossary_tooltip text="addons" term_id="addons" >}}があり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。 1. サポートされているアドオンをリストアップします: From a50744cf6ddd41ce03413685609036ff42f8230b Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 10:54:04 +0900 Subject: [PATCH 148/290] fix section 1 of 'Enable addons' --- content/ja/docs/tutorials/hello-minikube.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 41fb08e1c9..5ce71ba4e0 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -168,20 +168,22 @@ Minikubeはビルトインの{{< glossary_tooltip text="addons" term_id="addons" ```shell addon-manager: enabled - coredns: disabled dashboard: enabled default-storageclass: enabled efk: disabled freshpod: disabled - heapster: disabled + gvisor: disabled + helm-tiller: disabled ingress: disabled - kube-dns: enabled + ingress-dns: disabled + logviewer: disabled metrics-server: disabled nvidia-driver-installer: disabled nvidia-gpu-device-plugin: disabled registry: disabled registry-creds: disabled storage-provisioner: enabled + storage-provisioner-gluster: disabled ``` 2. ここでは例として`heapster`のアドオンを有効化します: From 696cd62a72f863f44e93d623a5687111f814c02f Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 11:50:38 +0900 Subject: [PATCH 149/290] fix wordings --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 5ce71ba4e0..89c7da211f 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -150,7 +150,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。 -5. Katacoda環境のみ：サービスの出力で5桁のポート番号が`8080`の反対側に表示されます。このポート番号はランダムに生成されるため、ここでの記載と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックします。前の例の場合は、「30369」と入力します。 +5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、「30369」と入力します。 "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。 From 68dd6290e32ffea18d402fa98c42c8209e53195b Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 12:15:21 +0900 Subject: [PATCH 150/290] fix text for Minikube build-in --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 89c7da211f..9472defc47 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -156,7 +156,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ ## アドオンの有効化 -Minikubeはビルトインの{{< glossary_tooltip text="addons" term_id="addons" >}}があり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。 +Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="addons" >}}があり、有効化、無効化、あるいはローカルのKubernetes環境に公開することができます。 1. サポートされているアドオンをリストアップします: From 06191dcfcfd5a0f1699e6c79058cd6759596d02f Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Mon, 1 Jun 2020 17:21:38 +0900 Subject: [PATCH 151/290] use English for hash flagment #termination-of-pods --- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 2 +- content/ja/docs/concepts/workloads/pods/pod-overview.md | 2 +- content/ja/docs/concepts/workloads/pods/pod.md | 2 +- .../configure-pod-container/attach-handler-lifecycle-event.md | 2 +- content/ja/docs/tasks/run-application/delete-stateful-set.md | 2 +- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index da5949374e..8e5a5ba626 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 -終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#podの終了)にあります。 +終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。 ### フックハンドラーの実装 diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index c3646c2100..05f68c1e60 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -113,6 +113,6 @@ spec: {{% capture whatsnext %}} * [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう * Podの振る舞いに関して学ぶには下記を参照してください - * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#podの終了) + * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods) * [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/) {{% /capture %}} diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index e0d9c951b4..74b561ef38 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -126,7 +126,7 @@ Podは、以下のことを容易にするためにプリミティブとして * アプリケーションの可用性を高める。 即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する -## Podの終了 +## Podの終了 {#termination-of-pods} Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 diff --git a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index e0acddd5f7..36197d7f2f 100644 --- a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -62,7 +62,7 @@ Pod内で実行されているコンテナでシェルを実行します: ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。 Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。 -コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#podの終了)を参照してください。 +コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)を参照してください。 {{< note >}} Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。 diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md index d8d6b8c89a..d588fca08f 100644 --- a/content/ja/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md @@ -50,7 +50,7 @@ kubectl delete pods -l app=myapp ### 永続ボリューム -StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#podの終了)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 +StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 {{< note >}} データを損失する可能性があるため、PVCを削除するときは注意してください。 diff --git a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md index be930f23e5..6c9c3573a1 100644 --- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -30,7 +30,7 @@ StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する kubectl delete pods ``` -上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/docs/user-guide/pods/#termination-of-pods)ことを保証します。 +上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。 Kubernetes（バージョン1.5以降）は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: From 3f0bb59eb0d52e93bc23f0af36daa399286be284 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 19:40:56 +0900 Subject: [PATCH 152/290] change tutorial url(add /ja/) --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 9472defc47..9c3cc44583 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -15,7 +15,7 @@ card: {{% capture overview %}} -このチュートリアルでは、[Minikube](/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 +このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 {{< note >}} [Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。 From 0ef68b9ca6230b54bb120d8b061ff4a8e0e3a557 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 19:46:37 +0900 Subject: [PATCH 153/290] remove 'shell' --- content/ja/docs/tutorials/hello-minikube.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 9c3cc44583..3020af3483 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -81,7 +81,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 出力は下記のようになります: - ```shell + ``` NAME READY UP-TO-DATE AVAILABLE AGE hello-node 1/1 1 1 1m ``` @@ -94,7 +94,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 出力は下記のようになります: - ```shell + ``` NAME READY STATUS RESTARTS AGE hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m ``` @@ -133,7 +133,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 出力は下記のようになります: - ```shell + ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s kubernetes ClusterIP 10.96.0.1 443/TCP 23m @@ -166,7 +166,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a 出力は下記のようになります: - ```shell + ``` addon-manager: enabled dashboard: enabled default-storageclass: enabled @@ -194,7 +194,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a 出力は下記のようになります: - ```shell + ``` heapster was successfully enabled ``` @@ -206,7 +206,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a 出力: - ```shell + ``` NAME READY STATUS RESTARTS AGE pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m @@ -235,7 +235,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a 出力は下記のようになります: - ```shell + ``` etrics-server was successfully disabled ``` From 4539d1271025ed53042981f2e81b668eea6d1359 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 19:47:29 +0900 Subject: [PATCH 154/290] change heapster to metrics-server in section 2 of 'Enable addons' --- content/ja/docs/tutorials/hello-minikube.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 3020af3483..1280ee7778 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -186,16 +186,16 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a storage-provisioner-gluster: disabled ``` -2. ここでは例として`heapster`のアドオンを有効化します: +2. ここでは例として`metrics-server`のアドオンを有効化します: ```shell - minikube addons enable heapster + minikube addons enable metrics-server ``` 出力は下記のようになります: ``` - heapster was successfully enabled + metrics-server was successfully enabled ``` 3. 作成されたPodとサービスを確認します: From 399e074f04249b6d3930696fe44f1c69ee70974f Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 19:49:44 +0900 Subject: [PATCH 155/290] fix for comments --- content/ja/docs/tutorials/hello-minikube.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 1280ee7778..4988656295 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -150,7 +150,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。 -5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、「30369」と入力します。 +5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。 "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。 @@ -236,7 +236,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a 出力は下記のようになります: ``` - etrics-server was successfully disabled + metrics-server was successfully disabled ``` ## クリーンアップ From 5aaaeda630eceda882fdac8c6009ebe0bd0676d5 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 23:28:54 +0900 Subject: [PATCH 156/290] ja: Make /docs/tasks/tools/install-kubectl/ follow v1.17 of the original text --- content/ja/docs/tasks/tools/install-kubectl.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 1e6bb6b3a5..24c0e8b6c3 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -51,7 +51,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと 4. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` ### ネイティブなパッケージマネージャーを使用してインストールする @@ -129,7 +129,7 @@ kubectl version 4. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` ### Homebrewを使用してmacOSへインストールする @@ -150,7 +150,7 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 2. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` ### MacPortsを使用してmacOSへインストールする @@ -167,7 +167,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 2. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` ## Windowsへkubectlをインストールする {#install-kubectl-on-windows} @@ -188,7 +188,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください: ``` - kubectl version + kubectl version --client ``` {{< note >}} [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。 @@ -212,7 +212,7 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー 2. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` {{< note >}}アップデートする際は、手順1に示した2つのコマンドを再実行してください。{{< /note >}} @@ -235,7 +235,7 @@ Windowsへkubectlをインストールするために、[Chocolatey](https://cho 2. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` 3. ホームディレクトリへ移動してください: @@ -277,7 +277,7 @@ Google Cloud SDKの一部として、kubectlをインストールすることも 3. インストールしたバージョンが最新であることを確認してください: ``` - kubectl version + kubectl version --client ``` ## kubectlの設定を検証する From 95730ec38f64f50134ecf615530cb30b0032bde7 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 23:49:11 +0900 Subject: [PATCH 157/290] update 'Install using other package management' section --- .../ja/docs/tasks/tools/install-kubectl.md | 20 ++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 24c0e8b6c3..69d94a1096 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -80,22 +80,24 @@ yum install -y kubectl ### 他のパッケージマネージャーを使用してインストールする +{{< tabs name="other_kubectl_install" >}} +{{% tab name="Snap" %}} Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマネージャーをサポートする別のLinuxディストリビューションを使用している場合、kubectlは[snap](https://snapcraft.io/)アプリケーションとして使用できます。 -Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。 - -{{< tabs name="other_kubectl_install" >}} -{{< tab name="Snap" codelang="bash" >}} -sudo snap install kubectl --classic +```shell +snap install kubectl --classic kubectl version -{{< /tab >}} -{{< tab name="Homebrew" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="Homebrew" %}} +Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネージャーを使用している場合は、kubectlを[インストール](https://docs.brew.sh/Homebrew-on-Linux#install)することが可能です。 +```shell brew install kubectl kubectl version -{{< /tab >}} -{{< /tabs >}} +``` +{{% /tab %}} ## macOSへkubectlをインストールする {#install-kubectl-on-macos} From 9a3cecfbee95d6e497e8ad716269ce77dd77c917 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Mon, 1 Jun 2020 23:54:34 +0900 Subject: [PATCH 158/290] add section 'Upgrade Bash' --- .../ja/docs/tasks/tools/install-kubectl.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 69d94a1096..7928e1abe9 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -383,6 +383,27 @@ Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コ bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2（macOSのデフォルト）用で、v2はBash 4.1以降向けです。kubectlの補完スクリプトはbash-completionのv1とBash 3.2では正しく**動作しません**。**bash-completion v2**および**Bash 4.1**が必要になります。したがって、macOSで正常にkubectlの補完を使用するには、Bash 4.1以降をインストールする必要があります([*手順*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。以下の手順では、Bash4.1以降（Bashのバージョンが4.1またはそれより新しいことを指します）を使用することを前提とします。 {{< /warning >}} +### bashのアップグレード + +ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。 + +```shell +echo $BASH_VERSION +``` + +バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。 + +```shell +brew install bash +``` + +シェルをリロードし、希望するバージョンを使用していることを確認してください。 + +```shell +echo $BASH_VERSION $SHELL +``` + +Homebrewは通常、`/usr/local/bin/bash`フォルダ下でインストールを行います。 ### bash-completionをインストールする From 926b0d778d9cded11b53dfed3eabac7da07f6bfc Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Tue, 2 Jun 2020 11:01:42 +0900 Subject: [PATCH 159/290] fix wording --- content/ja/docs/tasks/tools/install-kubectl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 7928e1abe9..59997650c8 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -403,7 +403,7 @@ brew install bash echo $BASH_VERSION $SHELL ``` -Homebrewは通常、`/usr/local/bin/bash`フォルダ下でインストールを行います。 +Homebrewは通常、`/usr/local/bin/bash`フォルダ下にインストールします。 ### bash-completionをインストールする From d31a5f7d5bd9502bcfe72ff1e05185ecb4b03813 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:57:52 +0900 Subject: [PATCH 160/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index f9145405cc..6b1570d0fd 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -173,7 +173,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 ## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe} -3つ目のLiveness Probeは、TCPソケットを使用するタイプです。 +3つ目のLiveness ProbeはTCPソケットを使用するタイプです。 この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。 コネクションを確立できる場合、コンテナを正常とみなし、失敗する場合は、異常とみなします。 From 654469b9461d287878d2edba4466c5a12a33bf67 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:58:07 +0900 Subject: [PATCH 161/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 6b1570d0fd..3b00a17439 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -174,7 +174,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 ## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe} 3つ目のLiveness ProbeはTCPソケットを使用するタイプです。 -この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。 +この構成において、kubeletは指定したコンテナのソケットを開くことを試みます。 コネクションを確立できる場合、コンテナを正常とみなし、失敗する場合は、異常とみなします。 {{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} From 83e84db0c8cf2a75ff8b9c5c884959dfef7e0a9e Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:58:20 +0900 Subject: [PATCH 162/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 3b00a17439..554678263c 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -175,7 +175,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 3つ目のLiveness ProbeはTCPソケットを使用するタイプです。 この構成において、kubeletは指定したコンテナのソケットを開くことを試みます。 -コネクションを確立できる場合、コンテナを正常とみなし、失敗する場合は、異常とみなします。 +コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。 {{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} From 6bf95a25a4b4cfc1fb8e0f734322d816b057263c Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:58:31 +0900 Subject: [PATCH 163/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 554678263c..22dcbb8f7a 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -179,7 +179,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 {{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} -見ての通り、TCPによるチェックの構成は、HTTPによるチェックと非常に似ています。 +見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。 この例では、Readiness ProbeとLiveness Probeを両方使用しています。 kubeletは、コンテナが起動してから5秒後に、最初のReadiness Probeを開始します。 これは、`goproxy`コンテナの8080ポートに対して、接続を試みます。 From 8dac42316c412ca7d85deb86427b82c4d0c2852a Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:58:41 +0900 Subject: [PATCH 164/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 22dcbb8f7a..5ece134ff1 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -181,7 +181,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。 この例では、Readiness ProbeとLiveness Probeを両方使用しています。 -kubeletは、コンテナが起動してから5秒後に、最初のReadiness Probeを開始します。 +kubeletは、コンテナが起動してから5秒後に最初のReadiness Probeを開始します。 これは、`goproxy`コンテナの8080ポートに対して、接続を試みます。 このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 From bda8d89e4f075084d68c402b7f813c667a699c53 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:58:53 +0900 Subject: [PATCH 165/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 5ece134ff1..32e6923776 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -186,7 +186,7 @@ kubeletは、コンテナが起動してから5秒後に最初のReadiness Probe このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 この構成では、Readiness Probeに加えて、Liveness Probeが含まれています。 -kubeletは、コンテナが起動してから15秒後に、最初のLiveness Probeを行います。 +kubeletは、コンテナが起動してから15秒後に最初のLiveness Probeを実行します。 Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して、接続を試みます。 Liveness Probeが失敗した場合、コンテナは再起動されます。 From caeada95d0057dbc78d4b21a2e61a8b6a9c46876 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:59:10 +0900 Subject: [PATCH 166/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 32e6923776..90a9d22a38 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -222,7 +222,7 @@ livenessProbe: ## Startup Probeを使用して、起動の遅いコンテナを保護する {#define-startup-probes} 場合によっては、最初の初期化において、追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。 -そのような場合において、デッドロックに対する迅速な反応を損なうことなく、Liveness Probeのパラメーターを設定することは難しい場合があります。 +そのような場合、デッドロックに対する迅速な反応を損なうことなくLiveness Probeのパラメーターを設定することは難しい場合があります。 これに対する解決策の一つは、Liveness Probeと同じ構成のコマンド、HTTPまたはTCPによるチェックを使用した、Startup Probeをセットアップすることです。 その際、`failureThreshold * periodSeconds`で計算される時間を、起動時間として想定される最も遅いケースをカバーできる十分な長さに設定します。 From 36fdde75a1c6b4da51d77baf298782261c7b29e3 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:59:26 +0900 Subject: [PATCH 167/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 90a9d22a38..8581a013c1 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -224,7 +224,7 @@ livenessProbe: 場合によっては、最初の初期化において、追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。 そのような場合、デッドロックに対する迅速な反応を損なうことなくLiveness Probeのパラメーターを設定することは難しい場合があります。 -これに対する解決策の一つは、Liveness Probeと同じ構成のコマンド、HTTPまたはTCPによるチェックを使用した、Startup Probeをセットアップすることです。 +これに対する解決策の一つは、Liveness Probeと同じ構成のコマンドを用いるか、HTTPまたはTCPによるチェックを使用したStartup Probeをセットアップすることです。 その際、`failureThreshold * periodSeconds`で計算される時間を、起動時間として想定される最も遅いケースをカバーできる十分な長さに設定します。 上記の例は、次のようになります: From d29759e4d2012e5fe0fe77d96c22d1bdd55d479b Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:59:40 +0900 Subject: [PATCH 168/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 8581a013c1..3199299b2d 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -259,7 +259,7 @@ Startup Probeが成功しない場合、コンテナは300秒後に終了し、 アプリケーションは、一時的にトラフィックを処理できないことが起こり得ます。 例えば、アプリケーションは、起動時に大きなデータまたは構成ファイルを読み込む必要がある場合や、起動後に外部サービスに依存する可能性があります。 このような場合、アプリケーションを終了させたくありませんが、リクエストを受けたくないと思います。 -Kubernetesは、これらの状況を検知して緩和するための機能として、Readiness Probeを提供します。 +Kubernetesは、これらの状況を検知して緩和するための機能としてReadiness Probeを提供します。 準備できていないことを報告するコンテナを含むPodは、KubernetesのServiceからトラフィックを受信しないようにできます。 {{< note >}} From 20ff93a8ccd3975773b4560d043cba0ce6b09843 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 12:59:53 +0900 Subject: [PATCH 169/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 3199299b2d..4cd8b6741a 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -187,7 +187,7 @@ kubeletは、コンテナが起動してから5秒後に最初のReadiness Probe この構成では、Readiness Probeに加えて、Liveness Probeが含まれています。 kubeletは、コンテナが起動してから15秒後に最初のLiveness Probeを実行します。 -Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して、接続を試みます。 +Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して接続を試みます。 Liveness Probeが失敗した場合、コンテナは再起動されます。 TCPのチェックによるLiveness Probeを試すには、以下のようにPodを作成します: From eb27845b81052e16a984139432518a613cc8dd04 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:00:10 +0900 Subject: [PATCH 170/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 4cd8b6741a..85135ca0e6 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -182,7 +182,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。 この例では、Readiness ProbeとLiveness Probeを両方使用しています。 kubeletは、コンテナが起動してから5秒後に最初のReadiness Probeを開始します。 -これは、`goproxy`コンテナの8080ポートに対して、接続を試みます。 +これは、`goproxy`コンテナの8080ポートに対して接続を試みます。 このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 この構成では、Readiness Probeに加えて、Liveness Probeが含まれています。 From e45724f0732f829d7bbf2edc533a283afce09a51 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:00:27 +0900 Subject: [PATCH 171/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 85135ca0e6..afdf7e279a 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -185,7 +185,7 @@ kubeletは、コンテナが起動してから5秒後に最初のReadiness Probe これは、`goproxy`コンテナの8080ポートに対して接続を試みます。 このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 -この構成では、Readiness Probeに加えて、Liveness Probeが含まれています。 +この構成では、Readiness Probeに加えてLiveness Probeが含まれています。 kubeletは、コンテナが起動してから15秒後に最初のLiveness Probeを実行します。 Readiness Probeと同様に、これは`goproxy`コンテナの8080ポートに対して接続を試みます。 Liveness Probeが失敗した場合、コンテナは再起動されます。 From 20aeadccd94a841a41d9aa04a7152d1cc7a9fc61 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:15:40 +0900 Subject: [PATCH 172/290] Update expressions --- .../configure-liveness-readiness-startup-probes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index afdf7e279a..fc92b9c8ab 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -161,15 +161,15 @@ HTTPリクエストのチェックによるLiveness Probeを試すには、以 kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml ``` -10秒後、Podのイベントを表示し、Liveness Probeが失敗し、コンテナが再起動されていることを確認します。 +10秒後、Podのイベントを表示して、Liveness Probeが失敗し、コンテナが再起動されていることを確認します。 ```shell kubectl describe pod liveness-http ``` -v1.13以前(v1.13を含む)のリリースにおいては、Podが起動しているノードにおいて、環境変数`http_proxy` -(または `HTTP_PROXY`)が設定されている場合、HTTPリクエストのLiveness Probeは、設定されたプロキシを使用します。 -v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定は、HTTPリクエストのLiveness Probeに影響しません。 +v1.13以前(v1.13を含む)のリリースにおいては、Podが起動しているノードに環境変数`http_proxy` +(または `HTTP_PROXY`)が設定されている場合、HTTPリクエストのLiveness Probeは設定されたプロキシを使用します。 +v1.13より後のリリースにおいては、ローカルHTTPプロキシ環境変数の設定はHTTPリクエストのLiveness Probeに影響しません。 ## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe} From 281325a24f7536a6050fa8cdaa293f8d0a07a2d9 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:28:08 +0900 Subject: [PATCH 173/290] Update expression in #configure-probes --- ...figure-liveness-readiness-startup-probes.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index fc92b9c8ab..bc9c5749e5 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -291,7 +291,7 @@ Eventually, some of this section could be moved to a concept topic. {{< /comment >}} [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) には、 -Liveness ProbeおよびReadiness Probeのチェック動作を、より正確に制御するために使用できるいくつかのフィールドがあります: +Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制御するために使用できるフィールドがあります: * `initialDelaySeconds`: コンテナが起動してから、Liveness ProbeまたはReadiness Probeが開始されるまでの秒数。デフォルトは0秒。最小値は0。 * `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。 @@ -299,11 +299,11 @@ Liveness ProbeおよびReadiness Probeのチェック動作を、より正確に * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 デフォルトは1。Liveness Probeには、1にする必要があります。最小値は1。 * `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 -Liveness Probeにおいて、試行回数に到達することは、コンテナを再起動することを意味します。 +Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。 [HTTPによるProbe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) -は、`httpGet`にて設定できる複数の追加フィールドがあります: +には、`httpGet`にて設定できる追加のフィールドがあります: * `host`: 接続先ホスト名。デフォルトはPod IP。おそらくはこのフィールドの代わりに`httpHeaders`内の"Host"を代わりに使用することになります。 * `scheme`: ホストへの接続で使用するスキーマ（HTTP または HTTPS）。デフォルトは HTTP。 @@ -311,12 +311,12 @@ Readiness Probeの場合は、Podが準備できていない状態として通 * `httpHeaders`: リクエスト内のカスタムヘッダー。HTTPでは重複したヘッダーが許可されています。 * `port`: コンテナにアクセスする際のポートの名前または番号。ポート番号の場合、1から65535の範囲内である必要があります。 -HTTPによるProbeの場合、kubeletは、指定したパスとポートに対するHTTPリクエストを送ることで、チェックを行います。 -kubeletは、`httpGet`のオプションである`host`フィールドでアドレスが上書きされない限り、PodのIPアドレスに対してProbeを送ります。 -`scheme`フィールドに`HTTPS`がセットされている場合、kubeletは、証明書の検証を行わずに、HTTPSリクエストを送ります。 -ほとんどのシナリオにおいては、`host`フィールドを使用する必要はありません。次のシナリオは、使用する場合の一例です。 -仮に、コンテナが127.0.0.1をリッスンしており、かつPodの`hostNetwork`フィールドがtrueだとします。 -その場合では、`httpGet`フィールド内の`host`には、127.0.0.1をセットする必要があります。 +HTTPによるProbeの場合、kubeletは指定したパスとポートに対するHTTPリクエストを送ることでチェックを行います。 +`httpGet`のオプションである`host`フィールドでアドレスが上書きされない限り、kubeletはPodのIPアドレスに対してProbeを送ります。 +`scheme`フィールドに`HTTPS`がセットされている場合、kubeletは証明書の検証を行わずにHTTPSリクエストを送ります。 +ほとんどのシナリオにおいては、`host`フィールドを使用する必要はありません。次のシナリオは使用する場合の一例です。 +仮にコンテナが127.0.0.1をリッスンしており、かつPodの`hostNetwork`フィールドがtrueだとします。 +その場合においては、`httpGet`フィールド内の`host`には127.0.0.1をセットする必要があります。 より一般的なケースにおいてPodが仮想ホストに依存している場合は、おそらく`host`フィールドではなく、`httpHeaders`フィールド内の`Host`ヘッダーを使用する必要があります。 TCPによるProbeの場合、kubeletはPodの中ではなく、ノードに対してコネクションを確立するProbeを実行します。 From 321b7f53a8a78a3e3f2978a72b98a80222b1560a Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:36:13 +0900 Subject: [PATCH 174/290] Update expression in #define-a-liveness-command --- .../configure-liveness-readiness-startup-probes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index bc9c5749e5..48a0408f8f 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -35,8 +35,8 @@ Readiness Probeによるチェックを無効にし、これらがアプリケ ## コマンド実行によるLiveness Probeを定義する {#define-a-liveness-command} -多くのアプリケーションは、長期間実行されている場合に、再起動されるまで回復できないような異常な状態になることがあります。 -Kubernetesは、このような状況を検知し、回復するためのLiveness Probeを提供します。 +長期間実行されているアプリケーションの多くは、再起動されるまで回復できないような異常な状態になることがあります。 +Kubernetesはこのような状況を検知し、回復するためのLiveness Probeを提供します。 この演習では、`k8s.gcr.io/busybox`イメージのコンテナを起動するPodを作成します。 Podの構成ファイルは次の通りです。 @@ -50,7 +50,7 @@ Probeの動作としては、kubeletは`cat /tmp/healthy`を対象のコンテ このコマンドが成功し、リターンコード0が返ると、kubeletはコンテナが問題なく動いていると判断します。 リターンコードとして0以外の値が返ると、kubeletはコンテナを終了し、再起動を行います。 -コンテナが起動すると、次のコマンドを実行します: +このコンテナは、起動すると次のコマンドを実行します: ```shell /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" @@ -90,7 +90,7 @@ FirstSeen LastSeen Count From SubobjectPath Type kubectl describe pod liveness-exec ``` -出力結果の最後に、Liveness Probeが失敗していることを示すメッセージが表示され、コンテナが強制終了して再作成されています。 +出力結果の最後に、Liveness Probeが失敗していることを示すメッセージが表示されます。これによりコンテナは強制終了し、再作成されました。 ``` FirstSeen LastSeen Count From SubobjectPath Type Reason Message From b4fcbc705ca19884adf3fd1c379ae1b4e50941fe Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:42:01 +0900 Subject: [PATCH 175/290] Update expression in #define-a-tcp-liveness-probe --- .../configure-liveness-readiness-startup-probes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 48a0408f8f..00fa1ed1ab 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -174,7 +174,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 ## TCPによるLiveness Probeを定義する {#define-a-tcp-liveness-probe} 3つ目のLiveness ProbeはTCPソケットを使用するタイプです。 -この構成において、kubeletは指定したコンテナのソケットを開くことを試みます。 +この構成においては、kubeletは指定したコンテナのソケットを開くことを試みます。 コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。 {{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} @@ -182,7 +182,7 @@ v1.13より後のリリースにおいては、ローカルHTTPプロキシ環 見ての通り、TCPによるチェックの構成はHTTPによるチェックと非常に似ています。 この例では、Readiness ProbeとLiveness Probeを両方使用しています。 kubeletは、コンテナが起動してから5秒後に最初のReadiness Probeを開始します。 -これは、`goproxy`コンテナの8080ポートに対して接続を試みます。 +これは`goproxy`コンテナの8080ポートに対して接続を試みます。 このProbeが成功すると、Podは準備ができていると通知されます。kubeletはこのチェックを10秒ごとに行います。 この構成では、Readiness Probeに加えてLiveness Probeが含まれています。 From 14e3318bcfa2bee4be5cb17ed725cc9ac4a50475 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:55:25 +0900 Subject: [PATCH 176/290] Update expression in #define-readiness-probes --- .../configure-liveness-readiness-startup-probes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 00fa1ed1ab..ac196403a3 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -256,11 +256,11 @@ Startup Probeが成功しない場合、コンテナは300秒後に終了し、 ## Readiness Probeを定義する {#define-readiness-probes} -アプリケーションは、一時的にトラフィックを処理できないことが起こり得ます。 -例えば、アプリケーションは、起動時に大きなデータまたは構成ファイルを読み込む必要がある場合や、起動後に外部サービスに依存する可能性があります。 -このような場合、アプリケーションを終了させたくありませんが、リクエストを受けたくないと思います。 +アプリケーションは一時的にトラフィックを処理できないことが起こり得ます。 +例えば、アプリケーションは起動時に大きなデータまたは構成ファイルを読み込む必要がある場合や、起動後に外部サービスに依存している場合があります。 +このような場合、アプリケーション自体を終了させたくはありませんが、このアプリケーションに対してリクエストも送信したくないと思います。 Kubernetesは、これらの状況を検知して緩和するための機能としてReadiness Probeを提供します。 -準備できていないことを報告するコンテナを含むPodは、KubernetesのServiceからトラフィックを受信しないようにできます。 +これにより、準備ができていないことを報告するコンテナを含むPodは、KubernetesのServiceを通してトラフィックを受信しないようになります。 {{< note >}} Readiness Probeは、コンテナの全てのライフサイクルにおいて実行されます。 From af98e9eb59824f4920c359c877806ee132f026cf Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 13:58:48 +0900 Subject: [PATCH 177/290] Update expression in #define-startup-probes --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index ac196403a3..ccc8e84c87 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -221,7 +221,7 @@ livenessProbe: ## Startup Probeを使用して、起動の遅いコンテナを保護する {#define-startup-probes} -場合によっては、最初の初期化において、追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。 +場合によっては、最初の初期化において追加の起動時間が必要になるようなレガシーアプリケーションを扱う必要があります。 そのような場合、デッドロックに対する迅速な反応を損なうことなくLiveness Probeのパラメーターを設定することは難しい場合があります。 これに対する解決策の一つは、Liveness Probeと同じ構成のコマンドを用いるか、HTTPまたはTCPによるチェックを使用したStartup Probeをセットアップすることです。 From ec319820615c99dbd1b9bb9d98488506811dca34 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 14:02:14 +0900 Subject: [PATCH 178/290] Update expression in #define-readiness-probes --- .../configure-liveness-readiness-startup-probes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index ccc8e84c87..99b117d8f6 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -266,8 +266,8 @@ Kubernetesは、これらの状況を検知して緩和するための機能と Readiness Probeは、コンテナの全てのライフサイクルにおいて実行されます。 {{< /note >}} -Readiness Probeは、Liveness Probeと同様に構成します。 -唯一の違いは、`readinessProbe`フィールドを`livenessProbe`フィールドの代わりに利用することだけです。 +Readiness ProbeはLiveness Probeと同様に構成します。 +唯一の違いは`readinessProbe`フィールドを`livenessProbe`フィールドの代わりに利用することだけです。 ```yaml readinessProbe: @@ -279,9 +279,9 @@ readinessProbe: periodSeconds: 5 ``` -HTTPおよびTCPによるReadiness Probeの構成も、Liveness Probeと同じです。 +HTTPおよびTCPによるReadiness Probeの構成もLiveness Probeと同じです。 -Readiness ProbeとLiveness Probeは、同じコンテナで同時に使用できます。 +Readiness ProbeとLiveness Probeは同じコンテナで同時に使用できます。 両方使用することで、準備できていないコンテナへのトラフィックが到達しないようにし、コンテナが失敗したときに再起動することができます。 ## Probeの構成 {#configure-probes} From 76797f659ab496035b47b509bd53e90f7578e1af Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 14:09:05 +0900 Subject: [PATCH 179/290] Update expression in #configure-probes --- .../configure-liveness-readiness-startup-probes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 99b117d8f6..c619290083 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -297,9 +297,9 @@ Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制 * `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 -デフォルトは1。Liveness Probeには、1にする必要があります。最小値は1。 +デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。 * `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 -Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 +Liveness Probeにおいて試行回数に到達することは、コンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。 [HTTPによるProbe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) From dd2c7d3fba4f41c44d057c5deef0e64555fad403 Mon Sep 17 00:00:00 2001 From: jinu Date: Tue, 2 Jun 2020 16:21:40 +0900 Subject: [PATCH 180/290] Update expression content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: inductor(Kohei) --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index c619290083..ddb9c6d5af 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -299,7 +299,7 @@ Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。 * `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 -Liveness Probeにおいて試行回数に到達することは、コンテナを再起動することを意味します。 +Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。 [HTTPによるProbe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) From 444cf3d623426fee69e63d2be655ea307a1f252a Mon Sep 17 00:00:00 2001 From: Shohei Ihaya Date: Tue, 2 Jun 2020 20:52:34 +0900 Subject: [PATCH 181/290] ja: Make docs/concepts/workloads/pods/pod-overview.md follow v1.17 of the original text --- content/ja/docs/concepts/workloads/pods/pod-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 05f68c1e60..7eec0541c5 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -28,7 +28,7 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで * **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。 -- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。 -[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。 +[Kubernetes Blog](https://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) From 4457b5a161d52b377391498fcc996ba87e7aec83 Mon Sep 17 00:00:00 2001 From: Shohei Ihaya Date: Tue, 2 Jun 2020 21:16:12 +0900 Subject: [PATCH 182/290] ja: Make docs/reference/_index.md follow v1.17 of the original text --- content/ja/docs/reference/_index.md | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index 7cbe46514b..2a41ebf925 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -17,12 +17,7 @@ content_template: templates/concept ## APIリファレンス * [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。 -* Kubernetes APIバージョン - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) +* [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) ## APIクライアントライブラリー @@ -35,18 +30,17 @@ content_template: templates/concept ## CLIリファレンス -* [kubectl](/docs/user-guide/kubectl-overview) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 - * [JSONPath](/docs/user-guide/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 -* [kubeadm](/docs/admin/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 -* [kubefed](/docs/admin/kubefed/) - 連合型クラスターを管理するのに役立つCLIツールです。 +* [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 + * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 +* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 ## 設定リファレンス -* [kubelet](/docs/admin/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。 -* [kube-apiserver](/docs/admin/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。 -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。 -* [kube-proxy](/docs/admin/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。 -* [kube-scheduler](/docs/admin/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。 +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。 +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。 +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。 +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。 +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。 ## 設計のドキュメント From a3a18fdf6964f9adea7bb2fb64d5ae8600e27833 Mon Sep 17 00:00:00 2001 From: esakat Date: Tue, 2 Jun 2020 22:07:11 +0900 Subject: [PATCH 183/290] ja: Make /docs/tasks/access-application-cluster/connecting-frontend-backend/ follow v1.17 of the original text --- .../connecting-frontend-backend.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 9ff0a60455..1e9047cee6 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -34,7 +34,7 @@ weight: 70 {{% capture lessoncontent %}} -### Deploymentを使用したバックエンドの作成 +## Deploymentを使用したバックエンドの作成 バックエンドは、単純な挨拶マイクロサービスです。 バックエンドのDeploymentの構成ファイルは次のとおりです: @@ -90,7 +90,7 @@ Events: ... ``` -### バックエンドServiceオブジェクトの作成 +## バックエンドServiceオブジェクトの作成 フロントエンドをバックエンドに接続する鍵は、バックエンドServiceです。 Serviceは、バックエンドマイクロサービスに常に到達できるように、永続的なIPアドレスとDNS名のエントリを作成します。 @@ -110,7 +110,7 @@ kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml この時点で、バックエンドのDeploymentが実行され、そちらにトラフィックをルーティングできるServiceがあります。 -### フロントエンドの作成 +## フロントエンドの作成 バックエンドができたので、バックエンドに接続するフロントエンドを作成できます。 フロントエンドは、バックエンドServiceに指定されたDNS名を使用して、バックエンドワーカーPodに接続します。 @@ -144,7 +144,7 @@ nginxの構成は、[コンテナイメージ](/examples/service/access/Dockerfi これを行うためのより良い方法は、[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。 {{< /note >}} -### フロントエンドServiceと対話 +## フロントエンドServiceと対話 LoadBalancerタイプのServiceを作成したら、このコマンドを使用して外部IPを見つけることができます: @@ -169,7 +169,7 @@ frontend LoadBalancer 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m このIPを使用して、クラスターの外部から`frontend` Serviceとやり取りできるようになりました。 -### フロントエンドを介するトラフィック送信 +## フロントエンドを介するトラフィック送信 フロントエンドとバックエンドが接続されました。 フロントエンドServiceの外部IPに対してcurlコマンドを使用して、エンドポイントにアクセスできます。 From 4da98ec65c21e96522bd6cc9f946ea79ee51022b Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 2 Jun 2020 22:30:40 +0900 Subject: [PATCH 184/290] Update content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-authored-by: nasa9084 --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index af6050c3fa..f2fd37e2de 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -32,7 +32,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-b ## ダッシュボードUIへのアクセス -クラスタデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。このデモ用のトークンを作成するには、[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。 +クラスターデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。このデモ用のトークンを作成するには、[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。 {{< warning >}} チュートリアルで作成されたサンプルユーザーには管理者権限が与えられ、教育目的のみに使用されます。 From 02e84e976de7610b7b5fa5a8f29e88df25df4802 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 2 Jun 2020 22:31:00 +0900 Subject: [PATCH 185/290] Update content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-authored-by: nasa9084 --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index f2fd37e2de..48c005fd8b 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -75,7 +75,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー - **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。コンテナイメージの指定はコロンで終わらせる必要があります。 -- **Number of pods** (必須): アプリケーションをデプロイするPodのターゲット数です。値は正の整数である必要があります。 +- **Number of pods** (必須): アプリケーションをデプロイするPodの数です。値は正の整数である必要があります。 クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。 From d834022dc51c0d992837ce34fd65e63e0b3ddf9d Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 2 Jun 2020 22:31:13 +0900 Subject: [PATCH 186/290] Update content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-authored-by: nasa9084 --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 48c005fd8b..237160bb91 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -79,7 +79,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。 -- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。外部サービスの場合は、そのために1つ以上のポートを開放する必要があるかもしれません。詳細は[こちら](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)を参照してください。 +- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。外部サービスの場合は、そのために1つ以上のポートを開放する必要があるでしょう。詳細は[こちら](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)を参照してください。 クラスター内部からしか見えないその他のサービスは、内部サービスと呼ばれます。 From 1faaa8aba8ef54d0ef3e698cc58c6b320f10a381 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 2 Jun 2020 22:31:25 +0900 Subject: [PATCH 187/290] Update content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-authored-by: nasa9084 --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 237160bb91..26f6fdc76f 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -107,7 +107,7 @@ track=stable 名前空間の作成に成功した場合は、デフォルトで選択されます。作成に失敗した場合は、最初の名前空間が選択されます。 -- **Image Pull Secret**: 指定されたDockerコンテナイメージがプライベートの場合、[pull secret](/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。 +- **Image Pull Secret**: 指定されたDockerコンテナイメージが非公開の場合、[pull secret](/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。 ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。Secret名は最大253文字で構成されます。 From c79f75bb987ad9ca3f38b6238efa7bef6825192e Mon Sep 17 00:00:00 2001 From: mochizuki-pg Date: Tue, 2 Jun 2020 21:05:05 +0900 Subject: [PATCH 188/290] Markdown code blocks described in Shell --- .../ja/docs/concepts/workloads/pods/podpreset.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 1af2514c12..29b4ddbda6 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -6,7 +6,7 @@ weight: 50 --- {{% capture overview %}} -このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 +このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 {{% /capture %}} @@ -16,14 +16,14 @@ weight: 50 `PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。 ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 -PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 +PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 ## PodPresetはどのように動くか -Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 +Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 1. 使用可能な全ての`PodPreset`を取得する。 @@ -40,7 +40,7 @@ Pod作成要求が発生した時、Kubernetesシステムは下記の処理を ### 特定のPodに対するPodPresetを無効にする -PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 +PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 `podpreset.admission.kubernetes.io/exclude: "true"` ## PodPresetを有効にする @@ -48,7 +48,12 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。 1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 -1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`を追加することで可能になります。 +1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + +を追加することで可能になります。 1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。 {{% /capture %}} From 3cd2db9c2b3593c187a3cd6e53b860cb0ded832b Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Tue, 2 Jun 2020 22:35:08 +0900 Subject: [PATCH 189/290] translate forgotten phrase --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 26f6fdc76f..2846ceec67 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -65,7 +65,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー 任意のページの右上にある**CREATE**ボタンをクリックして開始します。 -### Specifying application details +### アプリケーションの詳細の指定 デプロイウィザードでは、以下の情報を入力する必要があります: From a291eb26e0fa7167987e75a1e9ab5b4f6ba5d9f5 Mon Sep 17 00:00:00 2001 From: mochizuki-pg Date: Tue, 2 Jun 2020 22:36:15 +0900 Subject: [PATCH 190/290] Add one blank line --- content/ja/docs/concepts/workloads/pods/podpreset.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 29b4ddbda6..0432924bbb 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -49,6 +49,7 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ 1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に + ```shell --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset ``` From 33c00a596e8addb4228a1cc089a9bd7bf410e8fc Mon Sep 17 00:00:00 2001 From: mochizuki-pg Date: Tue, 2 Jun 2020 22:40:40 +0900 Subject: [PATCH 191/290] fix indent --- content/ja/docs/concepts/workloads/pods/podpreset.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 0432924bbb..e14db1c071 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -50,11 +50,11 @@ PodPresetによるPodの変更を受け付けたくないようなインスタ 1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` -を追加することで可能になります。 + を追加することで可能になります。 1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。 {{% /capture %}} From 67778d609b1f959d3df1395103838f80ace788f4 Mon Sep 17 00:00:00 2001 From: mochizuki-pg Date: Tue, 2 Jun 2020 22:58:00 +0900 Subject: [PATCH 192/290] fix blank space --- content/ja/docs/concepts/workloads/pods/podpreset.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index e14db1c071..4c76bd3a0c 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -6,7 +6,7 @@ weight: 50 --- {{% capture overview %}} -このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 +このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 {{% /capture %}} @@ -16,14 +16,14 @@ weight: 50 `PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。 ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 -PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 +PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 ## PodPresetはどのように動くか -Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 +Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 1. 使用可能な全ての`PodPreset`を取得する。 @@ -40,7 +40,7 @@ Pod作成要求が発生した時、Kubernetesシステムは下記の処理を ### 特定のPodに対するPodPresetを無効にする -PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 +PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 `podpreset.admission.kubernetes.io/exclude: "true"` ## PodPresetを有効にする From 0a6ddff5527a36a67dff162928f0fd5a08b1122a Mon Sep 17 00:00:00 2001 From: akitok Date: Wed, 3 Jun 2020 00:08:29 +0900 Subject: [PATCH 193/290] Update tutorials/configuration/configure-redis-using-configmap.md to follow v1.17 of the original (Englist) text. --- .../configuration/configure-redis-using-configmap.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md index a113679775..722e143088 100644 --- a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -21,7 +21,8 @@ content_template: templates/tutorial {{% capture prerequisites %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + * この例は、バージョン1.14以上での動作を確認しています。 * [ConfigMapを使ったコンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。 @@ -68,7 +69,7 @@ kustomizationディレクトリを反映して、ConfigMapオブジェクトとP kubectl apply -k . ``` -Examine the created objects by +作成されたオブジェクトを確認します ```shell > kubectl get -k . NAME DATA AGE @@ -95,6 +96,11 @@ kubectl exec -it redis redis-cli 2) "allkeys-lru" ``` +作成したPodを削除してください: +```shell +kubectl delete pod redis +``` + {{% /capture %}} {{% capture whatsnext %}} @@ -103,4 +109,3 @@ kubectl exec -it redis redis-cli {{% /capture %}} - From a6640e70d2c10aa38f112bed6f64ca0432665040 Mon Sep 17 00:00:00 2001 From: arisgi Date: Wed, 3 Jun 2020 00:17:13 +0900 Subject: [PATCH 194/290] Remove description of expose option --- .../tutorials/kubernetes-basics/expose/expose-intro.html | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html index c1ad09aa2d..ea39fbd94e 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -79,13 +79,8 @@ weight: 10
  • バージョンタグを埋め込む
  • タグを使用してオブジェクトを分類する
    • +
    -
    -
    -
    -

    kubectlの
    --expose を使用して、Deploymentの作成と同時にServiceを作成できます。

    -
    -

    From 2cb01ae562571193fe9c4e8dae431f979805cae4 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Wed, 3 Jun 2020 08:31:06 +0900 Subject: [PATCH 195/290] fix section 'bash-completion install' --- content/ja/docs/tasks/tools/install-kubectl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 59997650c8..b020581521 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -403,7 +403,7 @@ brew install bash echo $BASH_VERSION $SHELL ``` -Homebrewは通常、`/usr/local/bin/bash`フォルダ下にインストールします。 +Homebrewは通常、`/usr/local/bin/bash`にインストールします。 ### bash-completionをインストールする From 5321aed7fd94f51d47477aa044f28218b1eca779 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Wed, 3 Jun 2020 16:15:33 +0900 Subject: [PATCH 196/290] add tabs tag back --- content/ja/docs/tasks/tools/install-kubectl.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index b020581521..afa28c8a77 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -98,6 +98,7 @@ brew install kubectl kubectl version ``` {{% /tab %}} +{{< /tabs >}} ## macOSへkubectlをインストールする {#install-kubectl-on-macos} From 26ceb76eb92731fe3c8cca06e16c655dba9c8c99 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Sun, 24 May 2020 01:15:31 +0900 Subject: [PATCH 197/290] ja-trans: Translate concepts/policy/resource-quotas.md into Japanese #19282 --- content/ja/docs/concepts/policy/_index.md | 5 + .../docs/concepts/policy/resource-quotas.md | 554 ++++++++++++++++++ 2 files changed, 559 insertions(+) create mode 100755 content/ja/docs/concepts/policy/_index.md create mode 100644 content/ja/docs/concepts/policy/resource-quotas.md diff --git a/content/ja/docs/concepts/policy/_index.md b/content/ja/docs/concepts/policy/_index.md new file mode 100755 index 0000000000..1fa1c815ba --- /dev/null +++ b/content/ja/docs/concepts/policy/_index.md @@ -0,0 +1,5 @@ +--- +title: "リソースのポリシー" +weight: 90 +--- + diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md new file mode 100644 index 0000000000..e11feb50c7 --- /dev/null +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -0,0 +1,554 @@ +--- +reviewers: +title: リソースクォータ +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +複数のユーザーやチームが決められた数のノードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきます。 + +リソースクォータはこの問題に対処するための管理者向けツールです。 + +{{% /capture %}} + + +{{% capture body %}} + +`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。 + +リソースクォータは下記のように働きます。 + +- 異なる名前空間のクラスターで異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 +- 管理者は各名前空間において1つの`ResourceQuota`を作成します。 +- ユーザーが名前空間内でリソース(Pod, Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードウェアリソースのリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 +- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 +- `cpu`や`memory`といったコンピューターリソース対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を教養するために、`LimitRanger`という管理コントローラーを使用してください。この問題を解決する例は[walkthrough](/ja/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 + +名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 + +- 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。 +- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかける。 "production"という名前空間は制限をかけない。 + +クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。 + +リソースの競合もクォータの変更も、作成済みのリソースには影響しません。 + +## リソースクォータを有効にする + +多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときも有効になります。 + +特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその特定の名前空間に適用されます。 + +## リソースクォータの計算 + +特定の名前空間において、[コンピュートリソース](/ja/docs/user-guide/compute-resources)の合計に上限を設定できます。 + +下記のリソースタイプがサポートされています。 + + +| リソース名 | 説明 | +| --------------------- | ----------------------------------------------------------- | +| `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 | +| `limits.memory` | 停止していない状態の全てのPodで、メモリの合計がこの値を超えることができません。 | +| `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 | +| `requests.memory` | 停止していない状態の全てのPodで、メモリリクエストの合計がこの値を超えることができません。 | + +### 拡張リソースのためのリソースクォータ + +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/ja/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 + +拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 + +GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。 + +* `requests.nvidia.com/gpu: 4` + +さらなる詳細は[リソースクォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 + + +## ストレージのリソースクォータ + +特定の名前空間において[ストレージリソース](/ja/docs/concepts/storage/persistent-volumes/)の総数に上限をかけることができます。 + +さらに、関連するストレージクラスに基づいて、ストレージリソースの消費量に上限をかけることもできます。 + +| リソース名 | 説明 | +| --------------------- | ----------------------------------------------------------- | +| `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 | +| `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | +| `.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | + +例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。 + +* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` +* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` + +Kubernetes v1.8において、ローカルのエフェメラルストレージに対するリソースクォータのサポートがα版の機能として追加されました。 + +| リソース名 | 説明 | +| ------------------------------- |----------------------------------------------------------- | +| `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 | +| `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 | + +## オブジェクト数に対するクォータ Object Count Quota + +Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。 + +* `count/.` + +オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。 + +* `count/persistentvolumeclaims` +* `count/services` +* `count/secrets` +* `count/configmaps` +* `count/replicationcontrollers` +* `count/deployments.apps` +* `count/replicasets.apps` +* `count/statefulsets.apps` +* `count/jobs.batch` +* `count/cronjobs.batch` +* `count/deployments.extensions` + +Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 + +`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります!また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 + +Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。 + +下記のタイプのリソースがサポートされています。 + +| リソース名 | 説明 | +| ------------------------------- | ------------------------------------------------- | +| `configmaps` | 名前空間内で存在可能なConfigMapの総数。 | +| `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | +| `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 | +| `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 | +| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/ja/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | +| `services` | 名前空間内で存在可能なServiceの総数。 | +| `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 | +| `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 | +| `secrets` | 名前空間内で存在可能なSecretの総数。 | + +例えば、`Pod`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`Pod`のリソースクォータを設定したい場合があります。 + +## クォータのスコープについて + +各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。 + +スコープがリソースクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセットに以外のリソースクォータ上でリソースを指定するとバリデーションエラーになります。 + +| スコープ | 説明 | +| ----- | ----------- | +| `Terminating` | `.spec.activeDeadlineSeconds >= 0`であるPodに一致します。 | +| `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 | +| `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 | +| `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 | + +`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `Pod` + +`Terminating`, `NotTerminating`, `NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: + +* `cpu` +* `limits.cpu` +* `limits.memory` +* `memory` +* `pods` +* `requests.cpu` +* `requests.memory` + +### PriorityClass毎のリソースクォータ + +{{< feature-state for_k8s_version="1.12" state="beta" >}} + +Podは特定の[Podの優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 + +リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。 + +この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。 + +- クラスター内のPodは3つの優先度クラスのうち1つをもちます。それは"low", "medium", "high"です。 +- 1つのリソースクォータのオブジェクトは優先度毎に作成されます。 + +下記のYAMLを`quota.yml`というファイルに保存します。 + +```yaml +apiVersion: v1 +kind: List +items: +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-high + spec: + hard: + cpu: "1000" + memory: 200Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["high"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-medium + spec: + hard: + cpu: "10" + memory: 20Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["medium"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-low + spec: + hard: + cpu: "5" + memory: 10Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["low"] +``` + +`kubectl create`を実行してYAMLの内容を適用させます。 + +```shell +kubectl create -f ./quota.yml +``` + +```shell +resourcequota/pods-high created +resourcequota/pods-medium created +resourcequota/pods-low created +``` + +`kubectl describe quota`を実行して`Used`クォータが`0`であることを確認します。 + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 1k +memory 0 200Gi +pods 0 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに記述します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: high-priority +spec: + containers: + - name: high-priority + image: ubuntu + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello; sleep 10;done"] + resources: + requests: + memory: "10Gi" + cpu: "500m" + limits: + memory: "10Gi" + cpu: "500m" + priorityClassName: high +``` + +`kubectl create`を使ってマニフェストを適用させます。 + +```shell +kubectl create -f ./high-priority-pod.yml +``` + +`pods-high`という名前のプライオリティーが"high"のクォータにおける"Used"項目の値が変更され、それ以外の2つの値は変更されていないことを確認してください。 + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 500m 1k +memory 10Gi 200Gi +pods 1 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。 + +* `In` +* `NotIn` +* `Exist` +* `DoesNotExist` + +## リクエスト vs リミット + +コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。 + +`requests.cpu`もしくは`requests.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、`limits.cpu`もしくは`limits.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な制限を行います。 + +## クォータの確認と設定 {#viewing-and-setting-quotas} + +kubectlでは、クォータの作成、更新、確認をサポートしています。 + +```shell +kubectl create namespace myspace +``` + +```shell +cat < compute-resources.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: compute-resources +spec: + hard: + requests.cpu: "1" + requests.memory: 1Gi + limits.cpu: "2" + limits.memory: 2Gi + requests.nvidia.com/gpu: 4 +EOF +``` + +```shell +kubectl create -f ./compute-resources.yaml --namespace=myspace +``` + +```shell +cat < object-counts.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-counts +spec: + hard: + configmaps: "10" + persistentvolumeclaims: "4" + pods: "4" + replicationcontrollers: "20" + secrets: "10" + services: "10" + services.loadbalancers: "2" +EOF +``` + +```shell +kubectl create -f ./object-counts.yaml --namespace=myspace +``` + +```shell +kubectl get quota --namespace=myspace +``` + +```shell +NAME AGE +compute-resources 30s +object-counts 32s +``` + +```shell +kubectl describe quota compute-resources --namespace=myspace +``` + +```shell +Name: compute-resources +Namespace: myspace +Resource Used Hard +-------- ---- ---- +limits.cpu 0 2 +limits.memory 0 2Gi +requests.cpu 0 1 +requests.memory 0 1Gi +requests.nvidia.com/gpu 0 4 +``` + +```shell +kubectl describe quota object-counts --namespace=myspace +``` + +```shell +Name: object-counts +Namespace: myspace +Resource Used Hard +-------- ---- ---- +configmaps 0 10 +persistentvolumeclaims 0 4 +pods 0 4 +replicationcontrollers 0 20 +secrets 1 10 +services 0 10 +services.loadbalancers 0 2 +``` + +また、kubectlは`count/.`というシンタックスを用いることにより、名前空間に依存した全ての主要なリソースに対するオブジェクト数のクォータをサポートしています。 + +```shell +kubectl create namespace myspace +``` + +```shell +kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +``` + +```shell +kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +``` + +```shell +kubectl describe quota --namespace=myspace +``` + +```shell +Name: test +Namespace: myspace +Resource Used Hard +-------- ---- ---- +count/deployments.extensions 1 2 +count/pods 2 3 +count/replicasets.extensions 1 4 +count/secrets 1 4 +``` + +## クォータとクラスター容量 + +`ResourceQuotas`はクラスター容量に依存しません。それはユニット数の絶対値で表されます。そのためクラスターにノードを追加した時、`ResourceQuotas`は各名前空間においてさらなるリソース消費を行う能力を自動で追加*しません* + +下記のようなより複雑なポリシーが必要な状況があります。 + + - 複数チーム間でクラスターリソースの総量を分けあう。 + - 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。 + - 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。 + +このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。 + +リソースクォータは集約されたクラスターリソースを分割するが、ノードに対して何の制限も行わないことを注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 + +## デフォルトで優先度クラスの消費を制限する + +特定の優先度を持つPod、例えば"cluster-services"は、条件に一致するクォータオブジェクトが存在するときのみ名前空間上でのPodの使用を許可したい場合があります。 + +このメカニズムにおいて、オペレーターは限られた数の名前空間に対して、一定以上の高い優先度クラスの使用を制限することができ、デフォルトではこのような優先度クラスを全ての名前空間は使用することができません。 + +これを強制するために、kube-apiserverの`--admission-control-config-file`というフラグを使って下記の設定ファイルに対してパスを渡す必要がります。 + +{{< tabs name="example1" >}} +{{% tab name="apiserver.config.k8s.io/v1" %}} +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: apiserver.config.k8s.io/v1 + kind: ResourceQuotaConfiguration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` +{{% /tab %}} +{{% tab name="apiserver.k8s.io/v1alpha1" %}} +```yaml +# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。 +apiVersion: apiserver.k8s.io/v1alpha1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + # v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。 + apiVersion: resourcequota.admission.k8s.io/v1beta1 + kind: Configuration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` +{{% /tab %}} +{{< /tabs >}} + +なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間において存在可能です。 + +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` + +さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。 + +## 例 + +[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +さらなる情報は[リソースクォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 + +{{% /capture %}} From 086fd58a53deebaf050bca7119f353007163797e Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 27 May 2020 23:38:16 +0900 Subject: [PATCH 198/290] ja-trans: Improve Japanese translation in concepts/policy/resource-quotas.md #19282 --- content/ja/docs/concepts/policy/resource-quotas.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index e11feb50c7..d8611fb677 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -93,7 +93,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ | `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 | | `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 | -## オブジェクト数に対するクォータ Object Count Quota +## オブジェクト数に対するクォータ Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。 @@ -345,7 +345,7 @@ pods 0 10 `requests.cpu`もしくは`requests.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、`limits.cpu`もしくは`limits.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な制限を行います。 -## クォータの確認と設定 {#viewing-and-setting-quotas} +## リソースクォータの確認と設定 {#viewing-and-setting-quotas} kubectlでは、クォータの作成、更新、確認をサポートしています。 From ebd0b4c8319cb2dc366de8502add8162dba69ad1 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 00:31:17 +0900 Subject: [PATCH 199/290] ja-trans: Improve Japanese translation in concepts/policy/resource-quotas.md #19282 --- .../docs/concepts/policy/resource-quotas.md | 66 ++++++++++--------- .../concepts/storage/persistent-volumes.md | 2 +- 2 files changed, 35 insertions(+), 33 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index d8611fb677..cd8296f23c 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -20,16 +20,18 @@ weight: 10 リソースクォータは下記のように働きます。 -- 異なる名前空間のクラスターで異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 -- 管理者は各名前空間において1つの`ResourceQuota`を作成します。 -- ユーザーが名前空間内でリソース(Pod, Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードウェアリソースのリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 +- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 +- 管理者は各名前空間で1つの`ResourceQuota`を作成します。 +- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 -- `cpu`や`memory`といったコンピューターリソース対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を教養するために、`LimitRanger`という管理コントローラーを使用してください。この問題を解決する例は[walkthrough](/ja/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 +- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 + +`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 - 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。 -- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかける。 "production"という名前空間は制限をかけない。 +- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかけ、"production"という名前空間には制限をかけない。 クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。 @@ -37,13 +39,13 @@ weight: 10 ## リソースクォータを有効にする -多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときも有効になります。 +多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。 -特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその特定の名前空間に適用されます。 +特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。 ## リソースクォータの計算 -特定の名前空間において、[コンピュートリソース](/ja/docs/user-guide/compute-resources)の合計に上限を設定できます。 +特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。 下記のリソースタイプがサポートされています。 @@ -51,13 +53,13 @@ weight: 10 | リソース名 | 説明 | | --------------------- | ----------------------------------------------------------- | | `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 | -| `limits.memory` | 停止していない状態の全てのPodで、メモリの合計がこの値を超えることができません。 | +| `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 | | `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 | -| `requests.memory` | 停止していない状態の全てのPodで、メモリリクエストの合計がこの値を超えることができません。 | +| `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 | ### 拡張リソースのためのリソースクォータ -上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/ja/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 @@ -65,7 +67,7 @@ GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で * `requests.nvidia.com/gpu: 4` -さらなる詳細は[リソースクォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 +さらなる詳細は[クォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 ## ストレージのリソースクォータ @@ -115,7 +117,7 @@ Kubernetes v1.9では下記のシンタックスを使用して、名前空間 Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 -`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります!また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 +`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。 @@ -127,19 +129,19 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース | `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | | `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 | | `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 | -| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/ja/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | +| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | | `services` | 名前空間内で存在可能なServiceの総数。 | | `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 | | `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 | | `secrets` | 名前空間内で存在可能なSecretの総数。 | -例えば、`Pod`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`Pod`のリソースクォータを設定したい場合があります。 +例えば、`pods`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`pods`のリソースクォータを名前空間に設定したい場合があります。 ## クォータのスコープについて 各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。 -スコープがリソースクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセットに以外のリソースクォータ上でリソースを指定するとバリデーションエラーになります。 +スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。 | スコープ | 説明 | | ----- | ----------- | @@ -148,9 +150,9 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 | | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 | -`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `Pod` +`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods` -`Terminating`, `NotTerminating`, `NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: +`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: * `cpu` * `limits.cpu` @@ -164,13 +166,13 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース {{< feature-state for_k8s_version="1.12" state="beta" >}} -Podは特定の[Podの優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 +Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。 この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。 -- クラスター内のPodは3つの優先度クラスのうち1つをもちます。それは"low", "medium", "high"です。 +- クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。 - 1つのリソースクォータのオブジェクトは優先度毎に作成されます。 下記のYAMLを`quota.yml`というファイルに保存します。 @@ -223,7 +225,7 @@ items: values: ["low"] ``` -`kubectl create`を実行してYAMLの内容を適用させます。 +`kubectl create`を実行してYAMLの内容を適用します。 ```shell kubectl create -f ./quota.yml @@ -269,7 +271,7 @@ memory 0 20Gi pods 0 10 ``` -プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに記述します。 +プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに保存します。 ```yaml apiVersion: v1 @@ -292,7 +294,7 @@ spec: priorityClassName: high ``` -`kubectl create`を使ってマニフェストを適用させます。 +`kubectl create`でマニフェストを適用します。 ```shell kubectl create -f ./high-priority-pod.yml @@ -343,7 +345,7 @@ pods 0 10 コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。 -`requests.cpu`もしくは`requests.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、`limits.cpu`もしくは`limits.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な制限を行います。 +クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。 ## リソースクォータの確認と設定 {#viewing-and-setting-quotas} @@ -480,15 +482,15 @@ count/secrets 1 4 このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。 -リソースクォータは集約されたクラスターリソースを分割するが、ノードに対して何の制限も行わないことを注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 +リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 ## デフォルトで優先度クラスの消費を制限する -特定の優先度を持つPod、例えば"cluster-services"は、条件に一致するクォータオブジェクトが存在するときのみ名前空間上でのPodの使用を許可したい場合があります。 +例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。 -このメカニズムにおいて、オペレーターは限られた数の名前空間に対して、一定以上の高い優先度クラスの使用を制限することができ、デフォルトではこのような優先度クラスを全ての名前空間は使用することができません。 +このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。 -これを強制するために、kube-apiserverの`--admission-control-config-file`というフラグを使って下記の設定ファイルに対してパスを渡す必要がります。 +これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。 {{< tabs name="example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -503,7 +505,7 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` @@ -522,14 +524,14 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` {{% /tab %}} {{< /tabs >}} -なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間において存在可能です。 +なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。 ```yaml scopeSelector: @@ -549,6 +551,6 @@ plugins: {{% capture whatsnext %}} -さらなる情報は[リソースクォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 +さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 {{% /capture %}} diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 3e55db7066..e8aeb996f3 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -400,7 +400,7 @@ PVは[ノードアフィニティ](/docs/reference/generated/kubernetes-api/{{< CLIにはPVに紐付いているPVCの名前が表示されます。 -## 永続ボリューム要求 +## 永続ボリューム要求 {#persistentvolumeclaims} 各PVCにはspecとステータスが含まれます。これは、仕様とクレームのステータスです。 From 74655522d1e24a44a9cfb47374921b0171ffc239 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 00:33:19 +0900 Subject: [PATCH 200/290] ja-trans: Improve Japanese translation in concepts/policy/resource-quotas.md #19282 --- content/ja/docs/concepts/policy/resource-quotas.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index cd8296f23c..8b09a53c6c 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -347,7 +347,7 @@ pods 0 10 クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。 -## リソースクォータの確認と設定 {#viewing-and-setting-quotas} +## クォータの確認と設定 {#viewing-and-setting-quotas} kubectlでは、クォータの作成、更新、確認をサポートしています。 @@ -472,7 +472,7 @@ count/secrets 1 4 ## クォータとクラスター容量 -`ResourceQuotas`はクラスター容量に依存しません。それはユニット数の絶対値で表されます。そのためクラスターにノードを追加した時、`ResourceQuotas`は各名前空間においてさらなるリソース消費を行う能力を自動で追加*しません* +`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。 下記のようなより複雑なポリシーが必要な状況があります。 From 94228a9a81e1bfba8fe25c8a6a2efac5da0720b4 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 22:39:11 +0900 Subject: [PATCH 201/290] ja-trans: Fix Japanese translation in concepts/policy/_index.md #19282 --- content/ja/docs/concepts/policy/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/policy/_index.md b/content/ja/docs/concepts/policy/_index.md index 1fa1c815ba..c4990938e1 100755 --- a/content/ja/docs/concepts/policy/_index.md +++ b/content/ja/docs/concepts/policy/_index.md @@ -1,5 +1,5 @@ --- -title: "リソースのポリシー" +title: "ポリシー" weight: 90 --- From 3903fcc9bdda4fad37cd04168c15d078ff04bdf0 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 22:43:57 +0900 Subject: [PATCH 202/290] ja-trans: Fix page link in ja/docs/concepts/policy/_index.md #19282 --- content/ja/docs/concepts/policy/resource-quotas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index 8b09a53c6c..ea73d05832 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -26,7 +26,7 @@ weight: 10 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 - `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 -`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. +`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 From cc703ed761e34f079711d93bec722538414bd186 Mon Sep 17 00:00:00 2001 From: akitok Date: Wed, 3 Jun 2020 23:27:13 +0900 Subject: [PATCH 203/290] Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-authored-by: Naoki Oketani --- .../tutorials/configuration/configure-redis-using-configmap.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md index 722e143088..db88c90b58 100644 --- a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -24,7 +24,7 @@ content_template: templates/tutorial {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * この例は、バージョン1.14以上での動作を確認しています。 -* [ConfigMapを使ったコンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。 +* [ConfigMapを使ったコンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。 {{% /capture %}} @@ -108,4 +108,3 @@ kubectl delete pod redis * [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)について学ぶ {{% /capture %}} - From 73452d1eed413ba431c38f50df8d05c50a9937a8 Mon Sep 17 00:00:00 2001 From: akitok Date: Wed, 3 Jun 2020 23:28:14 +0900 Subject: [PATCH 204/290] Update tutorials/configuration/configure-redis-using-configmap.md --- .../configuration/configure-redis-using-configmap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md index 722e143088..1e2ded1937 100644 --- a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -24,7 +24,7 @@ content_template: templates/tutorial {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * この例は、バージョン1.14以上での動作を確認しています。 -* [ConfigMapを使ったコンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。 +* [ConfigMapを使ったコンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読んで理解しておいてください。 {{% /capture %}} @@ -96,7 +96,7 @@ kubectl exec -it redis redis-cli 2) "allkeys-lru" ``` -作成したPodを削除してください: +作成したPodを削除します: ```shell kubectl delete pod redis ``` From 1fb30939fca26b7a39fd3f3ddc1baa301ef94a1c Mon Sep 17 00:00:00 2001 From: kondo takeshi Date: Wed, 3 Jun 2020 23:38:48 +0900 Subject: [PATCH 205/290] Follow upstream/release-1.16 to upstream/release-1.17 in Japanese --- .../ja/docs/reference/kubectl/cheatsheet.md | 21 ++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 10827f6762..47b023755c 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -38,7 +38,7 @@ complete -F __start_kubectl k ```bash source <(kubectl completion zsh) # 現在のzshシェルでコマンド補完を設定します -echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。 +echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。 ``` ## Kubectlコンテキストの設定 @@ -84,7 +84,7 @@ kubectl config unset users.foo # ユーザーfooを削除します ## Objectの作成 -Kubernetesのマニフェストファイルは、jsonまたはyamlで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。 +Kubernetesのマニフェストファイルは、JSONまたはYAMLで定義できます。ファイル拡張子として、`.yaml`や`.yml`、`.json`が使えます。 ```bash kubectl apply -f ./my-manifest.yaml # リソースを作成します @@ -92,7 +92,7 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # 複数のファイルからリ kubectl apply -f ./dir # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します kubectl apply -f https://git.io/vPieo # urlで公開されているファイルからリソースを作成します kubectl create deployment nginx --image=nginx # 単一のnginx Deploymentを作成します -kubectl explain pods,svc # PodおよびServiceマニフェストのドキュメントを取得します +kubectl explain pods,svc # Podマニフェストのドキュメントを取得します # 標準入力から複数のYAMLオブジェクトを作成します @@ -147,7 +147,6 @@ kubectl get pods -o wide # 現在のネームスペース kubectl get deployment my-dep # 特定のDeploymentを表示します kubectl get pods # 現在のネームスペース上にあるすべてのPodのリストを表示します kubectl get pod my-pod -o yaml # PodのYAMLを表示します -kubectl get pod my-pod -o yaml --export # クラスター固有の情報を除いたPodのマニフェストをYAMLで表示します # Describeコマンドで詳細な情報を確認します kubectl describe nodes my-node @@ -159,8 +158,8 @@ kubectl get services --sort-by=.metadata.name # Restartカウント順にPodのリストを表示します kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# capacity順にソートしたtestネームスペースに存在するPodのリストを表示します -kubectl get pods -n test --sort-by=.spec.capacity.storage +# capacity順にソートしたPersistentVolumeのリストを表示します +kubectl get pv --sort-by=.spec.capacity.storage # app=cassandraラベルのついたすべてのPodのversionラベルを表示します kubectl get pods --selector=app=cassandra -o \ @@ -195,9 +194,16 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq +# すべてのPodのInitContainerのコンテナIDのリストを表示します +# initContainerの削除を回避しながら、停止したコンテナを削除するときに役立つでしょう +kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 + # タイムスタンプでソートされたEventのリストを表示します kubectl get events --sort-by=.metadata.creationTimestamp + +# クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。 +kubectl diff -f ./my-manifest.yaml ``` ## リソースのアップデート @@ -210,6 +216,7 @@ kubectl rollout history deployment/frontend # frontend Depl kubectl rollout undo deployment/frontend # 1つ前のDeploymentにロールバックします kubectl rollout undo deployment/frontend --to-revision=2 # 特定のバージョンにロールバックします kubectl rollout status -w deployment/frontend # frontend Deploymentのローリングアップデートを状態をwatchします +kubectl rollout restart deployment/frontend # frontend Deployment を再起動します # これらのコマンドは1.11から廃止されました @@ -341,7 +348,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの ### 出力のフォーマット -特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグを追加します。 +特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o （または`--output`）フラグを追加します。 出力フォーマット | 説明 ---------------- | ----------- From 1fe3861a64fdbfb8bd851883bbd0969513f0d6be Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Thu, 4 Jun 2020 10:45:52 +0900 Subject: [PATCH 206/290] Update replicaset.md for v1.17 Update document to follow the original document of 1.17 --- .../workloads/controllers/replicaset.md | 81 ++++++++++--------- 1 file changed, 41 insertions(+), 40 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index dbbba89a8e..a939558454 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -20,7 +20,7 @@ ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示す ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/ja/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。 -ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値がコントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 +ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値が {{< glossary_tooltip term_id="controller" >}} でないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 ## ReplicaSetを使うとき @@ -59,51 +59,48 @@ kubectl describe rs/frontend ```shell Name: frontend Namespace: default -Selector: tier=frontend,tier in (frontend) +Selector: tier=frontend Labels: app=guestbook tier=frontend -Annotations: +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",... Replicas: 3 current / 3 desired Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: - Labels: app=guestbook - tier=frontend + Labels: tier=frontend Containers: php-redis: - Image: gcr.io/google_samples/gb-frontend:v3 - Port: 80/TCP - Requests: - cpu: 100m - memory: 100Mi - Environment: - GET_HOSTS_FROM: dns - Mounts: - Volumes: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: + Host Port: + Environment: + Mounts: + Volumes: Events: - FirstSeen LastSeen Count From SubobjectPath Type Reason Message - --------- -------- ----- ---- ------------- -------- ------ ------- - 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh - 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy - 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm + Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv + Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts ``` そして最後に、ユーザーはReplicaSetによって作成されたPodもチェックできます。 ```shell -kubectl get Pods +kubectl get pods ``` 表示されるPodに関する情報は以下のようになります。 ```shell -NAME READY STATUS RESTARTS AGE -frontend-9si5l 1/1 Running 0 1m -frontend-dnjpy 1/1 Running 0 1m -frontend-qhloh 1/1 Running 0 1m +NAME READY STATUS RESTARTS AGE +frontend-b2zdv 1/1 Running 0 6m36s +frontend-vcmts 1/1 Running 0 6m36s +frontend-wtsmm 1/1 Running 0 6m36s ``` ユーザーはまた、それらのPodの`ownerReferences`が`frontend`ReplicaSetに設定されていることも確認できます。 これを確認するためには、稼働しているPodの中のどれかのyamlファイルを取得します。 ```shell -kubectl get pods frontend-9si5l -o yaml +kubectl get pods frontend-b2zdv -o yaml ``` その表示結果は、以下のようになります。その`frontend`ReplicaSetの情報が`metadata`の`ownerReferences`フィールドにセットされています。 @@ -111,19 +108,19 @@ kubectl get pods frontend-9si5l -o yaml apiVersion: v1 kind: Pod metadata: - creationTimestamp: 2019-01-31T17:20:41Z + creationTimestamp: "2020-02-12T07:06:16Z" generateName: frontend- labels: tier: frontend - name: frontend-9si5l + name: frontend-b2zdv namespace: default ownerReferences: - - apiVersion: extensions/v1beta1 + - apiVersion: apps/v1 blockOwnerDeletion: true controller: true kind: ReplicaSet name: frontend - uid: 892a2330-257c-11e9-aecd-025000000001 + uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf ... ``` @@ -148,16 +145,17 @@ kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml 下記のコマンドでPodを取得できます。 ```shell -kubectl get Pods +kubectl get pods ``` その表示結果で、新しいPodがすでに削除済みか、削除中のステータスになっているのを確認できます。 ```shell NAME READY STATUS RESTARTS AGE -frontend-9si5l 1/1 Running 0 1m -frontend-dnjpy 1/1 Running 0 1m -frontend-qhloh 1/1 Running 0 1m -pod2 0/1 Terminating 0 4s +frontend-b2zdv 1/1 Running 0 10m +frontend-vcmts 1/1 Running 0 10m +frontend-wtsmm 1/1 Running 0 10m +pod1 0/1 Terminating 0 1s +pod2 0/1 Terminating 0 1s ``` もしユーザーがそのPodを最初に作成する場合 @@ -173,15 +171,15 @@ kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml ユーザーはそのReplicaSetが作成したPodを所有し、さらにもともと存在していたPodと今回新たに作成されたPodの数が、理想のレプリカ数になるまでPodを作成するのを確認できます。 ここでまたPodの状態を取得します。 ```shell -kubectl get Pods +kubectl get pods ``` 取得結果は下記のようになります。 ```shell NAME READY STATUS RESTARTS AGE -frontend-pxj4r 1/1 Running 0 5s -pod1 1/1 Running 0 13s -pod2 1/1 Running 0 13s +frontend-hmmj2 1/1 Running 0 9s +pod1 1/1 Running 0 36s +pod2 1/1 Running 0 36s ``` この方法で、ReplicaSetはテンプレートで指定されたもの以外のPodを所有することができます。 @@ -192,6 +190,9 @@ pod2 1/1 Running 0 13s ReplicaSetでは、`kind`フィールドの値は`ReplicaSet`です。 Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが現在のバージョンで、デフォルトで有効です。`apps/v1beta2`というAPIバージョンは廃止されています。先ほど作成した`frontend.yaml`ファイルの最初の行を参考にしてください。 +ReplicaSetオブジェクトの名前は、有効な +[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必須です。 ### Pod テンプレート @@ -234,7 +235,7 @@ REST APIもしくは`client-go`ライブラリーを使用するとき、ユー 例えば下記のように実行します。 ```shell kubectl proxy --port=8080 -curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ > -H "Content-Type: application/json" ``` @@ -245,7 +246,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Orphan`と指定しなくてはなりません。 ```shell kubectl proxy --port=8080 -curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ > -H "Content-Type: application/json" ``` From 8c79145985afbca0758196d14c8371183bcbbba9 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 14:42:23 +0900 Subject: [PATCH 207/290] Update ttlafterfinished.md for v1.17 --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 3c28fe25ea..335fa26e7f 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -9,10 +9,10 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTLメカニズムを提供します。 +TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。 TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 -α版の免責事項: この機能は現在α版の機能で、[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 +α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 {{% /capture %}} @@ -51,6 +51,6 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode [Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) -[設計ドキュメント](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md) +[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) {{% /capture %}} From f6d59f2c3b071ec4e29bc062c4346b68e1842cfd Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Thu, 4 Jun 2020 14:56:51 +0900 Subject: [PATCH 208/290] Translate glossary_tooltip Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/controllers/replicaset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index a939558454..4ac56f17a4 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -20,7 +20,7 @@ ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示す ReplicaSetがそのPod群と連携するためのリンクは、Podの[metadata.ownerReferences](/ja/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの`ownerReferences`フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。 -ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値が {{< glossary_tooltip term_id="controller" >}} でないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 +ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし`ownerReference`フィールドの値を持たないPodか、`ownerReference`フィールドの値が {{< glossary_tooltip text="コントローラー" term_id="controller" >}}でないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 ## ReplicaSetを使うとき From f154650360c0b4c3e3fbedeb20100d3379b4ef41 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Thu, 4 Jun 2020 14:57:33 +0900 Subject: [PATCH 209/290] change docs link to japanese version Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/controllers/replicaset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index 4ac56f17a4..7e988f5d80 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -191,7 +191,7 @@ ReplicaSetでは、`kind`フィールドの値は`ReplicaSet`です。 Kubernetes1.9において、ReplicaSetは`apps/v1`というAPIバージョンが現在のバージョンで、デフォルトで有効です。`apps/v1beta2`というAPIバージョンは廃止されています。先ほど作成した`frontend.yaml`ファイルの最初の行を参考にしてください。 ReplicaSetオブジェクトの名前は、有効な -[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 また、ReplicaSetは[`.spec` セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必須です。 From bdb2636fde609e9b0a9fdc45b4e527c03d80c142 Mon Sep 17 00:00:00 2001 From: mochizuki-pg Date: Thu, 4 Jun 2020 15:43:20 +0900 Subject: [PATCH 210/290] Change the way the RegisterCloudProvider function references the defined line --- .../administer-cluster/developing-cloud-controller-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index ea15264c78..a5358f5bd0 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -13,7 +13,7 @@ content_template: templates/concept 独自のクラウドコントローラーマネージャーを構築する方法を説明する前に、クラウドコントローラーマネージャーがKubernetesの内部でどのように機能するかに関する背景を知っておくと役立ちます。 クラウドコントローラーマネージャーはGoインターフェースを利用する`kube-controller-manager`のコードで、任意のクラウドの実装をプラグインとして利用できるようになっています。スキャフォールディングと汎用のコントローラー実装の大部分はKubernetesのコアになりますが、[クラウドプロバイダーのインターフェイス](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)が満たされていれば提供されているクラウドプロバイダーのインターフェイスが実行されるようになります。 -実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。 +実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。 {{% /capture %}} From 7e0d4d5045138c2f3c5d020a698b4344116261ec Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 4 Jun 2020 14:47:24 +0900 Subject: [PATCH 211/290] Update install-minikube --- .../ja/docs/tasks/tools/install-minikube.md | 66 +++++++++++++++++-- 1 file changed, 60 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index fa98a198be..2b455bd8b9 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -75,12 +75,22 @@ kubectlがインストールされていることを確認してください。 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -{{< note >}} -minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 +Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 -noneドライバーを使用する場合は、[Docker](https://www.docker.com/products/docker-desktop)からdockerのaptインストールを使用することをおすすめします。 -dockerのsnapインストールは、minikubeでは機能しません。 -{{< /note >}} + +Debianもしくはその派生で`none`ドライバーを使用する場合は、snapパッケージではなくDockerの`.deb`パッケージを使用してください。snapパッケージはMinikubeでは機能しません。 +[Docker](https://www.docker.com/products/docker-desktop) から`.deb`パッケージをダウンロードできます。 + +{{< caution >}} +`none`VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 +`--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 +{{< /caution >}} + +MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 + +{{< caution >}} +`podman`ドライバーは、rootでコンテナを実行する必要があります。これは、通常ユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 +{{< /caution >}} ### パッケージを利用したMinikubeのインストール @@ -105,8 +115,16 @@ sudo mkdir -p /usr/local/bin/ sudo install minikube /usr/local/bin/ ``` +### Homebrewを利用したMinikubeのインストール + +別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。 + +```shell +brew install minikube +``` + {{% /tab %}} -{{% tab name="macOS" %}} +n{{% tab name="macOS" %}} ### kubectlのインストール kubectlがインストールされていることを確認してください。 @@ -190,6 +208,42 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window {{% /capture %}} +## インストールの確認 + +ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください: + +{{< note >}} + +`minikube start`で`--vm-driver`の設定をするため、次の``の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 + +{{< /note >}} + +```shell +minikube start --vm-driver= +``` + +`mnikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 + +```shell +minikube status +``` + +クラスターが起動していると、`minikube status`の出力はこのようになります。 + +``` +host: Running +kubelet: Running +apiserver: Running +kubeconfig: Configured +``` + +選択したハイパーバイザーでMinikubeが動作しているかどうか確認した後は、Minikubeを使い続けるか、クラスターを停止できます。クラスター +を停止するためには、次を実行してください。 + +```shell +minikube stop +``` + ## ローカル状態のクリーンアップ {#cleanup-local-state} もし以前に　Minikubeをインストールしていたら、以下のコマンドを実行します。 From 0b5271a731a584ae7287e7f8980d4b0e1a81b97e Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 4 Jun 2020 14:51:56 +0900 Subject: [PATCH 212/290] Update install-minikube --- content/ja/docs/tasks/tools/install-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 2b455bd8b9..46e19282a7 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -124,7 +124,7 @@ brew install minikube ``` {{% /tab %}} -n{{% tab name="macOS" %}} +{{% tab name="macOS" %}} ### kubectlのインストール kubectlがインストールされていることを確認してください。 From b72c35d9dde7369bcfeca36e41dea04456627ca9 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Thu, 4 Jun 2020 15:52:42 +0900 Subject: [PATCH 213/290] Update content/ja/docs/tasks/tools/install-minikube.md Co-authored-by: inductor(Kohei) --- content/ja/docs/tasks/tools/install-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 46e19282a7..35072e26d6 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -78,7 +78,7 @@ kubectlがインストールされていることを確認してください。 Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 -Debianもしくはその派生で`none`ドライバーを使用する場合は、snapパッケージではなくDockerの`.deb`パッケージを使用してください。snapパッケージはMinikubeでは機能しません。 +Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールください。snapパッケージはMinikubeでは機能しません。 [Docker](https://www.docker.com/products/docker-desktop) から`.deb`パッケージをダウンロードできます。 {{< caution >}} From ec221cb57124360a2a2fbc6b8b8f4142f2021137 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 4 Jun 2020 16:12:17 +0900 Subject: [PATCH 214/290] update to follow requested change --- content/ja/docs/tasks/tools/install-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 46e19282a7..35072e26d6 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -78,7 +78,7 @@ kubectlがインストールされていることを確認してください。 Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 -Debianもしくはその派生で`none`ドライバーを使用する場合は、snapパッケージではなくDockerの`.deb`パッケージを使用してください。snapパッケージはMinikubeでは機能しません。 +Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールください。snapパッケージはMinikubeでは機能しません。 [Docker](https://www.docker.com/products/docker-desktop) から`.deb`パッケージをダウンロードできます。 {{< caution >}} From bdc7ab86ecd8059e304c968fed234eab8d36a599 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 16:14:29 +0900 Subject: [PATCH 215/290] Update pod-lifecycle.md for v1.17 --- .../concepts/workloads/pods/pod-lifecycle.md | 37 +++++++++++++------ 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index f15348f443..be38978d6a 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -53,7 +53,6 @@ PodCondition配列の各要素には、次の6つのフィールドがありま * `PodScheduled`: PodがNodeにスケジュールされました。 * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 * `Initialized`: すべての[init containers](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。 - * `Unschedulable`: リソースの枯渇やその他の理由で、Podがスケジュールできない状態です。 * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 @@ -80,7 +79,7 @@ Handlerには次の3つの種類があります: * Failure: コンテナの診断が失敗しました。 * Unknown: コンテナの診断が失敗し、取れるアクションがありません。 -Kubeletは2種類のProbeを実行中のコンテナで行い、また反応することができます: +Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: * `livenessProbe`: コンテナが動いているかを示します。 livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 @@ -91,7 +90,14 @@ Kubeletは2種類のProbeを実行中のコンテナで行い、また反応す initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 -### livenessProbeとreadinessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} +* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。 + startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 + startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 + コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 + +### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 @@ -99,6 +105,10 @@ livenessProbeは不要です。この場合kubeletが自動でPodの`restartPoli Probeに失敗したときにコンテナを殺したり再起動させたりするには、 livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 +### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、 readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。 @@ -111,8 +121,17 @@ Podが削除されたときにリクエストを来ないようにするため Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunhealthyにします。 Pod内のコンテナが停止するのを待つ間Podはunhealthyのままです。 -livenessProbeまたはreadinessProbeを設定する方法の詳細については、 -[Configure Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)を参照してください +### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProveと同じエンドポイントをチェックするためにstartupProbeを指定します。 +`periodSeconds`のデフォルトは30秒です。 + +`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。 + +livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、 +[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 ## Podとコンテナのステータス {#pod-and-container-status} @@ -137,7 +156,7 @@ Pod内のコンテナごとにStateの項目として表示されます。 ... ``` -* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunningに入ると`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。 +* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。 ```yaml ... @@ -201,10 +220,6 @@ status: PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。 -K8s 1.1ではAlpha機能のため"Pod Ready++" 機能は`PodReadinessGates` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)にて明示的に指定する必要があります。 - -K8s 1.12ではこの機能はデフォルトで有効になっています。 - ## RestartPolicy {#restart-policy} PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。 @@ -324,7 +339,7 @@ spec: * [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる -* [configuring liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のハンズオンをやってみる +* [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のハンズオンをやってみる * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ From ee11f4aaa892b188afec8e7dc80df8fb9dcd352a Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Thu, 4 Jun 2020 17:08:40 +0900 Subject: [PATCH 216/290] typo of livenessProbe Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index be38978d6a..19acaec982 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -125,7 +125,7 @@ Pod内のコンテナが停止するのを待つ間Podはunhealthyのままで {{< feature-state for_k8s_version="v1.16" state="alpha" >}} -コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProveと同じエンドポイントをチェックするためにstartupProbeを指定します。 +コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。 `periodSeconds`のデフォルトは30秒です。 `failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。 From e0e9b1e46f18f939964f017cc0c2ef41ab7eb37c Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Thu, 4 Jun 2020 17:09:23 +0900 Subject: [PATCH 217/290] link docs to japanese version Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 19acaec982..cfd8fcb859 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -131,7 +131,7 @@ Pod内のコンテナが停止するのを待つ間Podはunhealthyのままで `failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。 livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、 -[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 +[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 ## Podとコンテナのステータス {#pod-and-container-status} From 386623edd2893bd2efaec8f76d7641149332c204 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Thu, 4 Jun 2020 17:09:31 +0900 Subject: [PATCH 218/290] link docs to japanese version Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index cfd8fcb859..08c1f572ee 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -339,7 +339,7 @@ spec: * [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオンをやってみる -* [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のハンズオンをやってみる +* [Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のハンズオンをやってみる * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ From a3fde1051a499b5f86da5d302e96277424628f57 Mon Sep 17 00:00:00 2001 From: KJ Date: Thu, 4 Jun 2020 17:28:21 +0900 Subject: [PATCH 219/290] Make docs/concepts/workloads/pods/pod.md follow v1.17 of the original text --- content/ja/docs/concepts/workloads/pods/pod.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index e0d9c951b4..81f109cb4f 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -141,7 +141,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される 1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 - 猶予期間が終了した後も `preStop` フックがまだ実行されている場合は、次に、短い延長された猶予期間（2秒）でステップ2が呼び出される + 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を修正する必要がある。 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある 1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない @@ -157,7 +157,7 @@ kubectlのバージョン1.5以降では、強制削除を実行するために ### Podの強制削除 Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。 -強制削除が実行されると、apiserverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。 +強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。 API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。 Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 From 9e48b31aad358ffeed6bb83bd8e1a628cc7e6560 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 17:55:34 +0900 Subject: [PATCH 220/290] Update pod-lifecycle.md for typo --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 08c1f572ee..d6f82e099e 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -118,8 +118,8 @@ readinessProbeが存在するということは、Podがトラフィックを受 livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。 -Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunhealthyにします。 -Pod内のコンテナが停止するのを待つ間Podはunhealthyのままです。 +Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。 +Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。 ### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} @@ -165,7 +165,7 @@ Pod内のコンテナごとにStateの項目として表示されます。 ... ``` -* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあればあれば実行されます。 +* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。 ```yaml ... From f6afad446befff30310b5ca5845ae66c71c75f3e Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 4 Jun 2020 18:19:05 +0900 Subject: [PATCH 221/290] add a space after driver names --- content/ja/docs/tasks/tools/install-minikube.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 35072e26d6..207215a95f 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -82,14 +82,14 @@ Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッ [Docker](https://www.docker.com/products/docker-desktop) から`.deb`パッケージをダウンロードできます。 {{< caution >}} -`none`VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 +`none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 `--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 {{< /caution >}} MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 {{< caution >}} -`podman`ドライバーは、rootでコンテナを実行する必要があります。これは、通常ユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 +`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常ユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 {{< /caution >}} ### パッケージを利用したMinikubeのインストール From d1620ac74c937d1e706cada2590bff558776a4f8 Mon Sep 17 00:00:00 2001 From: Takeshi Kondo <10370988+chaspy@users.noreply.github.com> Date: Thu, 4 Jun 2020 18:50:31 +0900 Subject: [PATCH 222/290] Update content/ja/docs/reference/kubectl/cheatsheet.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/kubectl/cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 47b023755c..304a473317 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -92,7 +92,7 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # 複数のファイルからリ kubectl apply -f ./dir # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します kubectl apply -f https://git.io/vPieo # urlで公開されているファイルからリソースを作成します kubectl create deployment nginx --image=nginx # 単一のnginx Deploymentを作成します -kubectl explain pods,svc # Podマニフェストのドキュメントを取得します +kubectl explain pods # Podマニフェストのドキュメントを取得します # 標準入力から複数のYAMLオブジェクトを作成します From d76e7a98633038b82f68dca19e5b44f44c6937c1 Mon Sep 17 00:00:00 2001 From: Takeshi Kondo <10370988+chaspy@users.noreply.github.com> Date: Thu, 4 Jun 2020 18:50:38 +0900 Subject: [PATCH 223/290] Update content/ja/docs/reference/kubectl/cheatsheet.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/kubectl/cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 304a473317..449e3d43ff 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -348,7 +348,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの ### 出力のフォーマット -特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o （または`--output`）フラグを追加します。 +特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o(または`--output`)フラグを追加します。 出力フォーマット | 説明 ---------------- | ----------- From e132feddefbef612119a65c8954c34b100bf0b67 Mon Sep 17 00:00:00 2001 From: jinu Date: Thu, 4 Jun 2020 18:55:37 +0900 Subject: [PATCH 224/290] Update expression in content/ja/docs/concepts/workloads/pods/pod.md Co-authored-by: bells17 --- content/ja/docs/concepts/workloads/pods/pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md index 81f109cb4f..e994c61693 100644 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ b/content/ja/docs/concepts/workloads/pods/pod.md @@ -141,7 +141,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される 1. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 - 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を修正する必要がある。 + 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して（2秒）、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある 1. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない From 4fdd219f5ae2aa240c4495295ddbb0142437673d Mon Sep 17 00:00:00 2001 From: Takeshi Kondo <10370988+chaspy@users.noreply.github.com> Date: Thu, 4 Jun 2020 19:47:09 +0900 Subject: [PATCH 225/290] Update content/ja/docs/reference/kubectl/cheatsheet.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/kubectl/cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 449e3d43ff..504b266583 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -348,7 +348,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの ### 出力のフォーマット -特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o(または`--output`)フラグを追加します。 +特定の形式で端末ウィンドウに詳細を出力するには、サポートされている`kubectl`コマンドに`-o`(または`--output`)フラグを追加します。 出力フォーマット | 説明 ---------------- | ----------- From 325b993f67cb5bd34740252b393a48ca6be91dbb Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 21:18:18 +0900 Subject: [PATCH 226/290] Update persistent-volumes.md for v1.17 --- .../concepts/storage/persistent-volumes.md | 29 +++++++++++++++++-- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index e8aeb996f3..2efb692b84 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -54,7 +54,7 @@ APIサーバーのコマンドラインフラグの詳細については[kube-ap ### バインディング -ユーザは、特定のサイズのストレージとアクセスモードを指定した上で`PersistentVolumeClaim`を作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なく`PersistentVolumeClaim`の紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは1対1です。 +ユーザは、特定のサイズのストレージとアクセスモードを指定した上でPersistentVolumeClaimを作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なくPersistentVolumeClaimの紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは1対1で、ClaimRefを使用したPersistentVolumeとPersistentVolumeClaim間の双方向の紐付けです。 一致するボリュームが存在しない場合、クレームはいつまでも紐付けされないままになります。一致するボリュームが利用可能になると、クレームがバインドされます。たとえば、50GiのPVがいくつもプロビジョニングされているクラスターだとしても、100Giを要求するPVCとは一致しません。100GiのPVがクラスターに追加されると、PVCを紐付けできます。 @@ -99,7 +99,7 @@ Labels: type=local Annotations: Finalizers: [kubernetes.io/pv-protection] StorageClass: standard -Status: Available +Status: Terminating Claim: Reclaim Policy: Delete Access Modes: RWO @@ -260,6 +260,8 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー ## 永続ボリューム 各PVには、仕様とボリュームのステータスが含まれているspecとstatusが含まれています。 +PersistentVolumeオブジェクトの名前は、有効な +[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 ```yaml apiVersion: v1 @@ -282,6 +284,11 @@ spec: server: 172.17.0.2 ``` +{{< note >}} +クラスター内でPersistentVolumeを使用するには、ボリュームタイプに関連するヘルパープログラムが必要な場合があります。 +この例では、PersistentVolumeはNFSタイプで、NFSファイルシステムのマウントをサポートするためにヘルパープログラム /sbin/mount.nfs が必要になります。 +{{< /note >}} + ### 容量 通常、PVには特定のストレージ容量があります。これはPVの`capacity`属性を使用して設定されます。容量によって期待される単位を理解するためには、Kubernetesの[リソースモデル](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)を参照してください。 @@ -404,6 +411,9 @@ CLIにはPVに紐付いているPVCの名前が表示されます。 各PVCにはspecとステータスが含まれます。これは、仕様とクレームのステータスです。 +PersistentVolumeClaimオブジェクトの名前は、有効な +[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + ```yaml apiVersion: v1 kind: PersistentVolumeClaim @@ -594,7 +604,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス ## ボリュームのスナップショットとスナップショットからのボリュームの復元のサポート -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} ボリュームスナップショット機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームのスナップショット](/docs/concepts/storage/volume-snapshots/)を参照してください。 @@ -659,3 +669,16 @@ spec: - ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。 {{% /capture %}} + {{% capture whatsnext %}} + +* [Creating a Persistent Volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)について学ぶ +* [Creating a Persistent Volume Claim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)について学ぶ +* [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)を読む + +### リファレンス + +* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) +* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) +* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) + {{% /capture %}} \ No newline at end of file From 98b03d44c6aed44864ca602a45c53eefad633dff Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 21:39:56 +0900 Subject: [PATCH 227/290] Update cron-jobs.md for v1.17 --- .../concepts/workloads/controllers/cron-jobs.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 0520b8a97b..f7cae6411c 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -6,14 +6,21 @@ weight: 80 {{% capture overview %}} +{{< feature-state for_k8s_version="v1.8" state="beta" >}} + _CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。 _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。 [Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。 -{{< note >}} -すべての**CronJob**`スケジュール`: 時刻はジョブが開始されたマスタータイムゾーンに基づいています。 -{{< /note >}} +{{< caution >}} +すべての**CronJob**`スケジュール`: 時刻はジョブが開始された{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}のタイムゾーンに基づいています。 + +コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、kube-controller-manager コンテナに設定されたタイムゾーンは、cron ジョブコントローラーが使用するタイムゾーンを決定します。 +{{< /caution >}} + +cronジョブリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 +名前は52文字を超えることはできません。これはcronジョブコントローラーが自動的に11文字のジョブ名を追加し、ジョブ名の最大長は63文字以内という制約があるためです。 cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。 @@ -27,7 +34,7 @@ cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1 `startingDeadlineSeconds`が大きな値、もしくは設定されていない(デフォルト)、そして、`concurrencyPolicy`を`Allow`に設定している場合には、少なくとも一度、ジョブが実行されることを保証します。 -最後にスケジュールされた時刻から現在までの間に、CronJobコントローラーはどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。 +最後にスケジュールされた時刻から現在までの間に、CronJob{{< glossary_tooltip term_id="controller" text="コントローラー">}}はどれだけスケジュールが間に合わなかったのかをCronJobごとにチェックします。もし、100回以上スケジュールが失敗していると、ジョブは開始されずに、ログにエラーが記録されます。 ```` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. From 0fc7cafdbde61408dac391832514610d52b9a9e6 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 21:54:07 +0900 Subject: [PATCH 228/290] Update daemonset.md for v1.17 --- .../docs/concepts/workloads/controllers/daemonset.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index ddd5089c02..9b73db731d 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -12,8 +12,8 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー DaemonSetのいくつかの典型的な使用例は以下の通りです。 - `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。 -- `fluentd`や`logstash`のようなログ集計デーモンを各Node上で稼働させる。 -- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`やInstana agentなどのようなNodeのモニタリングデーモンを各Node上で稼働させる。 +- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。 +- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。 シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。 さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。 @@ -32,7 +32,8 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。 {{< codenew file="controllers/daemonset.yaml" >}} -* YAMLファイルに基づいてDaemonSetを作成します。 +YAMLファイルに基づいてDaemonSetを作成します。 + ``` kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` @@ -42,6 +43,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。 設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 +DaemonSetオブジェクトの名前は、有効な +[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)セクションも必須となります。 ### Podテンプレート @@ -80,7 +84,7 @@ selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPod ## Daemon Podがどのようにスケジューリングされるか -### デフォルトスケジューラーによってスケジューリングされる場合(Kubernetes1.12からデフォルトで有効) +### デフォルトスケジューラーによってスケジューリングされる場合 {{< feature-state state="stable" for-kubernetes-version="1.17" >}} From cff14841b179f28ddd6bb50b2dfd9f804c183300 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Thu, 4 Jun 2020 22:08:17 +0900 Subject: [PATCH 229/290] Update debug-pod-replication-controller.md --- .../debug-pod-replication-controller.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 406466cc1c..94af1da0ce 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -113,6 +113,8 @@ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${AR kubectl exec cassandra -- cat /var/log/cassandra/system.log ``` +クラスターで有効にしていれば、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) を既存のPodに追加することもできます。 新しい一時的なコンテナを利用して、たとえばPod内の問題の診断のために任意のコマンドを実行することができます。利用できる機能を含む詳細については、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) のページを参照してください。 + これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。 ## ReplicationControllerのデバッグ From fb5793cd0eae85be20385a57bbfbce05d5a71789 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Fri, 5 Jun 2020 08:01:46 +0900 Subject: [PATCH 230/290] ja: Make docs/concepts/overview/working-with-objects/labels.md follow v1.17 of the original text --- .../overview/working-with-objects/labels.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index ec6f9f7201..33e30771b0 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -59,6 +59,26 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ 正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。 +例えば、`environment: production`と`app: nginx`の2つのラベルを持つPodのconfigファイルは下記のようになります。 + +```yaml + +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + +``` + ## ラベルセレクター {#label-selectors} [名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 From 0342000e728d681601cafdb71b0902b184259766 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Fri, 5 Jun 2020 08:13:44 +0900 Subject: [PATCH 231/290] add caution to 'Label selectors' section --- .../ja/docs/concepts/overview/working-with-objects/labels.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 33e30771b0..5926e3b9e3 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -97,6 +97,10 @@ Kubernetes APIは現在2タイプのセレクターをサポートしていま ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。 {{< /note >}} +{{< caution >}} +等価ベース、集合ベースともに、論理OR (`||`) オペレーターは存在しません。フィルターステートメントが構造化されていることを適宜確認してください。 +{{< /caution >}} + ### *等価ベース(Equality-based)* の要件(requirement) *等価ベース(Equality-based)* もしくは*不等ベース(Inequality-based)* の要件は、ラベルキーとラベル値によるフィルタリングを可能にします。 From e3a09dbd3ffb2eda4aac80aa8f96f4211cb7bc85 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 08:34:11 +0900 Subject: [PATCH 232/290] Update content/ja/docs/concepts/workloads/controllers/cron-jobs.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index f7cae6411c..b678a07c5c 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -19,7 +19,7 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、kube-controller-manager コンテナに設定されたタイムゾーンは、cron ジョブコントローラーが使用するタイムゾーンを決定します。 {{< /caution >}} -cronジョブリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 +CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 名前は52文字を超えることはできません。これはcronジョブコントローラーが自動的に11文字のジョブ名を追加し、ジョブ名の最大長は63文字以内という制約があるためです。 cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。 From 3ae504eed163605c98faccdc2a599ca5124484e3 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 08:34:38 +0900 Subject: [PATCH 233/290] Update content/ja/docs/concepts/workloads/controllers/cron-jobs.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index b678a07c5c..a4ada8793f 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -20,7 +20,7 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら {{< /caution >}} CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 -名前は52文字を超えることはできません。これはcronジョブコントローラーが自動的に11文字のジョブ名を追加し、ジョブ名の最大長は63文字以内という制約があるためです。 +名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。 cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。 From 8837c13333572b2a762723f79914594b60dbd684 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 09:09:21 +0900 Subject: [PATCH 234/290] Quote path with code block --- content/ja/docs/concepts/storage/persistent-volumes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 2efb692b84..73fa76bedd 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -286,7 +286,7 @@ spec: {{< note >}} クラスター内でPersistentVolumeを使用するには、ボリュームタイプに関連するヘルパープログラムが必要な場合があります。 -この例では、PersistentVolumeはNFSタイプで、NFSファイルシステムのマウントをサポートするためにヘルパープログラム /sbin/mount.nfs が必要になります。 +この例では、PersistentVolumeはNFSタイプで、NFSファイルシステムのマウントをサポートするためにヘルパープログラム`/sbin/mount.nfs`が必要になります。 {{< /note >}} ### 容量 @@ -681,4 +681,4 @@ spec: * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) - {{% /capture %}} \ No newline at end of file + {{% /capture %}} From cc0aeb95991ed7a0d1a5755926b04602c4045aa5 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 5 Jun 2020 09:35:39 +0900 Subject: [PATCH 235/290] update following reviewr comments --- content/ja/docs/tasks/tools/install-minikube.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 207215a95f..161dc26825 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -78,8 +78,8 @@ kubectlがインストールされていることを確認してください。 Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 -Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールください。snapパッケージはMinikubeでは機能しません。 -[Docker](https://www.docker.com/products/docker-desktop) から`.deb`パッケージをダウンロードできます。 +Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。 +[Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。 {{< caution >}} `none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 @@ -89,7 +89,7 @@ Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッ MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 {{< caution >}} -`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常ユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 +`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 {{< /caution >}} ### パッケージを利用したMinikubeのインストール @@ -222,7 +222,7 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window minikube start --vm-driver= ``` -`mnikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 +`minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 ```shell minikube status @@ -237,7 +237,7 @@ apiserver: Running kubeconfig: Configured ``` -選択したハイパーバイザーでMinikubeが動作しているかどうか確認した後は、Minikubeを使い続けるか、クラスターを停止できます。クラスター +選択したハイパーバイザーでMinikubeが動作しているか確認した後は、Minikubeを使い続けるか、クラスターを停止できます。クラスター を停止するためには、次を実行してください。 ```shell From a1cb7008fa3446ada7dec7da6c492cb0cf6ba1ff Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 09:55:08 +0900 Subject: [PATCH 236/290] Update kube-scheduler.md for v1.17 --- content/ja/docs/concepts/scheduling/kube-scheduler.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/scheduling/kube-scheduler.md b/content/ja/docs/concepts/scheduling/kube-scheduler.md index 53fd5c67b7..a6af30f763 100644 --- a/content/ja/docs/concepts/scheduling/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling/kube-scheduler.md @@ -106,13 +106,16 @@ kube-schedulerは、デフォルトで用意されているスケジューリン - `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。 -- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。 +- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。 - `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。 {{% /capture %}} {{% capture whatsnext %}} * [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。 +* [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 -* [複数のスケジューラーの設定](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 +* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 +* [トポロジー管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。 +* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。 {{% /capture %}} From fae6668fd6fdba2d52ab1ea823d200d31591a63f Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 10:20:07 +0900 Subject: [PATCH 237/290] Update content/ja/docs/concepts/workloads/controllers/cron-jobs.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index a4ada8793f..85575c57bb 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -16,7 +16,7 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら {{< caution >}} すべての**CronJob**`スケジュール`: 時刻はジョブが開始された{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}のタイムゾーンに基づいています。 -コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、kube-controller-manager コンテナに設定されたタイムゾーンは、cron ジョブコントローラーが使用するタイムゾーンを決定します。 +コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、cronジョブコントローラーのタイムゾーンとして、kube-controller-managerコンテナに設定されたタイムゾーンを使用します。 {{< /caution >}} CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 From 46d998658cbe67da238b22317689b63451f18a55 Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Fri, 5 Jun 2020 10:47:11 +0900 Subject: [PATCH 238/290] change url to japanese page --- .../ja/docs/concepts/overview/working-with-objects/labels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 5926e3b9e3..255d039041 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -198,7 +198,7 @@ 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`](/ja/docs/user-guide/services) と [`ReplicationController`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。 #### ServiceとReplicationController `Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。 From ba0cf849d702028928f2161b1ac2f5185083eb95 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 11:06:12 +0900 Subject: [PATCH 239/290] change the expression of CronJob controller --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 85575c57bb..ca73516682 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -16,7 +16,7 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら {{< caution >}} すべての**CronJob**`スケジュール`: 時刻はジョブが開始された{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}のタイムゾーンに基づいています。 -コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、cronジョブコントローラーのタイムゾーンとして、kube-controller-managerコンテナに設定されたタイムゾーンを使用します。 +コントロールプレーンがkube-controller-managerをPodもしくは素のコンテナで実行している場合、CronJobコントローラーのタイムゾーンとして、kube-controller-managerコンテナに設定されたタイムゾーンを使用します。 {{< /caution >}} CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 From 7451ebae7a76dbdaee6d44c72024065940e1fb2c Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 12:18:38 +0900 Subject: [PATCH 240/290] Change the expression of topology management policy Co-authored-by: bells17 --- content/ja/docs/concepts/scheduling/kube-scheduler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling/kube-scheduler.md b/content/ja/docs/concepts/scheduling/kube-scheduler.md index a6af30f763..53fd6d26bb 100644 --- a/content/ja/docs/concepts/scheduling/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling/kube-scheduler.md @@ -116,6 +116,6 @@ kube-schedulerは、デフォルトで用意されているスケジューリン * [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 * [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 -* [トポロジー管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。 +* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。 * [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。 {{% /capture %}} From 70f585823fce2dffa9bf6c2455e02d4d61900e97 Mon Sep 17 00:00:00 2001 From: nishipy Date: Fri, 5 Jun 2020 12:47:23 +0900 Subject: [PATCH 241/290] Update configure-access-multiple-clusters.md --- .../configure-access-multiple-clusters.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index fd5784a093..cfe066e646 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -73,7 +73,9 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username= ``` {{< note >}} -`kubectl config unset users.`を実行すると、ユーザーを削除することができます。 +`kubectl --kubeconfig=config-demo config unset users.`を実行すると、ユーザーを削除することができます。 +`kubectl --kubeconfig=config-demo config unset clusters.`を実行すると、クラスターを除去することができます。 +`kubectl --kubeconfig=config-demo config unset contexts.`を実行すると、context情報を除去することができます。 {{< /note >}} context情報を設定ファイルに追加してください: From 451bbf4568ecd67a7a7ca81a18dc64f9ab1cccb1 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 13:15:44 +0900 Subject: [PATCH 242/290] Update service-access-application-cluster.md --- .../service-access-application-cluster.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index 48be31fdb4..b6e346bd83 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -32,9 +32,14 @@ weight: 60 ## 2つのPodから成るアプリケーションのServiceを作成 +アプリケーションDeploymentの設定ファイルは以下の通りです: + +{{< codenew file="service/access/hello-application.yaml" >}} + 1. クラスタでHello Worldアプリケーションを稼働させます: + 上記のファイルを使用し、アプリケーションDeploymentを作成します: ```shell - kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080 + kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` このコマンドは [Deployment](/ja/docs/concepts/workloads/controllers/deployment/) From ba6375208f023f62f15b01e7c4955d6dd32f73e9 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 13:25:59 +0900 Subject: [PATCH 243/290] Update update-intro.html for v1.17 --- .../docs/tutorials/kubernetes-basics/update/update-intro.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/ja/docs/tutorials/kubernetes-basics/update/update-intro.html index 657c26a232..c4b27db8b2 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -9,8 +9,7 @@ weight: 10 - - +
    From b0d4e5a57de42edfcf2abebd600fb0455d377cb4 Mon Sep 17 00:00:00 2001 From: nishipy Date: Fri, 5 Jun 2020 13:27:59 +0900 Subject: [PATCH 244/290] Update configure-access-multiple-clusters.md --- .../configure-access-multiple-clusters.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index cfe066e646..2c26e33fff 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -10,7 +10,7 @@ card: {{% capture overview %}} -ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、contextの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。 +ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、コンテキストの情報を一つ以上の設定ファイルにまとめることで、`kubectl config use-context`のコマンドを使ってクラスターを素早く切り替えることができます。 {{< note >}} クラスターへのアクセスを設定するファイルを、*kubeconfig* ファイルと呼ぶことがあります。これは設定ファイルの一般的な呼び方です。`kubeconfig`という名前のファイルが存在するわけではありません。 @@ -26,7 +26,7 @@ card: {{% capture steps %}} -## クラスター、ユーザー、contextを設定する +## クラスター、ユーザー、コンテキストを設定する 例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。 @@ -56,7 +56,7 @@ contexts: name: exp-scratch ``` -設定ファイルには、クラスター、ユーザー、contextの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのcontextの情報が含まれています。 +設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。 `config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください: @@ -75,10 +75,10 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username= {{< note >}} `kubectl --kubeconfig=config-demo config unset users.`を実行すると、ユーザーを削除することができます。 `kubectl --kubeconfig=config-demo config unset clusters.`を実行すると、クラスターを除去することができます。 -`kubectl --kubeconfig=config-demo config unset contexts.`を実行すると、context情報を除去することができます。 +`kubectl --kubeconfig=config-demo config unset contexts.`を実行すると、コンテキスト情報を除去することができます。 {{< /note >}} -context情報を設定ファイルに追加してください: +コンテキスト情報を設定ファイルに追加してください: ```shell kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer @@ -92,7 +92,7 @@ kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratc kubectl config --kubeconfig=config-demo view ``` -出力には、二つのクラスター、二人のユーザー、三つのcontextが表示されます: +出力には、二つのクラスター、二人のユーザー、三つのコンテキストが表示されます: ```shell apiVersion: v1 @@ -139,23 +139,23 @@ users: 証明書ファイルのパスの代わりにbase64にエンコードされたデータを使用したい場合は、キーに`-data`の接尾辞を加えてください。例えば、`certificate-authority-data`、`client-certificate-data`、`client-key-data`とできます。 -それぞれのcontextは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`contextは、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。 +それぞれのコンテキストは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`コンテキストは、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。 -現在のcontextを設定してください: +現在のコンテキストを設定してください: ```shell kubectl config --kubeconfig=config-demo use-context dev-frontend ``` -これ以降実行される`kubectl`コマンドは、`dev-frontend`contextに設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`contextに設定されたユーザーの認証情報を使用します。 +これ以降実行される`kubectl`コマンドは、`dev-frontend`コンテキストに設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`コンテキストに設定されたユーザーの認証情報を使用します。 -現在のcontextの設定情報のみを確認するには、`--minify`フラグを使用してください。 +現在のコンテキストの設定情報のみを確認するには、`--minify`フラグを使用してください。 ```shell kubectl config --kubeconfig=config-demo view --minify ``` -出力には、`dev-frontend`contextの設定情報が表示されます: +出力には、`dev-frontend`コンテキストの設定情報が表示されます: ```shell apiVersion: v1 @@ -182,15 +182,15 @@ users: 今度は、実験用のクラスター内でしばらく作業する場合を考えます。 -現在のcontextを`exp-scratch`に切り替えてください: +現在のコンテキストを`exp-scratch`に切り替えてください: ```shell kubectl config --kubeconfig=config-demo use-context exp-scratch ``` -これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`contextに設定されたユーザーの認証情報を使用します。 +これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`コンテキストに設定されたユーザーの認証情報を使用します。 -新しく切り替えた`exp-scratch`contextの設定を確認してください。 +新しく切り替えた`exp-scratch`コンテキストの設定を確認してください。 ```shell kubectl config --kubeconfig=config-demo view --minify @@ -198,13 +198,13 @@ kubectl config --kubeconfig=config-demo view --minify 最後に、`development`クラスター内の`storage`namespaceでしばらく作業する場合を考えます。 -現在のcontextを`dev-storage`に切り替えてください: +現在のコンテキストを`dev-storage`に切り替えてください: ```shell kubectl config --kubeconfig=config-demo use-context dev-storage ``` -新しく切り替えた`dev-storage`contextの設定を確認してください。 +新しく切り替えた`dev-storage`コンテキストの設定を確認してください。 ```shell kubectl config --kubeconfig=config-demo view --minify @@ -227,7 +227,7 @@ contexts: name: dev-ramp-up ``` -上記の設定ファイルは、`dev-ramp-up`というcontextを表します。 +上記の設定ファイルは、`dev-ramp-up`というコンテキストを表します。 ## KUBECONFIG環境変数を設定する @@ -261,7 +261,7 @@ $Env:KUBECONFIG=("config-demo;config-demo-2") kubectl config view ``` -出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`contextの情報と、`config-demo`ファイルに設定された三つのcontextの情報がまとめてあることに注目してください: +出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`コンテキストの情報と、`config-demo`ファイルに設定された三つのコンテキストの情報がまとめてあることに注目してください: ```shell contexts: From 1703f94241cc68650443ef8b38305d1e981166b0 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 13:31:02 +0900 Subject: [PATCH 245/290] Update content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md Co-authored-by: inductor(Kohei) --- .../service-access-application-cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index b6e346bd83..a2d31896db 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -37,7 +37,7 @@ weight: 60 {{< codenew file="service/access/hello-application.yaml" >}} 1. クラスタでHello Worldアプリケーションを稼働させます: - 上記のファイルを使用し、アプリケーションDeploymentを作成します: + 上記のファイルを使用し、アプリケーションのDeploymentを作成します: ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` From 7160e01209c6a38d7241bd073255ad87a2177c35 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 5 Jun 2020 13:44:43 +0900 Subject: [PATCH 246/290] update uncomfortable translation --- content/ja/docs/tasks/tools/install-minikube.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 161dc26825..3e8d125d60 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -237,8 +237,7 @@ apiserver: Running kubeconfig: Configured ``` -選択したハイパーバイザーでMinikubeが動作しているか確認した後は、Minikubeを使い続けるか、クラスターを停止できます。クラスター -を停止するためには、次を実行してください。 +選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。 ```shell minikube stop From 5b0eb965076e06ae2c16ba0ed2aefe24f93c7b29 Mon Sep 17 00:00:00 2001 From: hiyokotaisa Date: Fri, 5 Jun 2020 14:31:34 +0900 Subject: [PATCH 247/290] Update content/ja/docs/concepts/storage/persistent-volumes.md Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 73fa76bedd..ef1f6b01a6 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -54,7 +54,7 @@ APIサーバーのコマンドラインフラグの詳細については[kube-ap ### バインディング -ユーザは、特定のサイズのストレージとアクセスモードを指定した上でPersistentVolumeClaimを作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なくPersistentVolumeClaimの紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは1対1で、ClaimRefを使用したPersistentVolumeとPersistentVolumeClaim間の双方向の紐付けです。 +ユーザは、特定のサイズのストレージとアクセスモードを指定した上でPersistentVolumeClaimを作成します（動的プロビジョニングの場合は、すでに作られています）。マスター内のコントロールループは、新しく作られるPVCをウォッチして、それにマッチするPVが見つかったときに、それらを紐付けます。PVが新しいPVC用に動的プロビジョニングされた場合、コントロールループは常にPVをそのPVCに紐付けます。そうでない場合、ユーザーは常に少なくとも要求したサイズ以上のボリュームを取得しますが、ボリュームは要求されたサイズを超えている可能性があります。一度紐付けされると、どのように紐付けられたかに関係なくPersistentVolumeClaimの紐付けは排他的（決められた特定のPVとしか結びつかない状態）になります。PVCからPVへの紐付けは、PersistentVolumeとPersistentVolumeClaim間の双方向の紐付けであるClaimRefを使用した1対1のマッピングになっています。 一致するボリュームが存在しない場合、クレームはいつまでも紐付けされないままになります。一致するボリュームが利用可能になると、クレームがバインドされます。たとえば、50GiのPVがいくつもプロビジョニングされているクラスターだとしても、100Giを要求するPVCとは一致しません。100GiのPVがクラスターに追加されると、PVCを紐付けできます。 From e0eed19740e7369eecffafc7210b30902e022610 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:41:14 +0900 Subject: [PATCH 248/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 2c26e33fff..b69b358871 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -139,7 +139,7 @@ users: 証明書ファイルのパスの代わりにbase64にエンコードされたデータを使用したい場合は、キーに`-data`の接尾辞を加えてください。例えば、`certificate-authority-data`、`client-certificate-data`、`client-key-data`とできます。 -それぞれのコンテキストは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`コンテキストは、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。 +それぞれのコンテキストは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、`dev-frontend`は、`developer`ユーザーの認証情報を使って`development`クラスターの`frontend`namespaceへのアクセスを意味しています。 現在のコンテキストを設定してください: @@ -334,4 +334,4 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED * [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) -{{% /capture %}} \ No newline at end of file +{{% /capture %}} From 0bfd7e55cfcb3dadfc7932a0adb98996dd2705a0 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:41:39 +0900 Subject: [PATCH 249/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index b69b358871..4439bc6cce 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -147,7 +147,7 @@ users: kubectl config --kubeconfig=config-demo use-context dev-frontend ``` -これ以降実行される`kubectl`コマンドは、`dev-frontend`コンテキストに設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`コンテキストに設定されたユーザーの認証情報を使用します。 +これ以降実行される`kubectl`コマンドは、`dev-frontend`に設定されたクラスターとnamespaceに適用されます。また、`dev-frontend`に設定されたユーザーの認証情報を使用します。 現在のコンテキストの設定情報のみを確認するには、`--minify`フラグを使用してください。 From f655d9cbfc5d281cf35678f4a6a5fd72de158c13 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:41:48 +0900 Subject: [PATCH 250/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 4439bc6cce..537746b15d 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -155,7 +155,7 @@ kubectl config --kubeconfig=config-demo use-context dev-frontend kubectl config --kubeconfig=config-demo view --minify ``` -出力には、`dev-frontend`コンテキストの設定情報が表示されます: +出力には、`dev-frontend`の設定情報が表示されます: ```shell apiVersion: v1 From ff41b4d049089529a97195d470336e3613e2d2ad Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:41:56 +0900 Subject: [PATCH 251/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 537746b15d..6becb6ba33 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -188,7 +188,7 @@ users: kubectl config --kubeconfig=config-demo use-context exp-scratch ``` -これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`コンテキストに設定されたユーザーの認証情報を使用します。 +これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`に設定されたユーザーの認証情報を使用します。 新しく切り替えた`exp-scratch`コンテキストの設定を確認してください。 From 08740da815c09d7b3deb5af32f4582a47e361b84 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:42:09 +0900 Subject: [PATCH 252/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 6becb6ba33..a44de63779 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -190,7 +190,7 @@ kubectl config --kubeconfig=config-demo use-context exp-scratch これ以降実行される`kubectl`コマンドは、`scratch`クラスター内のデフォルトnamespaceに適用されます。また、`exp-scratch`に設定されたユーザーの認証情報を使用します。 -新しく切り替えた`exp-scratch`コンテキストの設定を確認してください。 +新しく切り替えた`exp-scratch`の設定を確認してください。 ```shell kubectl config --kubeconfig=config-demo view --minify From 77838dbd2e5600745a5709d3d3402e0274a22178 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:42:15 +0900 Subject: [PATCH 253/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index a44de63779..9b24c07c1e 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -204,7 +204,7 @@ kubectl config --kubeconfig=config-demo view --minify kubectl config --kubeconfig=config-demo use-context dev-storage ``` -新しく切り替えた`dev-storage`コンテキストの設定を確認してください。 +新しく切り替えた`dev-storage`の設定を確認してください。 ```shell kubectl config --kubeconfig=config-demo view --minify From cbd20f482c8c832ce1eb04c4970a02965968a6c8 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 5 Jun 2020 14:42:39 +0900 Subject: [PATCH 254/290] Update content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md Co-authored-by: inductor(Kohei) --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 9b24c07c1e..eb040b3eb9 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -261,7 +261,7 @@ $Env:KUBECONFIG=("config-demo;config-demo-2") kubectl config view ``` -出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`コンテキストの情報と、`config-demo`ファイルに設定された三つのコンテキストの情報がまとめてあることに注目してください: +出力には、`KUBECONFIG`環境変数に含まれる全てのファイルの情報がまとめて表示されます。`config-demo-2`ファイルに設定された`dev-ramp-up`の情報と、`config-demo`に設定された三つのコンテキストの情報がまとめてあることに注目してください: ```shell contexts: From e8fd2ebad471bc8fd31376e099de4860eb3d86da Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Fri, 5 Jun 2020 17:07:51 +0900 Subject: [PATCH 255/290] fix wording --- .../ja/docs/concepts/overview/working-with-objects/labels.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 255d039041..b1160d440c 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -59,7 +59,7 @@ _ラベル(Labels)_ はPodなどのオブジェクトに割り当てられたキ 正しいラベル値は63文字以下の長さで、空文字か、もしくは開始と終了が英数字(`[a-z0-9A-Z]`)で、文字列の間がダッシュ(`-`)、アンダースコア(`_`)、ドット(`.`)と英数字である文字列を使うことができます。 -例えば、`environment: production`と`app: nginx`の2つのラベルを持つPodのconfigファイルは下記のようになります。 +例えば、`environment: production`と`app: nginx`の2つのラベルを持つPodの設定ファイルは下記のようになります。 ```yaml @@ -98,7 +98,7 @@ ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタ {{< /note >}} {{< caution >}} -等価ベース、集合ベースともに、論理OR (`||`) オペレーターは存在しません。フィルターステートメントが構造化されていることを適宜確認してください。 +等価ベース、集合ベースともに、論理OR (`||`) オペレーターは存在しません。フィルターステートメントが意図した通りになっていることを確認してください。 {{< /caution >}} ### *等価ベース(Equality-based)* の要件(requirement) From bee08c56f2cac9b785f5a2b8c1522ef8d74eb17c Mon Sep 17 00:00:00 2001 From: Ryoko Tominaga Date: Fri, 5 Jun 2020 17:09:36 +0900 Subject: [PATCH 256/290] fix URLs --- .../ja/docs/concepts/overview/working-with-objects/labels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index b1160d440c..3a5cf6f7eb 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -198,7 +198,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' ``` ### APIオブジェクトに参照を設定する -[`Service`](/ja/docs/user-guide/services) と [`ReplicationController`](/docs/user-guide/replication-controller)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/docs/user-guide/pods)のような他のリソースのセットを指定するのにも使われます。 +[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/pod/)のような他のリソースのセットを指定するのにも使われます。 #### ServiceとReplicationController `Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。 From d1352337a5aa591d243421164a580990a389462b Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 17:55:33 +0900 Subject: [PATCH 257/290] Update field-selectors.md for v1.17 --- .../concepts/overview/working-with-objects/field-selectors.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index 3247f1b8da..ddf947212d 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -43,7 +43,7 @@ Error from server (BadRequest): Unable to find "ingresses" that match label sele 例として、下記の`kubectl`コマンドは`default`ネームスペースに属していない全てのKubernetes Serviceを選択します。 ```shell -kubectl get services --field-selector metadata.namespace!=default +kubectl get services --all-namespaces --field-selector metadata.namespace!=default ``` ## 連結されたセレクター @@ -51,7 +51,7 @@ kubectl get services --field-selector metadata.namespace!=default 下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。 ```shell -kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default ``` ## 複数のリソースタイプ From d4028abb9c2c953a045cfff0557d0e803cd3c8fb Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 5 Jun 2020 18:41:31 +0900 Subject: [PATCH 258/290] add hello-application.yaml file under ja directory --- .../service/access/hello-application.yaml | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 content/ja/examples/service/access/hello-application.yaml diff --git a/content/ja/examples/service/access/hello-application.yaml b/content/ja/examples/service/access/hello-application.yaml new file mode 100644 index 0000000000..1cf41313c5 --- /dev/null +++ b/content/ja/examples/service/access/hello-application.yaml @@ -0,0 +1,20 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: hello-world +spec: + selector: + matchLabels: + run: load-balancer-example + replicas: 2 + template: + metadata: + labels: + run: load-balancer-example + spec: + containers: + - name: hello-world + image: gcr.io/google-samples/node-hello:1.0 + ports: + - containerPort: 8080 + protocol: TCP From b9b688828361e57219b8d66ff6801bb0abda10ee Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 19:03:53 +0900 Subject: [PATCH 259/290] Update dns-pod-service.md for v1.17 --- .../services-networking/dns-pod-service.md | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md index 2700b92ea8..1a5cf81e45 100644 --- a/content/ja/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -27,11 +27,11 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer ## Service {#services} -### Aレコード +### A/AAAAレコード -"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。 +"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。 -"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS Aレコードを割り当てられます。通常のServiceとは異なり、このAレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います… +"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを割り当てられます。通常のServiceとは異なり、このレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います。 ### SRVレコード @@ -42,12 +42,6 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返 ## Pod -### Aレコード - -DNSが有効なとき、Podは"`pod-ip-address.my-namespace.pod.cluster.local`"という形式のAレコードを割り当てられます。 - -例えば、`default`ネームスペース内で`cluster.local`というDNS名を持ち、`1.2.3.4`というIPを持ったPodは次の形式のエントリーを持ちます。: `1-2-3-4.default.pod.cluster.local`。 - ### Podのhostnameとsubdomainフィールド 現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。 @@ -105,13 +99,13 @@ spec: name: busybox ``` -もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのKubeDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するAレコードを返します。 -例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すAレコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したAレコードを持ちます。 +もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するA(AAAA)レコードを返します。 +例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはサービスのIPバージョンに応じてそのPodのIPを指し示すA(AAAA)レコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したA(AAAA)レコードを持ちます。 そのエンドポイントオブジェクトはそのIPに加えて`hostname`を任意のエンドポイントアドレスに対して指定できます。 {{< note >}} -AレコードはPodの名前に対して作成されないため、`hostname`はPodのAレコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するAレコードのみ作成します。 +A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。 {{< /note >}} ### PodのDNSポリシー From 698f77cfbce1a511528cfef966298f0ec333623f Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 19:38:35 +0900 Subject: [PATCH 260/290] Update _index.md for v1.17 --- content/ja/docs/setup/_index.md | 63 ++------------------------------- 1 file changed, 2 insertions(+), 61 deletions(-) diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 0508e24afa..aa28e4d2d3 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -37,77 +37,18 @@ Kubernetesについて学んでいる場合、Dockerベースのソリューシ |コミュニティ |エコシステム | | ------------ | -------- | | [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| | | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | | | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| | | [k3s](https://k3s.io)| -| | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)| ## 本番環境 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip text="アプリケーション" term_id="applications" >}}、 {{< glossary_tooltip text="データプレーン" term_id="data-plane" >}}、 {{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}、 {{< glossary_tooltip text="クラスターインフラ" term_id="cluster-infrastructure" >}}、 {{< glossary_tooltip text="そして、クラスター運用" term_id="cluster-operations" >}}があります。 - -次の図は、Kubernetesクラスターの抽象レイヤ一覧と、それぞれの抽象レイヤを自分で管理するのか、プロバイダによって管理されているのかを示しています。 - -本番環境のソリューション![Production environment solutions](/images/docs/KubernetesSolutions.svg) - -{{< table caption="Production environment solutions table lists the providers and the solutions." >}} -次の表は、各プロバイダーとそれらが提供するソリューションを一覧にしたものです。 - -|プロバイダー | マネージド | 即時利用可能 | オンプレDC | カスタム(クラウド) | カスタム(オンプレVM)| カスタム(ベアメタル) | -| --------- | ------ | ------ | ------ | ------ | ------ | ----- | -| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | ✔ | ✔ | | | -| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | | -| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | | -| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | | -| [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | -| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ | -| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | -| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | -| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | -| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| -| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ -| [Containership](https://containership.io) | ✔ |✔ | | | | -| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | -| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ -| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | -| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ -| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ -| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ -| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | -| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | -| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | -| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | -| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | -| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | -| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | -| [KubeSail](https://kubesail.com/) | ✔ | | | | | -| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | -| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | -| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | | -| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | -| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | -| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | -| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | | -| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/) -| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | | -| [oVirt](https://www.ovirt.org/) | | | | | ✔ | -| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | | -| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔ -| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/) -| [StackPoint](https://stackpoint.io/)  | ✔ | ✔ | | | | -| [Supergiant](https://supergiant.io/) | |✔ | | | | -| [SUSE](https://www.suse.com/) | | ✔ | | | | -| [SysEleven](https://www.syseleven.io/) | ✔ | | | | | -| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | -| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | -| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) -| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、"[Partners](https://kubernetes.io/partners/#conformance)"を参照してください。 {{% /capture %}} From 443ba046faa3e358b1a5f619b992de3b6fd96450 Mon Sep 17 00:00:00 2001 From: Kento Yagisawa Date: Fri, 5 Jun 2020 23:08:41 +0900 Subject: [PATCH 261/290] modify the incorrect update --- .../ja/docs/concepts/services-networking/dns-pod-service.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md index 1a5cf81e45..07d06a8edc 100644 --- a/content/ja/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -29,9 +29,9 @@ Kubernetesの`bar`というネームスペース内で`foo`という名前のSer ### A/AAAAレコード -"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。 +"通常の"(Headlessでない)Serviceは、`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを、ServiceのIPバージョンに応じて割り当てられます。このAレコードはそのServiceのClusterIPへと名前解決されます。 -"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを割り当てられます。通常のServiceとは異なり、このレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います。 +"Headless"(ClusterIPなしの)Serviceもまた`my-svc.my-namespace.svc.cluster.local`という形式のDNS A(AAAA)レコードを、ServiceのIPバージョンに応じて割り当てられます。通常のServiceとは異なり、このレコードはServiceによって選択されたPodのIPの一覧へと名前解決されます。クライアントはこの一覧のIPを使うか、その一覧から標準のラウンドロビン方式によって選択されたIPを使います。 ### SRVレコード @@ -100,7 +100,7 @@ spec: ``` もしそのPodと同じネームスペース内で、同じサブドメインを持ったHeadless Serviceが存在していた場合、クラスターのDNSサーバーもまた、そのPodの完全修飾ドメイン名(FQDN)に対するA(AAAA)レコードを返します。 -例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはサービスのIPバージョンに応じてそのPodのIPを指し示すA(AAAA)レコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したA(AAAA)レコードを持ちます。 +例えば、"`busybox-1`"というホスト名で、"`default-subdomain`"というサブドメインを持ったPodと、そのPodと同じネームスペース内にある"`default-subdomain`"という名前のHeadless Serviceがあると考えると、そのPodは自身の完全修飾ドメイン名(FQDN)を"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`"として扱います。DNSはそのPodのIPを指し示すA(AAAA)レコードを返します。"`busybox1`"と"`busybox2`"の両方のPodはそれぞれ独立したA(AAAA)レコードを持ちます。 そのエンドポイントオブジェクトはそのIPに加えて`hostname`を任意のエンドポイントアドレスに対して指定できます。 From 2ba23bdb9ed04d3fe96eec4645cc5d11a177c9df Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Fri, 5 Jun 2020 23:12:21 +0900 Subject: [PATCH 262/290] Update statefulset.md for v1.17 --- .../concepts/workloads/controllers/statefulset.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index dba8b807f7..f079d1821b 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -9,10 +9,6 @@ weight: 40 StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。 -{{< note >}} -StatefulSetはKubernetes1.9において利用可能(GA)です。 -{{< /note >}} - {{< glossary_definition term_id="statefulset" length="all" >}} {{% /capture %}} @@ -28,12 +24,11 @@ StatefulSetは下記の1つ以上の項目を要求するアプリケーショ * 規則的で自動化されたローリングアップデート 上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。 -もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するコントローラーを使ってアプリケーションをデプロイするべきです。 +もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するワークロードを使ってアプリケーションをデプロイするべきです。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)や[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)のようなコントローラーはこのようなステートレスな要求に対して最適です。 ## 制限事項 -* StatefuleSetはKubernetes1.9より以前のバージョンではβ版のリソースであり、1.5より前のバージョンでは利用できません。 * 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。 * StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。 * StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を要求します。ユーザーはこのServiceを作成する責任があります。 @@ -100,6 +95,7 @@ spec: * nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。 * webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。 * volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。 +* StatefulSetの名前は有効な[名前](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 ## Podセレクター ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。 @@ -142,7 +138,7 @@ Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/doc ### Podのネームラベル -StatefulSetのコントローラーがPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。 +StatefulSet {{< glossary_tooltip term_id="controller" >}} がPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。 ## デプロイとスケーリングの保証 @@ -199,6 +195,7 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。 +* [レプリカを持つステートフルアプリケーションを実行する](/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。 {{% /capture %}} From 39339c96bedc79197f6aa10ee38e54dcee16be7a Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Fri, 5 Jun 2020 23:35:12 +0900 Subject: [PATCH 263/290] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index f079d1821b..311dd663dc 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -138,7 +138,7 @@ Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/doc ### Podのネームラベル -StatefulSet {{< glossary_tooltip term_id="controller" >}} がPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。 +StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controller" >}} がPodを作成したとき、Podの名前として、`statefulset.kubernetes.io/pod-name`にラベルを追加します。このラベルによってユーザーはServiceにStatefulSet内の指定したPodを割り当てることができます。 ## デプロイとスケーリングの保証 @@ -198,4 +198,3 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe * [レプリカを持つステートフルアプリケーションを実行する](/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。 {{% /capture %}} - From eabda5beb94986bc1b177a994f1ac82045f5895b Mon Sep 17 00:00:00 2001 From: akitok Date: Sat, 6 Jun 2020 03:20:34 +0900 Subject: [PATCH 264/290] Update /docs/tasks/configure-pod-container/quality-service-pod/ follow v1.17 of the original text --- .../docs/tasks/configure-pod-container/quality-service-pod.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md index 346ce57a92..f21ac9d680 100644 --- a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md @@ -231,7 +231,7 @@ kubectl delete namespace qos-example * [コンテナおよびPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/) -* [コンテナとPodにCPUリソースを割り当てる](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [コンテナとPodにCPUリソースを割り当てる](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/) ### クラスター管理者向け @@ -248,6 +248,8 @@ kubectl delete namespace qos-example * [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) + +* [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) {{% /capture %}} From b6174a6563e61eb991a9ed26fcca608826812684 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Sat, 6 Jun 2020 21:29:17 +0900 Subject: [PATCH 265/290] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 311dd663dc..cc0646cf4d 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -95,7 +95,8 @@ spec: * nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。 * webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。 * volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。 -* StatefulSetの名前は有効な[名前](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 ## Podセレクター ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。 From b197b6cdf8775e2fcf0bd356e00553b5a48476cf Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Sat, 6 Jun 2020 21:29:24 +0900 Subject: [PATCH 266/290] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index cc0646cf4d..d8d2c3d687 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -196,6 +196,6 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。 -* [レプリカを持つステートフルアプリケーションを実行する](/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。 +* [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。 {{% /capture %}} From 8cf54798b501d6e591bb9a4a863fdfc23bec4330 Mon Sep 17 00:00:00 2001 From: nishipy Date: Sat, 6 Jun 2020 22:35:37 +0900 Subject: [PATCH 267/290] Update docs/concepts/services-networking/service.md --- .../concepts/services-networking/service.md | 29 +++++-------------- 1 file changed, 8 insertions(+), 21 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 3328dd5536..b9d1ce772a 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -49,7 +49,7 @@ Serviceによる抽象化は、クライアントからバックエンドのPod ## Serviceの定義 -KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。 +KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。Serviceオブジェクトの名前は、有効なDNSラベル名である必要があります。 例えば、TCPで9376番ポートで待ち受けていて、`app=Myapp`というラベルをもつPodのセットがあるとします。 @@ -123,6 +123,8 @@ subsets: - port: 9376 ``` +Endpointsオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + {{< note >}} Endpointsのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設定することができません。 @@ -345,7 +347,7 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類 * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。 {{< note >}} - `ExternalName`タイプのServiceを利用するためには、CoreDNSのバージョン1.7以上が必要となります。 + `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.08以上が必要となります。 {{< /note >}} また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。 @@ -397,7 +399,9 @@ status: - ip: 192.0.2.127 ``` -外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。 +外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。 + +LoadBalancerタイプのサービスで複数のポートが定義されている場合、すべてのポートが同じプロトコルである必要があり、さらにそのプロトコルは`TCP`、`UDP`、`SCTP`のいずれかである必要があります。 いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。 もし`loadBalancerIP`フィールドの値が指定されていない場合、そのロードバランサーはエフェメラルなIPアドレスに対して作成されます。もしユーザーが`loadBalancerIP`を指定したが、使っているクラウドプロバイダーがその機能をサポートしていない場合、その`loadBalancerIP`フィールドに設定された値は無視されます。 @@ -860,20 +864,14 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで ### TCP -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - ユーザーはどの種類のServiceにおいてもTCPを利用できます。これはデフォルトのネットワークプロトコルです。 ### UDP -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - ユーザーは多くのServiceにおいてUDPを利用できます。 type=LoadBalancerのServiceにおいては、UDPのサポートはこの機能を提供しているクラウドプロバイダーに依存しています。 ### HTTP -{{< feature-state for_k8s_version="v1.1" state="stable" >}} - もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。 {{< note >}} @@ -882,8 +880,6 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで ### PROXY プロトコル -{{< feature-state for_k8s_version="v1.1" state="stable" >}} - もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。 ロードバランサーは、最初の一連のオクテットを送信します。 @@ -932,21 +928,12 @@ SCTPはWindowsベースのNodeではサポートされていません。 kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。 {{< /warning >}} -## Future work - -将来的に、Serviceのプロキシーポリシーはシンプルなラウンドロビンのバランシングだけでなく、もっと細かな設定が可能になります。例えば、Masterによって選択されるものや、水平シャーディングされたりするようになります。 -我々もまた、いくつかのServiceが"実際の"ロードバランサーを備えることを想定します。その場合、仮想IPは単純にパケットをそのロードバランサーに転送します。 - -Kubernetesプロジェクトは、L7 (HTTP) Serviceへのサポートをもっと発展させようとしています。 - -Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLoadBalancerタイプのServiceに対して、より柔軟なIngressのモードを追加する予定です。 - {{% /capture %}} {{% capture whatsnext %}} * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 -* [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 +* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 {{% /capture %}} From 582884b548bef68b39b811a93623cb872d44d870 Mon Sep 17 00:00:00 2001 From: nishipy Date: Sat, 6 Jun 2020 22:42:25 +0900 Subject: [PATCH 268/290] Fix typo --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index b9d1ce772a..853f0e6d45 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -347,7 +347,7 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類 * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。 {{< note >}} - `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.08以上が必要となります。 + `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。 {{< /note >}} また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。 From 9e57f66d83990e04c31de20ba906e0275eed4e19 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Sun, 7 Jun 2020 17:22:33 +0900 Subject: [PATCH 269/290] Update content/ja/docs/concepts/services-networking/service.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 853f0e6d45..50cda0b3dc 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -49,7 +49,7 @@ Serviceによる抽象化は、クライアントからバックエンドのPod ## Serviceの定義 -KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。Serviceオブジェクトの名前は、有効なDNSラベル名である必要があります。 +KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。Serviceオブジェクトの名前は、有効な[DNSラベル名](/ja/docs/concepts/overview/working-with-objects/names#dns-label-names)である必要があります。 例えば、TCPで9376番ポートで待ち受けていて、`app=Myapp`というラベルをもつPodのセットがあるとします。 From 6d55257b2ac0429f7b424d521c77c58e7d192318 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Sun, 7 Jun 2020 17:22:41 +0900 Subject: [PATCH 270/290] Update content/ja/docs/concepts/services-networking/service.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 50cda0b3dc..9927f479aa 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -123,7 +123,7 @@ subsets: - port: 9376 ``` -Endpointsオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +Endpointsオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 {{< note >}} Endpointsのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や From 6e2386decb2230d8d95575096fc0ae9e6976a84f Mon Sep 17 00:00:00 2001 From: kondo takeshi Date: Sun, 7 Jun 2020 23:42:34 +0900 Subject: [PATCH 271/290] Follow "Update references to the patch release process" in Japanese --- content/ja/docs/setup/release/version-skew-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md index 4573e740a6..99ee0447b1 100644 --- a/content/ja/docs/setup/release/version-skew-policy.md +++ b/content/ja/docs/setup/release/version-skew-policy.md @@ -16,9 +16,9 @@ Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメ Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。 -セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing)がこれを決定しています。パッチリリースマネージャーは[各リリースのリリースチーム](https://github.com/kubernetes/sig-release/tree/master/releases/)のメンバーです。 +セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、[定期的](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)または必要に応じてこれらのブランチから分岐されます。[リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。 -マイナーリリースは約3ヶ月ごとに行われるため、それぞれのリリースブランチは約9ヶ月間メンテナンスされます。 +詳細は、Kubernetes[パッチリリース](https://git.k8s.io/sig-release/releases/patch-releases.md)ページを参照してください。 ## サポートされるバージョンの差異 From 2baa76a1d03cb7124406b766db1362469cfed02b Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Tue, 9 Jun 2020 00:46:20 +0900 Subject: [PATCH 272/290] follow ja:glossary/controller.md v1.17 --- content/ja/docs/reference/glossary/controller.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index 6e49e3a6b6..7e8d7e4e77 100755 --- a/content/ja/docs/reference/glossary/controller.md +++ b/content/ja/docs/reference/glossary/controller.md @@ -2,7 +2,7 @@ title: Controller id: controller date: 2018-04-12 -full_link: /docs/admin/kube-controller-manager/ +full_link: /docs/concepts/architecture/controller/ short_description: > クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。 @@ -11,8 +11,11 @@ tags: - architecture - fundamental --- - クラスターの状態を{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得して監視する制御ループで、現在の状態を望ましい状態に移行するように更新します。 +Kubernetesでは、コントローラーは{{< glossary_tooltip term_id="cluster" text="cluster" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。 -現在Kubernetesに同梱されているコントローラーの例には、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、およびサービスアカウントコントローラーがあります。 +コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" >}}の一部である{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得します。 + +いくつかのコントロールプレーン内部で動くコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。 +例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" >}}の内部で動作します。 From b794063d1811c59e0d3935a99fe313ad1523469d Mon Sep 17 00:00:00 2001 From: translucens Date: Tue, 9 Jun 2020 01:36:21 +0900 Subject: [PATCH 273/290] Update content/ja/docs/reference/glossary/controller.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index 7e8d7e4e77..10989bb584 100755 --- a/content/ja/docs/reference/glossary/controller.md +++ b/content/ja/docs/reference/glossary/controller.md @@ -11,7 +11,7 @@ tags: - architecture - fundamental --- -Kubernetesでは、コントローラーは{{< glossary_tooltip term_id="cluster" text="cluster" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。 +Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="cluster" text="cluster" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。 From e53627ddeca59efc24f428b25f736878ff154796 Mon Sep 17 00:00:00 2001 From: translucens Date: Tue, 9 Jun 2020 01:38:48 +0900 Subject: [PATCH 274/290] Update content/ja/docs/reference/glossary/controller.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index 10989bb584..7dfddb4e6d 100755 --- a/content/ja/docs/reference/glossary/controller.md +++ b/content/ja/docs/reference/glossary/controller.md @@ -15,7 +15,7 @@ Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="c -コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" >}}の一部である{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得します。 +コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" text="コントロールプレーン" >}}の一部である{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}から取得します。 いくつかのコントロールプレーン内部で動くコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。 例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" >}}の内部で動作します。 From ebb5d8ed2aeee3357cd547d42b6afe2ac1a98d13 Mon Sep 17 00:00:00 2001 From: translucens Date: Tue, 9 Jun 2020 02:14:24 +0900 Subject: [PATCH 275/290] Update content/ja/docs/reference/glossary/controller.md --- content/ja/docs/reference/glossary/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index 7dfddb4e6d..102f8855d4 100755 --- a/content/ja/docs/reference/glossary/controller.md +++ b/content/ja/docs/reference/glossary/controller.md @@ -18,4 +18,4 @@ Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="c コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" text="コントロールプレーン" >}}の一部である{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}から取得します。 いくつかのコントロールプレーン内部で動くコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。 -例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" >}}の内部で動作します。 +例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}の内部で動作します。 From 37cb596724d18ad0c84794ef10a4df6b3aee6cd0 Mon Sep 17 00:00:00 2001 From: translucens Date: Tue, 9 Jun 2020 02:57:50 +0900 Subject: [PATCH 276/290] Update content/ja/docs/reference/glossary/controller.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index 102f8855d4..10c8446bd9 100755 --- a/content/ja/docs/reference/glossary/controller.md +++ b/content/ja/docs/reference/glossary/controller.md @@ -17,5 +17,5 @@ Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="c コントローラーはクラスターの状態を{{< glossary_tooltip term_id="control-plane" text="コントロールプレーン" >}}の一部である{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}から取得します。 -いくつかのコントロールプレーン内部で動くコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。 +コントロールプレーン内部で動くいくつかのコントローラーは、Kubernetesの主要な操作に対する制御ループを提供します。 例えば、Deploymentコントローラー、Daemonsetコントローラー、Namespaceコントローラー、Persistent Volumeコントローラー等は{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}の内部で動作します。 From 6a565fd60c6d6a0a7978b80acb25bae892859a86 Mon Sep 17 00:00:00 2001 From: translucens Date: Tue, 9 Jun 2020 10:03:39 +0900 Subject: [PATCH 277/290] Update content/ja/docs/reference/glossary/controller.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index 10c8446bd9..d5ce544edd 100755 --- a/content/ja/docs/reference/glossary/controller.md +++ b/content/ja/docs/reference/glossary/controller.md @@ -11,7 +11,7 @@ tags: - architecture - fundamental --- -Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="cluster" text="cluster" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。 +Kubernetesにおいて、コントローラーは{{< glossary_tooltip term_id="cluster" text="クラスター" >}}の状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。それぞれのコントローラーは現在のクラスターの状態を望ましい状態に近づけるように動作します。 From 911317f7edb3cd7ff32aede4a1da264e10aec78b Mon Sep 17 00:00:00 2001 From: nishipy Date: Wed, 10 Jun 2020 02:13:54 +0900 Subject: [PATCH 278/290] Update ja/docs/concepts/services-networking/ingress.md --- .../concepts/services-networking/ingress.md | 28 +++++++++---------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index 6a8c17587f..2742e7aa9b 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -15,19 +15,15 @@ weight: 40 まずわかりやすくするために、このガイドでは次の用語を定義します。 -- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。 - -- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。 - -- エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。 - -- クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。 - -- Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。 +* ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。 +* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。 +* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。 +* クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。 +* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。 ## Ingressとは何か -Ingressはクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。 +[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。 ```none internet @@ -74,8 +70,9 @@ spec: servicePort: 80 ``` -他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。 -Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。 +他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。 +Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。 [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。 Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。 @@ -112,10 +109,10 @@ kubectl get ingress test-ingress ``` NAME HOSTS ADDRESS PORTS AGE -test-ingress * 107.178.254.228 80 59s +test-ingress * 203.0.113.123 80 59s ``` -`107.178.254.228`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。 +`203.0.113.123`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。 {{< note >}} IngressコントローラーとロードバランサーがIPアドレス割り当てるのに1、2分ほどかかります。この間、ADDRESSの情報は``となっているのを確認できます。 @@ -288,7 +285,7 @@ spec: ``` {{< note >}} -Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://git.k8s.io/ingress-nginx/README.md#https)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。 +Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。 {{< /note >}} ### 負荷分散 @@ -398,6 +395,7 @@ Ingressリソースに直接関与しない複数の方法でServiceを公開で {{% /capture %}} {{% capture whatsnext %}} +* [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ * [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ * [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube) {{% /capture %}} From f7faa9cb15ed36f6b0e21bfd45465d559000962c Mon Sep 17 00:00:00 2001 From: inductor Date: Wed, 10 Jun 2020 08:43:05 +0900 Subject: [PATCH 279/290] Remove unused shortcodes #21612 --- content/ja/_index.html | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/ja/_index.html b/content/ja/_index.html index e458e11754..7d01d366b7 100644 --- a/content/ja/_index.html +++ b/content/ja/_index.html @@ -3,9 +3,6 @@ title: "プロダクショングレードのコンテナ管理基盤" abstract: "自動化されたコンテナのデプロイ・スケール・管理" cid: home --- -{{< announcement >}} - -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} From 93b2f3a8d5fd1b8eaa8703fc7852d73059e53b07 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Wed, 10 Jun 2020 11:19:21 +0900 Subject: [PATCH 280/290] Update content/ja/docs/concepts/services-networking/ingress.md Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/services-networking/ingress.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index 2742e7aa9b..c37863ce51 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -71,7 +71,7 @@ spec: ``` 他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 -設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。 +設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。 Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。 [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。 From 30e7f91372397e010fc97f9c01da6075270b8e84 Mon Sep 17 00:00:00 2001 From: kondo takeshi Date: Thu, 11 Jun 2020 00:55:59 +0900 Subject: [PATCH 281/290] Follow tutorials/kubernetes-basics/create-cluster/cluster-intro in Japanese --- .../kubernetes-basics/create-cluster/cluster-intro.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index fdf1a66c7f..d0a62a1911 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -9,7 +9,7 @@ weight: 10 - +
    @@ -77,14 +77,14 @@ weight: 10
    -

    マスターはクラスターを管理するために、ノードは実行中のアプリケーションをホストするために使用されます。

    +

    マスターは実行中のアプリケーションをホストするために使用されるノードとクラスターを管理します。

    -

    Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスターのノードで実行されるようにスケジュールします。ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信します。エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。

    +

    Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスターのノードで実行されるようにスケジュールします。ノードは、マスターが公開しているKubernetes APIを使用してマスターと通信します。エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。

    Kubernetesクラスターは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるためにMinikubeを使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのノードのみを含む単純なクラスターをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスターを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。

    From 32591fddab06f6d42f40a60e362b6afe85e39bd1 Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 11 Jun 2020 08:45:46 +0900 Subject: [PATCH 282/290] transalte partners --- content/ja/partners/_index.html | 91 +++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 content/ja/partners/_index.html diff --git a/content/ja/partners/_index.html b/content/ja/partners/_index.html new file mode 100644 index 0000000000..e22220e340 --- /dev/null +++ b/content/ja/partners/_index.html @@ -0,0 +1,91 @@ +--- +title: パートナー +bigheader: Kubernetesパートナー +abstract: Kubernetesエコシステムの成長を支えるパートナー +class: gridPage +cid: partners +--- + +
    +
    +
    Kubernetesはパートナーと協力して、さまざまなプラットフォームをサポートする強力で活気のあるコードベースを作り上げています。
    +
    +
    +
    +
    + Kubernetes認定サービスプロバイダー(Kubernetes Certified Service Providers, KCSP) +
    +
    企業のKubernetes導入を支援してきた豊富な経験を持つ、熟練のサービスプロバイダーです。 +


    + +

    Interested in becoming a KCSP? +
    +
    +
    +
    +
    + 認定Kubernetesディストリビューション、マネージド環境、およびインストーラー +
    ソフトウェアの適合性により、すべてのベンダーのバージョンのKubernetesが必要なAPIを確実にサポートします。 +


    + +

    Interested in becoming Kubernetes Certified? +
    +
    +
    +
    +
    Kubernetesトレーニングパートナー(Kubernetes Training Partners, KTP)
    +
    クラウドネイティブな技術のトレーニングに長けた、熟練のトレーニングプロバイダーです。 +



    + +

    Interested in becoming a KTP? +
    +
    +
    + + + +
    + + +
    + +
    +
    + + + + From 350059fc9d5c8ac657810459ec53ea13764b7dc9 Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 11 Jun 2020 08:48:01 +0900 Subject: [PATCH 283/290] Translate partners --- content/ja/partners/_index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/partners/_index.html b/content/ja/partners/_index.html index e22220e340..c94bbc333d 100644 --- a/content/ja/partners/_index.html +++ b/content/ja/partners/_index.html @@ -18,7 +18,7 @@ cid: partners
    企業のKubernetes導入を支援してきた豊富な経験を持つ、熟練のサービスプロバイダーです。


    -

    Interested in becoming a KCSP? +

    KCSPに興味がありますか？
    @@ -28,7 +28,7 @@ cid: partners ソフトウェアの適合性により、すべてのベンダーのバージョンのKubernetesが必要なAPIを確実にサポートします。


    -

    Interested in becoming Kubernetes Certified? +

    Kubernetes Certifiedに興味がありますか？?
    @@ -37,7 +37,7 @@ cid: partners
    クラウドネイティブな技術のトレーニングに長けた、熟練のトレーニングプロバイダーです。



    -

    Interested in becoming a KTP? +

    KTPに興味がありますか？?
    From 665b7437f09fb10739dc2982a809273496492f4b Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 11 Jun 2020 09:08:20 +0900 Subject: [PATCH 284/290] Traslate /training/ into Japanese --- content/ja/training/_index.html | 54 ++++++++++++++++----------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index c966543062..f5d6f74cb1 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -1,7 +1,7 @@ --- -title: Training -bigheader: Kubernetes Training and Certification -abstract: Training programs, certifications, and partners. +title: トレーニング +bigheader: Kubernetesのトレーニングと資格 +abstract: トレーニングプログラム、資格、及びパートナーについて layout: basic cid: training class: training @@ -17,8 +17,8 @@ class: training
    -

    Build your cloud native career

    -

    Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.

    +

    あなたのクラウドネイティブなキャリアを創る/h2> +

    Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋がります。

    @@ -27,37 +27,37 @@ class: training
    -

    Take a free course on edX

    +

    edXで無料コースを受講する

    - Introduction to Kubernetes
          + Kubernetes入門
     
    -

    Want to learn Kubernetes? Get an in-depth primer on this powerful system for managing containerized applications.

    +

    Kubernetesを学びたいですか？コンテナ化されたアプリケーションを管理するための強力なシステムに入門しましょう。


    - Go to Course + コースに行く
    - Introduction to Cloud Infrastructure Technologies + クラウドインフラ技術入門
    -

    Learn the fundamentals of building and managing cloud technologies directly from The Linux Foundation, the leader in open source.

    +

    オープンソースのリーダーであるThe Linux Foundationから直接、クラウドテクノロジーの構築と管理の基本を学びます。


    - Go to Course + コースに行く
    - Introduction to Linux + Linux入門
    -

    Never learned Linux? Want a refresh? Develop a good working knowledge of Linux using both the graphical interface and command line across the major Linux distribution families.

    +

    Linuxを学ぶのは初めてですか？知識を更新したいですか？主要なLinuxディストリビューションでGUIとCLIの両方を使用し、Linuxの実用的な知識を深めます。


    - Go to Course + コースに行く
    @@ -66,10 +66,10 @@ class: training
    -

    Learn with the Linux Foundation

    -

    The Linux Foundation offers instructor-led and self-paced courses for all aspects of the Kubernetes application development and operations lifecycle.

    +

    Linux Foundationと共に学ぶ

    +

    Linux Foundationは、Kubernetesアプリケーションの開発と運用のライフサイクルのあらゆる側面について、インストラクター主導の自己学習コースを提供しています。



    - See Courses + コースを見る
    @@ -77,27 +77,27 @@ class: training
    -

    Get Kubernetes Certified

    +

    Kubernetes認定資格を受験する

    - Certified Kubernetes Application Developer (CKAD) + 認定Kubernetesアプリケーションデベロッパー(Certified Kubernetes Application Developer, CKAD)
    -

    The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.

    +

    認定Kubernetesアプリケーションデベロッパー(CKAD)試験は、ユーザーがKubernetes向けにクラウドネイティブアプリケーションを設計、構築、構成、公開できることを証明します。


    - Go to Certification + 試験を受ける
    - Certified Kubernetes Administrator (CKA) + 認定Kubernetesアドミニストレーター(Certified Kubernetes Administrator, CKA)
    -

    The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.

    +

    認定Kubernetesアドミニストレーター(CKA)プログラムは、保有者がKubernetes管理者の責任を実行するためのスキル、知識、および能力を持っていることを保証します。


    - Go to Certification + 試験を受ける
    @@ -107,8 +107,8 @@ class: training
    -

    Kubernetes Training Partners

    -

    Our network of Kubernetes Training Partners provide training services for Kubernetes and cloud native projects.

    +

    Kubernetesトレーニングパートナー

    +

    Kubernetesトレーニングパートナーネットワークは、Kubernetesおよびクラウドネイティブプロジェクトのトレーニングサービスを提供します。

    From d24ebd300d95d39e3065f40696d08043307a631d Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 11 Jun 2020 10:34:28 +0900 Subject: [PATCH 285/290] remove unnecessary question marks --- content/ja/partners/_index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/partners/_index.html b/content/ja/partners/_index.html index c94bbc333d..c2d3f52f7e 100644 --- a/content/ja/partners/_index.html +++ b/content/ja/partners/_index.html @@ -28,7 +28,7 @@ cid: partners ソフトウェアの適合性により、すべてのベンダーのバージョンのKubernetesが必要なAPIを確実にサポートします。


    -

    Kubernetes Certifiedに興味がありますか？? +

    Kubernetes Certifiedに興味がありますか？
    @@ -37,7 +37,7 @@ cid: partners
    クラウドネイティブな技術のトレーニングに長けた、熟練のトレーニングプロバイダーです。



    -

    KTPに興味がありますか？? +

    KTPに興味がありますか？
    From 83d5fd63547cef9e51198cf1638f25701f876c0f Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 11 Jun 2020 13:07:32 +0900 Subject: [PATCH 286/290] Update content/ja/training/_index.html Co-authored-by: nasa9084 --- content/ja/training/_index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index f5d6f74cb1..38128f4d4a 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -18,7 +18,7 @@ class: training

    あなたのクラウドネイティブなキャリアを創る/h2> -

    Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋がります。

    +

    Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。

    @@ -115,4 +115,4 @@ class: training - \ No newline at end of file + From d7e41951bd05228de5b6025b4bee7627a24327b8 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Thu, 11 Jun 2020 20:49:09 +0900 Subject: [PATCH 287/290] Update content/ja/training/_index.html Co-authored-by: Tim Bannister --- content/ja/training/_index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index 38128f4d4a..df7f08bc9b 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -1,7 +1,7 @@ --- title: トレーニング bigheader: Kubernetesのトレーニングと資格 -abstract: トレーニングプログラム、資格、及びパートナーについて +abstract: トレーニングプログラム、資格、及びパートナーについて。 layout: basic cid: training class: training From e7f67a05c2ca93e905cf997384d2ee412502e8bc Mon Sep 17 00:00:00 2001 From: inductor Date: Thu, 11 Jun 2020 20:51:40 +0900 Subject: [PATCH 288/290] improve translation --- content/ja/training/_index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index df7f08bc9b..dc4d1bf2c2 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -83,9 +83,9 @@ class: training
    - 認定Kubernetesアプリケーションデベロッパー(Certified Kubernetes Application Developer, CKAD) + 認定Kubernetesアプリケーション開発者(Certified Kubernetes Application Developer, CKAD)
    -

    認定Kubernetesアプリケーションデベロッパー(CKAD)試験は、ユーザーがKubernetes向けにクラウドネイティブアプリケーションを設計、構築、構成、公開できることを証明します。

    +

    認定Kubernetesアプリケーション開発者(CKAD)試験は、ユーザーがKubernetes向けにクラウドネイティブアプリケーションを設計、構築、構成、公開できることを証明します。


    試験を受ける
    @@ -93,9 +93,9 @@ class: training
    - 認定Kubernetesアドミニストレーター(Certified Kubernetes Administrator, CKA) + 認定Kubernetes管理者(Certified Kubernetes Administrator, CKA)
    -

    認定Kubernetesアドミニストレーター(CKA)プログラムは、保有者がKubernetes管理者の責任を実行するためのスキル、知識、および能力を持っていることを保証します。

    +

    認定Kubernetes管理者(CKA)プログラムは、保有者がKubernetes管理者の責務を実行するためのスキル、知識、および能力を持っていることを保証します。


    試験を受ける
    From 42ffececf7d2fc5abb33b142b35922c820221001 Mon Sep 17 00:00:00 2001 From: inductor Date: Fri, 12 Jun 2020 02:59:47 +0900 Subject: [PATCH 289/290] fix typo --- content/ja/training/_index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index dc4d1bf2c2..8ef1620e3f 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -17,7 +17,7 @@ class: training
    -

    あなたのクラウドネイティブなキャリアを創る/h2> +

    あなたのクラウドネイティブキャリアを創る

    Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。

    From 12ed94cbd475ed3631606883b2e18b865ae5476e Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Fri, 12 Jun 2020 11:52:02 +0900 Subject: [PATCH 290/290] Update _index.html --- content/ja/training/_index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html index 8ef1620e3f..8c92ea7f22 100644 --- a/content/ja/training/_index.html +++ b/content/ja/training/_index.html @@ -17,7 +17,7 @@ class: training
    -

    あなたのクラウドネイティブキャリアを創る

    +

    あなたのクラウドネイティブなキャリアを創る

    Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。