Skip to content

Commit adada78

Browse files
author
tamilselvan1102
committed
[ja] fix term "proxy" variations
1 parent 2525fba commit adada78

File tree

23 files changed

+86
-86
lines changed

23 files changed

+86
-86
lines changed

content/ja/docs/concepts/architecture/control-plane-node-communication.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ APIサーバーに接続したい{{< glossary_tooltip text="Pod" term_id="pod" >
3131

3232
コントロールプレーン(APIサーバー)からノードへの主要な通信経路は2つあります。
3333
1つ目は、APIサーバーからクラスター内の各ノードで実行される{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}プロセスへの通信経路です。
34-
2つ目は、APIサーバーの _プロキシー_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
34+
2つ目は、APIサーバーの _プロキシ_ 機能を介した、APIサーバーから任意のノード、Pod、またはサービスへの通信経路です。
3535

3636
### APIサーバーからkubeletへの通信 {#api-server-to-kubelet}
3737

@@ -67,7 +67,7 @@ SSHトンネルは現在非推奨であるため、自分が何をしている
6767

6868
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
6969

70-
SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシーを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
70+
SSHトンネルの代替として、Konnectivityサービスは、コントロールプレーンからクラスターへの通信に、TCPレベルのプロキシを提供します。Konnectivityサービスは、コントロールプレーンネットワークのKonnectivityサーバーと、ノードネットワークのKonnectivityエージェントの、2つの部分で構成されています。
7171
Konnectivityエージェントは、Konnectivityサーバーへの接続を開始し、ネットワーク接続を維持します。
7272
Konnectivityサービスを有効にすると、コントロールプレーンからノードへのトラフィックは、すべてこの接続を経由するようになります。
7373

content/ja/docs/concepts/cluster-administration/proxies.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,47 +1,47 @@
11
---
2-
title: Kubernetesのプロキシー
2+
title: Kubernetesのプロキシ
33
content_type: concept
44
weight: 100
55
---
66

77
<!-- overview -->
8-
このページではKubernetesと併用されるプロキシーについて説明します
8+
このページではKubernetesと併用されるプロキシについて説明します
99

1010

1111
<!-- body -->
1212

13-
## プロキシー
13+
## プロキシ
1414

15-
Kubernetesを使用する際に、いくつかのプロキシーを使用する場面があります
15+
Kubernetesを使用する際に、いくつかのプロキシを使用する場面があります
1616

17-
1. [kubectlのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
17+
1. [kubectlのプロキシ](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
1818

1919
- ユーザーのデスクトップ上かPod内で稼働します
20-
- ローカルホストのアドレスからKubernetes apiserverへのプロキシーを行います
21-
- クライアントからプロキシー間ではHTTPを使用します
22-
- プロキシーからapiserverへはHTTPSを使用します
20+
- ローカルホストのアドレスからKubernetes apiserverへのプロキシを行います
21+
- クライアントからプロキシ間ではHTTPを使用します
22+
- プロキシからapiserverへはHTTPSを使用します
2323
- apiserverの場所を示します
2424
- 認証用のヘッダーを追加します
2525

26-
1. [apiserverのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
26+
1. [apiserverのプロキシ](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
2727

2828
- apiserver内で動作する踏み台となります
2929
- これがなければ到達不可能であるクラスターIPへ、クラスターの外部からのユーザーを接続します
3030
- apiserverのプロセス内で稼働します
31-
- クライアントからプロキシー間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
32-
- プロキシーからターゲット間では利用可能な情報を使用して、プロキシーによって選択されたHTTPかHTTPSのいずれかを使用します
31+
- クライアントからプロキシ間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
32+
- プロキシからターゲット間では利用可能な情報を使用して、プロキシによって選択されたHTTPかHTTPSのいずれかを使用します
3333
- Node、Pod、Serviceへ到達するのに使えます
3434
- Serviceへ到達するときは負荷分散を行います
3535

3636
1. [kube proxy](/ja/docs/concepts/services-networking/service/#ips-and-vips):
3737

3838
- 各ノード上で稼働します
39-
- UDP、TCP、SCTPをプロキシーします
39+
- UDP、TCP、SCTPをプロキシします
4040
- HTTPを解釈しません
4141
- 負荷分散機能を提供します
4242
- Serviceへ到達させるためのみに使用されます
4343

44-
1. apiserverの前段にあるプロキシー/ロードバランサー:
44+
1. apiserverの前段にあるプロキシ/ロードバランサー:
4545

4646
- 実際に存在するかどうかと実装はクラスターごとに異なります(例: nginx)
4747
- 全てのクライアントと、1つ以上のapiserverの間に位置します
@@ -59,7 +59,7 @@ Kubernetesユーザーのほとんどは、最初の2つのタイプ以外に心
5959

6060
## リダイレクトの要求
6161

62-
プロキシーはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。
62+
プロキシはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。
6363

6464

6565

content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -108,9 +108,9 @@ kubectl config view
108108

109109
kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。
110110

111-
## プロキシー
111+
## プロキシ
112112

113-
kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシーを使用するように`kubectl`を設定することができます。
113+
kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシを使用するように`kubectl`を設定することができます。
114114

115115
```yaml
116116
apiVersion: v1

content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ weight: 20
1616

1717
## アグリゲーションレイヤー
1818

19-
アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシーします
19+
アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、_APIService_ オブジェクトを追加します。それを追加すると、アグリゲーションレイヤーはAPIパス(例、`/apis/myextension.mycompany.io/v1/…`)への全てのアクセスを、登録されたAPIServiceにプロキシします
2020

2121
APIServiceを実装する最も一般的な方法は、クラスター内で実行されるPodで*拡張APIサーバー* を実行することです。クラスター内のリソース管理に拡張APIサーバーを使用している場合、拡張APIサーバー("extension-apiserver"とも呼ばれます)は通常、1つ以上の{{< glossary_tooltip text="コントローラー" term_id="controller" >}}とペアになっています。apiserver-builderライブラリは、拡張APIサーバーと関連するコントローラーの両方にスケルトンを提供します。
2222

content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,7 @@ Kubernetesは、クラスターへカスタムリソースを追加する2つの
9999

100100
Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
101101

102-
アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
102+
アグリゲートAPIは、プロキシとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
103103

104104
CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。
105105

content/ja/docs/concepts/services-networking/connect-applications-service.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -138,7 +138,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m
138138

139139
クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
140140
Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
141-
この仕組みに興味がある場合は、[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
141+
この仕組みに興味がある場合は、[サービスプロキシ](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
142142

143143
## Serviceにアクセスする
144144

content/ja/docs/concepts/services-networking/ingress-controllers.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -40,11 +40,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン
4040
* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。
4141
* [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。
4242
* [Kusk Gateway](https://kusk.kubeshop.io/)[Envoy](https://www.envoyproxy.io)をベースにしたOpenAPIドリブンのIngressコントローラーです。
43-
* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシーとして)動作します。
43+
* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。
4444
* [ngrok Kubernetes Ingress Controller](https://github.com/ngrok/kubernetes-ingress-controller)は、[ngrok platform](https://ngrok.com)を使用するK8sサービスに安全な公開アクセスを追加するためのオープンソースコントローラーです。
4545
* [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)を管理することができます。
4646
* [Pomerium Ingress Controller](https://www.pomerium.com/docs/k8s/ingress.html)[Pomerium](https://pomerium.com/)ベースのものであり、コンテキストを考慮したアクセスポリシーを提供します。
47-
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです
47+
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシです
4848
* [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://traefik.io/traefik/) proxy向けのIngressコントローラーです。
4949
* [Tyk Operator](https://github.com/TykTechnologies/tyk-operator)はAPI管理機能をIngressに持たせるためにCustom ResourcesでAPIを拡張します。Tyk OperatorはOpen Source Tyk GatewayとTyk Cloudコントロールプレーンで動作します。
5050
* [Voyager](https://voyagermesh.com)は、[HAProxy](https://www.haproxy.org/#desc)向けのIngressコントローラーです。

content/ja/docs/concepts/services-networking/ingress.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -53,7 +53,7 @@ Ingressリソースの最小構成の例は以下のとおりです。
5353

5454
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コントローラーのドキュメントを確認してください。
5555

56-
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
56+
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
5757

5858
`ingressClassName`が省略された場合、[デフォルトのIngressClass](#default-ingress-class)を定義する必要があります。
5959

0 commit comments

Comments
 (0)