ImagePullBackOff エラーまたは許可エラーでレジストリーからイメージをプルできないのはなぜですか?
仮想プライベートクラウド クラシック・インフラストラクチャー
IBM Cloud Container Registry からイメージをプルするワークロードをデプロイすると、ポッドが ImagePullBackOff 状況で失敗します。
oc get pods
NAME READY STATUS RESTARTS AGE
<pod_name> 0/1 ImagePullBackOff 0 2m
ポッドに describe を実行すると、以下のような認証エラーが表示されます。
oc describe pod <pod_name>
Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... 401 Unauthorized
...
Failed to pull image "<image>:<tag>" ... Manifest for <image>:<tag> not found
クラスタが 画像のプルシークレットに 格納されている API キーを使用して、クラスタが IBM Cloud Container Registry から画像をプルする権限を付与している、または特定のタグを持つ画像がリポジトリに存在しない。
デフォルトでは、新しいクラスターには、default Red Hat OpenShift プロジェクトにデプロイされたコンテナーの任意のリージョン icr.io レジストリーからイメージをプルできるように、API キーを使用するイメージ・プル・シークレットがあります。
-
デプロイメント YAML ファイルでイメージの名前とタグが正しく使用されていることを確認します。
ibmcloud cr images -
プル・トラフィックとストレージ割り当て量を確認します。 限界に達した場合は、使用済みストレージを解放するか、割り当て量を増やすようにレジストリー管理者に依頼してください。
ibmcloud cr quota -
失敗するポッドのポッド構成ファイルを取得して、
imagePullSecretsセクションを探します。oc get pod <pod_name> -o yaml出力例
... imagePullSecrets: - name: all-icr-io ... -
イメージ・プル・シークレットが 1 つもリストされない場合は、プロジェクトにイメージ・プル・シークレットをセットアップします。
defaultプロジェクトに、使用する各リージョンレジストリーのicr-ioイメージ・プル・シークレットが含まれることを確認します。 プロジェクトにicr-ioシークレットがリストされていない場合は、ibmcloud oc cluster pull-secret apply --cluster <cluster_name_or_ID>コマンドを使用して、defaultプロジェクトにイメージ・プル・シークレットを作成します。oc get secrets -n default | grep "icr-io"- ワークロードをデプロイするプロジェクトに
all-icr-ioイメージ・プル・シークレットをdefaultRed Hat OpenShift プロジェクトからコピーします。. - この Red Hat OpenShift プロジェクトのサービス・アカウントにイメージ・プル・シークレットを追加して、プロジェクト内のすべてのポッドがイメージ・プル・シークレット資格情報を使用できるようにします。
-
イメージ・プル・シークレットがポッドにリストされている場合、IBM Cloud Container Registry にアクセスするために使用する資格情報のタイプを決定します。
- シークレットの名前に
icrが入っている場合は、icr.ioドメイン・ネームで認証する API キーを使用しています。 API キーを使用するイメージ・プル・シークレットのトラブルシューティングに進みます。 - 両方のタイプのシークレットがある場合は、両方の認証方式を使用しています。 今後は、コンテナー・イメージのデプロイメント YAML で
icr.ioドメイン・ネームを使用します。 API キーを使用するイメージ・プル・シークレットのトラブルシューティングに進みます。
- シークレットの名前に
API キーを使用するイメージ・プル・シークレットのトラブルシューティング
ポッド構成で、API キーを使用するイメージ・プル・シークレットが使用されている場合、API キー資格情報が正しくセットアップされていることを確認します。
以下の手順では、API キーにサービス ID の資格情報が保管されていることを想定しています。 個別ユーザーの API キーを使用するイメージ・プル・シークレットをセットアップしている場合、ユーザーの IBM Cloud IAM 許可および資格情報を確認する必要があります。
-
説明を確認して、イメージ・プル・シークレット用に API キーで使用されるサービス ID を見つけます。 クラスターを使用して作成されるサービス ID は
cluster-<cluster_ID>という名前で、defaultRed Hat OpenShift プロジェクトで使用されます。 別の Red Hat OpenShift プロジェクトにアクセスする、または IBM Cloud IAM 許可を変更するなどのために、別のサービス ID を作成した場合は、説明はカスタマイズされています。ibmcloud iam service-ids出力例
UUID Name Created At Last Updated Description Locked ServiceId-aa11... <service_ID_name> 2019-02-01T19:01+0000 2019-02-01T19:01+0000 ID for <cluster_name> false ServiceId-bb22... <service_ID_name> 2019-02-01T19:01+0000 2019-02-01T19:01+0000 Service ID for IBM Cloud Container Registry in Kubernetes cluster <cluster_name> namespace <project> false -
サービス ID に少なくとも IBM Cloud IAM リーダーのサービス・アクセス役割ポリシーが IBM Cloud Container Registry に対して割り当てられていることを確認します。 サービス ID にリーダーのサービス・アクセス役割が割り当てられていない場合は、IAM ポリシーを編集します。 ポリシーが正しい場合は、次のステップに進み、資格情報が有効かどうかを確認してください。
ibmcloud iam service-policies <service_ID_name>出力例
Policy ID: a111a111-b22b-333c-d4dd-e555555555e5 Roles: Reader Resources: Service Name container-registry Service Instance Region Resource Type namespace Resource <registry_namespace> -
イメージ・プル・シークレットの資格情報が有効かどうかを確認します。
-
イメージ・プル・シークレットの構成を取得します。 podが
defaultプロジェクトにない場合は、-nオプションを指定してください。oc get secret <image_pull_secret_name> -o yaml [-n <project>] -
出力で、
.dockerconfigjsonフィールドの base64 エンコード値をコピーします。apiVersion: v1 kind: Secret data: .dockerconfigjson: eyJyZWdp...== ... -
base64 ストリングをデコードします。 例えば、OS X の場合、以下のコマンドを実行できます。
echo -n "<base64_string>" | base64 --decode出力例
{"auths":{"<region>.icr.io":{"username":"iamapikey","password":"<password_string>","email":"<name@abc.com>","auth":"<auth_string>"}}} -
イメージ・プル・シークレットのリージョンレジストリー・ドメイン・ネームと、コンテナー・イメージで指定されているドメイン・ネームを比較します。 デフォルトで、新規クラスターでは
defaultRed Hat OpenShift プロジェクトで実行されるコンテナーのリージョンレジストリー・ドメイン・ネームごとにイメージ・プル・シークレットが作成されます。 ただし、デフォルト設定を変更した場合や、別の Red Hat OpenShift プロジェクトを使用している場合は、リージョンレジストリーのイメージ・プル・シークレットがない可能性があります。 リージョンレジストリー・ドメイン・ネームのイメージ・プル・シークレットをコピーします。 -
イメージ・プル・シークレットの
usernameとpasswordを使用して、ローカル・マシンからレジストリーにログインします。 ログインできない場合は、サービス ID を修正する必要がある場合があります。docker login -u iamapikey -p <password_string> <region>.icr.io- Red Hat OpenShift プロジェクトで実行されるコンテナーのクラスター・サービス ID、
defaultIBM Cloud IAM ポリシー、API キー、およびイメージ・プル・シークレットを再作成します。ibmcloud oc cluster pull-secret apply --cluster <cluster_name_or_ID> defaultRed Hat OpenShift プロジェクトのデプロイメントを再作成します。 それでも許可エラー・メッセージが表示される場合は、新規イメージ・プル・シークレットでステップ 1 から 5 を繰り返します。 それでもログインできない場合は、IBM Cloud サポートの Case をオープンしてください。
- Red Hat OpenShift プロジェクトで実行されるコンテナーのクラスター・サービス ID、
-
ログインに成功した場合は、イメージをローカルにプルします。 コマンドが
access deniedエラーで失敗する場合は、レジストリー・アカウントがクラスターとは別の IBM Cloud アカウントにあります。 他のアカウントにあるイメージにアクセスするためのイメージ・プル・シークレットを作成します。 ローカルマシンに画像を取得できるのであれば、APIキーの権限は適切ですが、クラスター内のAPI設定に問題があります。docker pull <region>icr.io/<namespace>/<image>:<tag> -
プル・シークレットが、デプロイメントから直接参照されているか、デプロイメントで使用しているサービス・アカウントから参照されていることを確認します。 それでも問題が解決しない場合には、サポートにお問い合わせください。
-