許可および資格情報のエラーのためにクラスターまたはワーカー・ノードを作成または削除できない

クラスタのワーカーノードを管理できず、permissions, credentials, SoftLayer, API keys, role のいずれかのエラーメッセージが表示されます。

パーミッションとクレデンシャルのエラー に関する情報を確認し、関連する手順に従ってください。

不適切なアカウントのエラーのためにワーカー・ノードを作成または削除できない

クラシック・インフラストラクチャー

クラシックな IBM Cloud インフラストラクチャアカウントでは、クラスタのワーカーノードを管理したり、クラスタのワーカーノードを表示したりすることはできません。 ただし、アカウントの他のクラスターは更新、管理できます。

さらに、適切なインフラストラクチャー資格情報を持っていることは確認済みです。

ワーカーノードのステータスに、以下の例のようなエラーメッセージが表示される場合があります。

incorrect account for worker - The 'classic' infrastructure user credentials changed and no longer match the worker node instance infrastructure account.

クラスターが、IBM Cloud Kubernetes Service アカウントとのリンクがなくなったクラシック IBM Cloud インフラストラクチャー・アカウントにプロビジョンされている可能性があります。 そのクラスターは孤立しています。 リソースは別のアカウントにあるため、リソースを変更するためのインフラストラクチャー資格情報がありません。

クラスターがなぜ孤立するのかを理解するために、以下の例の状況について考えてみましょう。

1. あなたは IBM Cloud 従量課金 (PAYG) アカウントを持っています。
2. あなたは Cluster1 という名前のクラスターを作成します。 ワーカー・ノードと他のインフラストラクチャー・リソースは従量課金アカウントに付属するインフラストラクチャー・アカウントにプロビジョンされます。
3. 後で、チームが既存のまたは共有のクラシック IBM Cloud インフラストラクチャー・アカウントを使用していることがわかります。 そこであなたは、ibmcloud ks credential set コマンドを使用して IBM Cloud インフラストラクチャー資格情報を変更し、チーム・アカウントを使用するようにします。
4. あなたは Cluster2 という名前の別のクラスターを作成します。 ワーカー・ノードと他のインフラストラクチャー・リソースが、チームのインフラストラクチャー・アカウントにプロビジョンされます。
5. あなたは Cluster1 でワーカー・ノードの更新、ワーカー・ノードの再ロードが必要なことに気付きますが、ここでは単純にワーカー・ノードを削除することによってクリーンアップしようと考えます。 ただし、Cluster1 は別のインフラストラクチャー・アカウントにプロビジョンされているため、そのインフラストラクチャー・リソースを変更することはできません。Cluster1 は孤立しています。
6. 以下のセクションの解決手順に従いますが、インフラストラクチャー資格情報をチーム・アカウントに戻しません。 Cluster1 は削除できますが、今度は Cluster2 が孤立しています。
7. あなたはインフラストラクチャー資格情報を、Cluster2 を作成したチーム・アカウントに戻します。 これで、もう孤立クラスターはなくなりました。

手順に従ってインフラストラクチャー資格情報を確認し、資格情報エラーが表示される理由を判別してください。

1. コンソールにログインします。

2. アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。.

3. クラスターが現在存在しているリージョンがどのインフラストラクチャー・アカウントを使用してクラスターをプロビジョンしているかを確認します。 REGION を、クラスターが存在する IBM Cloud リージョンに置き換えます。

   ibmcloud ks credential get --region REGION
   

   以下のようなメッセージが表示された場合、アカウントはデフォルトのリンクされたインフラストラクチャー・アカウントを使用します。

   No credentials set for resource group <resource group>.: The user credentials could not be found.
   

4. クラスターをプロビジョンするためにどのインフラストラクチャー・アカウントが使用されたかを確認します。

   1. **「ワーカー・ノード」**タブでワーカー・ノードを選択し、その ID を書き留めます。
   2. メニューを開く をクリックし、 インフラストラクチャ > クラシックインフラストラクチャをクリックします。
   3. インフラストラクチャーのナビゲーション・ペインから**「デバイス」>「デバイス・リスト」**をクリックします。
   4. 先ほど書き留めたワーカー・ノードの ID を検索します。
   5. ワーカー・ノード ID が見つからない場合、ワーカー・ノードはこのインフラストラクチャー・アカウントにプロビジョンされません。 別のインフラストラクチャー・アカウントに切り替えて、もう一度やり直します。

5. インフラストラクチャー・アカウントを比較します。

   • ワーカー・ノードがリンクされているインフラストラクチャー・アカウントに含まれている場合: ibmcloud ks credential unset コマンドを使用して、従量課金アカウントにリンクされているデフォルトのインフラストラクチャー資格情報を使用して再開します。

   • ワーカー・ノードが別のインフラストラクチャー・アカウントに含まれている場合: ibmcloud ks credential set コマンドを使用して、インフラストラクチャー資格情報を、クラスター・ワーカー・ノードがプロビジョンされたアカウント (前のステップで見つけたアカウント) に変更します。

     インフラストラクチャー資格情報にアクセスできなくなった場合は、IBM Cloud サポート Case を開いて、他のインフラストラクチャー・アカウントの管理者の E メール・アドレスを確認できます。 ただし、IBM Cloud サポートが孤立クラスターを削除することはできません。インフラストラクチャー資格情報を取得するには、他のアカウントの管理者に連絡する必要があります。

   • インフラストラクチャアカウントが一致している場合 ：クラスタ内の残りのワーカーノードをチェックし、異なるインフラストラクチャアカウントに割り当てられているものがないか確認します。 クラスタ内の、認証情報問題のあるワーカーノードをチェックしたことを確認してください。 その他のインフラストラクチャー資格情報の一般的な問題を確認します。

6. インフラストラクチャー資格情報が更新されたので、ワーカー・ノードの更新や削除などのブロックされたアクションを再試行し、アクションが成功することを確認します。

7. 同じリージョンおよびリソースに、以前のインフラストラクチャー資格情報を必要とする他のクラスターがある場合は、ステップ 3 を繰り返して、インフラストラクチャー資格情報を以前のアカウントにリセットします。 切り替え後のアカウントとは異なるインフラストラクチャー・アカウントを使用してクラスターを作成した場合、それらのクラスターは孤立化する可能性があります。

   クラスターまたはワーカーのアクションを実行することが必要になるたびにインフラストラクチャー・アカウントを切り替えないで済むようにしたい場合は、 同じインフラストラクチャー・アカウント内のリージョンおよびリソース・グループ内のすべてのクラスターを再作成することを検討してください。 その場合、ワークロードをマイグレーションし、別のインフラストラクチャー・アカウントから古いクラスターを削除します。

エンドポイントのエラーが原因でワーカー・ノードを作成または削除できない

クラスターのワーカー・ノードを管理できません。以下のようなエラー・メッセージを受け取ります。

Worker deploy failed due to network communications failing to master or registry endpoints. Please verify your network setup is allowing traffic from this subnet then attempt a worker replace on this worker

Pending endpoint gateway creation

ワーカー・ノードは、クラスターの仮想プライベート・エンドポイント (VPE) を介して Kubernetes マスターと通信できます。

VPC には、VPE ゲートウェイ・リソースがクラスターごとに 1 つ作成されます。 クラスターの VPE ゲートウェイが VPC に正常に作成されなかった場合や、VPE ゲートウェイが VPC から削除された場合、または VPE 用の予約 IP アドレスが VPC のサブネットから削除された場合、ワーカー・ノードは Kubernetes マスターとの接続を失います。

ワーカー・ノードと Kubernetes マスターの間の VPE 接続を再確立します。

1. VPCインフラストラクチャコンソールでクラスタのVPEゲートウェイを確認するには、 VPCダッシュボードの仮想プライベートエンドポイントゲートウェイを開き、 iks-<cluster_ID> という形式のVPEゲートウェイを探します。

   • クラスターのゲートウェイがリストされていない場合は、次のステップに進みます。
   • クラスターのゲートウェイがリストされていても、その状況がStable でない場合は、サポート Case をオープンします。 Case の詳細に、クラスター ID を含めてください。
   • クラスターのゲートウェイがリストされており、その状況がStable である場合、ファイアウォールまたはセキュリティー・グループのルールによって、クラスター・マスターへのワーカー・ノードの通信がブロックされていることがあります。 該当するポートおよび IP アドレスへの発信トラフィックを許可するように、セキュリティー・グループ・ルールを構成してください。

2. クラスター・マスターをリフレッシュします。 VPCにVPEゲートウェイが存在しない場合は、作成され、ワーカーノードが接続されているサブネット上の予約済みIPアドレスへの接続が再確立されます。 クラスターをリフレッシュした後、操作が完了するまで数分待ってください。

   ibmcloud ks cluster master refresh -c <cluster_name_or_ID>
   

3. クラスタのVPEゲートウェイが作成されていることを確認するには、 VPCダッシュボードの仮想プライベートエンドポイントゲートウェイを開き、 iks-<cluster_ID> という形式のVPEゲートウェイを探します。

4. クラスター・マスターのリフレッシュ後もワーカー・ノードを管理できない場合は、アクセスできないワーカー・ノードを置き換えます。

   1. クラスター内のすべてのワーカー・ノードをリストして、置換するワーカー・ノードの名前をメモします。

      kubectl get nodes
      

      このコマンドで返される名前は、ワーカー・ノードに割り当てられたプライベート IP アドレスです。 ibmcloud ks worker ls --cluster <cluster_name_or_ID> コマンドを実行して、同じプライベート IP アドレスを持つワーカー・ノードを探すと、ワーカー・ノードに関する詳細情報を参照できます。

   2. ワーカー・ノードを置換します。 置換プロセスの一部として、ワーカー・ノードで実行されているポッドが排出され、クラスター内の他のワーカー・ノードにスケジュール変更されます。 また、このワーカー・ノードは閉鎖されます。つまり、これ以降のポッドのスケジューリングに使用できないものとしてマークされます。 ibmcloud ks worker ls --cluster <cluster_name_or_ID> コマンドから返されたワーカー・ノード ID を使用します。

      ibmcloud ks worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
      

   3. ワーカー・ノードが置換されたことを確認します。

      ibmcloud ks worker ls --cluster <cluster_name_or_ID>
      

有料アカウントのエラーまたはワンタイム・パスワードのエラーが原因でワーカー・ノードを作成/削除できない

クラシック・インフラストラクチャー

クラスタのワーカーノードを管理できず、以下の例のようなエラーメッセージが表示されます。

Unable to connect to the IBM Cloud account. Ensure that you have a paid account.

can't authenticate the infrastructure user: Time-based One Time Password authentication is required to log in with this user.

IBM Cloud アカウントで、従量課金 (PAYG) アカウントを介して自動的にリンクされた独自のインフラストラクチャーを使用しています。

しかし、アカウント管理者は時間ベースのワンタイム・パスコード (TOTP) オプションを有効にしていて、ユーザーがログインするときに時間ベースのワンタイム・パスコード (TOTP) を求めるプロンプトが出されるようになっています。 このタイプの多要素認証 (MFA) はアカウント・ベースであり、アカウントに対するすべてのアクセスに影響を及ぼします。 TOTP MFA も、IBM Cloud Kubernetes Service が IBM Cloud インフラストラクチャーに対して呼び出しを行うために必要とするアクセスに影響を及ぼします。 TOTP がアカウントに対して有効になっている場合、IBM Cloud Kubernetes Service でクラスターとワーカー・ノードを作成して管理することはできません。

IBM Cloud アカウント所有者またはアカウント管理者は、以下のいずれかのアクションを実行する必要があります。

• アカウントで TOTP を無効にし、IBM Cloud Kubernetes Service で自動的にリンクされたインフラストラクチャーの資格情報を引き続き使用します。
• 引き続き TOTP を使用しますが、IBM Cloud Kubernetes Service が IBM Cloud インフラストラクチャー API を直接呼び出すために使用できるインフラストラクチャー API キーを作成します。