From 60ba92c12f51a24a66577263a1d20a8909d5513a Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Wed, 12 Aug 2020 11:52:35 +0900 Subject: [PATCH 01/10] completed translating --- content/ja/docs/concepts/containers/images.md | 273 ++++++++++++++++++ 1 file changed, 273 insertions(+) create mode 100644 content/ja/docs/concepts/containers/images.md diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md new file mode 100644 index 0000000000..f731078866 --- /dev/null +++ b/content/ja/docs/concepts/containers/images.md @@ -0,0 +1,273 @@ +--- +reviewers: +title: イメージ +content_type: concept +weight: 10 +--- + + +コンテナイメージはアプリケーションと依存関係のあるすべてソフトウェアをカプセル化したバイナリデータを表します。コンテナイメージはスタンドアロンで実行可能なソフトウェアをひとつにまとめ、ランタイム環境に関する想定を明確に定義しています。 + +アプリケーションのコンテナイメージを作成し、一般的には{{< glossary_tooltip text="Pod" term_id="pod" >}}で参照する前にレジストリへPushします。 + +このページではコンテナイメージのコンセプト概要を説明します。 + + + +## イメージの名称 + +コンテナイメージは、`pause`、`example/mycontainer`、または`kube-apiserver`のような名前が通常つけられます。 +イメージにはレジストリのホスト名も含めることができ（例：`fictional.registry.example/imagename`）、さらにポート番号も含めることが可能です（例：`fictional.registry.example:10443/imagename`）。 + +レジストリのホスト名を指定しない場合は、KubernetesはDockerパブリックレジストリを意味していると見なします。 + +イメージ名の後に、_タグ_ を追加することができます（`docker`や`podman`のようなコマンドを利用した場合と同様）。 +タグによって同じイメージの異なるバージョンを識別できます。 + +イメージタグは大文字と小文字、数値、アンダースコア(`_`)、ピリオド(`.`)とマイナス(`-`)で構成されます。 +イメージタグでは区切り記号(`_`、`-`、`.`)を指定できる追加ルールがあります。 +タグを指定しない場合は、Kubernetesは`latest`タグを指定したと見なします。 + +{{< caution >}} +本番環境でコンテナをデプロイする場合は、`latest`タグの使用を避けるべきです。 +実行中のイメージのバージョンを追跡するのが難しく、機能しているバージョンへのロールバックがより困難になるためです。 + +かわりに、`v1.42.0`のような特定できるタグを指定してください。 +{{< /caution >}} + + +## イメージの更新 + +デフォルトのpull policyでは、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}はイメージを既に取得済みの場合、イメージのPullをスキップさせる`IfNotPresent`が設定されています。 +常にPullを強制させたい場合は、次のいずれかの方法で実行できます。 + +- コンテナの`imagePullPolicy`に`Always`を設定します。 +- `imagePullPolicy`を省略し、使用するイメージに`:latest`タグを使用します。 +- `imagePullPolicy`と使用するイメージのタグを省略します。 +- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)アドミッションコントローラーを有効にします。 + +`imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。 + +## マニュフェストを使ったマルチアーキテクチャイメージ + +コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニュフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 +マニュフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニュフェストを参照できます。マニュフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 + +Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つを名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニュフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。 + +## プライベートレジストリを使用する方法 + +プライベートリポジトリではイメージを読み込む為にキーが必要になる場合があります。 +認証情報はいくつかの方法で提供できます。 + + - プライベートレジストリへの認証をNodeに設定する + - すべてのPodがプライベートレジストリを読み取ることができます。 + - クラスター管理者によるNodeの設定が必要です。 + - 事前にPullされたイメージ + - すべてのPodがNode上にキャッシュされたイメージを利用できます。 + - セットアップするためにはすべてのNodeに対するrootアクセスが必要です。 + - PodでImagePullSecretsを指定する + - キーを提供したPodのみがプライベートレジストリへアクセスできる。 + - ベンダー固有またはローカルエクステンション + - カスタムNode構成を使っている場合、あなた(または、あなたのクラウドプロバイダー)はコンテナレジストリーへの認証の仕組みを組み込むことができます。 + +これらのオプションについて、以下で詳しく説明します。 + +### プライベートレジストリへの認証をNodeに設定する + +Node上でDockerを実行している場合、プライベートコンテナリポジトリへの認証をDockerコンテナランタイムに設定できます。 + +Node構成を制御できる場合は、この方法が適しています。 + +{{< note >}} +KubernetesはDocker構成の`auths`と`HttpHeaders`セクションのみをサポートしています。 +Docker認証情報ヘルパー(`credHelpers`または`credsStore`)はサポートされていません。 +{{< /note >}} + + +Dockerは、`$HOME/.dockercfg`または`$HOME/.docker/config.json`ファイルの中に、プライベートレジストリのキーを保持します。 +下記リストの検索パスに同じファイルを配置した場合、kubeletはイメージをPullする時に認証情報プロバイダーとして利用します。 + + +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` + +{{< note >}} +kubeletプロセスの環境では、明示的に`HOME=/root`を設定する必要がある場合があります。 +{{< /note >}} + +以下は、プライベートレジストリを使用する為にNodeを構成する推奨の手順です。この例では、デスクトップ/ノートPC上で実行します。 + + 1. 使用したい認証情報のセット毎に `docker login [server]`を実行します。これであなたのPC上の`$HOME/.docker/config.json`が更新されます。 + 1. 使用したい認証情報が含まれているかを確認するため、エディターで`$HOME/.docker/config.json`を見ます。 + 1. Nodeの一覧を取得します。例: + - 名称が必要な場合: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - IPアドレスを取得したい場合: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` + 1. ローカルの`.docker/config.json`を上記の検索パスのいずれかにコピーします。 + - 例えば、これでテストします: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + +{{< note >}} +本番環境用クラスターでは、構成管理ツールを使用して必要なすべてのNodeに設定を反映してください。 +{{< /note >}} + +プライベートイメージを使用するPodを作成して確認します。 +例: + +```shell +kubectl apply -f - <}} +Node構成を制御できる場合、この方法が適しています。 +クラウドプロバイダーがNodeを管理し自動的に設定を置き換える場合は、確実に機能できません。 +{{< /note >}} + +デフォルトでは、kubeletは指定されたレジストリからそれぞれのイメージをPullしようとします。 +しかしながら、コンテナの`imagePullPolicy`プロパティに`IfNotPresent`や`Never`が設定されている場合、ローカルのイメージが使用されます。(それぞれに対して、優先的またはか排他的に) + +レジストリ認証の代替として事前にPullしたイメージを利用したい場合、クラスターのすべてのNodeが同じ事前にPullしたイメージを持っていることを確認する必要があります。 + +特定のイメージをあらかじめロードしておくことは高速化やプライベートレジストリへの認証の代替として利用することができます。 + +すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。 + +### PodでImagePullSecretsを指定する + +{{< note >}} +この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。 +{{< /note >}} + +KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。 + +#### Docker ConfigでSecretを作成する。 + +適切な大文字の値を置き換えて、次のコマンドを実行します。 + +```shell +kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL +``` + +既にDocker認証情報ファイルを持っている場合は、上記のコマンドの代わりに、認証情報ファイルをKubernetes {{< glossary_tooltip text="Secrets" term_id="secret" >}}としてインポートすることができます。 +[既存のDocker認証情報に基づいてSecretを作成する](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) で、この設定方法を説明します. + +これは複数のプライベートコンテナレジストリを使用している場合に特に有効です。`kubectl create secret docker-registry`はひとつのプライベートリポジトリーにのみ機能するSecretを作成するからです。 + +{{< note >}} +Podは自分自身のNamespace内にあるimage pull secretsのみが参照可能であるため、この作業はNemespace毎に1回行う必要があります。 +{{< /note >}} + +#### PodのimagePullSecretsを参照する方法 + +これで、`imagePullSecrets`セクションをPod定義へ追加することでSecretを参照するPodを作成できます。 + +例: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +これは、プライベートレジストリを使用する各Podで行う必要があります。 + +ただし、この項目の設定は[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)リソースの中でimagePullSecretsを指定することで自動化することができます。 + +詳細の手順は、[ImagePullSecretsをService Accountに追加する](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)をクリックしてください。 + +これを各Nodeの`.docker/config.json`に組み合わせて利用できます。認証情報はマージされます。 + +## ユースケース + +プライベートレジストリを設定するためのソリューションはいくつかあります。ここでは、いくつかの一般的なユースケースと推奨される解決方法を示します。 + +1. クラスターに独自仕様でない(例えば、オープンソース)イメージだけを実行します。イメージを非公開にする必要がありません。 + - Docker hubのパブリックイメージを利用します。 + - 設定は不要です。 + - クラウドプロバイダーによっては、可用性の向上とイメージをPullする時間を短くする為に、自動的にキャッシュやミラーされたパプリックイメージを提供します。 +1. 社外には非公開の必要があるが、すべてのクラスター利用者には見せてよい独自仕様のイメージをクラスターで実行しています。 + - ホストされたプライペートな [Dockerレジストリ](https://docs.docker.com/registry/)を使用する. + - [Docker Hub](https://hub.docker.com/signup)または他の場所の上でホストされている場合があります。 + - 上記のように各Node上のdocker/config.jsonを手動で構成します。 + - または、オープンな読み取りアクセスを許可したファイヤーウォールの背後で内部向けプライベートレジストリを実行します。 + - Kubernetesの設定は必要ありません。 + - イメージへのアクセスを制御できるホストされたコンテナイメージレジストリサービスを利用します。 + - Nodeを手動設定するよりもクラスターのオートスケーリングのほうがうまく機能します。 + - また、Node設定変更を自由にできないクラスターでは`imagePullSecrets`を使用します。 +1. 独自仕様のイメージを含むクラスターで、いくつかは厳格なアクセス制御が必要である。 + - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認してください。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性があります。 + - 機密のデータはイメージに含めてしまうのではなく、"Secret"リソースに移行してください。 +1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである。 + - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認してください。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性があります。 + - 認証が必要なプライベートレジストリを実行します。 + - それぞれのテナントでレジストリ認証を生成し、Secretへ設定し、各テナントのNamespaceに追加します。 + - テナントは、Secretを各NamespaceのimagePullSecretsへ追加します。 + +複数のレジストリへのアクセスが必要な場合、それぞれのレジストリ毎にひとつのSecretを作成する事ができます。 +Kubeletは複数の`imagePullSecrets`を単一の仮想的な`.docker/config.json`にマージします。 + +## {{% heading "whatsnext" %}} + +* [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を読みます。 From 1c06e3763cbe036c9fe7bc285ebcf4bba9d49296 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Wed, 12 Aug 2020 17:03:31 +0900 Subject: [PATCH 02/10] fix list-centence and concept --- content/ja/docs/concepts/containers/images.md | 76 +++++++++---------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index f731078866..75bb46a154 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -10,7 +10,7 @@ weight: 10 アプリケーションのコンテナイメージを作成し、一般的には{{< glossary_tooltip text="Pod" term_id="pod" >}}で参照する前にレジストリへPushします。 -このページではコンテナイメージのコンセプト概要を説明します。 +このページではコンテナイメージの概要を説明します。 @@ -41,10 +41,10 @@ weight: 10 デフォルトのpull policyでは、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}はイメージを既に取得済みの場合、イメージのPullをスキップさせる`IfNotPresent`が設定されています。 常にPullを強制させたい場合は、次のいずれかの方法で実行できます。 -- コンテナの`imagePullPolicy`に`Always`を設定します。 -- `imagePullPolicy`を省略し、使用するイメージに`:latest`タグを使用します。 -- `imagePullPolicy`と使用するイメージのタグを省略します。 -- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)アドミッションコントローラーを有効にします。 +- コンテナの`imagePullPolicy`に`Always`を設定する +- `imagePullPolicy`を省略し、使用するイメージに`:latest`タグを使用する +- `imagePullPolicy`と使用するイメージのタグを省略する +- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)アドミッションコントローラーを有効にする `imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。 @@ -61,15 +61,15 @@ Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィッ 認証情報はいくつかの方法で提供できます。 - プライベートレジストリへの認証をNodeに設定する - - すべてのPodがプライベートレジストリを読み取ることができます。 - - クラスター管理者によるNodeの設定が必要です。 + - すべてのPodがプライベートレジストリを読み取ることができる + - クラスター管理者によるNodeの設定が必要 - 事前にPullされたイメージ - - すべてのPodがNode上にキャッシュされたイメージを利用できます。 - - セットアップするためにはすべてのNodeに対するrootアクセスが必要です。 + - すべてのPodがNode上にキャッシュされたイメージを利用できる + - セットアップするためにはすべてのNodeに対するrootアクセスが必要 - PodでImagePullSecretsを指定する - - キーを提供したPodのみがプライベートレジストリへアクセスできる。 + - キーを提供したPodのみがプライベートレジストリへアクセスできる - ベンダー固有またはローカルエクステンション - - カスタムNode構成を使っている場合、あなた(または、あなたのクラウドプロバイダー)はコンテナレジストリーへの認証の仕組みを組み込むことができます。 + - カスタムNode構成を使っている場合、あなた(または、あなたのクラウドプロバイダー)はコンテナレジストリーへの認証の仕組みを組み込むことができる これらのオプションについて、以下で詳しく説明します。 @@ -104,19 +104,19 @@ kubeletプロセスの環境では、明示的に`HOME=/root`を設定する必 以下は、プライベートレジストリを使用する為にNodeを構成する推奨の手順です。この例では、デスクトップ/ノートPC上で実行します。 - 1. 使用したい認証情報のセット毎に `docker login [server]`を実行します。これであなたのPC上の`$HOME/.docker/config.json`が更新されます。 - 1. 使用したい認証情報が含まれているかを確認するため、エディターで`$HOME/.docker/config.json`を見ます。 - 1. Nodeの一覧を取得します。例: + 1. 使用したい認証情報のセット毎に `docker login [server]`を実行する。これであなたのPC上の`$HOME/.docker/config.json`が更新される + 1. 使用したい認証情報が含まれているかを確認するため、エディターで`$HOME/.docker/config.json`を見る + 1. Nodeの一覧を取得 例: - 名称が必要な場合: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` - IPアドレスを取得したい場合: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` - 1. ローカルの`.docker/config.json`を上記の検索パスのいずれかにコピーします。 - - 例えば、これでテストします: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + 1. ローカルの`.docker/config.json`を上記の検索パスのいずれかにコピーする + - 例えば、これでテスト実施: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` {{< note >}} 本番環境用クラスターでは、構成管理ツールを使用して必要なすべてのNodeに設定を反映してください。 {{< /note >}} -プライベートイメージを使用するPodを作成して確認します。 +プライベートイメージを使用するPodを作成し確認します。 例: ```shell @@ -243,27 +243,27 @@ EOF プライベートレジストリを設定するためのソリューションはいくつかあります。ここでは、いくつかの一般的なユースケースと推奨される解決方法を示します。 -1. クラスターに独自仕様でない(例えば、オープンソース)イメージだけを実行します。イメージを非公開にする必要がありません。 - - Docker hubのパブリックイメージを利用します。 - - 設定は不要です。 - - クラウドプロバイダーによっては、可用性の向上とイメージをPullする時間を短くする為に、自動的にキャッシュやミラーされたパプリックイメージを提供します。 -1. 社外には非公開の必要があるが、すべてのクラスター利用者には見せてよい独自仕様のイメージをクラスターで実行しています。 - - ホストされたプライペートな [Dockerレジストリ](https://docs.docker.com/registry/)を使用する. - - [Docker Hub](https://hub.docker.com/signup)または他の場所の上でホストされている場合があります。 - - 上記のように各Node上のdocker/config.jsonを手動で構成します。 - - または、オープンな読み取りアクセスを許可したファイヤーウォールの背後で内部向けプライベートレジストリを実行します。 - - Kubernetesの設定は必要ありません。 - - イメージへのアクセスを制御できるホストされたコンテナイメージレジストリサービスを利用します。 - - Nodeを手動設定するよりもクラスターのオートスケーリングのほうがうまく機能します。 - - また、Node設定変更を自由にできないクラスターでは`imagePullSecrets`を使用します。 -1. 独自仕様のイメージを含むクラスターで、いくつかは厳格なアクセス制御が必要である。 - - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認してください。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性があります。 - - 機密のデータはイメージに含めてしまうのではなく、"Secret"リソースに移行してください。 -1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである。 - - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認してください。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性があります。 - - 認証が必要なプライベートレジストリを実行します。 - - それぞれのテナントでレジストリ認証を生成し、Secretへ設定し、各テナントのNamespaceに追加します。 - - テナントは、Secretを各NamespaceのimagePullSecretsへ追加します。 +1. クラスターに独自仕様でない(例えば、オープンソース)イメージだけを実行する。イメージを非公開にする必要がない + - Docker hubのパブリックイメージを利用する + - 設定は不要 + - クラウドプロバイダーによっては、可用性の向上とイメージをPullする時間を短くする為に、自動的にキャッシュやミラーされたパプリックイメージが提供される +1. 社外には非公開の必要があるが、すべてのクラスター利用者には見せてよい独自仕様のイメージをクラスターで実行している + - ホストされたプライペートな [Dockerレジストリ](https://docs.docker.com/registry/)を使用 + - [Docker Hub](https://hub.docker.com/signup)または他の場所の上でホストされている場合がある + - 上記のように各Node上のdocker/config.jsonを手動で構成する + - または、オープンな読み取りアクセスを許可したファイヤーウォールの背後で内部向けプライベートレジストリを実行する + - Kubernetesの設定は必要ない + - イメージへのアクセスを制御できるホストされたコンテナイメージレジストリサービスを利用する + - Nodeを手動設定するよりもクラスターのオートスケーリングのほうがうまく機能する + - また、Node設定変更を自由にできないクラスターでは`imagePullSecrets`を使用する +1. 独自仕様のイメージを含むクラスターで、いくつかは厳格なアクセス制御が必要である + - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認する必要あり。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性がある + - 機密のデータはイメージに含めてしまうのではなく、"Secret"リソースに移行する +1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである + - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認する必要あり。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性がある + - 認証が必要なプライベートレジストリを実行する + - それぞれのテナントでレジストリ認証を生成し、Secretへ設定し、各テナントのNamespaceに追加する + - テナントは、Secretを各NamespaceのimagePullSecretsへ追加する 複数のレジストリへのアクセスが必要な場合、それぞれのレジストリ毎にひとつのSecretを作成する事ができます。 Kubeletは複数の`imagePullSecrets`を単一の仮想的な`.docker/config.json`にマージします。 From 4e418f3e8120d2a3736ea3585a439b61bc506810 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Mon, 24 Aug 2020 20:32:20 +0900 Subject: [PATCH 03/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 75bb46a154..91855c12bd 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -57,7 +57,7 @@ Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィッ ## プライベートレジストリを使用する方法 -プライベートリポジトリではイメージを読み込む為にキーが必要になる場合があります。 +プライベートレジストリではイメージを読み込む為にキーが必要になる場合があります。 認証情報はいくつかの方法で提供できます。 - プライベートレジストリへの認証をNodeに設定する From cb2500c56c43491c9a79af08dab97bff807f22cf Mon Sep 17 00:00:00 2001 From: takaf04 Date: Mon, 24 Aug 2020 20:32:44 +0900 Subject: [PATCH 04/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 91855c12bd..5c5bc46576 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -258,7 +258,7 @@ EOF - また、Node設定変更を自由にできないクラスターでは`imagePullSecrets`を使用する 1. 独自仕様のイメージを含むクラスターで、いくつかは厳格なアクセス制御が必要である - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認する必要あり。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性がある - - 機密のデータはイメージに含めてしまうのではなく、"Secret"リソースに移行する + - 機密データはイメージに含めてしまうのではなく、"Secret"リソースに移行する 1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認する必要あり。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性がある - 認証が必要なプライベートレジストリを実行する From 7ce319f687a001318d7d57343c61715ce5872714 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Mon, 24 Aug 2020 20:33:31 +0900 Subject: [PATCH 05/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 5c5bc46576..e41697c972 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -257,7 +257,7 @@ EOF - Nodeを手動設定するよりもクラスターのオートスケーリングのほうがうまく機能する - また、Node設定変更を自由にできないクラスターでは`imagePullSecrets`を使用する 1. 独自仕様のイメージを含むクラスターで、いくつかは厳格なアクセス制御が必要である - - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認する必要あり。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性がある + - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認する必要がある。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性がある - 機密データはイメージに含めてしまうのではなく、"Secret"リソースに移行する 1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認する必要あり。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性がある From 85eb1853e20cf207ac542001f9cf831eadbc79df Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Mon, 24 Aug 2020 22:22:40 +0900 Subject: [PATCH 06/10] recheck --- content/ja/docs/concepts/containers/images.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index e41697c972..a12276a263 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -69,13 +69,13 @@ Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィッ - PodでImagePullSecretsを指定する - キーを提供したPodのみがプライベートレジストリへアクセスできる - ベンダー固有またはローカルエクステンション - - カスタムNode構成を使っている場合、あなた(または、あなたのクラウドプロバイダー)はコンテナレジストリーへの認証の仕組みを組み込むことができる + - カスタムNode構成を使っている場合、あなた(または、あなたのクラウドプロバイダー)はコンテナレジストリへの認証の仕組みを組み込むことができる これらのオプションについて、以下で詳しく説明します。 ### プライベートレジストリへの認証をNodeに設定する -Node上でDockerを実行している場合、プライベートコンテナリポジトリへの認証をDockerコンテナランタイムに設定できます。 +Node上でDockerを実行している場合、プライベートコンテナレジストリへの認証をDockerコンテナランタイムに設定できます。 Node構成を制御できる場合は、この方法が適しています。 @@ -110,7 +110,7 @@ kubeletプロセスの環境では、明示的に`HOME=/root`を設定する必 - 名称が必要な場合: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` - IPアドレスを取得したい場合: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 1. ローカルの`.docker/config.json`を上記の検索パスのいずれかにコピーする - - 例えば、これでテスト実施: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + - 例えば、これでテストを実施する: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` {{< note >}} 本番環境用クラスターでは、構成管理ツールを使用して必要なすべてのNodeに設定を反映してください。 @@ -161,7 +161,7 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' そうでない場合、Podは一部のNodeで実行できますが他のNodeでは実行に失敗します。 例えば、Nodeのオートスケールを使用している場合、各インスタンスのテンプレートに`.docker/config.json`が含まれている、またはこのファイルが含まれているドライブをマウントする必要があります。 -プライベートレジストリーキーを`.docker/config.json`に追加した時点で、すべてのPodがプライベートレジストリのイメージに読み取りアクセス権も持つようになります。 +プライベートレジストリキーを`.docker/config.json`に追加した時点で、すべてのPodがプライベートレジストリのイメージに読み取りアクセス権も持つようになります。 ### 事前にPullしたイメージ @@ -171,7 +171,7 @@ Node構成を制御できる場合、この方法が適しています。 {{< /note >}} デフォルトでは、kubeletは指定されたレジストリからそれぞれのイメージをPullしようとします。 -しかしながら、コンテナの`imagePullPolicy`プロパティに`IfNotPresent`や`Never`が設定されている場合、ローカルのイメージが使用されます。(それぞれに対して、優先的またはか排他的に) +また一方では、コンテナの`imagePullPolicy`プロパティに`IfNotPresent`や`Never`が設定されている場合、ローカルのイメージが使用されます。(それぞれに対して、優先的またはか排他的に) レジストリ認証の代替として事前にPullしたイメージを利用したい場合、クラスターのすべてのNodeが同じ事前にPullしたイメージを持っていることを確認する必要があります。 @@ -187,7 +187,7 @@ Node構成を制御できる場合、この方法が適しています。 KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。 -#### Docker ConfigでSecretを作成する。 +#### Docker Configを利用してSecretを作成する。 適切な大文字の値を置き換えて、次のコマンドを実行します。 @@ -198,7 +198,7 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER 既にDocker認証情報ファイルを持っている場合は、上記のコマンドの代わりに、認証情報ファイルをKubernetes {{< glossary_tooltip text="Secrets" term_id="secret" >}}としてインポートすることができます。 [既存のDocker認証情報に基づいてSecretを作成する](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) で、この設定方法を説明します. -これは複数のプライベートコンテナレジストリを使用している場合に特に有効です。`kubectl create secret docker-registry`はひとつのプライベートリポジトリーにのみ機能するSecretを作成するからです。 +これは複数のプライベートコンテナレジストリを使用している場合に特に有効です。`kubectl create secret docker-registry`はひとつのプライベートレジストリにのみ機能するSecretを作成するからです。 {{< note >}} Podは自分自身のNamespace内にあるimage pull secretsのみが参照可能であるため、この作業はNemespace毎に1回行う必要があります。 @@ -245,7 +245,7 @@ EOF 1. クラスターに独自仕様でない(例えば、オープンソース)イメージだけを実行する。イメージを非公開にする必要がない - Docker hubのパブリックイメージを利用する - - 設定は不要 + - 設定は必要ない - クラウドプロバイダーによっては、可用性の向上とイメージをPullする時間を短くする為に、自動的にキャッシュやミラーされたパプリックイメージが提供される 1. 社外には非公開の必要があるが、すべてのクラスター利用者には見せてよい独自仕様のイメージをクラスターで実行している - ホストされたプライペートな [Dockerレジストリ](https://docs.docker.com/registry/)を使用 @@ -260,7 +260,7 @@ EOF - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認する必要がある。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性がある - 機密データはイメージに含めてしまうのではなく、"Secret"リソースに移行する 1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである - - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認する必要あり。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性がある + - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認する必要がある。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性がある - 認証が必要なプライベートレジストリを実行する - それぞれのテナントでレジストリ認証を生成し、Secretへ設定し、各テナントのNamespaceに追加する - テナントは、Secretを各NamespaceのimagePullSecretsへ追加する From 53f1a8a7b14d50efa3a17f5a7a7686a3eab5ad1c Mon Sep 17 00:00:00 2001 From: takaf04 Date: Tue, 25 Aug 2020 21:13:44 +0900 Subject: [PATCH 07/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index a12276a263..06233366cc 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -48,7 +48,7 @@ weight: 10 `imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。 -## マニュフェストを使ったマルチアーキテクチャイメージ +## マニフェストを使ったマルチアーキテクチャイメージ コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニュフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 マニュフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニュフェストを参照できます。マニュフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 From 3f6a7a86053cf5c2a8bc745f3a7ae86fdad6ff20 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Tue, 25 Aug 2020 21:13:55 +0900 Subject: [PATCH 08/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 06233366cc..80d03492d9 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -50,7 +50,7 @@ weight: 10 ## マニフェストを使ったマルチアーキテクチャイメージ -コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニュフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 +コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 マニュフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニュフェストを参照できます。マニュフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つを名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニュフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。 From 659f9a05cf47ee57dd2a060e45ad72fa2ea48d32 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Tue, 25 Aug 2020 21:14:03 +0900 Subject: [PATCH 09/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 80d03492d9..56fe05cc5d 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -51,7 +51,7 @@ weight: 10 ## マニフェストを使ったマルチアーキテクチャイメージ コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 -マニュフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニュフェストを参照できます。マニュフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 +マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つを名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニュフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。 From fabe7b67d53f22bd19b34b2374e8ca19136bf250 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Tue, 25 Aug 2020 21:14:28 +0900 Subject: [PATCH 10/10] Update content/ja/docs/concepts/containers/images.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 56fe05cc5d..0ad4459d79 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -53,7 +53,7 @@ weight: 10 コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 -Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つを名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニュフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。 +Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つ名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。 ## プライベートレジストリを使用する方法