chore(ja): unify cluster katakana notation

Author: Okabe-Junya

content/ja/blog/_posts/2024/consistent-read-from-cache.md

@@ -41,7 +41,7 @@ Watchキャッシュはクラスターの状態のスナップショットを保
 以上のようにして、データをフィルタリングするリクエストをキャッシュから処理できるようになり、etcdから読み取る必要のあるメタデータは最小限に抑えられます。
 
 
-**重要な注意点:** この機能を利用するには、Kubernetesクラスタでetcdバージョン3.4.31以降または3.5.13以降を実行している必要があります。
+**重要な注意点:** この機能を利用するには、Kubernetesクラスターでetcdバージョン3.4.31以降または3.5.13以降を実行している必要があります。
 古いバージョンのetcdを使用している場合、etcdから直接整合性のある読み込みを行う方式に自動で切り替わります。
 
 ### 体感できるパフォーマンスの向上
@@ -54,7 +54,7 @@ Watchキャッシュはクラスターの状態のスナップショットを保
 * **スケーラビリティの向上:** etcdの負荷軽減により、コントロールプレーンはパフォーマンスを犠牲にすることなくより多くのリクエストを処理できるようになるため、 数千ものノードとPodを持つような大規模なクラスターでは、最も大きなメリットが得られます。
 
 
-**5,000ノードのスケーラビリティテスト結果:** 5,000ノードのクラスタで行われた最近のスケーラビリティテストでは、キャッシュからの整合性のある読み込みを有効にすることで、以下のような目覚ましい改善が見られました。
+**5,000ノードのスケーラビリティテスト結果:** 5,000ノードのクラスターで行われた最近のスケーラビリティテストでは、キャッシュからの整合性のある読み込みを有効にすることで、以下のような目覚ましい改善が見られました。
 
 * kube-apiserverのCPU使用率が **30%削減**
 * etcdのCPU使用率が **25%削減**

content/ja/blog/_posts/2024/k8s-upstream-training-japan-spotlight/index.md

@@ -109,15 +109,15 @@ k8sは非常に大きなプロジェクトなので、コントリビューシ
 
 **Junya:** Kubernetes周りの機能改善や開発とは具体的にどのようなものですか？
 
-**Yoshiki:** PipeCDはKubernetesのGitOpsやProgressive Deliveryをサポートしていて、それらの機能開発などです。直近だと、マルチクラスタ上へのデプロイを効率化するための機能開発を進めているところです。
+**Yoshiki:** PipeCDはKubernetesのGitOpsやProgressive Deliveryをサポートしていて、それらの機能開発などです。直近だと、マルチクラスター上へのデプロイを効率化するための機能開発を進めているところです。
 
 **Junya:** OSSコントリビューションを行うなかで、難しかったことはありますか？
 
 **Yoshiki:** 機能の汎用性を維持しつつ、ユーザーのユースケースを満たすように開発を進めることです。社内SaaSを運用する中で機能要望をいただいた際には、もちろん課題を解決するためにまずは機能追加を検討します。一方で、PipeCDはOSSとしてより多くのユーザーに使ってもらうことも考えて行きたいです。なので、あるユースケースをもとに別のユースケースとしても使えるかどうかを考え、ソフトウェアとして汎用性をもたせるように意識しています。
 
 **Junya:** 今後の目標を教えてください！
 
-**Yoshiki:** PipeCDの機能拡張に力を入れていきたいと考えています。PipeCDは現在One CD for All のスローガンのもと開発を進めています。先程お伝えした通り、k8s、AWS ECS、Lambda、Cloud Run、Terraform の5種類に対応していますが、これ以外にもプラットフォームは存在しますし、今後も新たなプラットフォームが台頭してくるかもしれません。そこで、PipeCDは現在ユーザーが独自に拡張できるようにプラグイン機構の開発を進めています。それに力を入れていきたいですね。また、k8sのマルチクラスタデプロイ向けの機能開発も進めているところで、これからもよりインパクトのあるコントリビューションをしていきたいと考えてます。
+**Yoshiki:** PipeCDの機能拡張に力を入れていきたいと考えています。PipeCDは現在One CD for All のスローガンのもと開発を進めています。先程お伝えした通り、k8s、AWS ECS、Lambda、Cloud Run、Terraform の5種類に対応していますが、これ以外にもプラットフォームは存在しますし、今後も新たなプラットフォームが台頭してくるかもしれません。そこで、PipeCDは現在ユーザーが独自に拡張できるようにプラグイン機構の開発を進めています。それに力を入れていきたいですね。また、k8sのマルチクラスターデプロイ向けの機能開発も進めているところで、これからもよりインパクトのあるコントリビューションをしていきたいと考えてます。
 
 **Junya:** ありがとうございました！
 

content/ja/blog/_posts/2024/kubernetes-v1-31-release.md

@@ -59,7 +59,7 @@ Kubernetesのロードバランサーに関する一般的な課題の1つに、
 この機能では、kube-proxyに新たな仕組みを導入し、`type: LoadBalancer`と`externalTrafficPolicy: Cluster`を設定したサービスで公開される終了予定のNodeに対して、ロードバランサーが接続をスムーズに切り替えられるようにしています。
 また、クラウドプロバイダーとKubernetesのロードバランサー実装における推奨プラクティスも確立しました。
 
-この機能を利用するには、kube-proxyがクラスタ上でデフォルトのサービスプロキシとして動作し、ロードバランサーが接続の切り替えをサポートしている必要があります。
+この機能を利用するには、kube-proxyがクラスター上でデフォルトのサービスプロキシとして動作し、ロードバランサーが接続の切り替えをサポートしている必要があります。
 特別な設定は不要で、v1.30からkube-proxyにデフォルトで組み込まれており、v1.31で正式にGAとなりました。
 
 詳しくは、[仮想IPとサービスプロキシのドキュメント](/docs/reference/networking/virtual-ips/#external-traffic-policy)をご覧ください。
@@ -91,7 +91,7 @@ v1.31では、nftablesバックエンドがベータとして登場しました
 
 nftables APIは、iptables APIの次世代版として開発され、より高いパフォーマンスと拡張性を提供します。
 `nftables`プロキシモードは、`iptables`モードと比べてサービスエンドポイントの変更をより迅速かつ効率的に処理できます。
-また、カーネル内でのパケット処理も効率化されています(ただし、この効果は数万のサービスを持つ大規模クラスタでより顕著になります)。
+また、カーネル内でのパケット処理も効率化されています(ただし、この効果は数万のサービスを持つ大規模クラスターでより顕著になります)。
 
 Kubernetes v1.31の時点では、`nftables`モードはまだ新しい機能のため、すべてのネットワークプラグインとの互換性が確認されているわけではありません。
 お使いのネットワークプラグインのドキュメントで対応状況を確認してください。
@@ -131,7 +131,7 @@ Kubernetesクラスターには、IPアドレスを使用する複数のコン
 NodeとPodのIP範囲は、それぞれインフラストラクチャやネットワークプラグインに依存するため、動的に変更できます。
 しかし、サービスのIP範囲は、クラスター作成時にkube-apiserverのハードコードされたフラグとして定義されていました。
 長期間運用されているクラスターや大規模なクラスターでは、管理者が割り当てられたサービスCIDR範囲を拡張、縮小、あるいは完全に置き換える必要があり、IPアドレスの枯渇が問題となっていました。
-これらの操作は正式にサポートされておらず、複雑で繊細なメンテナンス作業を通じて行われ、しばしばクラスタのダウンタイムを引き起こしていました。
+これらの操作は正式にサポートされておらず、複雑で繊細なメンテナンス作業を通じて行われ、しばしばクラスターのダウンタイムを引き起こしていました。
 この新機能により、ユーザーとクラスター管理者はダウンタイムなしでサービスCIDR範囲を動的に変更できるようになります。
 
 この機能の詳細については、[仮想IPとサービスプロキシ](/docs/reference/networking/virtual-ips/#ip-address-objects)のドキュメントページをご覧ください。
@@ -167,7 +167,7 @@ _これは、v1.31のリリースでアルファとして導入された主な
 
 Kubernetes v1.31では、動的リソース割り当て(DRA)APIとその設計が更新されました。
 この更新の主な焦点は構造化パラメーターにあります。
-これにより、リソース情報とリクエストがKubernetesとクライアントに対して透明になり、クラスタのオートスケーリングなどの機能の実装が可能になります。
+これにより、リソース情報とリクエストがKubernetesとクライアントに対して透明になり、クラスターのオートスケーリングなどの機能の実装が可能になります。
 kubeletのDRAサポートも更新され、kubeletとコントロールプレーン間のバージョンの違いに対応できるようになりました。
 構造化パラメーターにより、スケジューラはPodのスケジューリング時にResourceClaimを割り当てます。
 DRAドライバーコントローラによる割り当ては、現在「クラシックDRA」と呼ばれる方法でも引き続きサポートされています。
@@ -213,7 +213,7 @@ CRDフィールドセレクター(これもv1.31でベータに移行)と組み
 ### 匿名APIアクセスへの制限
 
 `AnonymousAuthConfigurableEndpoints`フィーチャーゲートを有効にすることで、ユーザーは認証設定ファイルを使用して、匿名リクエストがアクセスできるエンドポイントを設定できるようになりました。
-これにより、匿名ユーザーにクラスタへの広範なアクセスを与えてしまうようなRBAC設定ミスから、ユーザー自身を守ることができます。
+これにより、匿名ユーザーにクラスターへの広範なアクセスを与えてしまうようなRBAC設定ミスから、ユーザー自身を守ることができます。
 
 この機能は、[SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth)が[KEP #4633](https://github.com/kubernetes/enhancements/issues/4633)の一環として開発しました。
 
@@ -371,7 +371,7 @@ Kubernetes v1.31リリースの詳細については、[リリースノート](h
 
 Kubernetes v1.31は、[GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.31.0)または[Kubernetesダウンロードページ](/ja/releases/download/)からダウンロードできます。
 
-Kubernetesを始めるには、[対話式のチュートリアル](/ja/docs/tutorials/)をチェックするか、[minikube](https://minikube.sigs.k8s.io/)を使用してローカルKubernetesクラスタを実行してください。
+Kubernetesを始めるには、[対話式のチュートリアル](/ja/docs/tutorials/)をチェックするか、[minikube](https://minikube.sigs.k8s.io/)を使用してローカルKubernetesクラスターを実行してください。
 また、[kubeadm](/ja/docs/setup/independent/create-cluster-kubeadm/)を使用して簡単にv1.31をインストールすることもできます。
 
 ## リリースチーム

content/ja/blog/_posts/2024/kubernetes-v1-32-release/index.md

@@ -289,7 +289,7 @@ Kubernetes v1.32リリースの詳細については、[リリースノート](h
 
 Kubernetes v1.32は、[GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.32.0)または[Kubernetesダウンロードページ](/ja/releases/download/)からダウンロードできます。
 
-Kubernetesを始めるには、[対話式のチュートリアル](/ja/docs/tutorials/)をチェックするか、[minikube](https://minikube.sigs.k8s.io/)を使用してローカルKubernetesクラスタを実行してください。
+Kubernetesを始めるには、[対話式のチュートリアル](/ja/docs/tutorials/)をチェックするか、[minikube](https://minikube.sigs.k8s.io/)を使用してローカルKubernetesクラスターを実行してください。
 また、[kubeadm](/ja/docs/setup/independent/create-cluster-kubeadm/)を使用して簡単にv1.32をインストールすることもできます。
 
 ## リリースチーム

content/ja/docs/concepts/configuration/windows-resource-management.md

@@ -49,7 +49,7 @@ Windowsではこれらの値はノードの[allocatable](/docs/tasks/administer-
 
 {{< caution >}}
 ワークロードをデプロイする時に、コンテナにメモリとCPUの制限を設定して下さい。
-これにより、`NodeAllocatable`が減少し、クラスタ全体のスケジューラーがどのPodをどのノードに配置するかの決定に役立ちます。
+これにより、`NodeAllocatable`が減少し、クラスター全体のスケジューラーがどのPodをどのノードに配置するかの決定に役立ちます。
 
 制限なしでPodをスケジューリングするとWindowsノードに過剰にプロビジョニングされ、極端な場合にはノードの健全性が低下する可能性があります。
 {{< /caution >}}

content/ja/docs/concepts/workloads/pods/disruptions.md

@@ -66,7 +66,7 @@ Podは誰か(人やコントローラー)が破壊するか、避けることが
 しかし、クラスター管理者やホスティングプロバイダーが何か追加のサービスを実行して自発的なDisruptionが発生する可能性があります。
 例えば、ノード上のソフトウェアアップデートのロールアウトは自発的なDisruptionの原因となります。
 また、クラスター(ノード)自動スケーリングの実装の中には、ノードのデフラグとコンパクト化のために自発的なDisruptionを伴うものがあります。
-クラスタ管理者やホスティングプロバイダーは、自発的なDisruptionがある場合、どの程度のDisruptionが予想されるかを文書化しているはずです。
+クラスター管理者やホスティングプロバイダーは、自発的なDisruptionがある場合、どの程度のDisruptionが予想されるかを文書化しているはずです。
 Podのspecの中で[PriorityClassesを使用している](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/)場合など、特定の設定オプションによっても自発的(および非自発的)なDisruptionを引き起こす可能性があります。
 
 

content/ja/docs/concepts/workloads/pods/user-namespaces.md

@@ -45,7 +45,7 @@ Linux 6.3でidmapマウントをサポートするポピュラーなファイル
 
 {{< note >}}
 いくつかのOCIランタイムには、LinuxのPodでユーザー名前空間を利用するのに必要なサポートが含まれていません。
-マネージドKubernetesを利用している場合やOCIランタイムをパッケージとしてダウンロードしてセットアップした場合には、クラスタ内のノードがユーザー名前空間をサポートしない可能性があります。
+マネージドKubernetesを利用している場合やOCIランタイムをパッケージとしてダウンロードしてセットアップした場合には、クラスター内のノードがユーザー名前空間をサポートしない可能性があります。
 {{< /note >}}
 
 Kubernetesでユーザー名前空間を利用する際、Podでこの機能を使うためにはCRI{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}} も必要です。
@@ -175,7 +175,7 @@ kubelet:65536:7208960
 
 ユーザー名前空間を有効化したLinuxのPodでは、Kubernetesは[Pod Security Standards](/docs/concepts/security/pod-security-standards)で制御されるアプリケーションの制限を緩和します。
 この挙動はエンドユーザーの早期オプトインを可能にするための`UserNamespacesPodSecurityStandards`[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)で制御することが可能です。
-このフィーチャーゲートを使う場合、クラスタ管理者はユーザー名前空間が全てのノードで有効化されていることを確実にする必要があります。
+このフィーチャーゲートを使う場合、クラスター管理者はユーザー名前空間が全てのノードで有効化されていることを確実にする必要があります。
 
 フィーチャーゲートを有効化した上でユーザー名前空間を使うPodを作成する場合、_Baseline_ないしは_Restricted_Podセキュリティ基準のセキュリティコンテキストが強制されていても、以下のフィールドによる制約がなされません。