web-dev-qa-db-ja.com

GKEk8sクラスターstorage.googleapis.com散発的な名前解決の一時的な失敗

Kubernetesクラスター(GKE)でsnakemakeパイプラインを実行しようとしています。ジョブはGCEVMから開始されています。時々それは機能しますが、ほとんどは機能しません。

私が取ったステップは

gcloud container clusters get-credentials snakemake-k8s-demo
kubectl delete pod $(kubectl get pods | grep snakejob|colprint 1)
snakemake --kubernetes --container-image eu.gcr.io/scailyte-is/snakemake-gsdk --use-conda --default-remote-provider GS --default-remote-prefix xxxxxx-snakemake-test-1 --jobs 2

この最初の試みは非常にうまくいきました。

次に、snakemakeパイプラインによって作成されたファイルを削除し、何も変更せずに同じジョブを再度実行しました。

ジョブは次のエラーメッセージで失敗しました。

HTTPSConnectionPool(Host='storage.googleapis.com', port=443): Max retries exceeded with url: /storage/v1/b/xxxxxxx-snakemake-test-1/o?projection=noAcl (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f3ee35159d0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

Google Cloudステータスダッシュボードによると、Google Cloud Storageに問題はありません。

その後の試行も同じように失敗しました。

解決策のヒントはありがたく受け入れられました。

2
Peter Evans

この問題は、クラスター内通信を許可する適切なファイアウォールルールがないことが原因でした。適切なALLOWルールが作成されると、ポッドがDNSサーバーに到達できたため、当面の問題は解消されました。

私たちのポリシーは、明示的に許可されていない限り、エンドポイント間のすべての通信(VPC内部を含む)を禁止することです。したがって、新しいアドレススペースの新しいクラスターには、適切に機能させるための追加が必要でした。

これは、以前のALLOWルールが適用されなかったときに発生する最後のDENYルールへのログオンを有効にすることで理解できました。

なぜ初めて動作したのかはわかりませんが、メモしなかった違いがあるのではないかと思います。

1
Peter Evans