サービスはデプロイされるのに、正常状態になりません

ビルドは成功し、新しい pod は起動しますが、デプロイが failed とマークされるか、新しいバージョンがいつまでもトラフィックを受け取りません。

これは何を意味するのか

プラットフォームのヘルスチェック（アプリのポートに対する TCP プローブ）が一度も通らないため、トラフィックが新しい pod に切り替わりません。Lizard は約 30 秒待ってから、デプロイを failed とマークします。すでに稼働していたサービスは以前のバージョンを提供し続けます。初回デプロイの場合は crashed と表示されます。

なぜ起こるのか

アプリが想定されたポートで listen していません。 Lizard は PORT 環境変数（デフォルトのコンテナポートは 3000）を注入し、アプリがそこで到達可能かどうかを確認します。アプリが別のポートにハードコードされているか、まったくバインドしていない場合、ヘルスチェックはいつまでも通りません。よくあるのは Python アプリです: gunicorn と uvicorn は、特に指定しない限り 127.0.0.1 にバインドし、プローブはプロセスの外側から来ます。Pythonアプリホスティングには、各フレームワークで必要な --bind 0.0.0.0:$PORT の行があります。
サービスが誤って worker mode になっています。 containerPort=0 を設定すると、サービスは worker mode になり、ヘルスチェックとロードバランサー登録の両方が完全にスキップされます。HTTP を提供するはずのサービスが誤って containerPort=0 に切り替えられると、デプロイは「成功」するものの何も配信せず、worker mode によって本来の起動問題が表面化せずに隠れてしまいます。

考えられる解決策

現在のポートを確認する

lizard port --service api

これが worker mode を表示する場合、そのサービスには containerPort=0 が設定されています。このサービスが HTTP を提供する想定なら、実際のポートに戻してください:

lizard port 3000 --service api
lizard redeploy --service api

アプリが Lizard の想定どおりの場所で listen していることを確認する

ランタイムログで、起動エラーと、アプリが listen していると報告するアドレスを確認してください。それを、Lizard が PORT としてアプリに渡すサービスのポートと比較します:

lizard logs --service api
lizard port --service api