From 26a4e5fd41dbf1fcaff21a3943f60f778fe68e99 Mon Sep 17 00:00:00 2001 From: ystkfujii Date: Fri, 31 Mar 2023 01:44:27 +0900 Subject: [PATCH] =?UTF-8?q?[ja]=20s/=E3=82=AF=E3=83=A9=E3=82=B9=E3=82=BF/?= =?UTF-8?q?=E3=82=AF=E3=83=A9=E3=82=B9=E3=82=BF=E3=83=BC/g?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../2020-12-02-dont-panic-kubernetes-and-docker.md | 6 +++--- content/ja/case-studies/nordstrom/index.html | 4 ++-- .../ja/docs/concepts/architecture/cloud-controller.md | 2 +- content/ja/docs/concepts/architecture/nodes.md | 2 +- .../ja/docs/concepts/cluster-administration/addons.md | 2 +- .../configuration/manage-resources-containers.md | 8 ++++---- content/ja/docs/concepts/configuration/overview.md | 2 +- .../overview/working-with-objects/common-labels.md | 2 +- .../overview/working-with-objects/object-management.md | 2 +- .../scheduling-eviction/scheduler-perf-tuning.md | 6 +++--- content/ja/docs/concepts/services-networking/_index.md | 2 +- .../connect-applications-service.md | 2 +- content/ja/docs/concepts/storage/ephemeral-volumes.md | 2 +- content/ja/docs/concepts/storage/persistent-volumes.md | 2 +- content/ja/docs/concepts/storage/storage-classes.md | 6 +++--- .../concepts/workloads/pods/ephemeral-containers.md | 2 +- .../ja/docs/concepts/workloads/pods/pod-lifecycle.md | 4 ++-- .../reference/access-authn-authz/authentication.md | 6 +++--- content/ja/docs/reference/access-authn-authz/rbac.md | 6 +++--- .../command-line-tools-reference/feature-gates.md | 2 +- .../reference/glossary/cloud-controller-manager.md | 2 +- content/ja/docs/reference/glossary/csi.md | 2 +- content/ja/docs/reference/kubectl/_index.md | 4 ++-- content/ja/docs/reference/tools.md | 6 +++--- content/ja/docs/setup/_index.md | 2 +- content/ja/docs/setup/best-practices/certificates.md | 2 +- .../ja/docs/setup/best-practices/node-conformance.md | 2 +- content/ja/docs/setup/learning-environment/minikube.md | 2 +- .../ja/docs/setup/production-environment/tools/kops.md | 10 +++++----- .../tools/kubeadm/kubelet-integration.md | 2 +- .../tools/kubeadm/troubleshooting-kubeadm.md | 10 +++++----- .../windows/intro-windows-in-kubernetes.md | 2 +- .../service-access-application-cluster.md | 2 +- .../access-application-cluster/web-ui-dashboard.md | 4 ++-- .../manage-resources/memory-constraint-namespace.md | 2 +- .../ja/docs/tasks/administer-cluster/nodelocaldns.md | 2 +- .../tasks/administer-cluster/securing-a-cluster.md | 8 ++++---- .../tasks/administer-cluster/use-cascading-deletion.md | 2 +- content/ja/docs/tasks/debug/debug-cluster/crictl.md | 4 ++-- .../docs/tasks/debug/debug-cluster/local-debugging.md | 2 +- .../run-replicated-stateful-application.md | 8 ++++---- .../docs/tasks/run-application/scale-stateful-set.md | 2 +- content/ja/docs/tutorials/clusters/apparmor.md | 6 +++--- .../mysql-wordpress-persistent-volume.md | 2 +- 44 files changed, 80 insertions(+), 80 deletions(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 3e57783328..7006883026 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -13,7 +13,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ 概要: ランタイムとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。 -もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスタ上でこれからも動作可能なのです。 +もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスター上でこれからも動作可能なのです。 もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、ワーカーノードがサポート対象のランタイムを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。 @@ -24,7 +24,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。 -このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。 +このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスターはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。 ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。 DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/))に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。 @@ -35,7 +35,7 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co ## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。 -みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。 +みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスターの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。 これがコンテナの仕様について、共通の仕様を策定している理由なのです。 さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょう。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。 diff --git a/content/ja/case-studies/nordstrom/index.html b/content/ja/case-studies/nordstrom/index.html index ec757ca23c..55558f947e 100644 --- a/content/ja/case-studies/nordstrom/index.html +++ b/content/ja/case-studies/nordstrom/index.html @@ -65,10 +65,10 @@ case_study_details:

Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。

{{< case-studies/quote >}} -「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 +「Kubernetesを使用することで、クラスターの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 {{< /case-studies/quote >}} -

スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」

+

スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスターの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」

Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」

diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index fa7e5a34fc..d21c3bd1cf 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -46,7 +46,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。 +ルートコントローラーは、クラスター内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。 クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。 diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 582f3172e2..1ae9f39a4f 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -217,7 +217,7 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担 ノードを複数のアベイラビリティゾーンに分散させる主な理由は、1つのゾーン全体が停止したときにワークロードを正常なゾーンに移動できることです。 したがって、ゾーン内のすべてのノードが異常である場合、ノードコントローラーは通常のレート `--node-eviction-rate`で退役します。 -コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。 +コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスター内にHealthyなノードがない）場合です。 このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。 ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。 diff --git a/content/ja/docs/concepts/cluster-administration/addons.md b/content/ja/docs/concepts/cluster-administration/addons.md index aea14c681a..e22ca75da5 100644 --- a/content/ja/docs/concepts/cluster-administration/addons.md +++ b/content/ja/docs/concepts/cluster-administration/addons.md @@ -45,7 +45,7 @@ weight: 120 ## インフラストラクチャ {#infrastructure} -* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスターで実行します。 * [node problem detector](https://github.com/kubernetes/node-problem-detector)はLinuxノード上で動作し、システムの問題を[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)または[ノードのCondition](/ja/docs/concepts/architecture/nodes/#condition)として報告します。 ## レガシーなアドオン {#legacy-add-ons} diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index 8c01988ea8..623b9e3041 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -378,10 +378,10 @@ Kubernetesが使用しないようにする必要があります。 ## 拡張リソース {#extended-resources} 拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。 -これにより、クラスタオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。 +これにより、クラスターオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。 拡張リソースを使用するためには、2つのステップが必要です。 -第一に、クラスタオペレーターは拡張リソースをアドバタイズする必要があります。 +第一に、クラスターオペレーターは拡張リソースをアドバタイズする必要があります。 第二に、ユーザーはPodで拡張リソースを要求する必要があります。 ### 拡張リソースの管理 {#managing-extended-resources} @@ -394,7 +394,7 @@ Nodeレベルの拡張リソースはNodeに関連付けられています。 各Nodeにデバイスプラグインで管理されているリソースをアドバタイズする方法については、[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を参照してください。 ##### その他のリソース {#other-resources} -新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。 +新しいNodeレベルの拡張リソースをアドバタイズするには、クラスターオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスター内のNodeの`status.capacity`に利用可能な量を指定します。 この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。 `status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。 スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。 @@ -513,7 +513,7 @@ Events: 同様のエラーメッセージは、メモリー不足による失敗を示唆することもあります(PodExceedsFreeMemory)。 一般的に、このタイプのメッセージでPodが保留されている場合は、いくつか試すべきことがあります。 -- クラスタにNodeを追加します。 +- クラスターにNodeを追加します。 - 不要なポッドを終了して、保留中のPodのためのスペースを空けます。 - PodがすべてのNodeよりも大きくないことを確認してください。 例えば、すべてのNodeが`cpu: 1`の容量を持っている場合、`cpu: 1.1`を要求するPodは決してスケジューリングされません。 diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 9bec6f87fb..678fdb0627 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -44,7 +44,7 @@ weight: 10 *これは順序付けの必要性を意味します* - `Pod`がアクセスしたい`Service`は`Pod`自身の前に作らなければならず、そうしないと環境変数は注入されません。DNSにはこの制限はありません。 -- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスタ全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。 +- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスター全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。 - どうしても必要な場合以外は、Podに`hostPort`を指定しないでください。Podを`hostPort`にバインドすると、Podがスケジュールできる場所の数を制限します、それぞれの<`hostIP`、 `hostPort`、`protocol`>の組み合わせはユニークでなければならないからです。`hostIP`と`protocol`を明示的に指定しないと、Kubernetesはデフォルトの`hostIP`として`0.0.0.0`を、デフォルトの `protocol`として`TCP`を使います。 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 7e5b278be0..2c34dd449b 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 @@ -50,7 +50,7 @@ metadata: ## アプリケーションとアプリケーションのインスタンス -単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。 +単一のアプリケーションは、Kubernetesクラスター内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。 例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。 アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/object-management.md b/content/ja/docs/concepts/overview/working-with-objects/object-management.md index cd76abd08b..94bc651fb0 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ja/docs/concepts/overview/working-with-objects/object-management.md @@ -52,7 +52,7 @@ kubectl create deployment nginx --image nginx オブジェクト設定手法に対する長所: - コマンドは簡潔、簡単に学ぶことができ、そして覚えやすいです -- コマンドではクラスタの設定を変えるのに、わずか1ステップしか必要としません +- コマンドではクラスターの設定を変えるのに、わずか1ステップしか必要としません オブジェクト設定手法に対する短所: diff --git a/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index f46a7b15e2..359e828ebc 100644 --- a/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -46,7 +46,7 @@ kubectl get pods -n kube-system | grep kube-scheduler ### デフォルトの閾値 -閾値を指定しない場合、Kubernetesは100ノードのクラスタでは50%、5000ノードのクラスタでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。 +閾値を指定しない場合、Kubernetesは100ノードのクラスターでは50%、5000ノードのクラスターでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。 つまり、明示的に`percentageOfNodesToScore`を5未満の値を設定しない限り、クラスターの規模に関係なく、kube-schedulerは常に少なくともクラスターの5%のノードに対してスコア付けをします。 @@ -72,9 +72,9 @@ percentageOfNodesToScore: 50 `percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。 {{< note >}} -割り当て可能なノードが50以下のクラスタでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。 +割り当て可能なノードが50以下のクラスターでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。 -小規模クラスタでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。 +小規模クラスターでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。 クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。 {{< /note >}} diff --git a/content/ja/docs/concepts/services-networking/_index.md b/content/ja/docs/concepts/services-networking/_index.md index 4089dc17cf..1a8eeba773 100644 --- a/content/ja/docs/concepts/services-networking/_index.md +++ b/content/ja/docs/concepts/services-networking/_index.md @@ -9,4 +9,4 @@ Kubernetesのネットワーキングは4つの懸念事項に対処します。 - Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。 - クラスターネットワーキングは、異なるPod間の通信を提供します。 - Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。 -- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。 +- Serviceを利用して、クラスター内部のみで使用するServiceの公開も可能です。 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 17aced1783..fbdce825c0 100644 --- a/content/ja/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md @@ -139,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク ## Serviceにアクセスする Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。 -前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。 +前者はそのまま使用でき、後者は[CoreDNSクラスターアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。 {{< note >}} サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。 {{< /note >}} diff --git a/content/ja/docs/concepts/storage/ephemeral-volumes.md b/content/ja/docs/concepts/storage/ephemeral-volumes.md index 1b3ed0d5b8..769848cf33 100644 --- a/content/ja/docs/concepts/storage/ephemeral-volumes.md +++ b/content/ja/docs/concepts/storage/ephemeral-volumes.md @@ -83,7 +83,7 @@ CSIエフェメラルボリュームを使用すると、ユーザーはPod仕 通常は管理者に制限されている`volumeAttributes`を許可するCSIドライバーは、インラインエフェメラルボリュームでの使用には適していません。 たとえば、通常StorageClassで定義されるパラメーターは、インラインエフェメラルボリュームを使用してユーザーに公開しないでください。 -Pod仕様内でインラインボリュームとして使用できるCSIドライバーを制限する必要があるクラスタ管理者は、次の方法で行うことができます。 +Pod仕様内でインラインボリュームとして使用できるCSIドライバーを制限する必要があるクラスター管理者は、次の方法で行うことができます。 - CSIドライバー仕様の`volumeLifecycleModes`から`Ephemeral`を削除します。これにより、ドライバーをインラインエフェメラルボリュームとして使用できなくなります。 - [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)を使用して、このドライバーの使用方法を制限します。 diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 0a82b6a3cb..a500423f2a 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -386,7 +386,7 @@ PersistentVolumeは、リソースプロバイダーがサポートする方法 : ボリュームは多数のNodeで読み取り/書き込みとしてマウントできます `ReadWriteOncePod` -: ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスタ全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。 +: ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスター全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。 これについてはブログ[Introducing Single Pod Access Mode for PersistentVolumes](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/)に詳細が記載されています。 diff --git a/content/ja/docs/concepts/storage/storage-classes.md b/content/ja/docs/concepts/storage/storage-classes.md index c27aec26ae..e0df25f382 100644 --- a/content/ja/docs/concepts/storage/storage-classes.md +++ b/content/ja/docs/concepts/storage/storage-classes.md @@ -159,7 +159,7 @@ spec: ### 許可されたトポロジー {#allowed-topologies} -クラスタオペレーターが`WaitForFirstConsumer`ボリュームバインディングモードを指定すると、ほとんどの状況でプロビジョニングを特定のトポロジに制限する必要がなくなります。ただし、それでも必要な場合は、`allowedTopologies`を指定できます。 +クラスターオペレーターが`WaitForFirstConsumer`ボリュームバインディングモードを指定すると、ほとんどの状況でプロビジョニングを特定のトポロジに制限する必要がなくなります。ただし、それでも必要な場合は、`allowedTopologies`を指定できます。 この例は、プロビジョニングされたボリュームのトポロジを特定のゾーンに制限する方法を示しており、サポートされているプラグインの`zone`および`zones`パラメーターの代わりとして使用する必要があります。 @@ -274,7 +274,7 @@ parameters: シークレットの例は[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml)にあります。 -* `clusterid`:`630372ccdc720a92c681fb928f27b53f`は、ボリュームのプロビジョニング時にHeketiによって使用されるクラスターのIDです。また、クラスタIDのリストにすることもできます。これはオプションのパラメーターです。 +* `clusterid`:`630372ccdc720a92c681fb928f27b53f`は、ボリュームのプロビジョニング時にHeketiによって使用されるクラスターのIDです。また、クラスターIDのリストにすることもできます。これはオプションのパラメーターです。 * `gidMin`、`gidMax`:StorageClassのGID範囲の最小値と最大値。この範囲内の一意の値(GID)(gidMin-gidMax)が、動的にプロビジョニングされたボリュームに使用されます。これらはオプションの値です。指定しない場合、ボリュームは、それぞれgidMinとgidMaxのデフォルトである2000から2147483647の間の値でプロビジョニングされます。 * `volumetype`:ボリュームタイプとそのパラメーターは、このオプションの値で構成できます。ボリュームタイプが記載されていない場合、プロビジョニング担当者がボリュームタイプを決定します。 例えば、 @@ -492,7 +492,7 @@ parameters: * `secretName`:Azureストレージアカウント名とキーを含むシークレットの名前。デフォルトは`azure-storage-account--secret`です * `readOnly`:ストレージが読み取り専用としてマウントされるかどうかを示すフラグ。デフォルトはfalseで、読み取り/書き込みマウントを意味します。この設定は、VolumeMountsの`ReadOnly`設定にも影響します。 -ストレージのプロビジョニング中に、`secretName`という名前のシークレットがマウント資格証明用に作成されます。クラスタで[RBAC](/ja/docs/reference/access-authn-authz/rbac/)と[Controller Roles](/ja/docs/reference/access-authn-authz/rbac/#controller-roles)の両方が有効になっている場合は、追加します。clusterrole`system:controller:persistent-volume-binder`に対するリソース`secret`の`create`パーミッション。 +ストレージのプロビジョニング中に、`secretName`という名前のシークレットがマウント資格証明用に作成されます。クラスターで[RBAC](/ja/docs/reference/access-authn-authz/rbac/)と[Controller Roles](/ja/docs/reference/access-authn-authz/rbac/#controller-roles)の両方が有効になっている場合は、追加します。clusterrole`system:controller:persistent-volume-binder`に対するリソース`secret`の`create`パーミッション。 マルチテナンシーコンテキストでは、`secretNamespace`の値を明示的に設定することを強くお勧めします。そうしないと、ストレージアカウントの資格情報が他のユーザーに読み取られる可能性があります。 diff --git a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md index a07fb2a73a..39e2b908ad 100644 --- a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md @@ -11,7 +11,7 @@ weight: 80 このページでは、特別な種類のコンテナであるエフェメラルコンテナの概要を説明します。エフェメラルコンテナは、トラブルシューティングなどのユーザーが開始するアクションを実行するために、すでに存在する{{< glossary_tooltip term_id="pod" >}}内で一時的に実行するコンテナです。エフェメラルコンテナは、アプリケーションの構築ではなく、serviceの調査のために利用します。 {{< warning >}} -エフェメラルコンテナは初期のアルファ状態であり、本番クラスタには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。 +エフェメラルコンテナは初期のアルファ状態であり、本番クラスターには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。 {{< /warning >}} diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index b633aa6d43..89d521098c 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -55,7 +55,7 @@ Podの各フェーズの値と意味は厳重に守られています。ここ Podの削除中に、kubectlコマンドには`Terminating`が出力されることがあります。この`Terminating`ステータスは、Podのフェーズではありません。Podには、正常に終了するための期間を与えられており、デフォルトは30秒です。`--force`フラグを使用して、[Podを強制的に削除する](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)ことができます。 {{< /note >}} -Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。 +Nodeが停止するか、クラスターの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。 ## コンテナのステータス {#container-states} @@ -310,7 +310,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 {{< caution >}} 即時削除では、実行中のリソースの終了を待ちません。 -リソースはクラスタ上で無期限に実行し続ける可能性があります。 +リソースはクラスター上で無期限に実行し続ける可能性があります。 {{< /caution >}} StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index e2bd78316b..1765c7d504 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -91,7 +91,7 @@ Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 {{< feature-state for_k8s_version="v1.18" state="stable" >}} -新しいクラスタの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。 +新しいクラスターの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。 トークンの形式は`[a-z0-9]{6}.[a-z0-9]{16}`です。最初のコンポーネントはトークンIDであり、第2のコンポーネントはToken Secretです。以下のように、トークンをHTTPヘッダーに指定します。 @@ -101,7 +101,7 @@ Authorization: Bearer 781292.db7bc3a58fc5f07e APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、コントローラーマネージャーの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。 -認証機能は`system:bootstrap:`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。 +認証機能は`system:bootstrap:`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスターのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。 ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。 @@ -184,7 +184,7 @@ type: kubernetes.io/service-account-token Secretは常にbase64でエンコードされるため、これらの値もbase64でエンコードされています。 {{< /note >}} -署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスタ内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。 +署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスター内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。 サービスアカウントは、ユーザー名`system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`で認証され、グループ`system:serviceaccounts`と`system:serviceaccounts:(NAMESPACE)`に割り当てられます。 diff --git a/content/ja/docs/reference/access-authn-authz/rbac.md b/content/ja/docs/reference/access-authn-authz/rbac.md index ef3d82a025..5a8689abae 100644 --- a/content/ja/docs/reference/access-authn-authz/rbac.md +++ b/content/ja/docs/reference/access-authn-authz/rbac.md @@ -508,7 +508,7 @@ APIサーバーは、デフォルトのClusterRoleオブジェクトとClusterRo 起動するたびに、APIサーバーはデフォルトのClusterRoleを不足している権限で更新し、 デフォルトのClusterRoleBindingを不足しているsubjectsで更新します。 -これにより、誤った変更をクラスタが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、 +これにより、誤った変更をクラスターが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、 RoleとRoleBindingを最新の状態に保つことができます。 この調整を無効化するには`rbac.authorization.kubernetes.io/autoupdate`をデフォルトのClusterRoleまたはRoleBindingのアノテーションを`false`に設定します。 @@ -557,7 +557,7 @@ ClusterRoleを編集すると、変更が[自動調整](#自動調整)によるA ### ユーザー向けRole -一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスタ全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。 +一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスター全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。 ユーザー向けのClusterRolesは[ClusterRoleの集約](#集約clusterrole)を使用して、管理者がこれらのClusterRolesにカスタムリソースのルールを含めることができるようにします。ルールを`admin`、`edit`、または`view` Roleに追加するには、次のラベルの一つ以上でClusterRoleを作成します。 @@ -907,7 +907,7 @@ subjects: ### `kubectl create clusterrolebinding` -以下に、クラスタ全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。 +以下に、クラスター全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。 * クラスター全体で、ClusterRole「cluster-admin」へのアクセス許可を「root」という名前のユーザーに付与します。 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 436a80752d..86932e212f 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 @@ -441,7 +441,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。 -- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。 +- `ServiceTopology`: クラスターのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。 - `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。 diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md index d0e705c7c1..8cb216dba7 100644 --- a/content/ja/docs/reference/glossary/cloud-controller-manager.md +++ b/content/ja/docs/reference/glossary/cloud-controller-manager.md @@ -11,7 +11,7 @@ tags: - architecture - operation --- - クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。 + クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスターのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。 diff --git a/content/ja/docs/reference/glossary/csi.md b/content/ja/docs/reference/glossary/csi.md index 70747f7b58..f3dfd24442 100644 --- a/content/ja/docs/reference/glossary/csi.md +++ b/content/ja/docs/reference/glossary/csi.md @@ -15,7 +15,7 @@ tags: -CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスタにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。 +CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスターにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。 * [KubernetesにおけるCSIのドキュメント](/docs/concepts/storage/volumes/#csi) * [利用可能なCSIドライバの一覧](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/ja/docs/reference/kubectl/_index.md b/content/ja/docs/reference/kubectl/_index.md index 255a6131ab..6d2f2d7a47 100644 --- a/content/ja/docs/reference/kubectl/_index.md +++ b/content/ja/docs/reference/kubectl/_index.md @@ -134,7 +134,7 @@ kubectl config set-context --current --namespace= `proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。 `replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。 `rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。 -`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 指定したイメージを、クラスタ上で実行します。 +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 指定したイメージを、クラスター上で実行します。 `scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 指定したReplicationControllerのサイズを更新します。 `set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。 `taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。 @@ -415,7 +415,7 @@ kubectl logs kubectl logs -f ``` -`kubectl diff` - 提案されたクラスタに対する更新の差分を表示します。 +`kubectl diff` - 提案されたクラスターに対する更新の差分を表示します。 ```shell # pod.jsonに含まれるリソースの差分を表示します。 diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md index dc925deffa..09b757375b 100644 --- a/content/ja/docs/reference/tools.md +++ b/content/ja/docs/reference/tools.md @@ -11,13 +11,13 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組 [`kubectl`](/ja/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。 ## Kubeadm -[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 +[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスターを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 ## Minikube -[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。 +[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスターをローカルで実行するツールです。 ## Dashboard -[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。 +[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、トラブルシューティングしたり、クラスターとそのリソース自体を管理したりすることが出来ます。 ## Helm [`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。 diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 6f7153f445..10510b2ab1 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -20,7 +20,7 @@ card: Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。 -Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。 +Kubernetesクラスターはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。 diff --git a/content/ja/docs/setup/best-practices/certificates.md b/content/ja/docs/setup/best-practices/certificates.md index 317902b251..a782b52fee 100644 --- a/content/ja/docs/setup/best-practices/certificates.md +++ b/content/ja/docs/setup/best-practices/certificates.md @@ -15,7 +15,7 @@ Kubernetesでは、TLS認証のためにPKI証明書が必要です。 -## クラスタではどのように証明書が使われているのか +## クラスターではどのように証明書が使われているのか Kubernetesは下記の用途でPKIを必要とします： diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 919e64ff66..f9ad8d26ec 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -6,7 +6,7 @@ weight: 30 ## ノード適合テスト -*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。 +*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスターに参加する資格があることになります。 ## ノードの前提条件 diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index 65054b66fb..ce09ddd669 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -7,7 +7,7 @@ content_type: concept -Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。 +Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスターを実行することができます。 diff --git a/content/ja/docs/setup/production-environment/tools/kops.md b/content/ja/docs/setup/production-environment/tools/kops.md index 78b51d2991..93cad2ec61 100644 --- a/content/ja/docs/setup/production-environment/tools/kops.md +++ b/content/ja/docs/setup/production-environment/tools/kops.md @@ -33,7 +33,7 @@ kops is an automated provisioning system: -## クラスタの作成 +## クラスターの作成 ### (1/5) kopsのインストール @@ -122,7 +122,7 @@ brew update && brew install kops {{< /tabs >}} -### (2/5) クラスタ用のroute53ドメインの作成 +### (2/5) クラスター用のroute53ドメインの作成 kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server from clients. @@ -154,7 +154,7 @@ your cluster is configured correctly if you have the dig tool by running: You should see the 4 NS records that Route53 assigned your hosted zone. -### (3/5) クラスタの状態を保存するS3バケットの作成 +### (3/5) クラスターの状態を保存するS3バケットの作成 kops lets you manage your clusters even after installation. To do this, it must keep track of the clusters that you have created, along with their configuration, the keys they are using etc. This information is stored @@ -179,7 +179,7 @@ the S3 bucket name. We suggest putting this in your bash profile or similar. -### (4/5) クラスタ設定の構築 +### (4/5) クラスター設定の構築 Run `kops create cluster` to create your cluster configuration: @@ -202,7 +202,7 @@ You can have several instance groups, for example if you wanted nodes that are a GPU and non-GPU instances. -### (5/5) AWSにクラスタを作成 +### (5/5) AWSにクラスターを作成 Run "kops update cluster" to create your cluster in AWS: diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index fbefc48895..1b25085c8d 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -64,7 +64,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub ### `kubeadm init`実行時の流れ -`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。 +`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスター内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。 二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index b183e75dbf..94f34654f1 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -18,10 +18,10 @@ weight: 20 -## RBACがないため、v1.18ノードをv1.17クラスタに結合できない -v1.18では、同名のノードが既に存在する場合にクラスタ内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。 +## RBACがないため、v1.18ノードをv1.17クラスターに結合できない +v1.18では、同名のノードが既に存在する場合にクラスター内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。 -しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスタに参加できないという問題が発生します。 +しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスターに参加できないという問題が発生します。 この問題を回避するには、次の2つの方法があります。 - kubeadm v1.18を用いて、コントロールプレーンノード上で`kubeadm init phase bootstrap-token`を実行します。 @@ -240,7 +240,7 @@ kubectl -n kube-system get deployment coredns -o yaml | \ CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。 {{< warning >}} -SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスタのセキュリティが損なわれる可能性があります。 +SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスターのセキュリティが損なわれる可能性があります。 {{< /warning >}} ## etcdのpodが継続的に再起動する @@ -343,6 +343,6 @@ nodeRegistration: あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。 ## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する -このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。 +このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスターをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスターのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。 この問題はバージョン1.19で修正されます。 diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 3ca0f5764e..3545f06820 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -195,7 +195,7 @@ Windowsでは、次のIPAMオプションがサポートされています。 #### コントロールプレーン -Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスタには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。 +Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスターには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。 #### コンピュート 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 34413cedd3..01fed37bc2 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 @@ -38,7 +38,7 @@ weight: 60 {{< codenew file="service/access/hello-application.yaml" >}} -1. クラスタでHello Worldアプリケーションを稼働させます: +1. クラスターでHello Worldアプリケーションを稼働させます: 上記のファイルを使用し、アプリケーションのDeploymentを作成します: ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml 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 ba78ba15fa..7c5cd69cec 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 @@ -89,7 +89,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー - **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。 コンテナイメージの指定はコロンで終わらせる必要があります。 - クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。 + クラスター全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。 - **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、 [Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。 @@ -124,7 +124,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー ``` - **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。 - これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。 + これらの仮想クラスターは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。 これにより、リソースを論理的に名前のついたグループに分割することができます。 ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。 diff --git a/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 4ab8a06de4..28509e6f09 100644 --- a/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -217,7 +217,7 @@ LimitRangeによってNamespaceに課される最大および最小のメモリ 例: -* クラスター内の各ノードは2GBのメモリーを持っています。クラスタ内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。 +* クラスター内の各ノードは2GBのメモリーを持っています。クラスター内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。 * クラスターは運用部門と開発部門で共有されています。 本番用のワークロードでは最大8GBのメモリーを消費しますが、開発用のワークロードでは512MBに制限したいとします。本番用と開発用に別々のNamespaceを作成し、それぞれのNamespaceにメモリー制限を適用します。 diff --git a/content/ja/docs/tasks/administer-cluster/nodelocaldns.md b/content/ja/docs/tasks/administer-cluster/nodelocaldns.md index 082b2b01b9..b6df10470d 100644 --- a/content/ja/docs/tasks/administer-cluster/nodelocaldns.md +++ b/content/ja/docs/tasks/administer-cluster/nodelocaldns.md @@ -46,7 +46,7 @@ NodeLocal DNSキャッシュは、クラスターノード上でDNSキャッシ {{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCacheのフロー" caption="この図は、NodeLocal DNSキャッシュがDNSクエリーをどう扱うかを表したものです。" >}} ## 設定 -{{< note >}} NodeLocal DNSキャッシュのローカルリッスン用のIPアドレスは、クラスタ内の既存のIPと衝突しないことが保証できるものであれば、どのようなアドレスでもかまいません。例えば、IPv4のリンクローカル範囲169.254.0.0/16やIPv6のユニークローカルアドレス範囲fd00::/8から、ローカルスコープのアドレスを使用することが推奨されています。 +{{< note >}} NodeLocal DNSキャッシュのローカルリッスン用のIPアドレスは、クラスター内の既存のIPと衝突しないことが保証できるものであれば、どのようなアドレスでもかまいません。例えば、IPv4のリンクローカル範囲169.254.0.0/16やIPv6のユニークローカルアドレス範囲fd00::/8から、ローカルスコープのアドレスを使用することが推奨されています。 {{< /note >}} この機能は、下記の手順により有効化できます。 diff --git a/content/ja/docs/tasks/administer-cluster/securing-a-cluster.md b/content/ja/docs/tasks/administer-cluster/securing-a-cluster.md index 52cceb9c83..e5cfd0d2db 100644 --- a/content/ja/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/ja/docs/tasks/administer-cluster/securing-a-cluster.md @@ -74,7 +74,7 @@ Kubeletsは、ノードやコンテナの強力な制御を可能にするHTTPS Kubernetesにおける権限付与は、意図的にハイレベルであり、リソースに対する粗いアクションに焦点を当てています。 -より強力なコントロールは**policies**として存在し、それらのオブジェクトがクラスタや自身、その他のリソースにどのように作用するかをユースケースによって制限します。 +より強力なコントロールは**policies**として存在し、それらのオブジェクトがクラスターや自身、その他のリソースにどのように作用するかをユースケースによって制限します。 ### クラスターのリソース使用量の制限 @@ -106,7 +106,7 @@ Linuxカーネルは、ハードウェアが接続されたときやファイル # DCCPは必要性が低く、複数の深刻な脆弱性があり、保守も十分ではありません。 blacklist dccp -# SCTPはほとんどのKubernetesクラスタでは使用されておらず、また過去には脆弱性がありました。 +# SCTPはほとんどのKubernetesクラスターでは使用されておらず、また過去には脆弱性がありました。 blacklist sctp ``` @@ -120,7 +120,7 @@ blacklist sctp サポートされている[Kubernetes networking providers](/ja/docs/concepts/cluster-administration/networking/)の多くは、ネットワークポリシーを尊重するようになりました。 クォータやリミットの範囲は、ユーザーがノードポートや負荷分散サービスを要求するかどうかを制御するためにも使用でき、多くのクラスターでは、ユーザーのアプリケーションがクラスターの外で見えるかどうかを制御できます。 -ノードごとのファイアウォール、クロストークを防ぐための物理的なクラスタノードの分離、高度なネットワークポリシーなど、プラグインや環境ごとにネットワークルールを制御する追加の保護機能が利用できる場合もあります。 +ノードごとのファイアウォール、クロストークを防ぐための物理的なクラスターノードの分離、高度なネットワークポリシーなど、プラグインや環境ごとにネットワークルールを制御する追加の保護機能が利用できる場合もあります。 ### クラウドメタデータのAPIアクセスを制限 @@ -145,7 +145,7 @@ Kubernetesは、エンドユーザーが利用できる[Node上へのPodのス ### etcdへのアクセスの制限 -API用のetcdバックエンドへの書き込みアクセスは、クラスタ全体のrootを取得するのと同等であり、読み取りアクセスはかなり迅速にエスカレートするために使用できます。 +API用のetcdバックエンドへの書き込みアクセスは、クラスター全体のrootを取得するのと同等であり、読み取りアクセスはかなり迅速にエスカレートするために使用できます。 管理者は、TLSクライアント証明書による相互認証など、APIサーバーからetcdサーバーへの強力な認証情報を常に使用すべきであり、API サーバーのみがアクセスできるファイアウォールの後ろにetcdサーバーを隔離することがしばしば推奨されます。 {{< caution >}} diff --git a/content/ja/docs/tasks/administer-cluster/use-cascading-deletion.md b/content/ja/docs/tasks/administer-cluster/use-cascading-deletion.md index e9af802f5a..ba8c6cc88e 100644 --- a/content/ja/docs/tasks/administer-cluster/use-cascading-deletion.md +++ b/content/ja/docs/tasks/administer-cluster/use-cascading-deletion.md @@ -139,7 +139,7 @@ kubectl delete deployment nginx-deployment --cascade=background ## オーナーオブジェクトの削除と従属オブジェクトの孤立 {#set-orphan-deletion-policy} -デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{}}は従属オブジェクトも削除します。クラスタが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{}} +デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{}}は従属オブジェクトも削除します。クラスターが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{}} **kubectlを使用する** diff --git a/content/ja/docs/tasks/debug/debug-cluster/crictl.md b/content/ja/docs/tasks/debug/debug-cluster/crictl.md index a918ab9ebf..2fa6d030cb 100644 --- a/content/ja/docs/tasks/debug/debug-cluster/crictl.md +++ b/content/ja/docs/tasks/debug/debug-cluster/crictl.md @@ -230,7 +230,7 @@ crictl logs --tail=1 87d3992f84f74 ### Podサンドボックスの実行 `crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。 -稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 +稼働中のKubernetesクラスターでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 1. 以下のようなJSONファイルを作成します: @@ -259,7 +259,7 @@ crictl logs --tail=1 87d3992f84f74 ### コンテナの作成 コンテナの作成に`crictl`を使うと、コンテナのランタイムをデバッグするのに便利です。 -稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 +稼働中のKubernetesクラスターでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 1. busyboxイメージをプルします: diff --git a/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md b/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md index 8fe2c4a5f4..624d52b972 100644 --- a/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md +++ b/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md @@ -10,7 +10,7 @@ Kubernetesアプリケーションは通常、複数の独立したサービス `telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。 `telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。 -このドキュメントでは、リモートクラスタ上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。 +このドキュメントでは、リモートクラスター上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。 ## {{% heading "prerequisites" %}} diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index 9b977d4de2..3f380f61f6 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -79,10 +79,10 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml ヘッドレスサービスは、StatefulSetコントローラーが StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。 -この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの +この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスターの 同じ名前空間内の他のPodは、`.mysql`を名前解決することでPodにアクセスできます。 -`mysql-read`と呼ばれるクライアントサービスは、独自のクラスタIPを持つ通常のServiceであり、 +`mysql-read`と呼ばれるクライアントサービスは、独自のクラスターIPを持つ通常のServiceであり、 Ready状態のすべてのMySQL Podに接続を分散します。 Serviceのエンドポイントには、MySQLマスターとすべてのスレーブが含まれる可能性があります。 @@ -313,7 +313,7 @@ StatefulSetコントローラーは`mysql-2` Podがもう存在しないこと ### ノードをdrainする -Kubernetesクラスタに複数のノードがある場合は、 +Kubernetesクラスターに複数のノードがある場合は、 [drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)を発行して ノードのダウンタイム(例えばノードのアップグレード時など)をシミュレートできます。 @@ -335,7 +335,7 @@ mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-mini ``は前のステップで確認したノードの名前に置き換えてください。 この操作はノード上の他のアプリケーションに影響を与える可能性があるため、 -**テストクラスタでのみこの操作を実行**するのが最善です。 +**テストクラスターでのみこの操作を実行**するのが最善です。 ```shell kubectl drain --force --delete-local-data --ignore-daemonsets diff --git a/content/ja/docs/tasks/run-application/scale-stateful-set.md b/content/ja/docs/tasks/run-application/scale-stateful-set.md index bfde1d0afd..cfec1518f4 100644 --- a/content/ja/docs/tasks/run-application/scale-stateful-set.md +++ b/content/ja/docs/tasks/run-application/scale-stateful-set.md @@ -70,7 +70,7 @@ spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断で 永続的な障害が原因でPodが正常でない場合、障害を修正せずにスケーリングすると、StatefulSetメンバーシップが正しく機能するために必要な特定の最小レプリカ数を下回る状態になる可能性があります。これにより、StatefulSetが利用できなくなる可能性があります。 -一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスタが完全に健全であることが確実な場合にのみスケーリングを実行してください。 +一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスターが完全に健全であることが確実な場合にのみスケーリングを実行してください。 diff --git a/content/ja/docs/tutorials/clusters/apparmor.md b/content/ja/docs/tutorials/clusters/apparmor.md index 24592fea4e..8bff80407c 100644 --- a/content/ja/docs/tutorials/clusters/apparmor.md +++ b/content/ja/docs/tutorials/clusters/apparmor.md @@ -289,7 +289,7 @@ PodのステータスはPendingとなり、`Pod Cannot enforce AppArmor: profile ### PodSecurityPolicyを使用したプロファイルの制限 -PodSecurityPolicy extensionが有効になっている場合、クラスタ全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。 +PodSecurityPolicy extensionが有効になっている場合、クラスター全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。 ``` --enable-admission-plugins=PodSecurityPolicy[,others...] @@ -306,7 +306,7 @@ defaultProfileNameオプションには、何も指定されなかった場合 ### AppArmorの無効化 -クラスタ上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。 +クラスター上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。 ``` --feature-gates=AppArmor=false @@ -316,7 +316,7 @@ defaultProfileNameオプションには、何も指定されなかった場合 ### AppArmorを使用するKubernetes v1.4にアップグレードする -クラスタをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。 +クラスターをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。 ### 一般利用可能(General Availability)への更新パス {#upgrade-path-to-general-availability} diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 39e4d36c97..da62df1fa6 100644 --- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -55,7 +55,7 @@ card: MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。 -多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。 +多くのクラスター環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。 PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。