API キーを使用するイメージ・プル・シークレットのトラブルシューティング

ポッド構成で、API キーを使用するイメージ・プル・シークレットが使用されている場合、API キー資格情報が正しくセットアップされていることを確認します。

以下の手順では、API キーにサービス ID の資格情報が保管されていることを想定しています。 個別ユーザーの API キーを使用するイメージ・プル・シークレットをセットアップしている場合、ユーザーの IBM Cloud IAM 許可および資格情報を確認する必要があります。

1. 説明を確認して、イメージ・プル・シークレット用に API キーで使用されるサービス ID を見つけます。 クラスターを使用して作成されるサービス ID は cluster-<cluster_ID> という名前で、default Kubernetes 名前空間で使用されます。 別の Kubernetes 名前空間にアクセスする、または 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 <namespace>                                                                                                                                         false
   

2. サービス 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>
   

3. イメージ・プル・シークレットの資格情報が有効かどうかを確認します。

   1. イメージ・プル・シークレットの構成を取得します。 ポッドが default ネームスペースにない場合は、 -n オプションを指定してください。

      kubectl get secret <image_pull_secret_name> -o yaml [-n <namespace>]
      

   2. 出力で、.dockerconfigjson フィールドの base64 エンコード値をコピーします。

      apiVersion: v1
      kind: Secret
      data:
        .dockerconfigjson: eyJyZWdp...==
      ...
      

   3. 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>"}}}
      

   4. イメージ・プル・シークレットのリージョンレジストリー・ドメイン・ネームと、コンテナー・イメージで指定されているドメイン・ネームを比較します。 デフォルトで、新規クラスターでは default Kubernetes 名前空間で実行されるコンテナーのリージョン・レジストリー・ドメイン・ネームごとにイメージ・プル・シークレットが作成されます。 ただし、デフォルト設定を変更した場合や、別の Kubernetes 名前空間を使用している場合は、リージョン・レジストリーのイメージ・プル・シークレットがない可能性があります。 リージョン・レジストリー・ドメイン・ネームのイメージ・プル・シークレットをコピーします。

   5. イメージ・プル・シークレットの username と password を使用して、ローカル・マシンからレジストリーにログインします。 ログインできない場合は、サービス ID を修正する必要がある場合があります。

      docker login -u iamapikey -p <password_string> <region>.icr.io
      

      1. default Kubernetes 名前空間で実行されるコンテナーのクラスター・サービス ID、IBM Cloud IAM ポリシー、API キー、およびイメージ・プル・シークレットを再作成します。

         ibmcloud ks cluster pull-secret apply --cluster <cluster_name_or_ID>
         

      2. default Kubernetes 名前空間のデプロイメントを再作成します。 それでも許可エラー・メッセージが表示される場合は、新規イメージ・プル・シークレットでステップ 1 から 5 を繰り返します。 それでもログインできない場合は、IBM Cloud サポートの Case をオープンしてください。

   6. ログインに成功した場合は、イメージをローカルにプルします。 コマンドが access denied エラーで失敗する場合は、レジストリー・アカウントがクラスターとは別の IBM Cloud アカウントにあります。 他のアカウントにあるイメージにアクセスするためのイメージ・プル・シークレットを作成します。 ローカルマシンに画像を取得できるのであれば、APIキーの権限は適切ですが、クラスター内のAPI設定に誤りがあります。

      docker pull <region>icr.io/<namespace>/<image>:<tag>
      

   7. プル・シークレットが、デプロイメントから直接参照されているか、デプロイメントで使用しているサービス・アカウントから参照されていることを確認します。 それでも問題が解決しない場合には、サポートにお問い合わせください。