Fix markdown. Rewrite some kanji to hiragana. Make parentheses half-width.

content/ja/docs/concepts/architecture/master-node-communication.md

@@ -6,8 +6,8 @@ weight: 20
 
 <!-- overview -->
 
-本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
-この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
+本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。
+この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
 
 
 
@@ -16,8 +16,8 @@ weight: 20
 
 ## クラスターからマスターへの通信
 
-クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。
-一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。
+クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
+一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。
 
 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
@@ -26,15 +26,15 @@ kubeletのクライアント証明書を自動プロビジョニングする方
 
 APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。
 
-`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。
+`kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。
 
 マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。
 
-その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
+その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
 
 ## マスターからクラスターへの通信
 
-マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。
+マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。
 1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。
 2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。
 
@@ -43,7 +43,7 @@ APIサーバーに接続したいPodは、サービスアカウントを利用
 APIサーバーからkubeletへの接続は以下の目的で使用されます:
 
   * Podのログを取得する
-  * 実行中のPodに（kubectlを通して）接続する
+  * 実行中のPodに(kubectlを通して)接続する
   * kubeletのポート転送機能を提供する
 
 これらの接続は、kubeletのHTTPSエンドポイントで終了します。
@@ -64,7 +64,7 @@ API URL内のノード、Pod、またはサービス名に`https:`を付ける
 ### SSHトンネル
 
 Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。
-この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
+この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
 このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。
 
 SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。