s <0x0 ベアメタル用 Google Distributed Cloud の既知の問題

このページには、ベアメタル向け Google Distributed Cloud（ソフトウェアのみ）（旧称 Google Distributed Cloud Virtual、旧称 Anthos clusters on bare metal）の既知の問題がすべて記載されています。

このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する管理者、アーキテクト、オペレーターを対象としています。 Google Cloudのコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

Google Developer Program に参加している場合は、このページを保存して、このページに関連するリリースノートが公開されたときに通知を受け取るようにしてください。詳細については、保存したページをご覧ください。

既知の問題をプロダクト バージョンまたはカテゴリでフィルタするには、次のプルダウン メニューからフィルタを選択します。

Google Distributed Cloud のバージョンを選択します。

問題のカテゴリを選択します。

または、問題を検索します。

カテゴリ 該当するバージョン 問題と回避策
ネットワーキング、アップグレード、アップデート 1.30 以降

Google Distributed Cloud にバンドルされている Ingress 機能は istiod を使用します。この機能は、Istio で定義されたカスタム リソース定義を使用しません。ただし、使用されるコードはオープンソースであるため、Pod は独自のユースケースで使用する Istio インストールに影響を受けます。

クラスタに Istio カスタム リソース定義が存在しない場合、Istiod はカスタム リソース定義を待たずに準備完了を宣言します。ただし、クラスタに v1beta カスタム リソース定義がある場合、Istiod は v1 カスタム リソース定義を待ってから、準備完了を宣言します。その結果、Istiod Pod が準備完了状態にならず、クラスタのアップグレードが失敗する可能性があります。

確認:

クラスタが影響を受けるかどうかを確認するには、gke-system Namespace の Istiod Pod のステータスを確認します。

kubectl get pods -n gke-system -l app=istiod

Pod のステータスが Running で、準備状況チェックが失敗した場合（0/1 の準備が完了しているなど）、クラスタが影響を受けている可能性があります。


回避策:

この問題を解決するには、次のいずれかのワークアラウンドを使用します。

  • Istio v1 カスタム リソース定義をクラスタに手動でデプロイします。

  • バンドルされた Ingress 機能を使用していない場合は、無効にします。
インストール、アップグレード、更新 1.30.400 以前

バージョン 1.30.400 以前のクラスタでは、PreflightCheck カスタム リソースを検証するときに lifecycle-controllers-manager Pod がクラッシュすることがあります。これらのクラッシュにより、クラスタのプロビジョニングとアップグレードが停止します。

この問題は、PreflightCheck リソースの検証中に nil ポインタの逆参照が発生することが原因で発生します。


回避策:

クラスタのプロビジョニングまたはアップグレードを続行するには、プリフライト チェックをバイパスします。クラスタ構成ファイルで、bypassPreflightCheck フィールドを true に設定します。

spec:
  bypassPreflightCheck: true

詳細については、Kubernetes リソース適用時のプリフライト チェックをバイパスするをご覧ください。
操作、リセット/削除 1.33 以前

bmctl restore cluster を使用してクラスタを復元すると、復元オペレーションの完了後にノードで Node Problem Detector（NPD）systemd サービスが起動しません。

影響を受けているかどうかを確認するには、復元オペレーションの後にクラスタノードで systemctl is-active node-problem-detector を実行します。コマンドが inactive を返す場合、この問題の影響を受けています。


回避策:

NPD を復元するには、次の操作を行います。

  1. ノードの問題の検出機能を有効または無効にする方法の手順に沿って、NPD を無効にします。
  2. ノードの問題の検出機能を有効または無効にする方法の手順に沿って NPD を有効にします。

NPD を無効にして有効にすると、NPD デプロイ担当者ジョブが明示的にトリガーされ、すべてのノードに NPD サービスがインストールされます。
ネットワーキング、オペレーション 1.28 以前、1.29.0-1.29.700、1.30.0-1.30.300

バンドルされたレイヤ 2 ロードバランサを使用するクラスタでは、7 日ごとに「Connection Refused」エラーが発生したり、API サーバーが短時間（約 1 分）使用できなくなることがあります。

この動作は、ジョブの存続期間の設定により、コントロール プレーン ノードの haproxy Pod と keepalived Pod が再起動されるために発生します。この問題は、バージョン 1.29.0 ～ 1.29.700、1.30.0 ～ 1.30.300、1.28 以前のクラスタに影響します。


確認:

クラスタがこの特定の問題の影響を受けていることを確認するには、次の手順でロードバランサの更新ジョブの構成を確認します。

  1. 更新ジョブの名前を確認します。

    kubectl get jobs -n kube-system | grep bm-system-cplb-update

  2. ジョブの有効期間の設定を確認します。

    kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}'

    JOB_NAME は、前の手順で返された名前に置き換えます。

  3. 出力が 604800（7 日間を秒単位で表した値）の場合、クラスタはこの問題の影響を受けています。


回避策:

毎週の再起動を防ぐには、次の手順に沿って、既存のロードバランサ更新ジョブの ttlSecondsAfterFinished フィールドを手動でより大きな値にパッチを適用します。

  1. ロードバランサ更新ジョブを編集します。

    kubectl edit job JOB_NAME -n kube-system

  2. エディタで ttlSecondsAfterFinished フィールドを見つけ、値を 7776000（約 90 日）に変更します。

  3. 変更を適用するには、保存してエディタを終了します。
オペレーション 1.32.0 ～ 1.32.700、1.33.0 ～ 1.33.300、1.34.0

コントローラのパニック: assignment to entry in nil map が原因で、cluster-operator Pod がクラッシュしたり、クラッシュループに陥ったりする可能性があります。これは、コントローラがアノテーションのない（nil マップ）カスタム リソース（NodePool など）のアノテーションを更新しようとした場合に発生する可能性があります。


回避策:

パニックを防ぐには、カスタム リソース（NodePool など）に少なくとも 1 つのアノテーションがあることを確認します。次のコマンドを使用して、ダミー アノテーションを追加できます。

kubectl annotate nodepool NODEPOOL_NAME \
    -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \
    --kubeconfig=ADMIN_KUBECONFIG

次のように置き換えます。

  • NODEPOOL_NAME: NodePool カスタム リソースの名前。
  • CLUSTER_NAMESPACE: クラスタの Namespace。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。
アップグレードと更新 1.34.0

ホスト名の不一致が原因でワーカーノードのアップグレードが失敗する

kubeadm の回帰（kubernetes/kubeadm#3244）が原因で、ワーカーノードのアップグレードが失敗します。この回帰は、Linux ホスト名が対応する Kubernetes ノードの kubernetes.io/hostname ラベルの値と一致しない場合に発生します。

影響を受けるノードが失敗することを確認するには、次のような journalctl を使用します。

[root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm

レスポンスは次の例のようになります。

Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found

この例では、journalctl レスポンスで報告された Linux ホスト名がノードの kubernetes.io/hostname ラベルと一致していません。これにより、アップグレードがこの問題の影響を受けていることが確認されます。

kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \
  -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}'

回答:

lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos

回避策:

影響を受けるノードでアップグレードを完了するには、次のように、対応する Kubernetes ノードの kubernetes.io/hostname ラベルの値と一致するようにホスト名を一時的に変更してみてください。

[root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
ネットワーキング 1.34.0

下り（外向き）NAT の高速フェイルオーバーを有効にすると、kubectl cordon <NODE_NAME> でゲートウェイ ノードを分離すると、既存の下り（外向き）接続を維持する正常な移行が開始されます。ただし、Google Distributed Cloud ソフトウェアのみのリリース 1.34.0 では、グレースフル移行機能が意図したとおりに機能しません。

高速フェイルオーバーを使用するバージョン 1.34.0 クラスタで、管理者がアクティブな下り（外向き）ゲートウェイ ノードを分離すると、分離は計画外のノード障害のように動作し、そのノード上の既存のステートフル接続をすべて直ちに終了します。


回避策:

この問題の回避策はありません。
ネットワーキング 1.32.0

トラフィックが異なるノードのバックエンド Pod にルーティングされると、ClusterIP Service で接続が断続的に発生したり、接続が失敗したりする可能性があります。この通信障害は、Cilium v1.15 の回帰が原因で、iptables から CILIUM_POST_nat ルールが削除されたことが原因です。CILIUM_POST_nat ルールは送信元ネットワーク アドレス変換（SNAT）に必要です。このルールを削除すると、kube-proxy によるマスカレードが信頼できなくなり、ClusterIP Service の通信障害が発生します。

たとえば、クラスタをアップグレードしているときにオペレーションが停止した場合、次のようなログメッセージが表示されることがあります。これは、ClusterIP サービスがノードプール np1 の API サーバーに接続しようとしたときに TLS ハンドシェイクがタイムアウトしたことを示しています。

      I0527 15:42:39.261368  372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout
      E0527 15:42:39.264789  372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out

この問題は、バージョン 1.32.100 以降で修正されています。

回避策:

修正を含むバージョンにアップグレードできない場合は、Cilium イメージをバージョン v1.15.6-anthos1.32.50 以降に手動でアップグレードすることをおすすめします。このアップデートでは、必要な CILIUM_POST_nat ルールを再導入することで、この問題を解決しています。

Cilium イメージをアップグレードするには、次の操作を行います。

  1. kube-system Namespace の anetd DaemonSet を編集します。
    kubectl edit ds anetd -n kube-system
  2. Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version.

    Example old image:

    image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc...

    新しい画像の例:

    image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50
  3. 変更を保存してエディタを閉じます。
インストール、アップグレード、更新 1.33

bmctl configure projects コマンドを使用して新しい Google Cloud プロジェクトの Workload Identity 連携を構成しようとすると、コマンドが失敗し、次のエラー メッセージが表示されます。

Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id

このエラーは、必要なデフォルトの Workload Identity プール projectID. が新しいプロジェクトに自動的にプロビジョニングされないために発生します。

回避策:

プロジェクトの Workload Identity 連携を構成する手順は次のとおりです。

  1. 不足しているデフォルトの Workload Identity プールを手動で作成します。
    gcloud iam workload-identity-pools create PROJECT_ID. \
    --location=global \
    --project=PROJECT_ID

    PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  2. 管理ワークステーションで、新しく取得したアクセス トークンを使用して GCP_ACCESS_TOKEN 環境変数を更新します。
    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)

    デフォルトでは、アクセス トークンの有効期間は 3, 600 秒（1 時間）です。Workload Identity クラスタ認証を使用している場合、bmctl はトークンの有効期限を確認します。トークンの有効期限が 1,800 秒（30 分）以内の場合、bmctl はエラーを報告して終了します。

  3. bmctl configure projects を再実行します。
アップグレードと更新、ロギングとモニタリング 1.29、1.30、1.31、1.32

cal-update Ansible プレイブックには、disableCloudAuditLogging フラグを変更しようとすると失敗する論理エラーが含まれています。これにより、監査ログの有効化または適切な無効化が妨げられます。

disableCloudAuditLogging が true から false に変更されると、監査ログを有効にできません。これは、構成の変更を kube-apiserver に適用する前にスクリプトが失敗するためです。disableCloudAuditLogging が false から true に変更されると、監査ログは無効になりますが、cal-update ジョブが継続的に失敗し、プレイブックがヘルスチェックに到達できなくなります。確認されたエラー メッセージは次のとおりです。

The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines'

回避策:

この問題の回避策はありません。修正が適用されたバージョンにクラスタをアップグレードする必要があります。アップグレードする際は、次の手順に沿って操作します。

  1. disableCloudAuditLogging を true に設定して、監査ロギングを無効にします。
  2. パッチが利用可能になったら、修正を含む次のマイナー リリース パッチ バージョン（以降）のいずれかにクラスタをアップグレードします。
    • 1.30.1200
    • 1.31.800
    • 1.32.400
  3. Cloud Audit Logs を再度有効にするには、disableCloudAuditLogging を false に戻します。
アップグレードと更新 1.32+

修復オペレーション後に高可用性（HA）管理クラスタのアップグレードが失敗する

HA 管理クラスタで、gkectl repair admin-master コマンドの実行後に gkectl upgrade admin コマンドを実行すると、コマンドが失敗して停止します。

gkectl repair admin-master コマンドは、修復されたマシンに machine.onprem.gke.io/managed=false アノテーションを追加します。このアノテーションにより、gkectl upgrade admin コマンドを実行すると、cluster-api コントローラが調整状態のままになります。非 HA クラスタのアップグレードには、このアノテーションを削除するピボット ロジックが含まれていますが、HA クラスタのアップグレードにはピボット ロジックがありません。

回避策:

アップグレードを開始する前に、管理クラスタの Machine リソースから machine.onprem.gke.io/managed アノテーションを手動で削除します。
アップグレード、構成 1.32.0 - 1.32.200

レジストリ ミラーで構成されたクラスタは、1.32.0 以降へのアップグレード中に check_gcr_pass プリフライト チェックに失敗します。この失敗は、PreflightCheck カスタム リソースの構築方法の変更が原因で、チェックで使用されるクラスタ仕様からレジストリ ミラー構成が省略されるためです。

この問題は、プロキシとレジストリ ミラー構成のクラスタに対する内部テスト中に発見されました。

回避策:

この問題の回避策として、次のいずれかのオプションを使用できます。

  • アップグレードをトリガーするときに --force フラグを使用します。
  • bmctl get config を使用して現在のクラスタ構成を取得し、この新しく生成された構成ファイルを使用してアップグレードをトリガーします。
構成、更新 1.15 ～ 1.30、1.31.0 ～ 1.31.800、1.32.0 ～ 1.32.300

指定されたクラスタ バージョンでは、クラスタ リソース構成が変更されても、定期的なヘルスチェックの CronJob が仕様を更新しないことがあります。これらの更新の失敗は、ヘルスチェックの古い状態につながり、ジョブの失敗につながる可能性があります。

この問題は、Google Distributed Cloud バージョン 1.31.900、1.32.400、1.33.0 以降で修正されています。

回避策:

バージョン 1.30 以前の場合は、次の手順を回避策として使用できます。

  1. 定期的なヘルスチェックを無効にします。

    これにより、現在の HealthCheck リソースが削除されます。

  2. 定期的なヘルスチェックを再度有効にします。

    これにより、最新のクラスタ構成を考慮した新しい HealthCheck リソースが作成されます。
ネットワーキング 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30、1.31

Keepalived は、高可用性を実現するために、コントロール プレーン VIP をあるマシンから別のマシンに移動するために使用されます。コントロール プレーン VIP がバンドルされたレイヤ 2 ロードバランサによって処理される場合、Keepalived インスタンスのフェイルオーバーによって、異なる MAC アドレスを持つ Gratuitous ARP がインターリーブされる短い間隔（1 秒未満）が生じる可能性があります。スイッチング ネットワーク インフラストラクチャは、このインターリーブを異常と解釈し、最大 30 分間、以降の ARP メッセージを拒否する可能性があります。ARP メッセージがブロックされると、この期間中にコントロール プレーン VIP が使用できなくなる可能性があります。

Gratuitous ARP のインターリーブは、バージョン 1.31 以前で使用されている Keepalived 設定が原因です。具体的には、すべてのノードが同じ優先度を使用するように構成されていました。バージョン 1.32 の Keepalived 構成の変更では、各 Keepalived インスタンスに異なる優先度を設定し、クラスタ設定 controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat を提供して、不要な ARP の数を減らすことで、この問題に対処しています。

回避策:

バージョン 1.31 以前では、Keepalived 構成ファイル /usr/local/etc/keepalived/keepalived.conf を直接編集することで、グラティアス ARP のインターリーブを減らすことができます。コントロール プレーン ロードバランサを実行する各ノードで、構成ファイルを編集して次の設定を変更します。

  • priority: 各ノードに個別の priority 値を設定します（有効な値は 1～254 の範囲）。
  • weight: ヘルスチェックが失敗したときに Keepalived フェイルオーバーがトリガーされるように、weight 値を -2 から -253 に変更します。
ロギングとモニタリング 1.30、1.31、1.32、1.33

内部定義エラーのため、kubernetes.io/anthos/custom_resurce_watchers 指標に不正確なデータが表示されることがあります。この問題の影響を受けている場合は、ログに次のようなエラーが表示されることがあります。

One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE.

これらのエラーは無視してかまいません。この指標は重要なシステム アラートには使用されず、エラーはプロジェクトやクラスタの機能に影響しません。
オペレーション 1.30、1.31、1.32、1.33

bmctl check cluster --snapshot を実行したときに管理ワークステーションに .manifests ディレクトリがない場合、コマンドは次のようなエラーで失敗します。

Error message: failing while capturing snapshot failed to parse cluster config
file
failed to get CRD file

このエラーは、bmctl check cluster --snapshot コマンドがクラスタ構成を検証するために .manifests ディレクトリのカスタム リソース定義ファイルを必要とするために発生します。このディレクトリは通常、クラスタの設定時に作成されます。誤ってディレクトリを削除した場合や、別の場所から bmctl を実行した場合、コマンドはスナップショット オペレーションを続行できません。

回避策

この問題を解決するには、次のいずれかの方法で .manifests ディレクトリを手動で再生成します。

  • bmctl check cluster コマンドを実行します。
    bmctl check cluster --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    このコマンドは、初期チェックの一環として、コマンドが正常に完了したかどうかにかかわらず、現在の作業ディレクトリに .manifests ディレクトリを自動的に作成します。

  • 現在のクラスタ構成ファイルを含むディレクトリで、bmctl create cluster コマンドを実行します。
    bmctl create cluster --cluster TEST_CLUSTER

    このコマンドを実行すると、クラスタ構成ファイルを解析できませんなどのエラーが発生する可能性がありますが、.manifests ディレクトリは現在の作業ディレクトリに作成されます。

    生成された一時ディレクトリ bmctl-workspace/TEST_CLUSTER は、後で安全に削除できます。

上記のいずれかの回避策を実施したら、bmctl check cluster --snapshot コマンドを再試行します。
インストール、アップグレード、更新 1.32.0、1.32.100

コントロール プレーン VIP をホストするノードで HAProxy インスタンスが使用できない場合、Keepalived インスタンスの nopreempt 設定により、コントロール プレーン VIP が正常な HAProxy を持つノードに移動しなくなります。この問題は、nopreempt 設定と互換性のない Keepalived 仮想ルーター冗長プロトコル（VRRP）の優先度を自動的に構成する機能に関連しています。


回避策:

この問題を回避するには、次の手順で Keepalived 機能を無効にします。

  1. preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" アノテーションをクラスタに追加します。
    kubectl annotate --kubeconfig ADMIN_KUBECONFIG \
    -n CLUSTER_NAMESPACE \
    clusters.baremetal.cluster.gke.io/CLUSTER_NAME \
    preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable"
  2. コントロール プレーン ロードバランサを実行するノードの /usr/local/etc/keepalived/keepalived.conf から nopreempt を削除します。

    これらは、ロードバランサの構成に応じて、コントロール プレーン ノードまたはロードバランサ ノードプール内のノードのいずれかになります。

  3. nopreempt を削除したら、構成ファイルの変更を取得するために keepalived 静的 Pod を再起動する必要があります。これを行うには、各ノードで次のコマンドを使用して keepalived Pod を再起動します。
    crictl rmp -f \
    $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
インストール、アップグレード、更新 1.30、1.31、1.32.0

プリフライト ジョブとヘルスチェック ジョブが失敗すると、タイムスタンプ付きの abm-tools-* フォルダが /usr/local/bin に残ることがあります。この問題の影響を受けている場合、次のようなフォルダが多数表示されることがあります。 /usr/local/bin/abm-tools-preflight-20250410T114317。 失敗が繰り返されると、ディスク使用量が増加する可能性があります。

回避策

この問題が発生した場合は、次のフォルダを手動で削除してください。

rm -rf  /usr/local/bin/abm-tools-*
ネットワーキング 1.28.0-1.28.200

下り（外向き）NAT ゲートウェイが有効になっているクラスタで、ロードバランサが古い EgressNATPolicy カスタム リソースで指定されたトラフィック選択ルールに一致するバックエンドを選択すると、ロードバランサ トラフィックがドロップされます。

この問題は、下り（外向き）ポリシーに一致する Pod の作成と削除時に発生します。Pod が削除されたときに外向きポリシーが適切にクリーンアップされず、古い外向きポリシーにより、LoadBalancer Pod が存在しない接続にトラフィックを送信しようとします。

この問題は、Google Distributed Cloud バージョン 1.28.300 以降で修正されています。

回避策

下り（外向き）NAT ポリシー リソースをクリーンアップするには、失敗しているバックエンドをホストしている各ノードを再起動します。
アップグレードと更新、リセット/削除 1.28

Google Distributed Cloud 1.28 でコントロール プレーン ノードを置き換える（削除、追加）と、新しいノードがクラスタに参加できないことがあります。これは、新しいノードの設定を担当するプロセス（bm-system-machine-init）で次のエラーが発生するためです。

Failed to add etcd member: etcdserver: unhealthy cluster

このエラーは、古いコントロール プレーン ノードが削除され、etcd-events のメンバーシップが適切にクリーンアップされず、古いメンバーが残っている場合に発生します。古いメンバーが原因で新しいノードが etcd-events クラスタに参加できず、machine-init プロセスが失敗して、新しいノードが継続的に再作成されます。

この問題の影響は次のとおりです。

  • 新しいコントロール プレーン ノードを正常に起動できません。
  • クラスタが RECONCILING 状態のままになることがあります。
  • machine-init の障害により、コントロール プレーン ノードが継続的に削除され、再作成されます。

この問題は、バージョン 1.29 以降で修正されています。

回避策:

バージョン 1.29 にアップグレードできない場合は、次の手順に沿って、クラスタから障害のある etcd-events メンバーを手動でクリーンアップできます。

  1. SSH を使用して、機能しているコントロール プレーン ノードにアクセスします。
  2. 次のコマンドを実行します。
    ETCDCTL_API=3 etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --endpoints=localhost:2382 \
    member list
  3. レスポンスのメンバー リストに削除されたノードが含まれている場合は、ノードの最初の列でメンバー ID を見つけて、次のコマンドを実行します。
    ETCDCTL_API=3 etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --endpoints=localhost:2382 \
    member remove MEMBER_ID
     MEMBER_ID は、削除されたノードのメンバー ID に置き換えます。

新しいコントロール プレーン ノードは、数分後に自動的にクラスタに参加します。
アップグレードと更新 1.30.500-gke.126、1.30.600-gke.68、1.31.100-gke.136、1.31.200-gke.58

クラスタのアップグレード中に、最初のコントロール プレーン ノードでアップグレード プロセスが失敗し、ansible ジョブ内に super-admin.conf ファイルがないことを示すエラー メッセージが表示されることがあります。

この問題は、アップグレードされる最初のコントロール プレーン ノードが、クラスタの作成時にプロビジョニングされた最初のノードではないことが原因で発生します。アップグレード プロセスでは、アップグレードする最初のノードに super-admin.conf ファイルが含まれていることを前提としています。

この問題は、次のパッチ アップデートで修正されています。1.30.500-gke.127、1.30.600-gke.69、1.31.200-gke.59

回避策:

この問題を軽減するには、失敗したノードで次の手順を行います。

  • /etc/kubernetes/admin.conf ファイルを /etc/kubernetes/super-admin.conf にコピーします。
    cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf

    アップグレード プロセスは自動的に再試行され、正常に続行されます。
アップグレードと更新 1.29.0 - 1.29.1100、1.30.0 - 1.30.400

NoSchedule toleration を持つ Pod は、アップグレード中に削除の対象と見なされます。ただし、NoSchedule の容認により、Deployment コントローラまたは DaemonSet コントローラがメンテナンス中のノードで Pod を再度スケジュールし、アップグレードが遅れる可能性があります。

この問題の影響を受けているかどうかを確認する手順は次のとおりです。

  1. anthos-cluster-operator Pod ログを確認して、ノードのドレインをブロックしている Pod を特定します。

    次のログ スニペットの例では、node-problem-detector-mgmt-ydhc2 Pod はまだドレインされていません。

    nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"}
  2. ノードのドレインをブロックしている Pod ごとに、次のコマンドを実行して容認をチェックします。
    kubectl get po POD_NAME -n kube-system \
    -o json | jq '.spec.tolerations'

    POD_NAME は、ノードのドレインをブロックしている Pod の名前に置き換えます。

    次のいずれかの組み合わせが表示されます。

    • NoSchedule 効果と Exists 演算子による容認
    • NoSchedule 効果と "baremetal.cluster.gke.io/maintenance" キーを含む Toleration
    • 効果が空で "baremetal.cluster.gke.io/maintenance" キーの toleration

    たとえば、次のようなレスポンスが返されます。

    {
  "effect": "NoSchedule",
  "operator": "Exists"
},

回避策:

次のいずれかの方法で、ノードのドレインをブロック解除できます。

  • baremetal.cluster.gke.io/maintenance:Schedule toleration があり、正常な終了を必要としない Pod に baremetal.cluster.gke.io/maintenance:NoExecute toleration を追加します。
  • ノードのドレイン中に強制排除される Pod から、特定された toleration の組み合わせを削除します。
ネットワーキング 1.28、1.29、1.30

hostPort が有効になっている Pod へのネットワーク呼び出しは、リクエストが Pod が実行されている同じノード内から発信された場合、失敗してパケットをドロップします。これは、すべてのクラスタタイプとノードタイプに適用されます。ただし、kube-proxy を指定せずに作成されたクラスタは影響を受けません。

この問題の影響を受けるかどうかを確認します。

  1. anetd Pod の名前を取得します。

    anetd Pod は、ネットワーク トラフィックの制御を担当します。

    kubectl get pods -l k8s-app=cilium -n kube-system
  2. anetd Pod のステータスを確認します。
    kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters

    ANETD_POD_NAME は、クラスタ内の anetd Pod のいずれかの名前に置き換えます。

    レスポンスに KubeProxyReplacement: Partial ... が含まれている場合、この問題の影響を受けています。

回避策

hostPort を使用する Pod に、実行中の同じノードからリクエストを送信するユースケースがある場合は、kube-proxy なしでクラスタを作成できます。または、portmap Container Network Interface（CNI）プラグインを使用するように Pod を構成することもできます。
ロギングとモニタリング 1.29.100 で確認済み。他のバージョンでも発生する可能性あり

ネットワーク接続の損失または無効なサービス アカウントによるディスク I/O の増加

stackdriver-log-forwarder Pod で接続が失われたり、サービス アカウントの有効期限が切れたりすると、これらのログを logging.googleapis.com に送信できなくなり、バッファにログが蓄積されて、ディスク I/O が高くなる可能性があります。Cloud ロギング エージェント（Fluent Bit）は、stackdriver-log-forwarder という名前の DaemonSet で、4 GB の上限があるファイル システム ベースのバッファを使用します。バッファが満杯になると、エージェントはバッファのローテーションまたはフラッシュを試みます。これにより、I/O が高くなる可能性があります。


確認事項:

サービス アカウント（SA）キーの有効期限が切れていないか確認します。その場合は、ローテーションして問題を解決します。

次のコマンドを使用して、現在使用されているサービス アカウントを確認し、IAM で同じアカウントを検証できます。

kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode

回避策:

警告: バッファを削除すると、バッファに現在保存されているすべてのログ（Kubernetes ノード、Pod、コンテナのログを含む）が完全に失われます。
バッファの蓄積が Google Cloud のロギング サービスへのネットワーク接続の喪失によって発生した場合、バッファが削除されるか、バッファがいっぱいでエージェントがログを送信できないと、これらのログは完全に失われます。

  1. ノード セレクタを追加して、クラスタから stackdriver-log-forwarder DaemonSet Pod を削除します（これにより、stackdriver-log-forwarder DaemonSet は維持されますが、ノードからスケジュールされなくなります）。

    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

    KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。

    stackdriver-log-forwarder Pod が削除されたことを確認して、次のステップに進みます。

  2. この問題が 1 つまたは少数のノードで発生している場合:

    • stackdriver-log-forwarder が実行されていたノードに SSH を使用して接続します（これらのノードで stackdriver-log-forwarder が実行されていないことを確認します）。
    • ノードで、rm -rf /var/log/fluent-bit-buffers/ を使用してすべてのバッファ ファイルを削除し、手順 6 に進みます。

  3. これらのファイルを含むノードが多すぎる場合、スクリプトを適用してこのバックログ チャンクを含むすべてのノードをクリーンアップするには、次のスクリプトを使用します。

    DaemonSet をデプロイして、fluent-bit のバッファ内のすべてのデータをクリーンアップします。

    kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

  4. DaemonSet がすべてのノードをクリーンアップしたことを確認します。次の 2 つのコマンドの出力は、クラスタ内のノード数と同じになります。

    kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

  5. クリーンアップの DaemonSet を削除します。

    kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup

  6. stackdriver-log-forwarder Pod を再起動します。

    kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
アップグレードと更新、オペレーション 1.28、1.29、1.30.0、1.30.100

ノードがドレインされると、Pod が終了できなくなることがあります。スタックした Pod は、ノードをドレインするアップグレードなどのオペレーションをブロックする可能性があります。コンテナの基盤となるメインプロセスがすでに正常に終了しているにもかかわらず、コンテナが実行中と表示されると、Pod がスタックすることがあります。この場合、crictl stop コマンドでもコンテナは停止しません。

この問題の影響を受けているかどうかを確認するには、次の手順を行います。

  1. クラスタにステータスが Terminating の Pod があるかどうかを確認します。
    kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
    -o wide | grep Terminating
  2. 終了処理が停止している Pod がある場合は、kubectl describe を使用してイベントを確認します。
    kubectl describe pod POD_NAME \
    --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE

    Unhealthy と FailedKillPod の両方が理由として次のような警告が表示される場合は、この問題の影響を受けています。

    Events:
  Type     Reason         Age                      From     Message
  ----     ------         ----                     ----     -------
  Warning  FailedKillPod  19m (x592 over 46h)      kubelet  error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"]
  Warning  Unhealthy      4m37s (x16870 over 46h)  kubelet  (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown

この問題は、アップストリームの containerd の問題が原因で発生します。この問題は、Google Distributed Cloud バージョン 1.28.1000、1.29.600、1.30.200、1.31 以降で修正されています。

回避策

クラスタ オペレーションのブロックを解除するには:

  1. スタックした Pod を強制的に削除します。
    kubectl delete pod POD_NAME -n POD_NAMESPACE --force
  2. Pod が正常に再起動したら、クラスタ オペレーションを再試行します。
アップグレードと更新、オペレーション 1.28、1.29、1.30.0 ～ 1.30.100

ノードがドレインされると、Pod が終了できなくなることがあります。スタックした Pod は、ノードをドレインするアップグレードなどのクラスタ オペレーションをブロックする可能性があります。runc init プロセスがフリーズすると、Pod がスタックする可能性があります。これにより、containerd がその Pod に関連付けられた cgroups を削除できなくなります。

この問題の影響を受けているかどうかを確認するには、次の手順を行います。

  1. クラスタにステータスが Terminating の Pod があるかどうかを確認します。
    kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
    -o wide | grep Terminating
  2. Pod の終了が停止しているノードの kubelet ログを確認します。

    次のコマンドは、テキスト Failed to remove cgroup を含むログエントリを返します。

    journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup"

    レスポンスに次のような警告が含まれている場合は、この問題の影響を受けています。

    May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
...
May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
...

回避策

runc init プロセスをフリーズ解除し、クラスタ オペレーションのブロックを解除するには:

  1. kubelet ログの cgroup パスを使用して、freezer.state ファイルの内容を確認し、cgroup がフリーズしているかどうかを確認します。
    cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state

    freezer.state の内容は cgroup の状態を示します。

    前の例のログエントリのパスを使用すると、コマンドは次のようになります。

    cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state
  2. FREEZING または FROZEN 状態の cgroups のフリーズを解除します。
    echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state

    cgroups が THAWED されると、対応する runc init プロセスが自動的に終了し、cgroups が自動的に削除されます。これにより、kubelet ログに余分な Failed to remove cgroup 警告が表示されなくなります。Terminating 状態のままになっている Pod も、クリーンアップ後しばらくすると自動的に削除されます。

  3. フリーズした cgroups がクリーンアップされ、スタックした Pod が削除されたら、クラスタ オペレーションを再試行します。
構成、ネットワーキング 1.28.0 ～ 1.28.1000、1.29.0 ～ 1.29.500、1.30.0 ～ 1.30.200

特定されたバージョンの Google Distributed Cloud では、kubelet がノードリースを 40 秒以上更新できず、NodeNotReady イベントが発生することがあります。

この問題は断続的に発生し、約 7 日ごとに発生します。コントロール プレーン VIP のフェイルオーバーは、NodeNotReady イベントの発生時に発生する可能性があります。

この問題は、バージョン 1.28.1100、1.29.600、1.30.300 以降で修正されています。

回避策:

この問題を軽減するには、次の手順で kubelet を構成します。

  1. /etc/default/kubelet を作成し、次の環境変数を追加します。
    2. HTTP2_READ_IDLE_TIMEOUT_SECONDS=10
HTTP2_PING_TIMEOUT_SECONDS=5
  2. kubelet を再起動します。
    systemctl restart kubelet
  3. kubelet の新しいプロセス ID（PID）を取得します。
    pgrep kubelet
  4. ノードで kubelet を再起動した後、環境変数が有効になっていることを確認します。
    cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS

    KUBELET_PID は、前の手順のコマンドの出力に置き換えます。

    cat コマンドの出力の最後の数行に、追加された 2 つの環境変数が表示されます。
更新 1.30

bmctl create cluster コマンドを使用してユーザー クラスタを作成し、ヘッダーの cloudOperationsServiceAccountKeyPath フィールドを渡すと、作成されたクラスタ リソースに spec.clusterOperations.serviceAccountSecret フィールドが追加されます。このフィールドはクラスタ構成ファイルに存在せず、変更できません。bmctl update cluster コマンドはヘッダーからこのフィールドに入力しないため、bmctl update cluster コマンドと元のクラスタ構成ファイルを使用してクラスタを更新しようとすると、次のエラーが発生します。

[2025-01-15 16:38:46+0000] Failed to calculate diff:
---
E000090: Unable to calculate diff

An error occurred while calculating diff between live configuration and cluster.yaml file



Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable.
(A in old)
(B in new)

{"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1"

A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"}

B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"}



For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090

この問題は、bmctl の 1.30.x バージョンを使用して更新を行う場合にのみ発生します。

回避策:

回避策として、更新を行う前に実際の Cluster リソースのクラスタ構成を取得できます。

  1. デプロイされた Cluster リソースに基づいて、ユーザー クラスタ構成ファイルを取得します。
    bmctl get config --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG_PATH

    取得したカスタム リソースは、bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml という名前の YAML ファイルに書き込まれます。この新しい構成ファイルには、更新コマンドの実行に必要な spec.clusterOperations.serviceAccountSecret が含まれています。ファイル名の TIMESTAMP は、ファイルが作成された日時を示します。

  2. 既存のクラスタ構成ファイルを取得したファイルに置き換えます。既存のファイルのバックアップを保存します。
  3. 新しいクラスタ構成ファイルを編集し、bmctl update を使用してユーザー クラスタを更新します。
    bmctl update cluster --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG_PATH
アップグレードと更新、セキュリティ 1.29、1.30、1.31

kubelet-client-current.pem と kubelet-server-current.pem がシンボリック リンク（symlink）ではなく実際のファイルの場合、Kubelet 証明書のローテーションは失敗します。

この問題は、bmctl restore を使用してバックアップからクラスタを復元した後に発生することがあります。

回避策:

この問題の影響を受けている場合は、次の手順を回避策として使用できます。
  1. 現在の証明書ファイルをバックアップします。
    mkdir -p ~/kubelet-backup/
cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/
  2. 必要に応じて、蓄積された証明書ファイルを削除します。
    ls | grep -E "^kubelet-server-20*" | xargs rm -rf
ls | grep -E "^kubelet-client-20*" | xargs rm -rf
  3. kubelet-client-current.pem ファイルと kubelet-server-current.pem ファイルの名前を変更します。

    タイムスタンプを使用することは、一般的な名前変更スキームです。

    datetime=$(date +%Y-%m-%d-%H-%M-%S)
mv kubelet-server-current.pem kubelet-server-${datetime}.pem
mv kubelet-client-current.pem kubelet-client-${datetime}.pem
  4. 前のコマンドと同じセッションで、有効な最新の（名前変更された）証明書を指すシンボリック リンクを作成します。
    ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem
ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem
  5. シンボリック リンクの権限を 777 に設定します。
    chmod 777 kubelet-server-current.pem
chmod 777 kubelet-client-current.pem
  6. 証明書が正常にローテーションされたら、バックアップ ディレクトリを削除します。
    rm -rf ~/kubelet-backup/
インストール、アップグレード、更新 1.31

Google Distributed Cloud バージョン 1.31 では、クラスタ（すべてのタイプ）やワークロードなどのカスタム リソースを作成しようとすると、エラーが発生することがあります。この問題は、Kubernetes 1.31 で導入された破壊的変更が原因で発生します。この変更により、カスタム リソース定義の caBundle フィールドが有効な状態から無効な状態に移行できなくなります。この変更の詳細については、Kubernetes 1.31 の変更ログをご覧ください。

Kubernetes 1.31 より前は、以前の Kubernetes バージョンでは API サーバーで空の CA バンドル コンテンツが許可されていなかったため、caBundle フィールドは \n の一時的な値に設定されることがよくありました。cert-manager は通常 caBundle を後で更新するため、\n を使用することは、混乱を避けるための妥当な回避策でした。

caBundle が無効な状態から有効な状態に一度パッチ適用されていれば、問題は発生しません。ただし、カスタム リソース定義が \n（または別の無効な値）に調整されると、次のエラーが発生する可能性があります。

...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

回避策

caBundle が無効な値に設定されているカスタム リソース定義がある場合は、caBundle フィールドを完全に削除しても安全です。これで問題が解決するはずです。
インストール、アップグレード、更新 1.28、1.29、1.30

クラスタのアップグレードでは、各クラスタノードがドレインされてアップグレードされます。リリース 1.28 以降では、Google Distributed Cloud は taint ベースのノードドレインから削除ベースのドレインに切り替わりました。また、Pod 間の依存関係に対処するために、削除ベースのドレインはマルチステージ ドレイン順序に従います。ドレインの各段階で、Pod には終了までの 20 分間の猶予期間が与えられます。以前の taint ベースのドレインでは、タイムアウトは 1 回の 20 分間でした。各ステージで 20 分間かけてすべての Pod を削除する必要がある場合、ノードのドレインにかかる時間は、以前の taint ベースのドレインよりも大幅に長くなる可能性があります。ノードドレイン時間が長くなると、クラスタのアップグレードやクラスタのメンテナンス モードへの移行にかかる時間が大幅に増加する可能性があります。

また、削除ベースのドレインのタイムアウト ロジックに影響するアップストリームの Kubernetes の問題もあります。この問題により、ノードのドレイン時間が長くなることもあります。

回避策:

回避策として、強制排除ベースのノードのドレインを無効にすることができます。これにより、taint ベースのドレインに戻ります。ただし、taint ベースのドレインは PodDisruptionBudgets（PDB）を尊重しないため、サービスの中断につながる可能性があります。そのため、おすすめしません。
インストール、アップグレード、更新 1.16、1.28、1.29

クラスタの調整は、クラスタの作成やクラスタのアップグレードなど、ほとんどのクラスタ オペレーションの標準フェーズです。クラスタの調整中に、Google Distributed Cloud クラスタ コントローラがプリフライト チェックをトリガーします。このプリフライト チェックが失敗すると、クラスタの再調整はブロックされます。その結果、クラスタの調整を含むクラスタ オペレーションもブロックされます。

このプリフライト チェックは定期的に実行されず、クラスタの調整の一環としてのみ実行されます。そのため、最初のプリフライト チェックの失敗の原因となった問題を修正し、オンデマンド プリフライト チェックが正常に実行された場合でも、この古い失敗したプリフライト チェックが原因でクラスタの調整がブロックされます。

クラスタのインストールまたはアップグレードが停止している場合は、次の手順でこの問題の影響を受けているかどうかを確認できます。

  1. anthos-cluster-operator Pod のログで、次のようなエントリを確認します。
    "msg"="Preflight check not ready. Won't reconcile"
  2. クラスタ コントローラによってトリガーされたプリフライト チェックが失敗状態かどうかを確認します。
    kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \
    -n CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    次のように置き換えます。

    • PREFLIGHT_CHECK_NAME: 削除する事前チェックの名前。この場合、名前はクラスタ名と同じです。
    • CLUSTER_NAMESPACE: 事前チェックが失敗しているクラスタの Namespace。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

    プリフライト チェックに失敗した場合（Status.Pass が false の場合）、この問題の影響を受けている可能性があります。

この問題は、1.30 リリースとそれ以降のすべてのリリースで修正されています。

回避策

クラスタ オペレーションのブロックを解除するには、失敗したプリフライト チェックを管理クラスタから手動で削除します。

kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \
    -n CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

古い失敗したプリフライト チェックが削除されると、クラスタ コントローラは新しいプリフライト チェックを作成できます。
インストール、アップグレード、更新 1.30.100、1.30.200、1.30.300

バージョン 1.30.100、1.30.200、1.30.300 でユーザー クラスタを作成したり、既存のユーザー クラスタをアップグレードしたりできないことがあります。この問題は、ユーザー クラスタの作成とアップグレード オペレーションに kubectl または GKE On-Prem API クライアント（ Google Cloud コンソール、gcloud CLI、Terraform）が使用されている場合にのみ発生します。

この場合、ユーザー クラスタの作成オペレーションは Provisioning 状態のままになり、ユーザー クラスタのアップグレードは Reconciling 状態のままになります。

クラスタが影響を受けるかどうかを確認するには、次の操作を行います。

  1. クラスタ リソースを取得します。
    kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    次のように置き換えます。

    • CLUSTER_NAME: 停止したユーザー クラスタの名前。
    • USER_CLUSTER_NAMESPACE: ユーザー クラスタの Namespace 名。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

    CLUSTER STATE の値が Provisioning または Reconciling の場合、この問題の影響を受けている可能性があります。次のレスポンス例は、アップグレードが停止していることを示しています。

    NAME            ABM VERSION      DESIRED ABM VERSION  CLUSTER STATE
some-cluster    1.30.0-gke.1930  1.30.100-gke.96      Reconciling

    バージョンの不一致は、クラスタのアップグレードが完了していないことも示しています。

  2. anthos-cluster-operator Pod のフルネームを確認します。
    kubectl get pods -n kube-system -o=name \
    -l baremetal.cluster.gke.io/lifecycle-controller-component=true \
    --kubeconfig ADMIN_KUBECONFIG

    次の例に示すように、出力は anthos-cluster-operator Pod を含む Pod のリストです。

    pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg
pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7
  3. クラスタがプロビジョニングまたは調整で停止していることを示すメッセージが繰り返されていないか、anthos-cluster-operator Pod のログをストリーミングします。
    kubectl logs POD_NAME -n kube-system -f --since=15s \
    --kubeconfig ADMIN_KUBECONFIG | \
    grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing"

    POD_NAME は、前の手順の anthos-cluster-operator Pod のフルネームに置き換えます。

    コマンドの実行中に、一致するログ行の連続的なストリームが表示された場合は、クラスタ オペレーションが停止していることを示します。次の出力例は、クラスタが調整で停止している場合に表示される出力に似ています。

    ...
I1107 17:06:32.528471       1 reconciler.go:1475]  "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926"
I1107 17:06:37.575174       1 reconciler.go:1475]  "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n"
...

    ログのストリーミングを停止するには、Control+C キーを押します。

  4. ConfigMapForwarder が停止しているかどうかを確認します。
    kubectl get configmapforwarder metadata-image-digests-in-cluster \
    -n USER_CLUSTER_NAMESPACE \
    -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \
    --kubeconfig ADMIN_KUBECONFIG

    レスポンスには、ConfigMapForwarder リソースの理由とメッセージが含まれます。ConfigMapForwarder が停止すると、次のような出力が表示されます。

    Reason: Stalled
Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation
  5. metadata-image-digests ConfigMap がユーザー クラスタの Namespace に存在しないことを確認します。
    kubectl get configmaps metadata-image-digests \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    レスポンスは次のようになります。

    Error from server (NotFound): configmaps "metadata-image-digests" not found

回避策

回避策として、ConfigMap を手動で更新して、不足しているアノテーションを追加できます。

  1. ConfigMap に不足しているアノテーションを追加します。
    kubectl annotate configmap metadata-image-digests \
    -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \
    --kubeconfig ADMIN_KUBECONFIG

    適切にアノテーションが付けられると、metadata-image-digests ConfigMap がユーザー クラスタの Namespace に自動的に作成されます。

  2. ConfigMap がユーザー クラスタの Namespace に自動的に作成されていることを確認します。
    kubectl get configmaps metadata-image-digests \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    ConfigMap が正常に作成されると、コマンド レスポンスは次のようになります。

    NAME                     DATA   AGE
metadata-image-digests   0      7s

上記の修正と検証により、クラスタ オペレーターのブロックが解除され、クラスタ オペレーションが通常どおりに進行するはずです。
操作、リセット/削除 1.30.0 - 1.30.300、1.29.0 - 1.29.700、1.28.0 - 1.28.1100

bmctl restore --control-plane-node を root 以外のユーザーとして実行すると、コントロール プレーン ノードからワークステーション マシンにファイルをコピーするときに chown の問題が発生します。

回避策:

root 以外のユーザーの場合は、sudo を指定して bmctl restore --control-plane-node コマンドを実行します。
アップグレード 1.30.0-gke.1930

アップグレード中に、pause:3.9 イメージがないため、upgrade-health-check ジョブがアクティブ状態のままになることがあります。

この問題はアップグレードの成功には影響しません。

回避策:

次のコマンドを使用して、upgrade-health-check ジョブを手動で削除します。

    kubectl delete job upgrade-health-check-JOB_ID --cascade=true
オペレーティング システム 1.28、1.29、1.30

RHEL 9.2 のコンテナ内のダウンロードが遅い

cgroup memory.max 制限を超えるサイズのアーティファクトのダウンロードは、非常に遅くなる可能性があります。この問題は、Red Hat Enterprise Linux（RHEL）9.2 の Linux カーネルのバグが原因で発生します。cgroup v2 が有効になっているカーネルが影響を受けます。この問題は、カーネル バージョン 5.14.0-284.40.1.el_9.2 以降で修正されています。

回避策:

影響を受ける Pod の場合は、コンテナのメモリ上限設定（spec.containers[].resources.limits.memory）を増やして、上限がダウンロードされたアーティファクトのサイズよりも大きくなるようにします。
アップグレード 1.28 ～ 1.29.200

ベアメタル クラスタのアップグレード中に、networks.networking.gke.io カスタム リソース定義で競合が発生したことを示すエラー メッセージが表示され、アップグレードが失敗することがあります。具体的には、v1alpha1 が spec.versions に存在しないというエラーが返されます。

この問題は、アップグレード プロセス中にカスタム リソース定義の v1alpha1 バージョンが v1 に移行されなかったために発生します。

回避策:

次のコマンドを使用して、影響を受けるクラスタにパッチを適用します。

kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
kubectl patch customresourcedefinitions/networks.networking.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
インストール、アップグレード、更新 1.28.0 から 1.28.600 へ、1.29.0 から 1.29.200 へ

クラスタのインストールまたはアップグレード中に、fs.inotify カーネル設定に関連するマシンのプリフライト チェックが失敗する可能性があります。この問題の影響を受けている場合、マシンのプリフライト チェックログには次のようなエラーが含まれています。

Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value.

この問題は、意図したノードマシンではなく、コントロール プレーンとブートストラップ ホストから fs.inotify max_user_instances 値と max_user_watches 値が誤って読み取られることが原因で発生します。

回避策:
この問題を回避するには、すべてのコントロール プレーンとブートストラップ マシンで fs.inotify.max_user_instances と fs.inotify.max_user_watches を推奨値に調整します。

echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf
echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf
sudo sysctl -p

インストールまたはアップグレード オペレーションが完了したら、必要に応じてこれらの値を元に戻すことができます。
アップグレード 1.28.0 - 1.28.500

bmctl を使用してクラスタをアップグレードすると、ターゲット URL が管理ワークステーションから到達可能であっても、GCP reachability check failed エラーでアップグレードが失敗することがあります。この問題は、bmctl バージョン 1.28.0 ～ 1.28.500 のバグが原因で発生します。

回避策:

bmctl upgrade コマンドを実行する前に、有効なサービス アカウント キーファイルを指すように GOOGLE_APPLICATION_CREDENTIALS 環境変数を設定します。

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

この方法でアプリケーションのデフォルト認証情報（ADC）を設定すると、bmctl が Google API エンドポイントにアクセスするために必要な認証情報を確実に取得できます。
構成、インストール、アップグレードと更新、ネットワーキング、セキュリティ 1.15、1.16、1.28、1.29

ipam-controller-manager が必要で、クラスタが Red Hat Enterprise Linux（RHEL）8.9 以降（アップストリーム RHEL の変更による）で SELinux が強制モードで実行されている場合、クラスタのインストールとアップグレードが失敗します。これは、特に container-selinux のバージョンが 2.225.0 より高い場合に適用されます。

クラスタでは、次のいずれかの状況で ipam-controller-manager が必要になります。

  • クラスタが IPv4/IPv6 デュアルスタック ネットワーキング用に構成されている
  • クラスタが構成され、clusterNetwork.flatIPv4 が true に設定されている
  • クラスタが preview.baremetal.cluster.gke.io/multi-networking: enable アノテーションで構成されている

ipam-controller-manager がインストールされている場合、クラスタのインストールとアップグレードが成功しません。

回避策

各コントロール プレーン ノードの /etc/kubernetes ディレクトリのデフォルト コンテキストをタイプ etc_t に設定します。

semanage fcontext /etc/kubernetes --add -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t
restorecon -R /etc/kubernetes

これらのコマンドは、/etc/kubernetes ディレクトリの container-selinux 変更を元に戻します。

クラスタが修正を含むバージョンにアップグレードされたら、各コントロール プレーン ノードで上記のファイル コンテキストの変更を元に戻します。

semanage fcontext /etc/kubernetes --delete -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t
restorecon -R /etc/kubernetes
アップグレード 1.28.0 - 1.28.500

bmctl を使用してクラスタをアップグレードすると、ターゲット URL が管理ワークステーションから到達可能であっても、GCP reachability check failed エラーでアップグレードが失敗することがあります。この問題は、bmctl バージョン 1.28.0 ～ 1.28.500 のバグが原因で発生します。

回避策:

bmctl upgrade コマンドを実行する前に、有効なサービス アカウント キーファイルを指すように GOOGLE_APPLICATION_CREDENTIALS 環境変数を設定します。

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

この方法でアプリケーションのデフォルト認証情報（ADC）を設定すると、bmctl が Google API エンドポイントにアクセスするために必要な認証情報を確実に取得できます。
インストール 1.29

クラスタの作成時に Binary Authorization ポリシーを有効にすると、個別のロードバランサ ノードプールを使用してクラスタをインストールできないことがあります。

この問題は、GKE Identity Service Pod や他の重要な Pod の作成が Binary Authorization Webhook によってブロックされるために発生します。

この問題の影響を受けるかどうかを判断するには、次の操作を行います。

  1. 失敗している Pod を特定します。
    kubectl get pods \
    -n anthos-identity-service \
    --kubeconfig CLUSTER_KUBECONFIG
  2. 障害が発生した Pod の説明を取得します。
  3. 出力で次のメッセージを探します。
    4. admission webhook "binaryauthorization.googleapis.com" denied the
        request: failed to post request to endpoint: Post
"https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview":
        oauth2/google: status code 400:
{"error":"invalid_target","error_description":"The
        target service indicated by the \"audience\" parameters is invalid.
This might either be because the pool or provider is disabled or deleted
or because it doesn't exist."}

    上記のメッセージが表示された場合は、クラスタにこの問題があります。

回避策:

この問題を回避するには、次の操作を行います。

  1. クラスタ作成オペレーションをキャンセルします。
  2. クラスタ構成ファイルから spec.binaryAuthorization ブロックを削除します。
  3. Binary Authorization を無効にしてクラスタを作成します。
  4. インストールが完了したら、既存のクラスタの Binary Authorization ポリシーを有効にします。
構成、インストール 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30

SELinux が有効になっていて、ファイル システムを Kubernetes 関連のディレクトリにマウントすると、クラスタの作成失敗、ファイルの読み取り不能、権限の問題などの問題が発生する可能性があります。

この問題の影響を受けるかどうかを判断するには、次のコマンドを実行します。

ls -Z /var/lib/containerd
。 system_u:object_r:container_var_lib_t:s0 などの別のラベルが表示されるはずの場所に system_u:object_r:unlabeled_t:s0 が表示されている場合は、この問題の影響を受けています。

回避策:

最近ファイル システムをディレクトリにマウントした場合は、それらのディレクトリが SELinux 構成で最新の状態になっていることを確認してください。

bmctl create cluster を実行する前に、各マシンで次のコマンドも実行する必要があります。

restorecon -R -v /var
 
restorecon -R -v /etc

この 1 回限りの修正は再起動後も保持されますが、同じマウント ポイントを持つ新しいノードが追加されるたびに必要になります。詳細については、Red Hat ドキュメントのファイル システムのマウントをご覧ください。
リセット / 削除 1.29.0

bmctl reset cluster -c ${USER_CLUSTER} を実行すると、関連するすべてのジョブが完了した後、コマンドがユーザー クラスタの名前空間の削除に失敗します。ユーザー クラスタの Namespace が Terminating 状態のままになる。最終的に、クラスタのリセットがタイムアウトしてエラーが返されます。

回避策:

名前空間を削除してユーザー クラスタのリセットを完了する手順は次のとおりです。

  1. クラスタから metrics-server Pod を削除します。
    kubectl delete pods -l k8s-app=metrics-server \
    -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
     この場合、metrics-server Pod によってクラスタ Namespace の削除が阻止されます。
  2. 管理クラスタで、ユーザー クラスタの Namespace のファイナライザーを強制的に削除します。
    kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
    jq '.spec.finalizers = []' | \
    kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
     ファイナライザが削除されると、クラスタ Namespace が削除され、クラスタのリセットが完了します。
構成、インストール、セキュリティ 1.16.0 から 1.16.7 へ、1.28.0 から 1.28.400 へ

Google Distributed Cloud 用の Binary Authorization を有効にしていて、バージョン 1.16.0 ～ 1.16.7 または 1.28.0 ～ 1.28.400 を使用している場合、この機能の Pod のスケジュール設定で問題が発生する可能性があります。これらのバージョンでは、Binary Authorization Deployment に nodeSelector がないため、この機能の Pod はコントロール プレーン ノードではなくワーカーノードでスケジュールできます。この動作によって何かが失敗することはありませんが、これは意図したものではありません。

回避策:

影響を受けるすべてのクラスタに対して、次の操作を行います。

  1. Binary Authorization のデプロイ ファイルを開きます。
    kubectl edit -n binauthz-system deployment binauthz-module-deployment
  2. spec.template.spec ブロックに次の nodeSelector を追加します。
    3.       nodeSelector:
        node-role.kubernetes.io/control-plane: ""
  3. 変更を保存します。

変更が保存されると、Pod はコントロール プレーン ノードにのみ再デプロイされます。この修正は、アップグレードのたびに適用する必要があります。
アップグレードと更新 1.28.0、1.28.100、1.28.200、1.28.300

バージョン 1.11.0 より前に作成されたクラスタをバージョン 1.28.0 ～ 1.28.300 にアップグレードすると、アップグレード中にライフサイクル コントローラ デプロイヤー Pod がエラー状態になることがあります。この場合、ライフサイクル コントローラ デプロイヤー Pod のログに、次のようなエラー メッセージが表示されます。 

"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions

回避策:

この問題は、バージョン 1.28.400 で修正されました。この問題を解決するには、バージョン 1.28.400 以降にアップグレードしてください。

アップグレードできない場合は、次のコマンドを実行して問題を解決します。 

kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
ロギングとモニタリング 1.13.7、1.14、1.15、1.16、1.28

ログ エクスプローラの resource.labels.project_id で、クラスタログまたはコンテナログが別のプロジェクト ID でタグ付けされることがあります。

これは、クラスタ構成の clusterOperations.projectID フィールドで設定されているオブザーバビリティ PROJECT_ONE を使用するようにクラスタが構成されている場合に発生します。 ただし、構成の cloudOperationsServiceAccountKeyPath にはプロジェクト PROJECT_TWO のサービス アカウント キーがあります。

この場合、すべてのログは PROJECT_ONE にルーティングされますが、resource.labels.project_id は PROJECT_TWO としてラベル付けされます。

回避策:

次のいずれかの方法で問題を解決します。

  • 同じ宛先プロジェクトのサービス アカウントを使用します。
  • サービス アカウント キーの JSON ファイルの project_id を現在のプロジェクトに変更します。
  • ログ エクスプローラのログフィルタで project_id を直接変更します。
ネットワーキング 1.29、1.30

BGP でバンドル型ロード バランシングを使用するバージョン 1.29.0 のクラスタの場合、LoadBalancer タイプの Service の合計数が 2,000 に近づくと、ロード バランシングのパフォーマンスが低下する可能性があります。パフォーマンスが低下すると、新しく作成されたサービスは接続に時間がかかるか、クライアントから接続できなくなります。既存の Service は引き続き機能しますが、ロードバランサ ノードの損失などの障害モードを効果的に処理しません。これらのサービスの問題は、メモリ不足により ang-controller-manager Deployment が終了したときに発生します。

クラスタがこの問題の影響を受ける場合、クラスタ内の Service にはアクセスできず、正常ではありません。ang-controller-manager Deployment は CrashLoopBackOff にあります。ang-controller-manager デプロイを一覧表示する際のレスポンスは次のようになります。

ang-controller-manager-79cdd97b88-9b2rd   0/1    CrashLoopBackOff   639 (59s ago)   2d10h   10.250.210.152   vm-bgplb-centos4-n1-02   <none>   <none>

ang-controller-manager-79cdd97b88-r6tcl   0/1   CrashLoopBackOff   620 (4m6s ago)   2d10h   10.250.202.2     vm-bgplb-centos4-n1-11   <none>   <none>

回避策

回避策として、ang-controller-manager Deployment のメモリリソースの上限を 100 MiB 増やし、CPU 上限を解除します。

kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG

変更が正常に完了してエディタを閉じると、次の出力が表示されます。 

deployment.apps/ang-controller-manager edited

変更が適用されたことを確認するには、クラスタ内の ang-controller-manager のマニフェストを調べます。 

kubectl get deployment ang-controller-manager \
   -n kube-system \
   -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \
   --kubeconfig ADMIN_KUBECONFIG

レスポンスは次のようになります。 

NAME                     CPU_LIMITS   MEMORY_LIMITS
ang-controller-manager   <none>       400Mi
インストール、アップグレード、バックアップと復元 1.28.0, 1.28.100

管理クラスタの複数のクラスタ オペレーションでブートストラップ クラスタが作成されます。ブートストラップ クラスタを作成する前に、bmctl は管理ワークステーションから Google Cloud 到達可能性チェックを実行します。このチェックは、Artifact Registry エンドポイント gcr.io との接続の問題が原因で失敗することがあります。次のようなエラー メッセージが表示されることがあります。

        system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

回避策

この問題を回避するには、--ignore-validation-errors フラグを指定してオペレーションを再試行します。
ネットワーキング 1.15, 1.16

ベアメタル クラスタは GKE Dataplane V2 を使用しますが、これは一部のストレージ プロバイダと互換性がありません。NFS ボリュームや Pod の停止に関する問題が発生する可能性があります。この問題の影響を受けやすいストレージ ドライバを基盤とする ReadWriteMany ボリュームを使用するワークロードがある場合は、特にこの問題が発生しやすくなります。

  • Robin.io
  • Portworx（sharedv4 サービスのボリューム）
  • csi-nfs

このリストはすべてを網羅したものではありません。

回避策

この問題の修正は、次の Ubuntu バージョンで利用できます。

  • 20.04 LTS: linux-image-5.4.0-166-generic より新しい 5.4.0 カーネル イメージを使用する
  • 22.04 LTS: linux-image-5.15.0-88-generic より後の 5.15.0 カーネル イメージを使用するか、6.5 HWE カーネルを使用します。

これらのバージョンを使用していない場合は、Google サポートにお問い合わせください。
ロギングとモニタリング 1.15、1.16、1.28

kube-state-metrics と同じノードに存在する kube-state-metrics または gke-metrics-agent Pod でメモリ不足（OOM）が発生していることがあります。

これは、50 個を超えるノードがあるクラスタや、多くの Kubernetes オブジェクトがあるクラスタで発生する可能性があります。

回避策

この問題を解決するには、ksmNodePodMetricsOnly フィーチャー ゲートを使用するように stackdriver カスタム リソース定義を更新します。このフィーチャー ゲートでは、少数の重要な指標のみが公開されるようにします。

この回避策を使用する手順は次のとおりです。

  1. 使用可能なフィーチャー ゲートについて、stackdriver カスタム リソース定義を確認します。
    kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
  2. stackdriver カスタム リソース定義を更新して、ksmNodePodMetricsOnly を有効にします。
    kind:stackdriver
spec:
  featureGates:
     ksmNodePodMetricsOnly: true
インストール 1.28.0-1.28.200

Red Hat Enterprise Linux（RHEL）9.2 オペレーティング システムにクラスタをインストールすると、iptables パッケージがないため、インストールが失敗することがあります。このエラーはプリフライト チェック中に発生し、次のようなエラー メッセージがトリガーされます。

'check_package_availability_pass': "The following packages are not available: ['iptables']"

RHEL 9.2 は、Google Distributed Cloud バージョン 1.28 のプレビュー版です。

回避策

クラスタ リソースで spec.bypassPreflightCheck を true に設定して、プリフライト チェック エラーをバイパスします。
オペレーション 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

MetalLB が多数のサービス（10,000 を超える）を処理する場合、フェイルオーバーに 1 時間以上かかることがあります。これは、MetalLB がレート制限されたキューを使用しており、高スケールの場合、フェイルオーバーが必要なサービスに到達するまでに時間がかかることがあるためです。

回避策

クラスタをバージョン 1.28 以降にアップグレードします。アップグレードできない場合は、サービスを手動で編集（アノテーションの追加など）すると、サービスがより早くフェイルオーバーします。
オペレーション 1.16.0-1.16.6, 1.28.0-1.28.200

管理ワークステーションで環境変数 HTTPS_PROXY と NO_PROXY が定義されていない場合、プロキシの障害により bmctl check cluster が失敗する可能性があります。bmctl コマンドは、次の例のように、一部の Google サービスの呼び出しに失敗したというエラー メッセージを報告します。

[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

回避策

管理ワークステーションで HTTPS_PROXY と NO_PROXY を手動で設定します。
アップグレードと更新 1.28.0-gke.435

場合によっては、コントロール プレーン ノードの /var/log/apiserver/audit.log ファイルで、グループとユーザーの所有権の両方が root に設定されていることがあります。このファイル所有権の設定により、クラスタをバージョン 1.16.x からバージョン 1.28.0-gke.435 にアップグレードするときに、コントロール プレーン ノードのアップグレード エラーが発生します。この問題は、バージョン 1.11 より前に作成され、Cloud Audit Logs が無効になっているクラスタにのみ適用されます。バージョン 1.9 以降のクラスタでは、Cloud Audit Logs がデフォルトで有効になっています。

回避策

クラスタをバージョン 1.28.100-gke.146 にアップグレードできない場合は、回避策として次の手順に沿ってクラスタをバージョン 1.28.0-gke.435 にアップグレードしてください。

  • Cloud Audit Logs が有効になっている場合は、/var/log/apiserver/audit.log ファイルを削除します。
  • Cloud Audit Logs が無効になっている場合は、/var/log/apiserver/audit.log の所有権が親ディレクトリ /var/log/apiserver と同じになるよう変更します。
ネットワーキング、アップグレード、アップデート 1.28.0-gke.435

Google Distributed Cloud は、バンドル型ロード バランシングに MetalLB を使用します。Google Distributed Cloud リリース 1.28.0-gke.435 では、バンドルされた MetalLB がバージョン 0.13 にアップグレードされ、IPAddressPools の CRD サポートが導入されています。ただし、ConfigMaps では IPAddressPool に任意の名前を使用できるため、IPAddressPool の名前の末尾にハッシュを追加して、プール名を Kubernetes 準拠の名前に変換する必要がありました。 たとえば、クラスタをバージョン 1.28.0-gke.435 にアップグレードすると、default という名前の IPAddressPool は default-qpvpd のような名前に変換されます。

MetalLB では選択で IPPool の特定の名前が必要とされるため、名前を変換することにより、MetalLB でプールの選択や IP アドレスの割り当てを行えなくなります。したがって、IP アドレスのアドレスプールを選択するためのアノテーションとして metallb.universe.tf/address-pool を使用するサービスでは、MetalLB コントローラから IP アドレスを受信しなくなります。

この問題は、Google Distributed Cloud バージョン 1.28.100-gke.146 で修正されています。

回避策

クラスタをバージョン 1.28.100-gke.146 にアップグレードできない場合は、回避策として次の手順を使用します。

  1. IPAddressPool の変換後の名前を取得します。
    kubectl get IPAddressPools -n kube-system
  2. 影響を受ける Service を更新して、metallb.universe.tf/address-pool アノテーションをハッシュで変換された名前に設定します。

    たとえば、IPAddressPool 名が default から default-qpvpd などの名前に変換されている場合は、Service のアノテーション metallb.universe.tf/address-pool: default を metallb.universe.tf/address-pool: default-qpvpd に変更します。

名前変換で使用されるハッシュは確定的であるため、回避策は永続的です。
アップグレードと更新 1.14、1.15、1.16、1.28、1.29

クラスタをバージョン 1.14.x にアップグレードすると、以前のバージョンのリソースの一部が削除されません。具体的には、次のような孤立した Pod のセットが表示されることがあります。

capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

これらの孤立したオブジェクトはクラスタ オペレーションに直接影響しませんが、ベスト プラクティスとして削除することをおすすめします。

  • 次のコマンドを実行して、孤立したオブジェクトを削除します。
    kubectl delete ns capi-webhook-system
kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration

この問題は、Google Distributed Cloud バージョン 1.15.0 以降で修正されています。
インストール 1.14

Google Distributed Cloud バージョン 1.14.x をインストールしようとすると、次の出力例のように、machine-init ジョブが原因で失敗することがあります。

"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

回避策:

machine-init ジョブの失敗の原因となる古い etcd メンバーを削除します。機能しているコントロール プレーンノードで次の手順を完了します。

  1. 既存の etcd メンバーを一覧表示します。
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member list
     次の出力例に示すように、ステータスが unstarted のメンバーを探します。
    5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
  2. 失敗した etcd メンバーを削除します。
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member remove MEMBER_ID
     MEMBER_ID は、失敗した etcd メンバーの ID に置き換えます。上記の出力例では、この ID は bd1949bcb70e2cb5 です。

    次の出力例は、メンバーが削除されたことを示しています。
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
ネットワーキング 1.28.0

Cilium 1.13 では、cilium-operator ClusterRole の権限が正しくありません。Node の list 権限と watch 権限がありません。cilium-operator がガベージ コレクタを起動できず、その結果、次の問題が発生します。

  • Cilium リソースのリーク。
  • 古い ID は BFP ポリシーマップから削除されません。
  • ポリシーマップが 16,000 の上限に達する場合があります。
    • 新しいエントリを追加できません。
    • NetworkPolicy の適用が正しくありません。
  • ID が 64,000 の上限に達する場合があります。
    • 新しい Pod を作成できない。

ノード権限がないオペレーターは、次のログメッセージの例を報告します。

2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

Cilium エージェントは、ポリシーマップにエントリを挿入できない場合に、次のようなエラー メッセージを報告します。

level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

回避策:

Cilium ID を削除し、不足している ClusterRole 権限をオペレーターに追加します。

  1. 既存の CiliumIdentity オブジェクトを削除します。
    kubectl delete ciliumid –-all
  2. cilium-operator ClusterRole オブジェクトを編集します。
    kubectl edit clusterrole cilium-operator
  3. 次の例に示すように、不足している権限を含む nodes のセクションを追加します。
    - apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  4. 保存してエディタを閉じます。オペレーターは権限の変更を動的に検出します。オペレーターを手動で再起動する必要はありません。
アップグレードと更新 1.15.0-1.15.7、1.16.0-1.16.3

アップグレードのプリフライト チェック中に実行される kubeadm ヘルスチェック タスクの一つが失敗し、次のエラー メッセージが表示される場合があります。

[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

このエラーは無視して問題ありません。アップグレードをブロックするこのエラーが発生した場合は、アップグレード コマンドを再実行します。

bmctl preflightcheck コマンドを使用して事前チェックを実行したときにこのエラーが発生しても、このエラーによってブロックされることはありません。プリフライト チェックを再度実行して、正確なプリフライト情報を取得できます。


回避策:

アップグレード コマンドを再実行します。bmctl preflightcheck で発生した場合は、preflightcheck コマンドを再実行します。
オペレーション 1.14、1.15.0-1.15.7、1.16.0-1.16.3、1.28.0

この問題は、ノードの置換または削除後に定期的にネットワーク ヘルスチェックを実行するクラスタに影響します。クラスタで定期的なヘルスチェックが実施された場合、この定期的なネットワーク ヘルスチェックは、ノードの置換や削除後に失敗します。これは、ネットワーク インベントリ ConfigMap は作成後に更新されないためです。


回避策:

回避策として、インベントリの ConfigMap と定期的なネットワーク ヘルスチェックを削除することをおすすめします。クラスタ オペレータが、最新の情報を使用して自動的に再作成します。

1.14.x クラスタの場合は、次のコマンドを実行します。

kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

1.15.0 以降のクラスタの場合は、次のコマンドを実行します。

kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
ネットワーキング 1.14、1.15、1.16.0-1.16.2

ネットワーク デバイスの名前がピリオド（.）が含まれる bond0.2 などの場合、Network Gateway for GDC は、sysctl を実行して変更を加える際にピリオドをディレクトリ内のパスとして扱います。Network Gateway for GDC が重複アドレス検出（DAD）が有効になっているかどうかを確認する場合、チェックが失敗するため調整されない可能性があります。

クラスタのバージョン間で動作は異なります。

  • 1.14 と 1.15: このエラーは、IPv6 フローティング IP アドレスを使用する場合にのみ発生します。IPv6 フローティング IP アドレスを使用しない場合、デバイス名にピリオドが含まれていると、この問題に気づくことはできません。
  • 1.16.0～1.16.2: このエラーは、デバイス名にピリオドが含まれている場合に常に発生します。

回避策:

クラスタをバージョン 1.16.3 以降にアップグレードします。

クラスタをアップグレードできる状態になるまでの回避策として、デバイスの名前からピリオド（.）を削除します。
アップグレードとアップデート、ネットワーキング、セキュリティ 1.16.0

クラスタで seccomp が無効になっている（spec.clusterSecurity.enableSeccomp を false に設定）場合は、バージョン 1.16.0 へのアップグレードは失敗します。

Google Distributed Cloud バージョン 1.16 は、Kubernetes バージョン 1.27 を使用します。Kubernetes バージョン 1.27.0 以降では、seccomp プロファイルを設定する機能は一般提供されており、フィーチャー ゲートは使用されません。この Kubernetes の変更により、クラスタ構成で seccomp が無効になっている場合、バージョン 1.16.0 へのアップグレードが失敗します。この問題は、バージョン 1.16.1 以降のクラスタで修正されています。cluster.spec.clusterSecurity.enableSeccomp フィールドが false に設定されている場合は、バージョン 1.16.1 以降にアップグレードできます。

spec.clusterSecurity.enableSeccomp が未設定か、true に設定されているクラスタは影響を受けません。
インストール、オペレーション 1.11、1.12、1.13、1.14、1.15.0-1.15.5、1.16.0-1.16.1

/var/lib/containerd をマウントしている場合、再起動後に containerd メタデータが破損する可能性があります。メタデータが破損すると、システム クリティカルな Pod を含む Pod が失敗する可能性があります。

この問題の影響を受けるかどうかを確認するには、/var/lib/containerd/ の /etc/fstab でオプションのマウントが定義され、マウント オプションに nofail が含まれているかどうかを確認します。


回避策:

/etc/fstab の nofail マウント オプションを削除するか、クラスタをバージョン 1.15.6 以降にアップグレードします。
オペレーション 1.13、1.14、1.15、1.16、1.28

Deployment（ReplicaSet）によって管理されている Pod が Failed 状態で TaintToleration ステータスとして表示される場合があります。これらの Pod はクラスタ リソースを使用しませんが、削除する必要があります。

次の kubectl コマンドを使用して、クリーンアップ可能な Pod を一覧表示できます。

kubectl get pods –A | grep TaintToleration

次の出力例は、TaintToleration ステータスの Pod を示しています。

kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

回避策:

説明されている症状を持つ各 Pod について、Pod が属する ReplicaSet を確認します。ReplicaSet が満たされている場合は、Pod を削除できます。

  1. Pod を管理する ReplicaSet を取得し、ownerRef.Kind 値を見つけます。
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
  2. ReplicaSet を取得し、status.replicas が spec.replicas と同じであることを確認します。
    kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
  3. 名前が一致する場合は、Pod を削除します。
    kubectl delete pod POD_NAME -n NAMESPACE.
アップグレード 1.16.0

既存のクラスタをバージョン 1.16.0 にアップグレードすると、etcd イベントに関連する Pod の障害によりオペレーションが停止する場合があります。具体的には、TASK [etcd_events_install : Run etcdevents] ステップで upgrade-node ジョブが失敗します。

この問題の影響を受けている場合は、次のような Pod の障害が発生します。

  • kube-apiserver Pod が次のエラーで起動に失敗します。
    connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
  • etcd-events Pod が次のエラーで起動に失敗します。
    Error: error syncing endpoints with etcd: context deadline exceeded

回避策:

修正でクラスタをバージョンにアップグレードできない場合は、次の一時的な回避策を使用してエラーに対処してください。

  1. SSH を使用して、エラーが報告されたコントロール プレーン ノードにアクセスします。
  2. etcd-events マニフェスト ファイル /etc/kubernetes/manifests/etcd-events.yaml を編集し、initial-cluster-state=existing フラグを削除します。
  3. マニフェストを適用します。
  4. アップグレードは続行されます。
ネットワーキング 1.15.0～1.15.2

OrderPolicy がパラメータとして認識されないため、使用されません。代わりに、Google Distributed Cloud は常に Random を使用します。

この問題は、CoreDNS テンプレートが更新されておらず、orderPolicy が無視されることが原因で発生します。


回避策:

CoreDNS テンプレートを更新して修正を適用します。この修正は、アップグレードするまで維持されます。

  1. 既存のテンプレートを編集します。
    kubectl edit cm -n kube-system coredns-template
     ファイルの内容を次のコードで置き換えます。
    coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
ネットワーキング、オペレーション 1.10, 1.11, 1.12, 1.13, 1.14

kube-system のネットワーク ゲートウェイ Pod には、次の要約した出力例に示すように、Pending または Evicted のステータスが表示される場合があります。

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

これらのエラーは、ノードのリソースを原因とする強制排除イベント、または Pod のスケジューリング不能を示しています。Network Gateway for GDC Pod には PriorityClass がないため、他のワークロードと同じデフォルトの優先度が設定されます。ノードにリソース制約がある場合、ネットワーク ゲートウェイ Pod が強制終了される可能性があります。この動作は特に、ang-node DaemonSet では問題になります。これらの Pod は、特定のノードでスケジュールする必要があり、移動することはできません。


回避策:

1.15 以降にアップグレードします。

短期的な解決策として、Network Gateway for GDC コンポーネントに PriorityClass を手動で割り当てる方法があります。Google Distributed Cloud コントローラは、クラスタのアップグレードなどの調整プロセス中に、こうした手動による変更を上書きします。

  • system-cluster-critical PriorityClass を ang-controller-manager と autoscaler のクラスタ コントローラの Deployment に割り当てます。
  • system-node-critical PriorityClass を ang-daemon ノードの DaemonSet に割り当てます。
インストール、アップグレード、更新 1.15.0、1.15.1、1.15.2

クラスタ名が 48 文字（バージョン 1.15.0）、または 45 文字（バージョン 1.15.1 または 1.15.2）を超えると、バージョン 1.15.0、1.15.1、1.15.2 のクラスタの作成や、バージョン 1.15.0、1.15.1、1.15.2 へのアップグレードが失敗します。クラスタの作成とアップグレードのオペレーション中に、Google Distributed Cloud は、クラスタ名とバージョンを組み込む名前のヘルスチェック リソースを作成します。

  • バージョン 1.15.0 のクラスタでは、ヘルスチェックのリソース名は CLUSTER_NAME-add-ons-CLUSTER_VER です。
  • バージョン 1.15.1 または 1.15.2 のクラスタでは、ヘルスチェックのリソース名は CLUSTER_NAME-kubernetes-CLUSTER_VER です。

長いクラスタ名の場合、ヘルスチェック リソース名はラベル名に対する Kubernetes における 63 文字の長さの制限を超え、これによりヘルスチェック リソースの作成が妨げられます。ヘルスチェックが成功しなかった場合、クラスタ オペレーションは失敗します。

この問題の影響を受けるかどうかを確認するには、kubectl describe を使用して失敗したリソースを確認します。

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

この問題の影響を受けている場合は、レスポンスに次のような ReconcileError の警告が含まれています。

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

回避策

クラスタのアップグレードや作成のブロックを解除するために、ヘルスチェックをバイパスできます。次のコマンドを使用して、ヘルスチェックのカスタム リソースに (status: {pass: true}) ステータスのパッチを適用します。

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
アップグレードと更新 1.14、1.15

バージョン 1.14.0 と 1.14.1 のクラスタでプレビュー機能が有効になっている場合、それらからバージョン 1.15.x へのアップグレードが正常にブロックされます。これは、kube-proxy なしのクラスタを作成する機能などのプレビュー機能に適用されます。これはクラスタ構成ファイルで次のアノテーション付きで有効になっています。

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

この問題の影響を受けると、クラスタのアップグレード中に次のようなエラーが発生します。

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

この問題は、バージョン 1.14.2 以降のクラスタで修正されています。


回避策:

クラスタをバージョン 1.15.x にアップグレードする前に、バージョン 1.14.2 以降にアップグレードできない場合は、ブートストラップ クラスタを使用してバージョン 1.15.x に直接アップグレードできます。

bmctl upgrade cluster --use-bootstrap=true
オペレーション 1.15

GDC 用ネットワーク ゲートウェイでは、既存の NetworkGatewayGroup カスタム リソースですでに使用されている spec.floatingIPs の IP アドレスを含む新しい NetworkGatewayGroup カスタム リソースを作成できません。このルールは、ベアメタル クラスタ バージョン 1.15.0 以降の Webhook によって適用されます。既存の重複するフローティング IP アドレスはエラーの原因になりません。Webhook は、重複する IP アドレスを含む新しい NetworkGatewayGroups カスタム リソースの作成のみを禁止します。

Webhook エラー メッセージによって、競合する IP アドレスと、すでに使用されている既存のカスタム リソースが識別されます。

IP address exists in other gateway with name default

下り（外向き）NAT ゲートウェイなどの高度なネットワーク機能の最初のドキュメントでは、IP アドレスの重複は考慮されません。最初は、default という名前の NetworkGatewayGroup リソースのみが Reconciler によって認識されていました。GDC 用 Network Gateway は現在、システム名前空間内のすべての NetworkGatewayGroup カスタム リソースを認識します。既存の NetworkGatewayGroup カスタム リソースはそのまま扱われます。


回避策:

エラーは、新しい NetworkGatewayGroup カスタム リソースの作成時にのみ発生します。

エラーを処理するには、次のようにします。

  1. 次のコマンドを使用して、NetworkGatewayGroups カスタム リソースを一覧表示します。
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system -o yaml
  2. 既存の NetworkGatewayGroup カスタム リソースを開き、競合するフローティング IP アドレス（spec.floatingIPs）を削除します。
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system RESOURCE_NAME
  3. 変更を適用するには、編集したカスタム リソースを閉じて保存します。
GDC 上の VM ランタイム 1.13.7

プライベート レジストリを使用する新規またはアップグレードされたバージョン 1.13.7 のクラスタで GDC 上の VM ランタイムを有効にすると、ノード ネットワークに接続する、または GPU を使用する VM が正しく起動しない場合があります。この問題は、vm-system Namespace の一部のシステム Pod でイメージ プルエラーが発生することが原因です。たとえば、VM でノード ネットワークを使用している場合、一部の Pod では以下のようなイメージの pull エラーが報告されることがあります。

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

この問題は、バージョン 1.14.0 以降のクラスタで修正されています。

回避策

クラスタを直ちにアップグレードできない場合は、手動でイメージを pull できます。次のコマンドは、VM の macvtap CNI プラグイン イメージを pull し、非公開レジストリに push します。

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

REG_HOST は、ローカルにミラーリングするホストのドメイン名に置き換えます。
インストール 1.11, 1.12

kind クラスタ内でクラスタを作成している間、次のようなイメージの pull エラーのため、gke-metrics-agent Pod が起動しません。

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

また、ブートストラップ クラスタの containerd ログに次のエントリが表示されます。

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Pod に次の「failing to pull」エラーが表示されます。

gcr.io/gke-on-prem-staging/gke-metrics-agent

回避策

kind クラスタ内での gke-metrics-agent Pod の目的は、クラスタ作成の成功率を促進することと、内部トラッキングとモニタリングであるため、エラーにもかかわらず、クラスタ作成プロセスはブロックされません。そのため、このエラーは無視して問題ありません。

回避策

kind クラスタ内での gke-metrics-agent Pod の目的は、クラスタ作成の成功率を促進することと、内部トラッキングとモニタリングであるため、エラーにもかかわらず、クラスタ作成プロセスはブロックされません。そのため、このエラーは無視して問題ありません。
オペレーション、ネットワーキング 1.12、1.13、1.14、1.15、1.16、1.28

デュアルスタック Service（IPv4 と IPv6 の両方のエンドポイントを持つ Service）にアクセスして IPv6 エンドポイントを使用すると、Service を提供する LoadBalancer ノードがクラッシュする場合があります。この問題は、CentOS または RHEL でデュアル スタック サービスを使用し、kernel-4.18.0-372.46.1.el8_6 より前のカーネル バージョンを使用しているお客様に影響します。

この問題の影響を受けていると思われる場合は、uname -a コマンドを使用して LoadBalancer ノードのカーネル バージョンを確認します。


回避策:

LoadBalancer ノードをカーネル バージョン kernel-4.18.0-372.46.1.el8_6 以降に更新します。このカーネル バージョンは、CentOS と RHEL バージョン 8.6 以降でデフォルトで使用できます。
ネットワーキング 1.11、1.12、1.13、1.14.0

ノードを再起動した後、NodePort または LoadBalancer Service の断続的な接続問題が発生することがあります。たとえば、断続的な TLS handshake または接続リセットエラーが発生する場合があります。この問題は、クラスタ バージョン 1.14.1 以降で修正されています。

この問題の影響を受けているかどうかを確認するには、影響を受ける Service のバックエンド Pod が実行されているノードの iptables 転送ルールを確認します。

sudo iptables -L FORWARD

iptables の CILIUM_FORWARD ルールの前に KUBE-FORWARD ルールが表示されている場合は、この問題の影響を受けている場合があります。次の出力例は、問題が存在するノードを示しています。

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

回避策:

正しく構成されていない ノードで anetd Pod を再起動します。anetd Pod を再起動すると、iptables の転送ルールが正しく構成されます。

次の出力例は、CILIUM_FORWARD ルールが KUBE-FORWARD ルールの前に正しく構成されていることを示しています。

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
アップグレードと更新 1.9, 1.10

bmctl 1.9.x を使用する 1.9.x クラスタのプレビュー機能では、元の権限とオーナー情報が保持されません。この機能の影響を受けているかどうかを確認するには、次のコマンドを使用してバックアップ ファイルを抽出します。

tar -xzvf BACKUP_FILE

回避策

metadata.json が存在するか、bmctlVersion が 1.9.x であるかを確認します。metadata.json が存在しない場合は、1.10.x クラスタにアップグレードし、bmctl 1.10.x を使用してバックアップ/復元します。
アップグレードと作成 1.14.2

OIDC/LDAP 構成でバージョン 1.14.2 クラスタにアップグレードしたまたはそれを作成した場合は、clientconfig-operator Pod が保留状態のままになる場合があります。この問題では、2 つの clientconfig-operator Pod のうち 1 つが実行状態になり、もう 1 つが保留状態になります。

この問題は、バージョン 1.14.2 のクラスタにのみ該当します。1.14.0 や 1.14.1 などの以前のクラスタ バージョンは影響を受けません。この問題は、バージョン 1.14.3 と 1.15.0 以降を含むすべての後続のリリースで修正されています。


回避策:

回避策として、clientconfig-operator デプロイにパッチを適用して、追加のセキュリティ コンテキストを追加し、デプロイの準備が整っていることを確認します。

次のコマンドを使用して、ターゲット クラスタ内の clientconfig-operator にパッチを適用します。

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

以下を置き換えます。

  • CLUSTER_KUBECONFIG: ターゲット クラスタの kubeconfig ファイルのパス。
オペレーション 1.11、1.12、1.13、1.14、1.15

バンドル型ロード バランシングが実施されないクラスタ（spec.loadBalancer.mode が manual に設定されている）の場合は、bmctl update credentials certificate-authorities rotate コマンドが応答しなくなり、x509: certificate signed by unknown authority のエラーで失敗する可能性があります。

この問題の影響を受けると、bmctl コマンドから応答しなくなる前に、次のメッセージが出力される可能性があります。

Signing CA completed in 3/0 control-plane nodes

この場合、コマンドは最終的に失敗します。3 つのコントロール プレーンを持つクラスタのローテーション認証局ログに、次のようなエントリが含まれる場合があります。

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

回避策

さらにサポートを必要とされる場合は、Google サポートにお問い合わせください。
インストール、ネットワーキング 1.11、1.12、1.13、1.14.0-1.14.1

デュアルスタック クラスタ（IPv4 と IPv6 アドレスの両方を持つクラスタ）をデプロイすると、ipam-controller-manager Pod がクラッシュループする場合があります。この動作により、ノードは Ready と NotReady の状態で循環し、クラスタのインストールが失敗する可能性があります。この問題は、API サーバーが高負荷の場合に発生する可能性があります。

この問題の影響を受けているかどうかを確認するには、ipam-controller-manager Pod が CrashLoopBackOff エラーで失敗しているかどうかを確認します。

kubectl -n kube-system get pods | grep  ipam-controller-manager

次の出力例は、CrashLoopBackOff 状態の Pod を示しています。

ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

NotReady 状態のノードの詳細を取得します。

kubectl describe node <node-name> | grep PodCIDRs

この問題が発生しているクラスタでは、次の出力例に示すように、ノードに PodCIDR が割り当てられていません。

PodCIDRs:

正常なクラスタでは、次の出力例に示すように、すべてのノードにデュアル スタック PodCIDR が割り当てられます。

PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

回避策:

ipam-controller-manager Pod を再起動します。

kubectl -n kube-system rollout restart ds ipam-controller-manager
オペレーション 1.6、1.7、1.8、1.9、1.10、1.11、1.12、1.13、1.14

etcd バージョン 3.4.13 以前を実行しているクラスタで、ウォッチが不足したり、動作していないリソースのウォッチが発生する場合があります。これにより、次の問題が発生する可能性があります。

  • Pod のスケジューリングが中断される
  • ノードが登録できない
  • kubelet が Pod の変更をモニタリングしない

これらの問題により、クラスタが機能しなくなる場合があります。

この問題は、Google Distributed Cloud バージョン 1.12.9、1.13.6、1.14.3 以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 が使用されています。Google Distributed Cloud の以前のバージョンはすべて、この問題の影響を受けます。

回避策

直ちにアップグレードできない場合は、クラスタ内のノード数を減らすことで、クラスタ障害のリスクを軽減できます。etcd_network_client_grpc_sent_bytes_total 指標が 300 MBps 未満になるまでノードを削除します。

この指標を Metrics Explorer で表示するには:

  1. Google Cloud コンソールで [Metrics Explorer] に移動します。

    Metrics Explorer に移動

  2. [Configuration] タブを選択します。
  3. [指標の選択] を展開し、フィルタバーに「Kubernetes Container」と入力してから、サブメニューを使用して指標を選択します。
    1. [有効なリソース] メニューで [Kubernetes コンテナ] を選択します。
    2. [有効な指標カテゴリ] メニューで [Anthos] を選択します。
    3. [アクティブな指標] メニューで [etcd_network_client_grpc_sent_bytes_total] を選択します。
    4. [適用] をクリックします。
ネットワーキング 1.11.6、1.12.3

SriovNetworkNodeState オブジェクトの syncStatus は、構成されたノードの「Failed」値をレポートできます。ノードのステータスを表示し、問題が影響を受けるかどうかを判断するには、次のコマンドを実行します。

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

NODE_NAME は、確認するノードの名前に置き換えます。


回避策:

SriovNetworkNodeState オブジェクトのステータスが「失敗」の場合は、クラスタをバージョン 1.11.7 以降またはバージョン 1.12.4 以降にアップグレードします。
アップグレードと更新 1.10、1.11、1.12、1.13、1.14.0、1.14.1

アップグレードが完了すると、一部のワーカーノードの Ready 条件が false に設定されることがあります。ノード リソースで、次の例のような Ready 条件の横にエラーが表示されます。

container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

停止しているマシンにログインすると、マシンの CNI 構成は空になります。

sudo ls /etc/cni/net.d/

回避策

ノードの anetd Pod を削除して再起動します。
アップグレードと更新、セキュリティ 1.10

複数の手動または自動証明書ローテーションを行った後、anthos-cluster-operator などの Webhook Pod は、cert-manager によって発行された新しい証明書で更新されません。クラスタのカスタム リソースを更新すると、失敗し、次のようなエラーが発生します。

Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

この問題は、次のような状況で発生する場合があります。

  • 180 日以上経過したクラスタで、2 つの cert-manager 発行の証明書を手動ローテーションし、anthos-cluster-operator を再起動していない場合。
  • 90 日以上経過したクラスタで、cert-manager 発行の証明書を手動ローテーションし、anthos-cluster-operator を再起動していない場合。

回避策

anthos-cluster-operator を終了して Pod を再起動します。
アップグレードと更新 1.14.0

バージョン 1.14.0 の管理クラスタでは、ユーザー クラスタのアップグレード中に 1 つ以上の古いライフサイクル コントローラ デプロイヤー Pod が作成されることがあります。この問題は、最初に 1.12 より前のバージョンで作成されたユーザー クラスタに見られます。意図せずに作成された Pod はアップグレード オペレーションを妨げませんが、予期しない状態になっている場合があります。古い Pod を削除することをおすすめします。

この問題はリリース 1.14.1 で修正されています。

回避策:

古いライフサイクル コントローラ デプロイヤー Pod を削除するには:

  1. プリフライト チェック リソースを一覧表示します。
    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

    出力は次のようになります。

    NAMESPACE                    NAME                      PASS   AGE
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

    ここで、ci-87a021b9dcbb31c はクラスタ名です。

  2. PASS 列の値が true または false のリソースを削除します。

    たとえば、上記のサンプル出力のリソースを削除するには、次のコマンドを使用します。

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG 
kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG
ネットワーキング 1.9、1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

外部ピアが多数のルート（約 100 以上）をアドバタイズすると、Google Distributed Cloud の高度なネットワーキングは BGP セッションを正しく管理できません。受信ルートが多数存在する場合、ノードローカルの BGP コントローラは BGP セッションの調整に時間がかかりすぎて、ステータスを更新できません。ステータス更新、またはヘルスチェックが実施されないと、セッションは古くなるため削除されます。

問題が起きたことを示す可能性がある BGP セッションでの望ましくない動作には、次のようなものがあります。

  • bgpsession の削除と再作成を継続的に行う。
  • bgpsession.status.state が Established にならない
  • ルートのアドバタイズに失敗する、または繰り返しアドバタイズされて取り消されます。

BGP ロード バランシングの問題は、LoadBalancer サービスへの接続の問題で顕著になっている可能性があります。

BGP FlatIP の問題は、Pod への接続の問題で顕著になっている可能性があります。

リモートピアでのアドバタイジングのルートが多すぎるために BGP の問題が発生しているかどうかを判断するには、次のコマンドを使用して関連するステータスと出力を確認します。

  • 影響を受けるクラスタで kubectl get bgpsessions を使用します。出力には、「Not Established」の状態とともに bgpsessions が表示され、最終レポート時間が、ゼロにリセットされるまで最大 10 ～ 12 秒継続的にカウントされます。
  • kubectl get bgpsessions の出力には、影響を受けるセッションが繰り返し再作成されていることが示されます。
    kubectl get bgpsessions \
    -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
  • 最新ではない BGP セッションが削除されたことを示すログメッセージ。 
    kubectl logs ang-controller-manager-POD_NUMBER

    POD_NUMBER は、クラスタ内のリーダー Pod に置き換えます。


回避策:

エクスポート ポリシーで、リモートピアからクラスタにアドバタイズされるルートの数を減らすか、なくします。

クラスタ バージョン 1.14.2 以降では、AddOnConfiguration を使用して、受信したルートを処理する機能を無効にすることもできます。ang-daemon DaemonSet の bgpd コンテナに --disable-received-routes 引数を追加します。
ネットワーキング 1.14、1.15、1.16、1.28

カーネル 5.15 以降を使用する Ubuntu OS で実行されているクラスタは、netfilter 接続トラッキング（conntrack）テーブルの挿入エラーの影響を受けやすくなります。conntrack テーブルに新しいエントリの余地があっても、挿入エラーが発生する可能性があります。エラーは、チェーン長に基づいてテーブルの挿入を制限するカーネル 5.15 以降の変更が原因です。

この問題の影響を受けるかどうかを確認するには、次のコマンドでカーネル内の接続トラッキング システムの統計情報を確認します。

sudo conntrack -S

レスポンスは次のようになります。

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

レスポンスの chaintoolong 値がゼロ以外であれば、この問題の影響を受けています。

回避策

短期的な緩和策としては、netfiler ハッシュ テーブル（nf_conntrack_buckets）と netfilter 接続トラッキング テーブル（nf_conntrack_max）の両方のサイズを拡大します。テーブルのサイズを拡大するには、各クラスタノードで次のコマンドを実行します。

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

TABLE_SIZE は、新しいサイズ（バイト数）に置き換えます。デフォルトのテーブルサイズ値は 262144 です。ノードのコア数の 65,536 倍に等しい値を設定することをおすすめします。たとえば、ノードに 8 個のコアがある場合は、テーブルサイズを 524288 に設定します。
アップグレードと更新 1.11.3、1.11.4、1.11.5、1.11.6、1.11.7、1.11.8、1.12.4、1.12.5、1.12.6、1.12.7、1.12.8、1.13.4、1.13.5

アップグレードが失敗した場合に以前のバージョンを復元できるように、アップグレードする前にクラスタをバックアップすることをおすすめします。bmctl restore cluster コマンドの問題により、特定されたバージョンのクラスタのバックアップを復元できません。この問題は、以前のバージョンのバックアップを復元するアップグレードに特有です。

クラスタが影響を受ける場合、bmctl restore cluster ログに次のエラーが含まれます。

Error: failed to extract image paths from profile: anthos version VERSION not supported

回避策:

この問題が解決するまで、クラスタのバックアップと復元の手順に沿ってクラスタを手動でバックアップし、必要に応じて手動で復元することをおすすめします。
ネットワーキング 1.10、1.11、1.12、1.13、1.14.0-1.14.2

NetworkGatewayGroup は、IPv4 インターフェースと IPv6 インターフェースの両方を持たないノードのデーモンを作成できません。これにより、BGP LB や EgressNAT などの機能が失敗します。kube-system 名前空間で失敗した ang-node Pod のログを確認した場合、IPv6 アドレスが欠落していると、次のようなエラーが表示されます。

ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

前の例では、ens192 インターフェースに IPv6 アドレスがありません。ノードに IPv4 アドレスがない場合も、同様の ARP エラーが表示されます。

NetworkGatewayGroup は、リンクローカル IP アドレスへの ARP 接続と NDP 接続の確立を試みます。IP アドレスが存在しない場合（ARP の場合は IPv4、NDP の場合は IPv6）、接続は失敗し、デーモンは続行されません。

この問題はリリース 1.14.3 で修正されています。


回避策:

SSH を使用してノードに接続し、ノード IP を含むリンクに IPv4 アドレスまたは IPv6 アドレスを追加します。上記のログエントリの例では、このインターフェースは ens192 でした。

ip address add dev INTERFACE scope link ADDRESS

以下を置き換えます。

  • INTERFACE: ノードのインターフェース（ens192 など）。
  • ADDRESS: インターフェースに適用する IP アドレスとサブネット マスク。
リセット / 削除 1.10、1.11、1.12、1.13.0-1.13.2

Cluster.Spec から IP アドレスを削除してコントロール プレーンノードを削除しようとすると、anthos-cluster-operator がクラッシュ ループ状態になり、他のオペレーションをブロックします。


回避策:

問題は、1.13.3 と 1.14.0 以降で修正されています。他のすべてのバージョンが影響を受けます。修正バージョンのいずれかにアップグレードする

回避策として、次のコマンドを実行します。

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

以下を置き換えます。

  • IP_ADDRESS: クラッシュ ループ状態のノードの IP アドレス。
  • CLUSTER_NAMESPACE: クラスタの Namespace。
インストール 1.13.1、1.13.2、1.13.3

多数のノードを持つクラスタをインストールすると、次の例のような kubeadmin join エラー メッセージが表示されることがあります。

TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

回避策:

この問題は、Google Distributed Cloud バージョン 1.13.4 以降で解決されています。

影響を受けるバージョンを使用する必要がある場合は、まず 20 ノード未満のクラスタを作成し、インストールが完了した後にクラスタのサイズを変更してノードを追加します。
ロギングとモニタリング 1.10、1.11、1.12、1.13.0

Google Distributed Cloud Edge クラスタでは、metrics-server の CPU 上限を低く設定すると、metrics-server が頻繁に再起動される場合があります。metrics-server が異常なため、水平 Pod 自動スケーリング（HPA）が機能しない。

metrics-server CPU 上限が 40m より小さい場合、クラスタが影響を受ける可能性があります。metrics-server の CPU 上限を確認するには、次のいずれかのファイルを確認します。

  • クラスタ バージョン 1.x ～ 1.12:
    kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml
  • クラスタ バージョン 1.13 以降:
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

回避策:

この問題は、クラスタ バージョン 1.13.1 以降で解決されています。この問題を解決するには、クラスタをアップグレードします。

クラスタをアップグレードできるようになるまでの短期的な回避策は、次のように metrics-server の CPU 上限を手動で引き上げることです。

  1. スケールダウン metrics-server-operator 
    kubectl scale deploy metrics-server-operator --replicas=0
  2. 構成を更新して CPU の上限を引き上げます。
    • クラスタ バージョン 1.x ～ 1.12:
      kubectl -n kube-system edit deployment metrics-server
    • クラスタ バージョン 1.13:
      kubectl -n gke-managed-metrics-server edit deployment metrics-server

    次の例に示すように、--config-dir=/etc/config の行を削除して CPU の上限値を増やします。

    [...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
  3. 変更を適用するには、metrics-server を保存して閉じます。
ネットワーキング 1.14、1.15、1.16

NodePort Service を介する hostNetwork が有効な Pod への接続は、バックエンド Pod がターゲット NodePort と同じノード上にある場合、失敗します。この問題は、hostNetwork された Pod で使用する LoadBalancer Service に影響します。複数のバックエンドを使用すると、散発的な接続エラーが発生する可能性があります。

この問題は、eBPF プログラムのバグが原因で発生します。


回避策:

Nodeport Service を使用する場合は、バックエンド Pod のいずれかが実行されているノードをターゲットにしないでください。LoadBalancer Service を使用する場合は、hostNetwork された Pod が LoadBalancer ノードで実行されないようにしてください。
アップグレードと更新 1.12.3、1.13.0

バージョン 1.13.0 を実行する管理クラスタは、バージョン 1.12.3 を実行するユーザー クラスタを管理できません。バージョン 1.12.3 のユーザー クラスタに対するオペレーションが失敗します。


回避策:

管理クラスタをバージョン 1.13.1 にアップグレードするか、ユーザー クラスタを管理クラスタと同じバージョンにアップグレードします。
アップグレードと更新 1.12

バージョン 1.13.0 以降の管理クラスタには、ワーカー ノードプールを配置することはできません。ワーカー ノードプールがある管理クラスタでは、バージョン 1.13.0 以降へのアップグレードがブロックされます。管理クラスタのアップグレードが停止している場合は、bmctl-workspace フォルダ内の upgrade-cluster.log ファイルで次のエラーを確認して、ワーカー ノードプールが原因かどうかを確認できます。

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

回避策:

アップグレードする前に、すべてのワーカー ノードプールをユーザー クラスタに移動します。ノードプールの追加と削除の手順については、クラスタ内のノードプールの管理をご覧ください。
アップグレードと更新 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

kubectl apply を使用して ClientConfig や Stackdriver カスタム リソースなどの既存のリソースを更新すると、コントローラがエラーを返すか、入力と計画の変更を元に戻すことができます。

たとえば、次のように、リソースを取得してから更新バージョンを適用することによって、Stackdriver カスタム リソースを編集しようとする場合があります。

  1. 既存の YAML 定義を取得します。 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. YAML ファイルで機能を有効にするか、構成を更新します。
  3. 更新された YAML ファイルを再度適用します。 
    kubectl apply -f stackdriver.yaml

kubectl apply の最後の手順で問題が発生する可能性があります。


回避策:

kubectl apply を使用して既存のリソースを変更しないでください。代わりに、次の例に示すように kubectl edit または kubectl patch を使用します。

  1. Stackdriver カスタム リソースを編集します。 
    kubectl edit stackdriver -n kube-system stackdriver
  2. YAML ファイルで機能を有効にするか、構成を更新します。
  3. 保存してエディタを終了する

kubectl patch を使用した代わりのアプローチ:

  1. 既存の YAML 定義を取得します。 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. YAML ファイルで機能を有効にするか、構成を更新します。
  3. 更新された YAML ファイルを再度適用します。 
    kubectl patch stackdriver stackdriver --type merge \
    -n kube-system --patch-file stackdriver.yaml
ロギングとモニタリング 1.12、1.13、1.14、1.15、1.16

破損したバックログ チャンクを処理しようとすると、stackdriver-log-forwarder がクラッシュ ループします。次のエラー例がコンテナログに表示されます。

[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

このクラッシュループが発生すると、Cloud Logging でログを確認できません。


回避策:

これらのエラーを解決するには、次の操作を行います。

  1. 破損したバックログ チャンクを特定します。次のエラー メッセージの例を確認します。 
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    この例では、var/log/fluent-bit-buffers/tail.1/ に保存されているファイル tail.1/1-1659339894.252926599.flb にエラーがあります。フォーマット チェックに失敗したすべての *.flb ファイルを削除する必要があります。
  2. stackdriver-log-forwarder の実行中の Pod を終了します。 
    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
     KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。

    stackdriver-log-forwarder Pod が削除されたことを確認して、次のステップに進みます。
  3. stackdriver-log-forwarder が実行されているノードに SSH を使用して接続します。
  4. ノードで、var/log/fluent-bit-buffers/tail.1/ 内の破損した *.flb ファイルをすべて削除します。

    破損したファイルが多すぎる場合、スクリプトを適用してすべてのバックログ チャンクをクリーンアップするには、次のスクリプトを使用します。
    1. DaemonSet をデプロイして、fluent-bit のバッファ内のすべてのダーティデータをクリーンアップします。
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    2. DaemonSet がすべてのノードをクリーンアップしたことを確認します。次の 2 つのコマンドの出力は、クラスタ内のノード数と同じになります。
      kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    3. クリーンアップの DaemonSet を削除します。 
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup
    4. stackdriver-log-forwarder Pod を再起動します。
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
ネットワーキング、GDC 上の VM ランタイム 1.14.0

マルチ NIC クラスタで Dataplane V2（anetd）を再起動すると、仮想マシンがネットワークに接続できなくなる可能性があります。anetd Pod のログに、次のようなエラーが表示される場合があります。

could not find an allocator to allocate the IP of the multi-nic endpoint

回避策:

クイック フィックスとして VM を再起動できます。この問題の再発を回避するには、クラスタをバージョン 1.14.1 以降にアップグレードします。
オペレーション 1.13、1.14.0、1.14.1

クラスタのワークロードによっては、gke-metrics-agent が 4,608 MiB を超えるメモリを使用する場合があります。この問題は、Google Distributed Cloud for bare metal の Edge プロファイル クラスタにのみ影響します。デフォルトのプロファイル クラスタは影響を受けません。


回避策:

クラスタをバージョン 1.14.2 以降にアップグレードします。
インストール 1.12、1.13

kubectl を使用してクラスタを作成する場合、競合状態のためにプリフライト チェックが決して終了しない場合があります。その結果、場合によっては、クラスタの作成に失敗することがあります。

プリフライト チェック調整ツールは、デフォルトの ssh-key シークレットをターゲット名前空間にコピーするために SecretForwarder を作成します。通常、プリフライト チェックは、オーナー参照を利用し、SecretForwarder が完了すると調整されます。ただし、まれに SecretForwarder のオーナー参照がプリフライト チェックへの参照を失い、プリフライト チェックが停止する可能性があります。その結果、クラスタの作成が失敗します。コントローラ ドリブンのプリフライト チェックの調整を続行するためには、クラスタ オペレータ Pod を削除するか、プリフライト チェック リソースを削除します。プリフライト チェック リソースを削除すると、別のものが作成され、調整が続行されます。または、既存のクラスタ（以前のバージョンで作成されたクラスタ）を修正バージョンにアップグレードすることもできます。
ネットワーキング 1.9、1.10、1.11、1.12、1.13、1.14、1.15

マルチ NIC 機能では、CNI whereabouts プラグインを使用していて、CNI DEL オペレーションを使用して Pod のネットワーク インターフェースを削除すると、一部の予約済み IP アドレスが正しく解放されないことがあります。これは、CNI DEL オペレーションが中断された場合に発生します。

使用されていない Pod の IP アドレスの予約を確認するには、次のコマンドを実行します。

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

回避策:

使用されていない IP アドレス（ippool）を手動で削除します。
インストール 1.10、1.11.0、1.11.1、1.11.2

バージョン 1.11.0、1.11.1、1.11.2 の管理クラスタが 1.10.x ユーザー クラスタを管理している場合、バージョン 1.10.x ユーザー クラスタで Node Problem Detector が失敗することがあります。Node Problem Detector が失敗すると、次のエラー メッセージとともにログが更新されます。

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

回避策

この問題を解決するには、管理クラスタを 1.11.3 にアップグレードします。
オペレーション 1.14

リリース 1.14 では、maxPodsPerNode の設定がアイランド モードのクラスタを考慮していないため、ノードには 24 の Pod CIDR マスクサイズが割り当てられます（256 個の IP アドレス）。これにより、クラスタで想定よりも早く Pod IP アドレスが不足する可能性があります。たとえば、クラスタの Pod CIDR マスクサイズが 22 の場合、各ノードには 24 の Pod CIDR マスクが割り当てられ、クラスタがサポートできるのは最大 4 つのノードまでです。maxPodsPerNode が 129 以上に設定され、各ノードの Pod CIDR に十分なオーバーヘッドがない場合、Pod のチャーンが高い期間にクラスタでネットワークが不安定になる場合があります。

クラスタが影響を受けている場合、クラスタに新しいノードを追加したときに podCIDR が使用できないと、anetd Pod は次のエラーを報告します。

error="required IPv4 PodCIDR not available"

回避策

次の手順で問題を解決します。

  1. 1.14.1 以降のバージョンにアップグレードします。
  2. ワーカーノードを削除してから、追加し直します。
  3. コントロール プレーンノードを削除してから、ノードを追加し直し（1 つずつが望ましい）、クラスタのダウンタイムを回避します。
アップグレードと更新 1.14.0、1.14.1

バージョン 1.14.0 または 1.14.1 のクラスタでは、アップグレード ロールバックが失敗する場合があります。クラスタを 1.14.0 から 1.14.1 にアップグレードしてから、bmctl restore cluster コマンドを使用して 1.14.0 にロールバックしようとすると、次の例のようなエラーが返されることがあります。

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

回避策:

クラスタ Namespace の下にあるすべての healthchecks.baremetal.cluster.gke.io リソースを削除し、bmctl restore cluster コマンドを再実行します。

  1. すべての healthchecks.baremetal.cluster.gke.io リソースを一覧表示します。
    kubectl get healthchecks.baremetal.cluster.gke.io \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    以下を置き換えます。

    • CLUSTER_NAMESPACE: クラスタの名前空間。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。
  2. 前のステップでリストしたすべての healthchecks.baremetal.cluster.gke.io リソースを削除します。
    kubectl delete healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_RESOURCE_NAME \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
     HEALTHCHECK_RESOURCE_NAME は、ヘルスチェック リソースの名前に置き換えます。
  3. bmctl restore cluster コマンドを再実行します。
ネットワーキング 1.12.0

flatIPv4 が true に設定されているクラスタでは、LoadBalancer タイプの Service に外部 IP アドレスでアクセスできません。

この問題は、バージョン 1.12.1 で修正されています。


回避策:

cilium-config ConfigMap で、enable-415 を "true" に設定し、anetd Pod を再起動します。
アップグレードと更新 1.13.0、1.14

bmctl 1.14.0 と --use-bootstrap=false フラグを使用して 1.13.0 から 1.14.x へのインプレース アップグレードを行おうとすると、アップグレードは決して完了しません。

preflight-check 演算子のエラーが、クラスタが必要なチェックをスケジューリングできなくすることは決してありません。つまり、プリフライト チェックは決して終了しません。


回避策:

1.14.x にアップグレードする前に、まず 1.13.1 にアップグレードします。1.13.0 から 1.13.1 へのインプレース アップグレードは正常に機能します。または、--use-bootstrap=false フラグなしで 1.13.0 から 1.14.x にアップグレードします。
アップグレードと更新、セキュリティ 1.13、1.14

ワークロード Pod がスケジュールされるのを防ぐには、コントロール プレーン ノードに 2 つの特定の taint が必要です。バージョン 1.13 のクラスタをバージョン 1.14.0 にアップグレードすると、コントロール プレーン ノードは次の必要な taint を失います。

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

この問題によりアップグレードは失敗しませんが、コントロール プレーン ノードで実行されない Pod がアップグレードを開始する可能性があります。これらのワークロード Pod は、コントロール プレーン ノードに過剰な負荷をかけて、クラスタが不安定になる可能性があります。

影響を受けるかどうかを判断する

  1. コントロール プレーンノードを検索するには、次のコマンドを使用します。
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH
  2. ノードの taint のリストを確認するには、次のコマンドを使用します。
    kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH

    必要な taint のいずれも一覧表示されない場合は、影響を受けています。

回避策

影響を受けるバージョン 1.14.0 クラスタのコントロール プレーンノードごとに、次の手順を使用して、適切な機能を復元します。これらの手順は、node-role.kubernetes.io/master:NoSchedule taint と関連する Pod を対象としています。コントロール プレーンノードで PreferNoSchedule taint を使用する場合は、それに応じて手順を調整します。
オペレーション、GDC 上の VM ランタイム 1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30、1.31

kubectl virt create vm コマンドで新しい仮想マシン（VM）を作成すると、イメージのアップロード中にまれに失敗します。この問題は、Linux VM と Windows VM の両方に該当します。エラーは次の例のようになります。

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

回避策

kubectl virt create vm コマンドを再試行して VM を作成します。
アップグレードと更新、ロギングとモニタリング 1.11

マネージド コレクション コンポーネントは Managed Service for Prometheus の一部です。バージョン 1.11 Anthos clusters の gmp-system 名前空間にマネージド コレクション コンポーネントを手動でデプロイした場合、バージョン 1.12 にアップグレードすると、関連するリソースは保持されません。

バージョン 1.12.0 クラスタ以降、gmp-system Namespace 内の Managed Service for Prometheus コンポーネントと関連するカスタム リソース定義は、enableGMPForApplications フィールドで stackdriver-operator によって管理されます。enableGMPForApplications フィールドはデフォルトの true に設定されているため、バージョン 1.12 にアップグレードする前に名前空間に Managed Service for Prometheus コンポーネントを手動でデプロイすると、stackdriver-operator によってリソースが削除されます。

回避策

手動で管理されるコレクション リソースを保持するには:

  1. 既存のすべての PodMonitoring カスタム リソースをバックアップします。
  2. クラスタをバージョン 1.12 にアップグレードし、Managed Service for Prometheus を有効にします。
  3. アップグレードしたクラスタに PodMonitoring カスタム リソースを再デプロイします。
アップグレードと更新 1.13

Docker コンテナ ランタイムを使用するバージョン 1.12 のクラスタに次のアノテーションがない場合は、バージョン 1.13 にアップグレードできません。

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

この問題の影響を受けると、bmctl が bmctl-workspace フォルダ内の upgrade-cluster.log ファイルに次のエラーを書き込みます。

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

アップグレードは Docker コンテナ ランタイムを維持するためのアノテーションが不要になるため、これは、バージョン 1.11 からアップグレードされたバージョン 1.12 の Docker クラスタでほぼ発生します。この場合、1.13 にアップグレードする際、クラスタにアノテーションはありません。バージョン 1.13 以降では、containerd が許可される唯一のコンテナ ランタイムであるため注意してください。

回避策:

この問題の影響を受けている場合は、欠落しているアノテーションを使用してクラスタ リソースを更新します。アノテーションは、アップグレード実行中、またはキャンセルしてからアップグレードを再試行する前に追加できます。
インストール 1.11

Google Distributed Cloud バージョン 1.11.0 では、クラスタ作成に失敗する場合があります（この問題は、Google Distributed Cloud リリース 1.11.1 で修正されています）。場合によっては、bmctl create cluster コマンドが早期に終了し、次のようなエラーがログに書き込まれます。

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

回避策

失敗したオペレーションによりアーティファクトが生成されますが、クラスタは動作しません。この問題の影響を受ける場合は、次の手順でアーティファクトをクリーンアップし、クラスタを作成します。
インストール、GDC 上の VM ランタイム 1.11, 1.12

クラスタ作成オペレーションで次のようなエラーが報告されることがあります。

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

回避策

このエラーは無害なため、無視しても問題ありません。
インストール 1.10、1.11、1.12

次の条件の組み合わせがある場合、クラスタの作成が失敗します。

  • クラスタが、コンテナ ランタイムとして containerd を使用するように構成されている（クラスタ構成ファイルで nodeConfig.containerRuntime が containerd に設定されている。これは Google Distributed Cloud バージョン 1.13 以降のデフォルトである）。
  • クラスタが、Pod 用に複数のネットワーク インターフェース（マルチ NIC）を提供するように構成されている（クラスタ構成ファイルで clusterNetwork.multipleNetworkInterfaces が true に設定されている）。
  • クラスタが、プロシキを使用するように構成されている（spec.proxy.url はクラスタ構成ファイルで指定されます）。クラスタの作成に失敗しても、この設定はクラスタを作成しようとするときに伝搬されます。このプロキシ設定は、HTTPS_PROXY 環境変数として、または containerd 構成（/etc/systemd/system/containerd.service.d/09-proxy.conf）で確認できます。

回避策

すべてのノードマシンで NO_PROXY 環境変数にサービス CIDR（clusterNetwork.services.cidrBlocks）を追加します。
インストール 1.10、1.11、1.12

Google Distributed Cloud リリース 1.10.0 では、すべてのコントロール プレーン コンポーネントを root 以外のユーザーとして実行する、ルートレス コントロール プレーン機能が導入されました。すべてのコンポーネントを root 以外のユーザーとして実行すると、0077 のより制限が厳しい umask の設定があるシステムでインストールやアップグレードの失敗が発生する可能性があります。


回避策

コントロール プレーン ノードをリセットし、すべてのコントロール プレーン マシンで umask の設定を 0022 に変更します。マシンが更新された後、インストールを再試行します。

インストールまたはアップグレードを続行するために、コントロール プレーン マシンで /etc/kubernetes のディレクトリとファイルのアクセス許可を変更することもできます。

  • /etc/kubernetes とそのすべてのサブディレクトリを公開読み取り可能にします。chmod o+rx
  • root ユーザーが所有し、ディレクトリ内に存在するすべてのファイルを（再帰的に）/etc/kubernetes 公開読み取り可能（chmod o+r）にします。秘密鍵ファイル（.key）は、適切な所有権と権限ですでに作成されているため、この変更から除外します。
  • /usr/local/etc/haproxy/haproxy.cfg を公開読み取り可能にします。
  • /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml を公開読み取り可能にします。
インストール 1.10, 1.11, 1.12, 1.13

コントロール グループ v2（cgroup v2）は、Google Distributed Cloud 1.13 以前ではサポートされていません。ただし、バージョン 1.14 では、プレビュー機能として cgroup v2 がサポートされています。/sys/fs/cgroup/cgroup.controllers の存在は、システムで cgroup v2 が使用されていることを示しています。


回避策

システムで cgroup v2 を使用している場合は、クラスタをバージョン 1.14 にアップグレードします。
インストール 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29

管理クラスタまたはハイブリッド クラスタによってトリガーされるインストール（つまり、ユーザー クラスタなど、bmctl で作成されていないクラスタ）では、プリフライト チェックは Google Cloud サービス アカウントの認証情報や、関連付けられている権限を検証しません。
インストール 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30

vSphere VM にベアメタル クラスタをインストールする場合は、tx-udp_tnl-segmentation フラグと tx-udp_tnl-csum-segmentation フラグをオフに設定する必要があります。これらのフラグは、vSphere ドライバ VMXNET3 によるハードウェア セグメンテーション オフロードに関連しており、ベアメタル クラスタの GENEVE トンネルでは機能しません。


回避策

各ノードで次のコマンドを実行して、これらのフラグの現在の値を確認します。

ethtool -k NET_INTFC | grep segm

NET_INTFC を、ノードの IP アドレスに関連付けられたネットワーク インターフェースに置き換えます。

レスポンスには、次のようなエントリが含まれます。

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
 RHEL 8.4 では、ethtool でこれらのフラグがオフではない場合でもオフと表示されることがあります。これらのフラグを明示的にオフに設定するには、次のコマンドを使用して、フラグをオンにしてからオフにします。 
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

このフラグの変更はリブート時に保持されません。起動スクリプトを構成することで、システムの起動時にこれらのフラグを明示的に設定します。
アップグレードと更新 1.10

管理クラスタのバージョンにかかわらず、bmctl CLI は以前のマイナー バージョンのユーザー クラスタを作成、更新、リセットできません。たとえば、管理クラスタのバージョンが 1.N.X であっても、バージョン 1.N-1.Y のユーザークラスタをリセットするのに 1.N.X の bmctl を使用できません。

この問題の影響を受けている場合、bmctl を使用すると、次のようなログが表示されます。

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

回避策:

kubectl を使用して、管理クラスタ内のユーザー クラスタ カスタム リソースを作成、編集、削除します。

ユーザー クラスタをアップグレードする機能に対する影響はありません。
アップグレードと更新 1.12

API サーバーを使用できないため、クラスタをバージョン 1.12.1 へのアップグレードが停止する場合があります。この問題は、すべてのクラスタタイプとサポートされているすべてのオペレーティング システムに影響します。この問題が発生すると、bmctl upgrade cluster コマンドが複数のポイントで失敗する可能性があります（プリフライト チェックの第 2 フェーズなど）。


回避策

アップグレードのログを確認すると、この問題の影響を受けるかどうかを判断できます。アップグレード ログはデフォルトで /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP に保存されます。

upgrade-cluster.log に次のようなエラーが含まれている可能性があります。

Failed to upgrade cluster: preflight checks failed: preflight check failed
 マシンログには、次のようなエラーが含まれている場合があります（繰り返し失敗する場合は、この問題の影響を受けていることを示しています）。 
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

クラスタをバージョン 1.12.1 にアップグレードすることを再び試みる前に、HAProxy と Keepalived が各コントロール プレーン ノードで実行されている必要があります。各ノードの crictl コマンドライン インターフェースを使用して、haproxy コンテナと keepalived コンテナが実行されているかどうかを確認します。

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

HAProxy と Keepalived のいずれかがノードで実行されていない場合は、ノードで kubelet を再起動します。

systemctl restart kubelet
アップグレードと更新、GDC 上の VM ランタイム 1.11, 1.12

バージョン 1.12.0 クラスタでは、VM Runtime on GDC の GA リリースを適切にサポートするために、VM Runtime on GDC に関連するすべてのリソースが vm-system 名前空間に移行されます。バージョン 1.11.x 以前のクラスタで GDC 上の VM ランタイムが有効になっている場合、最初に GDC 上の VM ランタイムを無効にしない限り、バージョン 1.12.0 以降にアップグレードできません。この問題の影響を受けると、アップグレード オペレーションで次のエラーが報告されます。

Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

回避策

GDC 上の VM ランタイムを無効にするには:

  1. VMRuntime カスタム リソースを編集します。 
    kubectl edit vmruntime
  2. 仕様で enabled を false に設定します。 
    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...
  3. カスタム リソースをエディタに保存します。
  4. クラスタのアップグレードが完了したら、GDC 上の VM ランタイムを再度有効にします。

詳細については、GDC 上の VM ランタイムを有効または無効にするをご覧ください。
アップグレードと更新 1.10、1.11、1.12

場合によっては、クラスタのアップグレードが完了せず、bmctl CLI が応答しなくなる可能性があります。この問題は、リソースが正しく更新されていないことが原因の可能性があります。この問題の影響を受けているかどうかを判断し、修正するには、anthos-cluster-operator ログを確認し、次のエントリのようなエラーを探します。

controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

これらのエントリは、リソースが誤って更新された場合の症状です。ここで、{RESOURCE_NAME} は問題リソースの名前です。


回避策

ログにこれらのエラーがある場合は、次の手順を完了します。

  1. kubectl edit を使用して、ログ メッセージに含まれているリソースから kubectl.kubernetes.io/last-applied-configuration アノテーションを削除します。
  2. 変更を保存してリソースに適用します。
  3. クラスタのアップグレードをもう一度行ってください。
アップグレードと更新 1.10、1.11、1.12

Egress NAT ゲートウェイまたは BGP によるバンドル型ロード バランシングを使用するクラスタでは、1.10.x から 1.11.x へのクラスタのアップグレードが失敗します。これらの機能では、いずれも Network Gateway for GDC を使用します。クラスタのアップグレードが Waiting for upgrade to complete... コマンドライン メッセージで停止し、anthos-cluster-operator ログに次のようなエラーが記録されます。

apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

回避策

アップグレードのブロックを解除するには、アップグレードするクラスタに対して次のコマンドを実行します。

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
アップグレードと更新 1.10、1.11、1.12、1.13、1.14、1.15

bmctl update コマンドでは、クラスタ リソース構成の maintenanceBlocks セクションを削除や変更をすることはできません。


回避策

メンテナンス モードでノードを削除する手順などの詳細については、ノードをメンテナンス モードにするをご覧ください。
オペレーション 1.10、1.11、1.12

バージョン 1.12.0（anthosBareMetalVersion: 1.12.0）以下のクラスタを実行し、ノードで kubectl cordon を手動で使用する場合、Google Distributed Cloud for bare metal は、想定される状態を調整するために、準備が整う前にノードの閉鎖解除を行う場合があります。


回避策

バージョン 1.12.0 以前のクラスタの場合は、メンテナンス モードを使用してノードを閉鎖してドレインします。

バージョン 1.12.1（anthosBareMetalVersion: 1.12.1）以降では、kubectl cordon を使用しても、Google Distributed Cloud for bare metal が予期せずノードを閉鎖解除しません。
オペレーション 1.11

管理クラスタがバージョン 1.11 で、レジストリ ミラーを使用している場合、マイナー バージョンがそれより小さいユーザー クラスタは管理できません。この問題は、ユーザー クラスタのリセット、更新、アップグレード オペレーションに影響します。

この問題の影響を受けているかどうかを判断するには、クラスタ オペレーション（作成、アップグレード、リセットなど）のログを確認します。デフォルトの場合、これらのログは、bmctl-workspace/CLUSTER_NAME/ フォルダにあります。この問題の影響を受けている場合は、ログに次のエラー メッセージが含まれています。

flag provided but not defined: -registry-mirror-host-to-endpoints
オペレーション 1.10, 1.11

bmctl check cluster コマンドをユーザー クラスタで実行すると、ユーザー クラスタ kubeconfig シークレットが管理クラスタ kubeconfig で上書きされます。このファイルを上書きすると、更新やアップグレードなどの標準のクラスタ オペレーションが、影響を受けるユーザー クラスタで失敗します。この問題は、クラスタ バージョン 1.11.1 以前に適用されます。

この問題がユーザー クラスタに影響するかどうかを判断するには、次のコマンドを実行します。

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

以下を置き換えます。

  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。
  • USER_CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、クラスタ Namespace の名前は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、デフォルトの名前空間は cluster-test になります。
  • USER_CLUSTER_NAME: 確認するユーザー クラスタの名前。

出力内のクラスタ名（次のサンプル出力の contexts.context.cluster を参照）が管理クラスタ名である場合は、指定したユーザー クラスタが影響を受けます。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

回避策

次の手順で、影響を受けるユーザー クラスタ（USER_CLUSTER_NAME）に機能を復元します。

  1. ユーザー クラスタ kubeconfig ファイルを見つけます。Google Distributed Cloud for bare metal は、クラスタの作成時に管理ワークステーションに kubeconfig ファイルを生成します。デフォルトでは、このファイルは bmctl-workspace/USER_CLUSTER_NAME ディレクトリにあります。
  2. この kubeconfig が正しいユーザー クラスタ kubeconfig であることを確認します。 
    kubectl get nodes \
    --kubeconfig PATH_TO_GENERATED_FILE
     PATH_TO_GENERATED_FILE は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。ユーザー クラスタのノードに関する詳細情報が返されます。マシン名がクラスタに対して正しいことを確認します。
  3. 次のコマンドを実行して、管理クラスタ内の壊れた kubeconfig ファイルを削除します。 
    kubectl delete secret \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig
  4. 次のコマンドを実行して、正しい kubeconfig シークレットを管理クラスタに保存し直します。 
    kubectl create secret generic \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE
オペレーション 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30

コンテナ ランタイムとして containerd を使用する場合、root 以外のユーザーとしてスナップショットを実行するには、ユーザーの PATH に /usr/local/bin が存在する必要があります。それ以外の場合は、crictl: command not found エラーで失敗します。

root ユーザーとしてログインしていない場合は、sudo を使用してスナップショット コマンドを実行します。sudo の PATH はルート プロファイルと異なる場合があり、/usr/local/bin を含んでいないことがあります。


回避策

/etc/sudoers の secure_path を更新して、/usr/local/bin を追加します。あるいは、別の /bin ディレクトリに crictl のシンボリック リンクを作成します。
ロギングとモニタリング 1.10

コンテナ ランタイム インターフェース（CRI）パーサーが解析時間として誤った正規表現を使用している場合、stackdriver-log-forwarder Pod のログに次のようなエラーと警告が記録されます。

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

回避策:
ロギングとモニタリング 1.10、1.11、1.12、1.13、1.14、1.15

クラスタ バージョン 1.10 ～ 1.15 では、[お支払い] ページで予想外に高額な Metrics volume の料金が表示される場合があります。この問題は、次の両方の状況に該当する場合にのみ影響します。

  • アプリケーションのモニタリングが有効になっている（enableStackdriverForApplications=true）
  • Managed Service for Prometheus が有効になっていない（enableGMPForApplications）
  • アプリケーション Pod に prometheus.io/scrap=true アノテーションがある

この問題の影響を受けるかどうかを確認するには、ユーザー定義の指標を一覧表示します。不要な指標に対する請求が表示される場合は、この問題に該当します。


回避策

影響を受ける場合は、クラスタをバージョン 1.12 にアップグレードして、この問題に対処する新しいアプリケーション モニタリング ソリューションの managed-service-for-prometheus に切り替えることをおすすめします。

  • アプリケーション ログの収集とアプリケーション指標の収集を制御する個別のフラグ
  • バンドルされた Google Cloud Managed Service for Prometheus

    • バージョン 1.12 にアップグレードできない場合は、次の手順を使用します。

    1. 不要な請求があるソース Pod と Service を見つけます。 
      kubectl --kubeconfig KUBECONFIG \
    get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
    services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Pod または Service から prometheus.io/scrap=true アノテーションを削除します。
    ロギングとモニタリング 1.11、1.12、1.13、1.14、1.15、1.16、1.28

    Pod の密度が高いと、極端な場合、ロギングとモニタリングのオーバーヘッドが過剰になり、Metrics Server が停止して再起動する可能性があります。Metrics Server を実行し続けるために、metrics-server-config ConfigMap を編集してより多くのリソースを割り当てることができます。ただし、調整により、metrics-server-config に対して行われた編集がクラスタの更新またはアップグレード オペレーション中にデフォルト値に戻されることがあります。Metrics Server は直ちに影響を受けませんが、次に再起動したときに、元に戻された ConfigMap が取得され、再び過剰なオーバーヘッドが発生する可能性があります。


    回避策

    1.11.x の場合は、ConfigMap の編集をスクリプト化し、クラスタの更新またはアップグレードとともに実行できます。1.12 以降の場合は、サポートまでお問い合わせください。
    ロギングとモニタリング 1.11, 1.12

    いくつかの Google Distributed Cloud ソフトウェア専用指標が非推奨になり、Google Distributed Cloud リリース 1.11 以降、これらの非推奨の指標のデータは収集されなくなりました。これらの指標をいずれかのアラート ポリシーで使用する場合、アラート条件をトリガーするデータはありません。

    次の表に、サポートが終了した個別の指標と、それらに代わる指標を表示します。

    サポートが終了した指標 置き換える指標
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity

    1.11 より前のクラスタ バージョンでは、推奨 Anthos on baremetal node cpu usage exceeds 80 percent (critical) アラートのポリシー定義ファイルによって、サポートが終了した指標が使用されます。node-cpu-usage-high.json JSON 定義ファイルは、リリース 1.11.0 以降用に更新されます。


    回避策

    置換指標に移行するには、次の手順に従います。

    1. Google Cloud コンソールで、[モニタリング] を選択するか、次のボタンをクリックします。
      [モニタリング] に移動
    2. ナビゲーション パネルで、[ダッシュボード] を選択し、[Anthos クラスタノード ステータス] ダッシュボードを削除します。
    3. [サンプル ライブラリ] タブをクリックし、[Anthos clusters ノード ステータス] ダッシュボードを再インストールします。
    4. アラート ポリシーの作成の手順に沿って、更新された node-cpu-usage-high.json ポリシー定義ファイルを使用してポリシーを作成します。
    ロギングとモニタリング 1.10, 1.11

    状況によっては、fluent-bit ロギング エージェントが壊れたチャンクの処理で動かなくなることがあります。ロギング エージェントが破損したチャンクを迂回できない場合は、stackdriver-log-forwarder が CrashloopBackOff エラーでクラッシュを繰り返す可能性があります。この問題が発生している場合、ログには次のようなエントリがあります。

    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0

    回避策:

    Stackdriver Log Forwarder のバッファ チャンクをクリーンアップします。

    注: 次のコマンドでは、KUBECONFIG を管理クラスタの kubeconfig ファイルへのパスに置き換えます。

    1. すべての stackdriver-log-forwarder Pod を終了します。 
      kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
       stackdriver-log-forwarder Pod が削除されたことを確認して、次のステップに進みます。
    2. 次の DaemonSet をデプロイして、fluent-bit バッファ内の破損したデータをクリーンアップします。
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. 次のコマンドを使用して、DaemonSet がすべてのノードをクリーンアップしたことを確認します。
      kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l \
    app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG -n \
    kube-system get pods -l \
    app=fluent-bit-cleanup --no-headers | wc -l
       2 つのコマンドの出力は、クラスタ内のノード数と同じになります。
    4. クリーンアップの DaemonSet を削除します。 
      kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
    5. ログ フォワーダー Pod を再起動します。 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset \
    stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    ロギングとモニタリング 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

    gke-metrics-agent は、各ノードで指標を収集し、Cloud Monitoring に転送する daemonset です。次のようなログが生成されることがあります。

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    以下のものを含む、他の指標タイプにも同様のエラーが発生する可能性があります（ただし、これらに限定されません）。

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    これらのエラーログは、参照されている指標がサポートされておらず、モニタリング目的で重要ではないため、無視しても問題ありません。
    ロギングとモニタリング 1.10, 1.11

    クラスタでは、一部のノードで通常の指標の継続的なエクスポートが中断されたり、指標が欠落したりすることがあります。この問題がクラスタに影響する場合は、少なくとも次の指標でデータのギャップが見られる可能性があります。

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    回避策

    クラスタをバージョン 1.11.1 以降にアップグレードします。

    アップグレードできない場合は、回避策として次の手順を行ってください。

    1. stackdriver リソースを編集用に開きます。 
      kubectl -n kube-system edit stackdriver stackdriver
    2. gke-metrics-agent の CPU リクエストを 10m から 50m に引き上げるには、stackdriver マニフェストに次の resourceAttrOverride セクションを追加します。 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
       編集したリソースは、次のようになります。
      spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. 変更を保存し、テキスト エディタを終了します。
    4. 変更が有効になっていることを確認するには、次のコマンドを実行します。 
      kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
       変更が有効になっている場合は、このコマンドで cpu: 50m が検出されます。
    ネットワーキング 1.10

    ノードに複数のデフォルト ゲートウェイがあると、Pod 内から google.com などの外部エンドポイントへの接続が切断される可能性があります。

    この問題の影響を受けるかどうかを判断するには、ノードで次のコマンドを実行します。

    ip route show

    レスポンスに default のインスタンスが複数存在する場合は、影響を受けていることを示します。
    ネットワーキング 1.12

    バージョン 1.12.x のクラスタでは、ユーザー クラスタ内のネットワーキング カスタム リソースを手動で編集できます。Google Distributed Cloud は、クラスタのアップグレード時に、ユーザー クラスタ内のカスタム リソースと管理クラスタのカスタム リソースを調整します。この調整は、ユーザー クラスタのネットワーク カスタム リソースに直接行われた編集内容を上書きします。ネットワーキング カスタム リソースは管理クラスタでのみ変更する必要がありますが、バージョン 1.12.x クラスタではこの要件は適用されません。

    高度なネットワーキング機能（BGP によるバンドル型ロード バランシング、下り NAT ゲートウェイ、SR-IOV ネットワーキング、BGP によるフラットモード、Pod 用マルチ NICなど）では、次のカスタム リソースを使用します。

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    管理クラスタでこうしたカスタム リソースを編集すると、整合化の手順でユーザー クラスタに変更が適用されます。


    回避策

    ユーザー クラスタ上で前述のカスタム リソースのいずれかを変更した場合は、管理クラスタ上の対応するカスタム リソースをアップグレード前に変更します。この手順により、構成の変更内容が確実に保持されます。クラスタ バージョン 1.13.0 以降では、ユーザー クラスタのネットワーキング カスタム リソースを直接変更することはできません。
    ネットワーキング 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

    Google Distributed Cloud は、ソースの検証を無効にするために、ノードでリバースパス フィルタリングを構成します（net.ipv4.conf.all.rp_filter=0）。rp_filter 設定を 1 または 2 に変更すると、ノード外の通信タイムアウトのために Pod は失敗します。

    リバースパス フィルタリングは、IPv4 構成フォルダ（net/ipv4/conf/all）内の rp_filter ファイルで設定されています。この値は、sysctl（/etc/sysctl.d/60-gce-network-security.conf などのネットワーク セキュリティ構成ファイル内でリバースパス フィルタリング設定を格納する）によってオーバーライドされる場合もあります。


    回避策

    次のいずれかの回避策を行うことで、Pod の接続を復元できます。

    net.ipv4.conf.all.rp_filter の値を 0 に手動で戻し、sudo sysctl -p を実行して変更を適用します。

    または

    anetd Pod を再起動して、net.ipv4.conf.all.rp_filter を 0 に戻します。anetd Pod を再起動するには、次のコマンドを使用して anetd Pod を見つけて削除します。すると、新しい anetd Pod が代わりに開始されます。

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ

    ANETD_XYZ は、anetd Pod の名前で置き換えます。

    いずれかの回避策を実行したら、各ノードで sysctl net.ipv4.conf.all.rp_filter を実行して、net.ipv4.conf.all.rp_filter の値が 0 に設定されていることを確認します。
    ネットワーキング 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30、1.31、1.32、1.33、1.34

    192.168.122.0/24 と 10.96.0.0/27 は、ブートストラップ（kind）クラスタで使用されるデフォルトの Pod と Service の CIDR です。それがクラスタ ノード マシンの IP アドレスと重複すると、プリフライト チェックが不合格になります。


    回避策

    この競合を回避するには、--bootstrap-cluster-pod-cidr フラグと --bootstrap-cluster-service-cidr フラグを bmctl に渡して別の値を指定します。
    オペレーティング システム 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

    2020 年 12 月、CentOS コミュニティと Red Hat は CentOS の開発およびサポートの終了を発表しました。2022 年 1 月 31 日に CentOS 8 はサポート終了（EOL）となりました。EOL の結果として、yum リポジトリが CentOS で機能しなくなり、クラスタの作成とクラスタのアップグレードのオペレーションが失敗するようになりました。これは、CentOS のすべてのサポートされているバージョンに適用され、クラスタのすべてのバージョンに影響します。


    回避策
    セキュリティ 1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

    コンテナ ランタイムとして containerd を使用し、オペレーティング システムで SELinux が有効になっている場合、アプリケーション Dockerfile で定義された VOLUME が書き込みできない可能性があります。たとえば、次の Dockerfile でビルドされたコンテナは、/tmp フォルダに書き込むことができません。

    FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp

    この問題の影響を受けているかどうかを確認するには、問題のあるコンテナをホストするノードで次のコマンドを実行します。

    ausearch -m avc

    この問題の影響を受けると、次のような denied エラーが表示されます。

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0

    回避策

    この問題を回避するには、次のいずれかの変更を行います。

    • SELinux を無効にします。
    • Dockerfile 内で VOLUME 機能を使用しないでください。
    アップグレードと更新 1.10、1.11、1.12

    クラスタをアップグレードする場合、Node Problem Detector はデフォルトでは有効になっていません。この問題は、リリース 1.10 から 1.12.1 へのアップグレードに該当し、リリース 1.12.2 で修正されています。


    回避策:

    Node Problem Detector を有効にするには:

    1. ノードで node-problem-detector systemd サービスが実行されているかどうかを確認します。
      1. SSH コマンドを使用してノードに接続します。
      2. ノードで node-problem-detector systemd サービスが実行されているかどうかを確認します。 
        systemctl is-active node-problem-detector
         コマンドの結果に inactive と表示されている場合、node-problem-detector はノード上で実行されていません。
    2. Node Problem Detector を有効にするには、kubectl edit コマンドを使用して node-problem-detector-config ConfigMap を編集します。詳細については、Node Problem Detector をご覧ください。
    オペレーション 1.9, 1.10

    nodeAccess.loginUser が root 以外のユーザー名に設定されている場合、bmctl backup cluster コマンドは失敗します。


    回避策:

    この問題は、バージョン 1.9.x、1.10.0、1.10.1 に適用され、バージョン 1.10.2 以降で修正されています。
    ネットワーキング 1.10、1.11、1.12

    バックエンド ポッドがコントロール プレーン ノードで実行され、かつコンテナの仕様で hostNetwork: true フィールドを使用している場合、LoadBalancer Service でパケットが破棄される anetd のバグがあります。

    バグはバージョン 1.13 以降には含まれていません。


    回避策:

    hostNetwork Pod でサポートされる LoadBalancer Service を使用する場合は、次の回避策をお勧めします。

    1. コントロール プレーン ノードではなくワーカーノードで実行する
    2. Service 仕様で externalTrafficPolicy: local を使用し、ワークロードがロードバランサ ノードで実行されるようにする
    アップグレードと更新 1.12、1.13

    1.12.x から 1.13.x にアップグレードするクラスタでは、ImagePullBackOff エラーで anthos-version-$version$ Pod が失敗する場合があります。これは、anthos-cluster-operator の競合状態がアップグレードされるために発生するもので、通常のクラスタ機能には影響しません。

    このバグはバージョン 1.13 以降には含まれていません。


    回避策:

    kubectl delete job anthos-version-$version$ -n kube-system によって dynamic-version-installer のジョブを削除する
    アップグレードと更新 1.13

    バージョン 1.11 からアップグレードされたバージョン 1.12 クラスタは、バージョン 1.13.0 にアップグレードできません。このアップグレードの問題は、バージョン 1.12 で作成されたクラスタには該当しません。

    影響を受けるかどうかを確認するには、管理クラスタの upgrade-first-no* 文字列を含むアップグレード ジョブのログを確認します。次のエラー メッセージが表示された場合は影響を受けます。

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
...

    回避策:

    この問題を回避するには:

    1. 管理ワークステーションで次のコマンドを実行します。 
      echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
    2. クラスタのアップグレードをもう一度試行します。
    ロギングとモニタリング 1.16.2、1.16.3

    stackdriver-operator に問題があるため、通常より消費する CPU 時間が長くなります。アイドル状態の stackdriver-operator の場合、通常の CPU 使用率は 50 ミリ CPU（50m）未満です。stackdriver-operator が cert-manager の想定に基づいて適用する証明書リソースの不一致が原因です。この不一致により、これらのリソースの更新時に cert-manager と stackdriver-operator の間で競合状態が発生します。

    この問題により、CPU の可用性が制限されているクラスタでパフォーマンスが低下する可能性があります。


    回避策:

    このバグが修正されたバージョンにアップグレードできるようになるまでは、次の回避策を使用してください。

    1. stackdriver-operator を一時的に 0 レプリカにスケールダウンするには、AddonConfiguration カスタム リソースを適用します。
      kubectl scale deploy stackdriver-operator --replicas=0
    2. この問題を解決するバージョンにアップグレードしたら、stackdriver-operator バックアップを再度スケーリングします。
      kubectl scale deploy stackdriver-operator --replicas=1
    ロギングとモニタリング 1.16.0、1.16.1

    Google Distributed Cloud 1.16 のマイナー リリースでは、stackdriver カスタム リソース仕様の enableStackdriverForApplications フィールドは非推奨になっています。このフィールドは、stackdriver カスタム リソースの enableCloudLoggingForApplications フィールドと enableGMPForApplications フィールドに置き換えられます。

    ワークロードのモニタリングには、Google Cloud Managed Service for Prometheus を使用することをおすすめします。この機能を有効にするには、enableGMPForApplications フィールドを使用します。

    ワークロードの prometheus.io/scrape アノテーションによってトリガーされる指標の収集に依存している場合は、annotationBasedApplicationMetrics 機能ゲートフラグを使用して以前の動作を維持できます。ただし、annotationBasedApplicationMetrics が正しく機能しない問題があり、アプリケーションから Cloud Monitoring への指標の収集が妨げられます。


    回避策:

    この問題を解決するには、クラスタをバージョン 1.16.2 以降にアップグレードします。

    annotationBasedApplicationMetrics 機能ゲートによって有効になるアノテーション ベースのワークロード指標の収集では、prometheus.io/scrape アノテーションを持つオブジェクトの指標が収集されます。オープンソースの送信元を持つ多くのソフトウェア システムでは、このアノテーションを使用する場合があります。この方法の指標の収集を続ける場合は、この依存関係に注意してください。Cloud Monitoring の指標が変更された際に対応できるようにしてください。
    ロギングとモニタリング 1.15、1.16、1.28.0 ～ 1.28.900、1.29.0 ～ 1.29.400、1.30.0、1.30.100

    Cloud Audit Logs には、GKE Hub を介して cluster-operator によって自動的に実行される特別な権限設定が必要です。

    ただし、1 つの管理クラスタが異なるプロジェクト ID を持つ複数のクラスタを管理している場合、cluster-operator のバグにより、同じサービス アカウントが許可リストに繰り返し追加され、サイズ制限により許可リスト登録リクエストが失敗します。これにより、これらのクラスタの一部またはすべての監査ログが Google Cloudに挿入されなくなります。

    この状況になると、影響を受けるクラスタの audit-proxy Pod での一連の Permission Denied エラーが発生します。

    別の症状として、GKE Hub でクラウド監査ロギングの許可リストを確認すると、エラー ステータスと重複したサービス アカウントの長いリストが表示されます。

    curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

{
  "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging",
  "spec": {
    "cloudauditlogging": {
      "allowlistedServiceAccounts": [
        "SERVICE-ACCOUNT-EMAIL",
        ...
        ... multiple lines of the same service account
      ]
    }
  },
  "state": {
    "state": {
      "code": "ERROR"
    }
  }
}

    この問題を解決するには、クラスタを少なくとも 1.28.1000、1.29.500、または 1.30.200 にアップグレードして問題を修正するか、次の回避策を適用します。
    構成 1.29 以前のすべてのパッチ バージョン、1.30.400 以前、1.31.0

    hosts フィールドのみが変更された場合、ノードのレジストリ ミラー構成が更新されない

    クラスタ仕様でレジストリ ミラー エンドポイントの containerRuntime.registryMirrors.hosts フィールドを更新しても、変更はクラスタノードに自動的に適用されません。この問題は、調整ロジックが hosts フィールドのみに加えられた変更を検出しないことが原因です。その結果、ノードの containerd 構成の更新を担当するマシン更新ジョブがトリガーされません。

    確認:

    この問題を確認するには、レジストリ ミラーの hosts フィールドのみを変更し、ワーカーノードの containerd 構成ファイル（パスはバージョンと設定に応じて /etc/containerd/config.toml または /etc/containerd/config.d/01-containerd.conf などのパスになる場合があります）を調べます。ファイルに、ミラー エンドポイントの更新された hosts リストが表示されない。

    回避策:

    次のいずれかを選択します。

    1. 修正を含むバージョンにアップグレードする: クラスタを 1.30.500-gke.126 以降、1.31.100-gke.136 以降、または 1.32.0 にアップグレードします。
    2. NodePool の変更を介して更新をトリガーする: 影響を受けるノードの NodePool 仕様に小さな変更を加えます。たとえば、一時的なラベルやアノテーションを追加します。これにより、レジストリ ミラーの変更を取得するマシン更新プロセスがトリガーされます。些細な変更は後で削除できます。

    次のステップ

    さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。サポート リソースの詳細（以下の内容など）については、サポートを受けるもご覧ください。

    • サポートケースを登録するための要件。
    • 環境構成、ログ、指標など、トラブルシューティングに役立つツール。
    • サポート対象のコンポーネント。