change Node expression

content/ja/docs/concepts/configuration/secret.md

@@ -1123,11 +1123,11 @@ Secret APIへのアクセスが必要なアプリケーションは、必要なS
 Secretはそれを使用するPodとは独立に作成されるので、Podを作ったり、参照したり、編集したりするワークフローにおいてSecretが晒されるリスクは軽減されています。
 システムは、可能であればSecretの内容をディスクに書き込まないような、Secretについて追加の考慮も行っています。
 
-SecretはNode上のPodが必要とした場合のみ送られます。
+Secretはノード上のPodが必要とした場合のみ送られます。
 kubeletはSecretがディスクストレージに書き込まれないよう、`tmpfs`に保存します。
 Secretを必要とするPodが削除されると、kubeletはSecretのローカルコピーも同様に削除します。
 
-同一のNodeにいくつかのPodに対する複数のSecretが存在することもあります。
+同一のノードにいくつかのPodに対する複数のSecretが存在することもあります。
 しかし、コンテナから参照できるのはPodが要求したSecretのみです。
 そのため、あるPodが他のPodのためのSecretにアクセスすることはできません。
 
@@ -1154,4 +1154,4 @@ Podに複数のコンテナが含まれることもあります。しかし、Po
  - アプリケーションはボリュームからSecretの値を読み取った後も、その値を保護する必要があります。例えば意図せずログに出力する、信用できない相手に送信するようなことがないようにです。
  - Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。
  - 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。
- 単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているNodeに対してのみSecretを送る機能が計画されています。
+ 単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。