Cloud Run for Anthos の既知の問題

このページには、Cloud Run for Anthos の既知の問題が記載されています。既知のセキュリティ脆弱性については、セキュリティのベスト プラクティスをご覧ください。

また、公開 Issue Tracker で既存の問題の確認や、新しい問題の報告を行うことができます。

トラブルシューティングの方法と一般的なエラーの解決策については、トラブルシューティングもご覧ください。

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 でゾーンクラスタを使用している場合、クラスタのメンテナンス中はコントロール プレーンにアクセスできません。

この間、Cloud Run for Anthos は想定どおりに動作しない可能性があります。そのクラスタにデプロイされたサービスは、次のようになります。

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

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

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

コマンドラインを使用してサービスをデプロイする場合、そのサービスにメモリ上限を設定するには、--memory フラグを含める必要があります。--memory フラグを除外すると、Pod が動作しているノードで使用可能なメモリの合計量までサービスで消費できるため、予期しない問題が発生する場合があります。

Google Cloud Console を使用してデプロイする場合は、別の値が指定されていない限り、デフォルト値の 256M が使用されます。

各サービスに対してデフォルトの上限を定義しなくても済むように、これらのサービスをデプロイする名前空間にデフォルトのメモリ上限を定義できます。詳細については、Kubernetes ドキュメントのデフォルトのメモリ上限の構成をご覧ください。

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

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

この問題は、Cloud Run for Anthos でサービスをデプロイする Namespace に、デフォルトの CPU 上限を定義することで回避できます。詳細については、Kubernetes ドキュメントのデフォルトの CPU 上限の構成をご覧ください。

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

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

コンテナで /var/log にファイルやフォルダ（/var/log/nginx など）を作成すると、そのコンテナを Cloud Run for Anthos で実行しても、そうしたファイルやフォルダは表示されません。これは、空の読み取り/書き込みボリュームが /var/log にマウントされており、基になるコンテナのコンテンツが見えなくなるためです。

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

回避策

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

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

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

   kubectl get domainmapping --all-namespaces
   

2. 次のコマンドを実行して、指定した VirtualService を削除します。

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

Artifact Registry での非公開コンテナ イメージのデプロイ

非公開コンテナ イメージがデプロイされる際に、Cloud Run for Anthos と Artifact Registry 間の認証の失敗によって発生するデプロイの問題が報告されています。Artifact Registry に非公開イメージをデプロイする際の問題を回避するには、次のいずれかを行います。

• 非公開コンテナ イメージのイメージ ダイジェストを使用して、サービスをデプロイします。

• imagePullSecret を作成して使用します。imagePullSecret を使用すると、非公開のコンテナ イメージのイメージタグを使用できます。詳細については、他のコンテナ レジストリからの非公開コンテナ イメージのデプロイをご覧ください。

バージョン 0.20.0-gke.6 にアップグレードしたクラスタで構成エラー

バージョン 0.20.0-gke.6 にアップグレードされたクラスタでは、次のいずれかのエラーが発生することがあります。

クラスタの configmap を更新すると、クラスタが次のエラーを受け取ることがあります。

Error from server (InternalError): error when replacing "/tmp/file.yaml":
Internal error occurred: failed calling webhook "config.webhook.istio.networking.internal.knative.dev":
the server rejected our request for an unknown reason

キュープロキシの失敗により Pod の起動に失敗した場合、クラスタでは次のエラーを受け取る可能性があります。

Startup probe failed: flag provided but not defined: -probe-timeout

これらのエラーを解決するには、次のコマンドを実行し、0.20.0 でサポートされなくなった validatingwebhookconfiguration 構成を削除する必要があります。

kubectl delete validatingwebhookconfiguration config.webhook.istio.networking.internal.knative.dev

サポートされていない構成を削除すると、クラスタの configmap の更新に進むことができます。

Cloud Run for Anthos 0.23.0-gke.9 へのアップグレード後に指標が見つからない

問題: クラスタ バージョンを 0.23.0-gke.9 にアップグレードした後、Request count、Request latencies、Container instance count の指標が見つからない

考えられる原因: Metric Collector が無効になっている

Metric Collector が指標の収集を妨げているかどうかを判断するには:

1. 次のコマンドを実行して、Cloud Run for Anthos のバージョンが 0.23.0-gke.9 であることを確認します。

   kubectl get deployment controller -n knative-serving -o jsonpath='{.metadata.labels.serving\.knative\.dev/release}'
   

2. 次のコマンドを実行して、Metric Collector が無効になっているかどうかを確認します。

   kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'
   

   結果が {enabled: true} でない場合、Metric Collector は無効になっています。

3. Metric Collector を有効にするには、次のいずれかのコマンドを実行します。

   • 結果が空の場合は、次のコマンドを実行します。

     kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec", "value": NULL}, {"op": "add", "path": "/spec", "value": {}}]'
     kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "test", "path": "/spec/metricscollector", "value": NULL}, {"op": "add", "path": "/spec/metricscollector", "value": {}}]'
     kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "add", "path": "/spec/metricscollector/enabled", "value": true}]'
     

   • 結果が {enabled: false} の場合は、次のコマンドを実行します。

     kubectl patch cloudrun cloud-run -n cloud-run-system --type='json' -p='[{"op": "replace", "path": "/spec/metricscollector/enabled", "value": true}]'
     

4. 次のコマンドを実行して、Metric Collector が有効になっていることを確認します。

   kubectl get cloudrun cloud-run -n cloud-run-system -o jsonpath='{.spec.metricscollector}'