Cloud Run for Anthos の既知の問題

このページでは、Cloud Run for Anthos の既知の問題の一覧を示します。

また、公開バグトラッカーで既存の問題を確認したり、新しい問題を報告したりすることも可能です。

MutatingWebhookConfiguration がないため、RevisionMissing でサービスが停止しています

Webhook 構成がないため、新しいサービスまたは新しいサービス リビジョンの作成が「RevisionMissing」の状態のまま停止する場合があります。これを確認するには、次のコマンドを実行します。

kubectl get mutatingwebhookconfiguration webhook.serving.knative.dev

この場合、次の結果が返されます。

kmutatingwebhookconfigurations.admissionregistration.k8s.io "webhook.serving.knative.dev" not found`

一時的な回避策

この問題は、新しいバージョンで修正されるまで、次の手順で解決できます。

  1. Webhook Pod を再起動して MutatingWebhookConfiguration を再作成します。

    kubectl delete pod -n knative-serving -lapp=webhook
    kubectl get mutatingwebhookconfiguration --watch
  2. コントローラを再起動します。

    kubectl delete pod -n gke-system -listio=pilot
    kubectl delete pod -n knative-serving -lapp=controller
  3. RevisionMissing の問題があるサービスごとに新しいリビジョンをデプロイします。

    gcloud run services update SERVICE --update-labels client.knative.dev/nonce=""

    SERVICE は、サービスの名前に置き換えます。

  4. サービスの新しいバージョンをデプロイするときに同じ問題が発生する場合は、必要に応じて上記の手順を繰り返します。

ゾーンクラスタ

Cloud Run for Anthos on Google Cloud でゾーンクラスタを使用する場合、クラスタのメンテナンス中はコントロール プレーンにアクセスできません。

この期間中、Cloud Run for Anthos on Google Cloud は想定どおりに機能しない可能性があります。たとえば、そのクラスタにデプロイされているサービスに関して、以下のような問題が起きることがあります。

  • Cloud Console や gcloud SDK 経由で表示されない
  • 削除または更新できない
  • 自動的にインスタンスをスケーリングしないが、既存のインスタンスでは引き続き新しいリクエストが処理される

これらの問題を回避するために、リージョン クラスタを使用できます。これにより、高可用性コントロール プレーンが確保されます。

デフォルトのメモリ制限は、コマンドラインでは適用されません

コマンドラインを使用してデプロイする場合は、--memory 引数が使用されない限り、デプロイされるサービスにメモリ制限はありません。これにより、ポッドが実行されているノードで使用可能なメモリ量をサービスが消費し、予期しない副作用が生じる可能性があります。

UI を使用してデプロイする場合は、値がオーバーライドされない限り、デフォルト値の 256M が使用されます。

この問題を回避するには、Cloud Run on GKE でサービスをデプロイする名前空間のデフォルトのメモリ制限を定義します。詳細については、Kubernetes ドキュメントのデフォルトのメモリ制限の構成をご覧ください。

デフォルトの CPU 制限が有効になっていません

コマンドラインや Console を使用してデプロイする場合、サービスで使用できる CPU の量は定義されません。これにより、実行中のノードで使用可能なすべての CPU をサービスが消費し、予期しない副作用が生じる可能性があります。

この問題を回避するには、Cloud Run on GKE でサービスをデプロイする名前空間のデフォルトの CPU 制限を定義します。詳細については、Kubernetes ドキュメントのデフォルトの CPU 制限の構成をご覧ください。

注: Cloud Run for Anthos on Google Cloud でデプロイされたサービスでは、400m CPU がリクエストされます。これは、クラスタ ノード上のサービスのインスタンスをスケジュールするために使用されます。

Istio 1.0 limitations

Cloud Run for Anthos on Google Cloud は、ネットワーキングに Istio 1.0 を使用します。これにより、クラスタ内に存在するサービスとリビジョンの数が制限されます。これらの制限事項の詳細については、Istio 1.0 のパフォーマンスとスケーラビリティをご覧ください。

Cloud Run for Anthos on Google Cloud を使用して、同じクラスタに 150 以上のサービスまたは 300 個以上のアクティブ リビジョンをデプロイすることはできません。

コンテナ内の読み取り/書き込みポイントの内容が常に空である

コンテナが /var/log にファイルやフォルダ(/var/log/nginx など)を作成した場合、そのコンテナを Cloud Run for Anthos on Google Cloud で実行しても、これらのファイルまたはフォルダは表示されません。空の読み取り/書き込みボリュームが /var/log にマウントされており、元のコンテナのコンテンツが表示されないためです。

サービスが /var/log のサブディレクトリに書き込む必要がある場合は、フォルダにファイルを書き込む前に、ランタイム時にそのフォルダが存在することを確認する必要があります。コンテナ イメージからそのフォルダが存在すると想定することはできません。

GKE 1.17 にアップグレードしたクラスタでカスタム ドメインのマッピングが失敗する

カスタム ドメイン マッピングを使用する Cloud Run for Anthos クラスタに既知の問題があります。このようなクラスタが GKE バージョン 1.15 または 1.16 から GKE バージョン 1.17 にアップグレードされると、新しいサービスのデプロイはすべて失敗します。

クラスタにカスタム ドメイン マッピングがある場合は、GKE バージョン 1.17 にアップグレードしないでください。

回避策

クラスタを GKE バージョン 1.17 にアップグレードしてサービスのデプロイで問題が発生した場合は、DomainMapping によって生成された VirtualService を削除する必要があります。これは、新しいコントローラと互換性がないためです。これを削除すると、コントローラは対応する VirtualService を再作成し、サービスのデプロイに関する問題を解決します。

次のコマンドを実行して VirtualService を削除します。VirtualService の名前は、DomainMappings と同じです。例: foo.example.com

  1. 次のコマンドを実行して、すべての DomainMappings を一覧表示します。

    kubectl get domainmapping --all-namespaces
    
  2. 次のコマンドを実行して、指定した VirtualService を削除します。

    kubectl delete vs your-domain-mapping-name -n your-domain-mapping-namespace