[ja] fix term "proxy" variations

kubernetes · Feb 6, 2024 · adada78 · adada78
1 parent 2525fba
commit adada78
Show file tree

Hide file tree

Showing 23 changed files with 86 additions and 86 deletions.
diff --git a/content/ja/docs/concepts/architecture/control-plane-node-communication.md b/content/ja/docs/concepts/architecture/control-plane-node-communication.md
@@ -31,7 +31,7 @@ APIサーバーに接続したい{{< glossary_tooltip text="Pod" term_id="pod" >
 
 コントロールプレーン(APIサーバー)からノードへの主要な通信経路は2つあります。
 1つ目は、APIサーバーからクラスター内の各ノードで実行される{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}プロセスへの通信経路です。
-2つ目は、APIサーバーの _プロキシー_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
+2つ目は、APIサーバーの _プロキシ_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
 
 ### APIサーバーからkubeletへの通信 {#api-server-to-kubelet}
 
@@ -67,7 +67,7 @@ SSHトンネルは現在非推奨であるため、自分が何をしている
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシーを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
+SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
 Konnectivityエージェントは、Konnectivityサーバーへの接続を開始し、ネットワーク接続を維持します。
 Konnectivityサービスを有効にすると、コントロールプレーンからノードへのトラフィックは、すべてこの接続を経由するようになります。
 

diff --git a/content/ja/docs/concepts/cluster-administration/proxies.md b/content/ja/docs/concepts/cluster-administration/proxies.md
@@ -1,47 +1,47 @@
 ---
-title: Kubernetesのプロキシー
+title: Kubernetesのプロキシ
 content_type: concept
 weight: 100
 ---
 
 <!-- overview -->
-このページではKubernetesと併用されるプロキシーについて説明します。
+このページではKubernetesと併用されるプロキシについて説明します。
 
 
 <!-- body -->
 
-## プロキシー
+## プロキシ
 
-Kubernetesを使用する際に、いくつかのプロキシーを使用する場面があります。
+Kubernetesを使用する際に、いくつかのプロキシを使用する場面があります。
 
-1. [kubectlのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
+1. [kubectlのプロキシ](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
 
     - ユーザーのデスクトップ上かPod内で稼働します
-    - ローカルホストのアドレスからKubernetes apiserverへのプロキシーを行います
-    - クライアントからプロキシー間ではHTTPを使用します
-    - プロキシーからapiserverへはHTTPSを使用します
+    - ローカルホストのアドレスからKubernetes apiserverへのプロキシを行います
+    - クライアントからプロキシ間ではHTTPを使用します
+    - プロキシからapiserverへはHTTPSを使用します
     - apiserverの場所を示します
     - 認証用のヘッダーを追加します
 
-1. [apiserverのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
+1. [apiserverのプロキシ](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
 
     - apiserver内で動作する踏み台となります
     - これがなければ到達不可能であるクラスターIPへ、クラスターの外部からのユーザーを接続します
     - apiserverのプロセス内で稼働します
-    - クライアントからプロキシー間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
-    - プロキシーからターゲット間では利用可能な情報を使用して、プロキシーによって選択されたHTTPかHTTPSのいずれかを使用します
+    - クライアントからプロキシ間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
+    - プロキシからターゲット間では利用可能な情報を使用して、プロキシによって選択されたHTTPかHTTPSのいずれかを使用します
     - Node、Pod、Serviceへ到達するのに使えます
     - Serviceへ到達するときは負荷分散を行います
 
 1.  [kube proxy](/ja/docs/concepts/services-networking/service/#ips-and-vips):
 
     - 各ノード上で稼働します
-    - UDP、TCP、SCTPをプロキシーします
+    - UDP、TCP、SCTPをプロキシします
     - HTTPを解釈しません
     - 負荷分散機能を提供します
     - Serviceへ到達させるためのみに使用されます
 
-1.  apiserverの前段にあるプロキシー/ロードバランサー:
+1.  apiserverの前段にあるプロキシ/ロードバランサー:
 
     - 実際に存在するかどうかと実装はクラスターごとに異なります(例: nginx)
     - 全てのクライアントと、1つ以上のapiserverの間に位置します
@@ -59,7 +59,7 @@ Kubernetesユーザーのほとんどは、最初の2つのタイプ以外に心
 
 ## リダイレクトの要求
 
-プロキシーはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。
+プロキシはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。
 
 
 

diff --git a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -108,9 +108,9 @@ kubectl config view
 
 kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。
 
-## プロキシー
+## プロキシ
 
-kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシーを使用するように`kubectl`を設定することができます。
+kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシを使用するように`kubectl`を設定することができます。
 
 ```yaml
 apiVersion: v1

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
@@ -16,7 +16,7 @@ weight: 20
 
 ## アグリゲーションレイヤー
 
-アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシーします。
+アグリゲーションレイヤーは、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サーバーと関連するコントローラーの両方にスケルトンを提供します。
 

diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの
 
 Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
 
-アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
+アグリゲートAPIは、プロキシとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
 
 CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。
 

diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md
@@ -138,7 +138,7 @@ my-nginx   10.244.2.5:80,10.244.3.4:80   1m
 
 クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
 Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
-この仕組みに興味がある場合は、[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
+この仕組みに興味がある場合は、[サービスプロキシ](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
 
 ## Serviceにアクセスする
 

diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md
@@ -40,11 +40,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン
 * [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。
 * [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。
 * [Kusk Gateway](https://kusk.kubeshop.io/)は[Envoy](https://www.envoyproxy.io)をベースにしたOpenAPIドリブンのIngressコントローラーです。 
-* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシーとして)動作します。
+* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。
 * [ngrok Kubernetes Ingress Controller](https://github.com/ngrok/kubernetes-ingress-controller)は、[ngrok platform](https://ngrok.com)を使用するK8sサービスに安全な公開アクセスを追加するためのオープンソースコントローラーです。 
 * [OCI Native Ingress Controller](https://github.com/oracle/oci-native-ingress-controller#readme)は、Oracle Cloud Infrastructure用のIngressコントローラーであり、[OCI Load Balancer](https://docs.oracle.com/ja-jp/iaas/Content/Balance/home.htm)を管理することができます。
 * [Pomerium Ingress Controller](https://www.pomerium.com/docs/k8s/ingress.html)は[Pomerium](https://pomerium.com/)ベースのものであり、コンテキストを考慮したアクセスポリシーを提供します。
-* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシです。
 * [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://traefik.io/traefik/) proxy向けのIngressコントローラーです。
 * [Tyk Operator](https://github.com/TykTechnologies/tyk-operator)はAPI管理機能をIngressに持たせるためにCustom ResourcesでAPIを拡張します。Tyk OperatorはOpen Source Tyk GatewayとTyk Cloudコントロールプレーンで動作します。
 * [Voyager](https://voyagermesh.com)は、[HAProxy](https://www.haproxy.org/#desc)向けのIngressコントローラーです。

diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md
@@ -53,7 +53,7 @@ Ingressリソースの最小構成の例は以下のとおりです。
 
 Ingressには`apiVersion`、`kind`、`metadata`や`spec`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/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(S)トラフィックに対してのルールのみサポートしています。
+Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
 
 `ingressClassName`が省略された場合、[デフォルトのIngressClass](#default-ingress-class)を定義する必要があります。