change "projected" to Japanese

This commit is contained in:
Kobayashi Daisuke
2022-01-25 13:21:41 +09:00
parent c60045bbdb
commit efcf33c4a9
@@ -1,20 +1,20 @@
---
title: Projectedボリューム
title: 投影ボリューム
content_type: concept
weight: 21 # just after persistent volumes
---
<!-- overview -->
このドキュメントでは、Kubernetesの*projectedボリューム*について説明します。[ボリューム](/docs/concepts/storage/volumes/)に精通していることをお勧めします。
このドキュメントでは、Kubernetesの*投影ボリューム*について説明します。[ボリューム](/docs/concepts/storage/volumes/)に精通していることをお勧めします。
<!-- body -->
## 概要
ボリュームは、いくつかの既存の`projected`ボリュームソースを同じディレクトリにマップします。
ボリュームは、いくつかの既存の`投影`ボリュームソースを同じディレクトリにマップします。
現在、次のタイプのボリュームソースをproject(投影)できます。
現在、次のタイプのボリュームソースを投影できます。
* [`secret`](/docs/concepts/storage/volumes/#secret)
* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi)
@@ -31,7 +31,7 @@ weight: 21 # just after persistent volumes
{{< codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" >}}
projectedボリュームソースは、specの`sources`にリストされています。パラメータは、2つの例外を除いてほぼ同じです。
投影ボリュームソースは、specの`sources`にリストされています。パラメータは、2つの例外を除いてほぼ同じです。
* secretについて、ConfigMapの命名と一致するように`secretName`フィールドが`name`に変更されました。
* `defaultMode`はprojectedレベルでのみ指定でき、各ボリュームソースには指定できません。ただし上に示したように、個々の投影ごとに`mode`を明示的に設定できます。
@@ -40,36 +40,36 @@ weight: 21 # just after persistent volumes
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
例のPodには、挿入されたサービスアカウントトークンを含むprojectedボリュームがあります。このトークンはPodのコンテナがKubernetes APIサーバーにアクセスするために使用できます。この`audience`フィールドにはトークンのオーディエンスが含まれています。トークンの受信者は、トークンのオーディエンスで指定された識別子で自分自身を識別する必要があります。そうでない場合はトークンを拒否する必要があります。このフィールドはオプションで、デフォルトではAPIサーバーの識別子が指定されます。
例のPodには、挿入されたサービスアカウントトークンを含む投影ボリュームがあります。このトークンはPodのコンテナがKubernetes APIサーバーにアクセスするために使用できます。この`audience`フィールドにはトークンのオーディエンスが含まれています。トークンの受信者は、トークンのオーディエンスで指定された識別子で自分自身を識別する必要があります。そうでない場合はトークンを拒否する必要があります。このフィールドはオプションで、デフォルトではAPIサーバーの識別子が指定されます。
`expirationSeconds`はサービスアカウントトークンが有効であると予想される期間です。
デフォルトは1時間で、最低でも10分(600秒)でなければなりません。
管理者は、APIサーバーに`--service-account-max-token-expiration`オプションを指定することで、その最大値を制限することも可能です。
`path`フィールドは、projectedボリュームのマウントポイントへの相対パスを指定します。
`path`フィールドは、投影ボリュームのマウントポイントへの相対パスを指定します。
{{< note >}}
projectedボリュームソースを[`subPath`](/docs/concepts/storage/volumes/#using-subpath)ボリュームマウントとして使用しているコンテナは、それらのボリュームソースの更新を受信しません。
投影ボリュームソースを[`subPath`](/docs/concepts/storage/volumes/#using-subpath)ボリュームマウントとして使用しているコンテナは、それらのボリュームソースの更新を受信しません。
{{< /note >}}
## SecurityContextの相互作用
[projectedサービスアカウントのボリューム拡張でのファイル権限処理の提案]((https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#token-volume-projection))により、正しい所有者権限が設定されたprojectedファイルが導入されました。
[サービスアカウントの投影ボリューム拡張でのファイル権限処理の提案]((https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#token-volume-projection))により、正しい所有者権限が設定された投影ファイルが導入されました。
### Linux
projectedボリュームがあり、Podの[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)に`RunAsUser`が設定されているLinux Podでは、projectedファイルには、コンテナユーザーの所有権を含む正しい所有権が設定されます。
投影ボリュームがあり、Podの[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)に`RunAsUser`が設定されているLinux Podでは、投影されたファイルには、コンテナユーザーの所有権を含む正しい所有権が設定されます。
### Windows
projectedボリュームを持ち、Podの`SecurityContext``RunAsUsername`を設定したWindows Podでは、Windowsのユーザーアカウント管理方法により所有権が強制されません。
投影ボリュームを持ち、Podの`SecurityContext``RunAsUsername`を設定したWindows Podでは、Windowsのユーザーアカウント管理方法により所有権が強制されません。
Windowsは、ローカルユーザーとグループアカウントをセキュリティアカウントマネージャー(SAM)と呼ばれるデータベースファイルに保存し、管理します。
各コンテナはSAMデータベースの独自のインスタンスを維持し、コンテナの実行中はホストはそのインスタンスを見ることができません。
Windowsコンテナは、OSのユーザーモード部分をホストから分離して実行するように設計されており、そのため仮想SAMデータベースを維持することになります。
そのため、ホスト上で動作するkubeletには、仮想化されたコンテナアカウントのホストファイル所有権を動的に設定する機能がありません。
ホストマシン上のファイルをコンテナと共有する場合は、`C:\`以外の独自のボリュームマウントに配置することをお勧めします。
デフォルトでは、projectedボリュームファイルの例に示されているように、projectedファイルには次の所有権があります。
デフォルトでは、投影ボリュームファイルの例に示されているように、投影されたファイルには次の所有権があります。
```powershell
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List