セルフホストランナーのトラブルシューティング

ディスク容量の不足により Pod へのボリュームマウントが失敗する旨の警告が表示され、タスクは Preparing Environment ステップで停滞します。

十分なディスク容量があることを確認してください。

Pod がホストされているノードのメモリが不足すると、タスクが失敗し、 Runner Instance Failure という名前の失敗ステップと以下のメッセージが表示されます。

kubectl を使って Kubernetes で表示すると、Pod のステータスは OOMKilled になります。 タスク Pod の設定を使って、ジョブ自体のメモリーの割り当てを管理できます。

ノードがいっぱいになると、 node.kuberenetes.io/disk-pressure という Taint が表示され、新しいタスク Pod をスケジュールできなくなります。 この Pod のすべての有効なノードに同じ Taint またはスケジュールを妨げるその他の条件があると、そのタスク Pod は Taint されていない有効なノードが使用できるようになるまで保留状態になります。 これにより、このジョブが UI の Preparing Environment ステップで停滞しているように見えます。

この状態にならないよう、クラスタをより効果的にスケーリングるする必要があります。

コンテナランナーが別の Node でホストされている場合、タイムアウトになるまでタスクは CircleCI UI で実行されているように見えます。 kubectl も、クラスタの liveness Probe のタイムアウトになるまで、Pod を実行中として表示します。 Podは terminating 状態になり、そのまま停滞します。 この時点で、Pod を強制的に削除する必要があります。 強制的に削除しないと、kubectl がハングする場合があります。

イメージに指定されたエントリポイントが無効な場合、タスクが失敗し、エラーになります。

コンテナランナーとクラウド版 CircleCI では、 プライマリコンテナ のエントリポイントの設定方法が異なります。 クラウドの場合、プライマリコンテナのエントリポイントは com.circleci.preserve-entrypoint=true LABEL 指示を使用して保持されていない限り無視されます ( エントリポイントの追加 を参照)。 一方コンテナランナーの場合、常にシェル (/bin/sh) がデフォルト設定されるか、ジョブ設定でエントリポイントが指定されている場合はそれが設定されます。

注: エントリポイントは、失敗せずに最後まで実行される必要があります。 失敗した場合、またはビルドの途中で停止した場合は、ビルドも停止します。 ログまたはビルドステータスにアクセスする必要がある場合は、エントリポイントの代わりにバックグラウンドステップを使用します。

このエラーを減らすには、 エントリポイントの追加 に関するドキュメントに沿ってエントリポイントを指定します。 カスタムビルドされた Docker イメージの使用 に記載されているようにエントリポイントを明示的に設定します。

ジョブのイメージがデプロイされているノードと異なるアーキテクチャを使用している場合、コンテナランナーはエラーになります。

タスク Pod にはエラーステータスも表示されます。 CircleCI UI で失敗したジョブとしてエラーとともにに表示されます。

ジョブを使ってノードに使用されている基盤アーキテクチャをジョブで使用されているイメージのアーキテクチャに合わせて修正する必要があります。

リソースクラスのタスク Pod の設定が誤っている場合、タスクは要求されると失敗します。 UI では、このエラーは Runner Instance Failure ステップに入り、以下のようなメッセージが表示されます。

Kuberenetes クラスタで Pod が一つも作成されていない タスク Pod の設定を、 コンテナランナー に記載されているように修正する必要があります。

コンテナランナーで実行されるジョブで使用するカスタムイメージには Bash が必要です。

もし、「Oops, there was an issue with your infrastructure」というメッセージが表示された場合。 セルフホストランナーのインフラストラクチャが動作していることを確認し、ジョブを再実行してみてください。 それでも問題が解決しない場合は、ジョブのページにある「トラブルシューティングガイド」を参照するか、タスクのライフサイクルステップにコンテンツがない場合（図のような場合）、以下に説明する潜在的な原因を検討する必要があります：

kubectl exec --stdin --tty -n circleci < full pod name > — /bin/sh コマンドを使って Pod に接続し、ping テストを長時間実行することを推奨します。 また、 CircleCI のセルフホストランナーに必要な接続 についてのセクションが含まれる「よく寄せられるご質問」のリンクへの接続を確認することを推奨します。

リソースの使用量を監視できる外部ツールもあります。 Kubernetes のドキュメント をご覧ください。

場合によっては、root で実行できるように、ローンチエージェントの実行権限を更新する必要があります。 以下の 2 つのコマンドを実行してください。

ジョブをキャンセルし、再実行します。 それでもジョブが実行されない場合は、 サポートチケット を送信してください。

CircleCI マシンランナーでは、デバッグのために SSH 接続でジョブを再実行することが可能です。 この機能の使用に関する詳細は、 SSH を使用したデバッグをご覧ください。