Version 1.16. This version is no longer supported. For information about how to upgrade to version 1.28, see Upgrade clusters in the latest documentation. For more information about supported and unsupported versions, see the Versioning page in the latest documentation.

GKE on Bare Metal の既知の問題

このページには、Google Distributed Cloud Virtual for Bare Metal のすべての既知の問題が記載されています。既知の問題をプロダクトバージョンまたはカテゴリでフィルタするには、次のプルダウンメニューからフィルタを選択します。

GDCV for Bare Metal のバージョンを選択します。

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

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

Category 識別されたバージョン問題と回避策

リセット / 削除

1.29.0

ユーザークラスタをリセットしようとして名前空間を削除できない

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

回避策:

名前空間を削除してユーザークラスタのリセットを完了するには、次の手順を行います。

クラスタから metrics-server Pod を削除します。
```
kubectl delete pods -l k8s-app=metrics-server \
    -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
```
この場合、metrics-server Pod はクラスタの名前空間の削除を禁止します。
管理クラスタで、ユーザークラスタの名前空間のファイナライザを強制的に削除します。
```
kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
    jq '.spec.finalizers = []' | \
    kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
```
ファイナライザが削除されると、クラスタの名前空間が削除され、クラスタのリセットが完了します。

構成、インストール、セキュリティ

1.16.0 から 1.16.7 へ、1.28.0 から 1.28.400 へ

Binary Authorization のデプロイに nodeSelector がない

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

回避策:

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

Binary Authorization Deployment ファイルを開きます。


kubectl edit -n binauthz-system deployment binauthz-module-deployment

spec.template.spec ブロックに次の nodeSelector を追加します。


      nodeSelector:
        node-role.kubernetes.io/control-plane: ""

変更を保存します。

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

アップグレードと更新

1.28.0、1.28.100、1.28.200、1.28.300

クラスタを 1.28.0 ～ 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

ログエクスプローラに表示されるプロジェクト ID が正しくない

ログエクスプローラの 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.0

BGP によるバンドル型ロードバランシングを使用したクラスタのパフォーマンス低下

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

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

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

Container Registry エンドポイントの `gcr.io` 接続の問題でクラスタオペレーションがブロックされる可能性がある

管理クラスタの複数のクラスタオペレーションにより、ブートストラップクラスタが作成されます。ブートストラップクラスタを作成する前に、bmctl は管理ワークステーションから Google Cloud ネットワーク到達性チェックを実行します。このチェックは、Container 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 は一部のストレージドライバと互換性がない

GKE on Bare Metal は 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` OOM

kube-state-metrics と同じノード上にある kube-state-metrics または gke-metrics-agent Pod のメモリ不足（OOM）に注意してください。

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

回避策

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

この回避策を使用するには、次の手順を行います。

使用可能なフィーチャーゲートについて、stackdriver カスタムリソース定義を確認します。

kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly

stackdriver カスタムリソース定義を更新して、ksmNodePodMetricsOnly を有効にします。
```
kind:stackdriver
spec:
  featureGates:
     ksmNodePodMetricsOnly: true
        
```

インストール

1.28.0-1.28.200

iptables がないために RHEL 9.2 でプリフライトチェックが失敗する

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

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

RHEL 9.2 は、GKE on Bare Metal バージョン 1.28 のプレビュー版です。

回避策

クラスタリソースで spec.bypassPreflightCheck を true に設定すると、プリフライトチェックエラーをバイパスします。

オペレーション

1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

高スケールでの MetalLB フェイルオーバーが遅い

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

`audit.log` の所有権が正しくない場合、バージョン 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

MetalLB で VIP Service に IP アドレスが割り当てられない

GKE on Bare Metal では、バンドル型ロードバランシングに MetalLB を使用します。GKE on Bare Metal のリリース 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 アドレスを受信しなくなります。

この問題は、GKE on Bare Metal バージョン 1.28.100-gke.146 で修正されています。

回避策

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

IPAddressPool の変換された名前を取得します。
```
kubectl get IPAddressPools -n kube-system
```
影響を受ける 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

GKE on Bare Metal クラスタをバージョン 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

この問題は、GKE on Bare Metal バージョン 1.15.0 以降では修正されています。

インストール

1.14

クラスタの作成が `machine-init` ジョブで先に進まない

Google Distributed Cloud Virtual for Bare Metal バージョン 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 メンバーを削除します。機能しているコントロールプレーンノードで次の手順を行います。

既存の 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

障害が発生した 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-operator` にノード `list` と `watch` の権限がない

Cilium 1.13 では、cilium-operator ClusterRole 権限が正しくありません。ノードの 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 権限をオペレーターに追加します。

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

アップグレードと更新

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

デバイス名にピリオドが含まれている場合、Network Gateway for GDC は構成を適用できません

ネットワークデバイスの名前がピリオド（.）が含まれる 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` を無効にすると、1.16.0 へのアップグレードが失敗する

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

GKE on Bare Metal バージョン 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 メタデータが破損する可能性がある

必要に応じて /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

クラスタ内の古い Pod をクリーンアップする

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 を削除できます。

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

アップグレード

1.16.0

バージョン 1.16.0 にアップグレードすると、etcd イベントが停止する場合がある

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

この問題の影響を受けると、次のような 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

回避策:

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

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

ネットワーキング

1.15.0-1.15.2

CoreDNS `orderPolicy` が認識されない

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

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

回避策:

CoreDNS テンプレートを更新し、修正を適用します。この修正はアップグレードまで続きます。

既存のテンプレートを編集します。

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

優先度クラスがないため、GDC コンポーネントが強制排除される、または保留中になる

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 のスケジューリング不能を示しています。GDC Pod 用ネットワークゲートウェイには PriorityClass がないため、他のワークロードと同じデフォルトの優先度が設定されます。ノードがリソースの制約を受けると、ネットワークゲートウェイ Pod が強制排除されることがあります。この動作は ang-node DaemonSet では特に良好ではない状態になります。これらの Pod は特定のノードでスケジュールする必要があり、移行できないためです。

回避策:

1.15 以降にアップグレードしてください。

一時的な修正として、GDC コンポーネント用のネットワークゲートウェイに PriorityClass を手動で割り当てることができます。GKE on Bare Metal コントローラは、クラスタのアップグレード中など、調整プロセス中にこれらの手動の変更を上書きします。

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 へのアップグレードが失敗します。クラスタの作成とアップグレードのオペレーション中に、GKE on Bare Metal は、クラスタ名とバージョンを組み込む名前のヘルスチェックリソースを作成します。

バージョン 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 にアップグレードできない

バージョン 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

バージョン 1.15 クラスタは、重複するフローティング IP アドレスを受け入れない

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

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

IP address exists in other gateway with name default

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

回避策:

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

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

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

GDC 上の VM ランタイム

1.13.7

非公開レジストリを使用する 1.13.7 クラスタで VM が起動しない場合がある

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

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

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

回避策

クラスタを直ちにアップグレードできない場合は、手動でイメージを 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 クラスタでのクラスタ作成中に、gke-metric-agent Pod が起動しない

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

回避策

オペレーション、ネットワーキング

1.12、1.13、1.14、1.15、1.16、1.28

IPv6 Service エンドポイントにアクセスすると、CentOS または RHEL の LoadBalancer ノードがクラッシュする

デュアルスタック 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

`clientconfig-operator` が `CreateContainerConfigError` で保留状態のままになる

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

デュアルスタッククラスタの `ipam-controller-manager` クラッシュループ

デュアルスタッククラスタ（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 ウォッチの不足

etcd バージョン 3.4.13 以前を実行しているクラスタでは、ウォッチの枯渇と非運用リソースのウォッチが発生する場合があります。これは、次の問題につながる可能性があります。

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

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

この問題は、GDCV for Bare Metal バージョン 1.12.9、1.13.6、1.14.3、およびそれ以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 を使用します。以前のバージョンの GDCV for Bare Metal はすべて、この問題の影響を受けます。

回避策

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

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

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

ネットワーキング

1.11.6、1.12.3

SR-IOV 演算子の `vfio-pci` モードが「Failed」状態

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 状態にならない

アップグレードが完了すると、一部のワーカーノードで 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

cert-manager から複数の証明書がローテーションされると、不整合が発生する

複数の手動または自動証明書ローテーションを行った後、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

ユーザークラスタのアップグレード中に作成された、古いライフサイクルコントローラデプロイヤー Pod

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

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

回避策:

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

プリフライトチェックリソースを一覧表示します。

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 はクラスタ名です。

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

受信ルートが多数存在するため `BGPSession` の状態が常に変化する

外部ピアが多数のルート（約 100 以上）をアドバタイズすると、GKE on Bare Metal の高度なネットワークは 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 に置き換えます。

回避策:

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

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

ネットワーキング

1.14、1.15、1.16、1.28

conntrack テーブル挿入エラーによるアプリケーションタイムアウト

カーネル 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` を使用してクラスタのバックアップを復元できない

アップグレードが失敗した場合に以前のバージョンを復元できるように、アップグレードする前にクラスタをバックアップすることをおすすめします。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

インターフェースに IP アドレスがない場合に、`NetworkGatewayGroup` がクラッシュする

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

コントロールプレーンノードの削除時の `anthos-cluster-operator` クラッシュループ

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: クラスタの名前空間。

インストール

1.13.1、1.13.2、1.13.3

トークンの不一致のために大規模なクラスタで `kubeadm join` が失敗する

多数のノードを持つ GKE on Bare Metal クラスタをインストールすると、次の例のような 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"]}

回避策:

この問題は、GDCV for Bare Metal バージョン 1.13.4 以降で解決されています。

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

ロギングとモニタリング

1.10、1.11、1.12、1.13.0

Edge クラスタでの `metrics-server` の CPU 上限が低い

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

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

GKE on Bare Metal クラスタバージョン 1.x-1.12:

kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml

GKE on Bare Metal クラスタバージョン 1.13 以降:

kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

回避策:

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

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

スケールダウン metrics-server-operator

kubectl scale deploy metrics-server-operator --replicas=0

構成を更新して CPU の上限を引き上げます。

GKE on Bare Metal クラスタバージョン 1.x-1.12:

kubectl -n kube-system edit deployment metrics-server

GKE on Bare Metal クラスタバージョン 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
[...]

metrics-server を保存して閉じ、変更を適用します。

ネットワーキング

1.14、1.15、1.16

hostNetwork Pod への NodePort 直接接続が機能しない

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.13.0 を実行する管理クラスタは、バージョン 1.12.3 を実行するユーザークラスタを管理できません。バージョン 1.12.3 のユーザークラスタに対するオペレーションは失敗します。

回避策:

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

アップグレードと更新

1.12

ワーカーノードプールがある管理クラスタでは、1.13.x へのアップグレードがブロックされる

バージョン 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` を使用したリソース更新時のエラー

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

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

既存の YAML 定義を取得します。

kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml

YAML ファイルで機能を有効にするか、構成を更新します。
更新された YAML ファイルを再度適用します。
```
kubectl apply -f stackdriver.yaml
```

kubectl apply の最後のステップで、問題が発生する場合があります。

回避策:

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

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

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

既存の YAML 定義を取得します。

kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml

YAML ファイルで機能を有効にするか、構成を更新します。

更新された 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` のクラッシュループの原因となる

破損したバックログチャンクを処理しようとすると、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 にログが表示されません。

回避策:

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

破損したバックログチャンクを特定します。次のエラーメッセージの例を確認します。
```
[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 ファイルを削除する必要があります。
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 が削除されたことを確認して、次のステップに進みます。
stackdriver-log-forwarder が実行されている SSH を使用してノードに接続します。

ノードで、var/log/fluent-bit-buffers/tail.1/ 内の破損した *.flb ファイルをすべて削除します。

破損したファイルが多すぎる場合、スクリプトを適用してすべてのバックログチャンクをクリーンアップするには、次のスクリプトを使用します。

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

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

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

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

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

クラスタで Dataplane V2（`anetd`）を再起動すると、既存の VM が Pod 以外のネットワークに接続できなくなる可能性がある

マルチ 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` に、Edge プロファイルクラスタに対するメモリ上限がない

クラスタのワークロードによっては、gke-metrics-agent が 4,608 MiB を超えるメモリを使用する場合があります。この問題は、GKE on 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 機能で whereabouts プラグインを使用しても、予約済み IP アドレスが解放されない

マルチ 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.10.4 ユーザークラスタで Node Problem Detector が失敗する

バージョン 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 アイランドモード IPv4 クラスタノードの Pod CIDR マスクサイズが 24 に設定されている

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

この問題は、65～128 の範囲外の maxPodsPerNode を使用するアイランドモード IPv4 クラスタにのみ影響します。

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

error="required IPv4 PodCIDR not available"

回避策

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

1.14.1 以降のバージョンにアップグレードします。
ワーカーノードを削除してから、追加し直します。
コントロールプレーンノードを削除してから、ノードを追加し直し（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

回避策:

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

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

ネットワーキング

1.12.0

Service の外部 IP アドレスがフラットモードで機能しない

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

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

回避策:

cilium-config ConfigMap で enable-415 を "true" に設定し、anetd Pod を再起動します。

アップグレードと更新

1.13.0、1.14

1.13.0 から 1.14.x へのインプレースアップグレードが完了しない

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

1.14.0 にアップグレードしたクラスタがマスター taint を失う

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

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

注: スタンドアロンタイプのクラスタなどの自己管理クラスタでは、デフォルトで PreferNoSchedule taint が使用されます。

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

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

コントロールプレーンノードを検索するには、次のコマンドを使用します。

kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH

ノードの taint のリストを確認するには、次のコマンドを使用します。
```
kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH
```
必要な taint のいずれも一覧表示されない場合は、影響を受けています。

回避策

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

回避策を表示する

欠落している taint を適用します。

kubectl taint nodes NODE_NAME \
    node-role.kubernetes.io/master:NoSchedule \
    -–kubeconfig KUBECONFIG_PATH

node-role.kubernetes.io/master:NoSchedule toleration がない Pod を検索します。

kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \
    -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \
    --kubeconfig KUBECONFIG_PATH | \
    grep -v  "node-role.kubernetes.io/master" | uniq

node-role.kubernetes.io/master:NoSchedule toleration がない Pod を削除します。
```
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
```

オペレーション、GDC 上の VM ランタイム

1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29

VM の作成が断続的にアップロードエラーで失敗する

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

1.11 クラスタ内のマネージドコレクションコンポーネントは、1.12 へのアップグレードで保持されない

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

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

回避策

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

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

アップグレードと更新

1.13

Docker コンテナランタイムを使用している一部のバージョン 1.12 クラスタが、バージョン 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

クラスタの作成が完了する前に `bmctl` が終了してしまう

GDCV for Bare Metal バージョン 1.11.0 では、クラスタ作成に失敗する場合があります（この問題は、GDCV for Bare Metal リリース 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

回避策

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

回避策を表示する

クラスタのアーティファクトを削除してノードマシンをリセットするには、次のコマンドを実行します。
```
bmctl reset -c USER_CLUSTER_NAME
```
クラスタ作成オペレーションを開始するには、次のコマンドを実行します。
```
bmctl create cluster -c USER_CLUSTER_NAME \
    --keep-bootstrap-cluster
```
このコマンドが失敗した場合、--keep-bootstrap-cluster フラグが重要になります。クラスタ作成コマンドが成功した場合は、残りの手順をスキップできます。それ以外の場合は次に進みます。
次のコマンドを実行して、ブートストラップクラスタのバージョンを取得します。
```
kubectl get cluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig bmctl-workspace/.kindkubeconfig \
    -o=jsonpath='{.status.anthosBareMetalVersion}
```
出力は 1.11.0 である必要があります。出力が「1.11.0」でない場合は、1～2 分待ってから再試行してください。

リソースをブートストラップクラスタからターゲットクラスタに手動で移動するには、次のコマンドを実行します。

bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \
    --to-kubeconfig \
    bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \
    -n USER_CLUSTER_NAMESPACE

クラスタを削除するには、次のコマンドを実行します。
```
bmctl reset bootstrap
```

インストール、GDC 上の VM ランタイム

1.11, 1.12

インストールで VM ランタイムの調整エラーが報告される

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

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

マルチ NIC、`containerd`、HTTP プロキシを使用していると、クラスタの作成に失敗する

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

クラスタが、コンテナランタイムとして containerd を使用するように構成されています（クラスタ構成ファイルで nodeConfig.containerRuntime が containerd に設定されています。これは GDCV for Bare Metal バージョン 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

制限付きの `umask` 設定があるシステムでのエラー

GDCV for Bare Metal のリリース 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 の非互換性

コントロールグループ v2（cgroup v2）は、GDCV for Bare Metal のバージョン 1.13 以前の GKE on Bare Metal クラスタではサポートされていません。ただし、バージョン 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

vSphere へのインストール

vSphere VM に GKE on Bare Metal クラスタをインストールする場合は、tx-udp_tnl-segmentation フラグと tx-udp_tnl-csum-segmentation フラグをオフに設定する必要があります。これらのフラグは、vSphere ドライバ VMXNET3 によるハードウェアセグメンテーションオフロードに関連しており、GKE on Bare Metal クラスタの 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` は、前のバージョンのユーザークラスタを作成、更新、リセットすることはできません

管理クラスタのバージョンにかかわらず、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

バージョン 1.12.1 へのクラスタのアップグレードが停止する場合がある

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

GDC で VM ランタイムが有効になっている場合は、クラスタをバージョン 1.12.0 以降にアップグレードできない

バージョン 1.12.0 の GKE on Bare Metal クラスタでは、GDC 上の VM ランタイムの一般提供リリースを適切にサポートするために、GDC 上の VM ランタイムに関連するすべてのリソースが 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 ランタイムを無効にするには:

VMRuntime カスタムリソースを編集します。
```
kubectl edit vmruntime
```

仕様で enabled を false に設定します。

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...

カスタムリソースをエディタに保存します。
クラスタのアップグレードが完了したら、GDC で VM ランタイムを再度有効にします。

詳細については、VM ベースのワークロードの操作をご覧ください。

アップグレードと更新

1.10、1.11、1.12

`error during manifests operations` でアップグレードが停止する

場合によっては、クラスタのアップグレードが完了せず、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} は問題リソースの名前です。

回避策

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

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

アップグレードと更新

1.10、1.11、1.12

Network Gateway for GDC を使用する機能を持つクラスタのアップグレードがブロックされる

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


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

回避策

注意: 次の回避策では、マニフェストを削除し、BGP とのバンドル型ロードバランシングに 30～60 秒の短いダウンタイムが発生します。BGP セッションは破棄され、再確立されます。この間、LoadBalancer サービスは使用できません。anthos-cluster-operator によりマニフェストが再インストールされると、機能が回復します。

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

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` でメンテナンスブロックが削除されない

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

回避策

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

オペレーション

1.10、1.11、1.12

メンテナンスモード手順を使用しない場合、ノードが閉鎖解除される

バージョン 1.12.0 以前のクラスタ（anthosBareMetalVersion: 1.12.0）を実行し、ノードで kubectl cordon を手動で使用する場合、GKE on Bare Metal は、想定される状態を調整する必要があります。

回避策

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

バージョン 1.12.1（anthosBareMetalVersion: 1.12.1）以降では、kubectl cordon を使用しても、GKE on Bare Metal が予期せずノードを閉鎖解除しません。

オペレーション

1.11

レジストリミラーを使用するバージョン 11 の管理クラスタは、バージョン 1.10 のクラスタを管理できない

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

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


flag provided but not defined: -registry-mirror-host-to-endpoints

オペレーション

1.10, 1.11

kubeconfig シークレットが上書きされる

bmctl check cluster コマンドをユーザークラスタで実行すると、ユーザークラスタ kubeconfig シークレットが管理クラスタ kubeconfig で上書きされます。このファイルを上書きすると、更新やアップグレードなどの標準のクラスタオペレーションが、影響を受けるユーザークラスタで失敗します。この問題は、GKE on Bare Metal クラスタバージョン 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: クラスタの名前空間。デフォルトでは GKE on Bare Metal クラスタのクラスタ名前空間は、先頭に 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）に機能を復元します。

ユーザークラスタ kubeconfig ファイルを見つけます。GKE on Bare Metal は、クラスタの作成時に管理ワークステーションに kubeconfig ファイルを生成します。デフォルトでは、このファイルは bmctl-workspace/USER_CLUSTER_NAME ディレクトリにあります。
この kubeconfig が正しいユーザークラスタ kubeconfig であることを確認します。
```
kubectl get nodes \
    --kubeconfig PATH_TO_GENERATED_FILE
```
PATH_TO_GENERATED_FILE は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。ユーザークラスタのノードに関する詳細情報が返されます。マシン名がクラスタに対して正しいことを確認します。
次のコマンドを実行して、管理クラスタ内の壊れた kubeconfig ファイルを削除します。
```
kubectl delete secret \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig
```

次のコマンドを実行して、正しい 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

コンテナランタイムとして 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

`stackdriver-log-forwarder` には `[parser:cri] invalid time format` 警告ログがあります

コンテナランタイムインターフェース（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.11.0 以降にアップグレードします。

クラスタをすぐにアップグレードできない場合は、次の手順を使用して CRI 解析正規表現を更新します。

変更が元の状態に戻ることを回避するには、stackdriver-operator をスケールダウンします。

kubectl  --kubeconfig KUBECONFIG \
    -n kube-system scale deploy \
    stackdriver-operator --replicas=0

stackdriver-log-forwarder-config ConfigMap の Regex エントリを編集します。

kubectl --kubeconfig KUBECONFIG \
    -n kube-system edit configmap \
    stackdriver-log-forwarder-config

編集したリソースは、次のようになります。

[PARSER]
    # https://rubular.com/r/Vn30bO78GlkvyB
    Name cri
    Format regex
    # The timestamp is described in
    https://www.rfc-editor.org/rfc/rfc3339#section-5.6
    Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9]
    {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]
    {2}:[0-9]{2})) (?<stream>stdout|stderr)
    (?<logtag>[^ ]*) (?<log>.*)$
    Time_Key    time
    Time_Format %Y-%m-%dT%H:%M:%S.%L%z
    Time_Keep   off

ログフォワーダー Pod を再起動します。

kubectl --kubeconfig KUBECONFIG \
    -n kube-system rollout restart daemonset \
    stackdriver-log-forwarder

ロギングとモニタリング

1.10、1.11、1.12、1.13、1.14、1.15

予想外の請求のモニタリング

GKE on Bare Metal クラスタバージョン 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 にアップグレードできない場合は、次の手順を使用します。

不要な請求があるソース 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"'

Pod または Service から prometheus.io/scrap=true アノテーションを削除します。

ロギングとモニタリング

1.11、1.12、1.13、1.14、1.15、1.16、1.28

`metrics-server-config` への編集が保持されない

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

サポートが終了した指標は Cloud Monitoring ダッシュボードに影響を与える

いくつかの GKE on Bare Metal 指標が非推奨になりました。GDCV for Bare Metal リリース 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 より前の GKE on Bare Metal では、推奨 Anthos on baremetal node cpu usage exceeds 80 percent (critical) アラートのポリシー定義ファイルによってサポートが終了した指標が使用されます。node-cpu-usage-high.json JSON 定義ファイルは、リリース 1.11.0 以降用に更新されます。

回避策

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

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

ロギングとモニタリング

1.10, 1.11

`stackdriver-log-forwarder` の `CrashloopBackOff` エラー

状況によっては、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 ファイルへのパスに置き換えます。

すべての 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 が削除されたことを確認して、次のステップに進みます。

次の 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

次のコマンドを使用して、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 つのコマンドの出力は、クラスタ内のノード数と同じになります。

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

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

ログフォワーダー 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 ログに不明な指標エラーがある

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

指標エクスポートの断続的な中断

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

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 以降にアップグレードします。

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

stackdriver リソースを編集用に開きます。

kubectl -n kube-system edit stackdriver stackdriver

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

変更を保存し、テキストエディタを終了します。
変更が有効になっていることを確認するには、次のコマンドを実行します。
```
kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
```
変更が有効になっている場合は、このコマンドで cpu: 50m が検出されます。

ネットワーキング

1.10

複数のデフォルトゲートウェイで外部エンドポイントへの接続が切断される

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

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

ip route show

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

ネットワーキング

1.12

ユーザークラスタのネットワーキングカスタムリソースの編集内容が上書きされる

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

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

BGPLoadBalancer
BGPPeer
NetworkGatewayGroup
NetworkAttachmentDefinition
ClusterCIDRConfig
FlatIPMode

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

回避策

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

ネットワーキング

1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

Pod の接続障害とリバースパスフィルタリング

GKE on Bare Metal　は、ソースの検証を無効にするために、ノードでリバースパスフィルタリングを構成します（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

ブートストラップ（kind）クラスタ IP アドレスとクラスタノードの IP アドレスの重複

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

CentOS でクラスタの作成またはアップグレードの失敗

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

回避策

回避策を表示する

回避策として、次のコマンドを実行し、CentOS でアーカイブフィードを使用します。

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

長期的な解決策としては、別のサポートされているオペレーティングシステムへの移行を検討してください。

セキュリティ

1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28

コンテナが、containerd と SELinux を使用して Dockerfile で定義された `VOLUME` に書き込むことができない

コンテナランタイムとして 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 が、クラスタのアップグレード後にデフォルトで有効になっていない

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

回避策:

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

ノードで node-problem-detector systemd サービスが実行されているかどうかを確認します。
1. SSH コマンドを使用してノードに接続します。
2. ノードで node-problem-detector systemd サービスが実行されているかどうかを確認します。
```
systemctl is-active node-problem-detector
```
  コマンドの結果に inactive と表示されている場合、node-problem-detector はノード上で実行されていません。
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 を使用する場合は、次の回避策をお勧めします。

コントロールプレーンノードではなくワーカーノードで実行する
Service 仕様で externalTrafficPolicy: local を使用し、ワークロードがロードバランサノードで実行されるようにする

アップグレードと更新

1.12、1.13

孤立した anthos-version-$version$ Pod がイメージを pull できない

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.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.
...

回避策:

この問題を回避するには:

管理ワークステーションで次のコマンドを実行します。

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'

クラスタのアップグレードをもう一度試行します。

ロギングとモニタリング

1.16.2、1.16.3

`stackdriver-operator` の CPU 使用率が高い

stackdriver-operator に問題があるため、通常より消費する CPU 時間が長くなります。通常の CPU 使用率がアイドル状態の stackdriver-operator に対して 50 ミリ CPU（50m）未満。stackdriver-operator が cert-manager の想定に基づいて適用する証明書リソースの不一致が原因です。この不一致により、リソースを更新する際に cert-manager と stackdriver-operator の間に競合状態が発生します。

この問題により、CPU の可用性が制限されているクラスタではパフォーマンスが低下する可能性があります。

回避策:

このバグを修正したバージョンにアップグレードできるようになるまで、次の回避策を使用します。

一時的に stackdriver-operator を 0 レプリカにスケールダウンするには、AddonConfiguration カスタムリソースを適用します。
```
kubectl scale deploy stackdriver-operator --replicas=0
```
この問題を解決するバージョンにアップグレードしたら、stackdriver-operator バックアップを再度スケーリングします。
```
kubectl scale deploy stackdriver-operator --replicas=1
```

ロギングとモニタリング

1.16.0、1.16.1

アノテーションベースの指標のスクレイピングが機能しない

GDCV for Bare Metal 1.16 のマイナーリリースでは、stackdriver カスタムリソース仕様の enableStackdriverForApplications フィールドが非推奨になりました。このフィールドは、Stackdriver カスタムリソースの 2 つのフィールド（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 の指標が変更された際に対応できるようにしてください。

さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。

GKE on Bare Metal の既知の問題

ユーザー クラスタをリセットしようとして名前空間を削除できない

Binary Authorization のデプロイに nodeSelector がない

クラスタを 1.28.0 ～ 1.28.300 にアップグレードする際にエラーが発生する

ログ エクスプローラに表示されるプロジェクト ID が正しくない

BGP によるバンドル型ロード バランシングを使用したクラスタのパフォーマンス低下

Container Registry エンドポイントの gcr.io 接続の問題でクラスタ オペレーションがブロックされる可能性がある

GKE Dataplane V2 は一部のストレージ ドライバと互換性がない

大規模なクラスタにおける kube-state-metrics OOM

iptables がないために RHEL 9.2 でプリフライト チェックが失敗する

高スケールでの MetalLB フェイルオーバーが遅い

プロキシが有効になっている場合は、管理ワークステーションで環境変数を設定する必要があります

audit.log の所有権が正しくない場合、バージョン 1.28.0-gke.435 へのアップグレードが失敗することがある

MetalLB で VIP Service に IP アドレスが割り当てられない

バージョン 1.14.x にアップグレードした後の孤立した Pod

クラスタの作成が machine-init ジョブで先に進まない

Cilium-operator にノード list と watch の権限がない

プリフライト チェック中に発生した一時的な問題

ノードが置換または削除されると、定期的なネットワーク ヘルスチェックが失敗する

デバイス名にピリオドが含まれている場合、Network Gateway for GDC は構成を適用できません

seccomp を無効にすると、1.16.0 へのアップグレードが失敗する

/var/lib/containerd がマウントされると、再起動後に containerd メタデータが破損する可能性がある

クラスタ内の古い Pod をクリーンアップする

バージョン 1.16.0 にアップグレードすると、etcd イベントが停止する場合がある

CoreDNS orderPolicy が認識されない

優先度クラスがないため、GDC コンポーネントが強制排除される、または保留中になる

クラスタ名の長さが原因でクラスタの作成とアップグレードが失敗する

プレビュー機能を備えたバージョン 1.14.0 と 1.14.1 のクラスタをバージョン 1.15.x にアップグレードできない

バージョン 1.15 クラスタは、重複するフローティング IP アドレスを受け入れない

非公開レジストリを使用する 1.13.7 クラスタで VM が起動しない場合がある

kind クラスタでのクラスタ作成中に、gke-metric-agent Pod が起動しない

IPv6 Service エンドポイントにアクセスすると、CentOS または RHEL の LoadBalancer ノードがクラッシュする

ノード再起動後の断続的な接続の問題

プレビュー機能では、元の権限とオーナー情報が保持されない

clientconfig-operator が CreateContainerConfigError で保留状態のままになる

バンドル型ロード バランシングのないクラスタの認証局のローテーションが失敗する

デュアルスタック クラスタの ipam-controller-manager クラッシュループ

etcd ウォッチの不足

SR-IOV 演算子の vfio-pci モードが「Failed」状態

アップグレード後に一部のワーカーノードが Ready 状態にならない

cert-manager から複数の証明書がローテーションされると、不整合が発生する

ユーザー クラスタのアップグレード中に作成された、古いライフサイクル コントローラ デプロイヤー Pod

受信ルートが多数存在するため BGPSession の状態が常に変化する

conntrack テーブル挿入エラーによるアプリケーション タイムアウト

一部のバージョンでは bmctl を使用してクラスタのバックアップを復元できない

インターフェースに IP アドレスがない場合に、NetworkGatewayGroup がクラッシュする

コントロール プレーンノードの削除時の anthos-cluster-operator クラッシュ ループ

トークンの不一致のために大規模なクラスタで kubeadm join が失敗する

Edge クラスタでの metrics-server の CPU 上限が低い

hostNetwork Pod への NodePort 直接接続が機能しない

1.13.0 管理クラスタは 1.12.3 ユーザー クラスタを管理できない

ワーカー ノードプールがある管理クラスタでは、1.13.x へのアップグレードがブロックされる

kubectl apply を使用したリソース更新時のエラー

バックログ チャンクの破損が stackdriver-log-forwarder のクラッシュ ループの原因となる

クラスタで Dataplane V2（anetd）を再起動すると、既存の VM が Pod 以外のネットワークに接続できなくなる可能性がある

gke-metrics-agent に、Edge プロファイル クラスタに対するメモリ上限がない

競合状態が原因でクラスタの作成に失敗する場合がある

マルチ NIC 機能で whereabouts プラグインを使用しても、予約済み IP アドレスが解放されない

1.10.4 ユーザー クラスタで Node Problem Detector が失敗する

1.14 アイランド モード IPv4 クラスタノードの Pod CIDR マスクサイズが 24 に設定されている

クラスタ アップグレードのロールバックの失敗

Service の外部 IP アドレスがフラットモードで機能しない

1.13.0 から 1.14.x へのインプレース アップグレードが完了しない

1.14.0 にアップグレードしたクラスタがマスター taint を失う

回避策を表示する

VM の作成が断続的にアップロード エラーで失敗する

1.11 クラスタ内のマネージド コレクション コンポーネントは、1.12 へのアップグレードで保持されない

Docker コンテナ ランタイムを使用している一部のバージョン 1.12 クラスタが、バージョン 1.13 にアップグレードできない

クラスタの作成が完了する前に bmctl が終了してしまう

回避策を表示する

インストールで VM ランタイムの調整エラーが報告される

マルチ NIC、containerd、HTTP プロキシを使用していると、クラスタの作成に失敗する

制限付きの umask 設定があるシステムでのエラー

コントロール グループ v2 の非互換性

プリフライト チェックとサービス アカウント認証情報

vSphere へのインストール

bmctl は、前のバージョンのユーザー クラスタを作成、更新、リセットすることはできません

バージョン 1.12.1 へのクラスタのアップグレードが停止する場合がある

GDC で VM ランタイムが有効になっている場合は、クラスタをバージョン 1.12.0 以降にアップグレードできない

error during manifests operations でアップグレードが停止する

ユーザークラスタをリセットしようとして名前空間を削除できない

ログエクスプローラに表示されるプロジェクト ID が正しくない

BGP によるバンドル型ロードバランシングを使用したクラスタのパフォーマンス低下

Container Registry エンドポイントの `gcr.io` 接続の問題でクラスタオペレーションがブロックされる可能性がある

GKE Dataplane V2 は一部のストレージドライバと互換性がない

大規模なクラスタにおける `kube-state-metrics` OOM

iptables がないために RHEL 9.2 でプリフライトチェックが失敗する

`audit.log` の所有権が正しくない場合、バージョン 1.28.0-gke.435 へのアップグレードが失敗することがある

クラスタの作成が `machine-init` ジョブで先に進まない

`Cilium-operator` にノード `list` と `watch` の権限がない

プリフライトチェック中に発生した一時的な問題

ノードが置換または削除されると、定期的なネットワークヘルスチェックが失敗する

`seccomp` を無効にすると、1.16.0 へのアップグレードが失敗する

`/var/lib/containerd` がマウントされると、再起動後に containerd メタデータが破損する可能性がある

CoreDNS `orderPolicy` が認識されない

`clientconfig-operator` が `CreateContainerConfigError` で保留状態のままになる

バンドル型ロードバランシングのないクラスタの認証局のローテーションが失敗する

デュアルスタッククラスタの `ipam-controller-manager` クラッシュループ

SR-IOV 演算子の `vfio-pci` モードが「Failed」状態

ユーザークラスタのアップグレード中に作成された、古いライフサイクルコントローラデプロイヤー Pod

受信ルートが多数存在するため `BGPSession` の状態が常に変化する

conntrack テーブル挿入エラーによるアプリケーションタイムアウト

一部のバージョンでは `bmctl` を使用してクラスタのバックアップを復元できない

インターフェースに IP アドレスがない場合に、`NetworkGatewayGroup` がクラッシュする

コントロールプレーンノードの削除時の `anthos-cluster-operator` クラッシュループ

トークンの不一致のために大規模なクラスタで `kubeadm join` が失敗する

Edge クラスタでの `metrics-server` の CPU 上限が低い

1.13.0 管理クラスタは 1.12.3 ユーザークラスタを管理できない

ワーカーノードプールがある管理クラスタでは、1.13.x へのアップグレードがブロックされる

`kubectl apply` を使用したリソース更新時のエラー

バックログチャンクの破損が `stackdriver-log-forwarder` のクラッシュループの原因となる

クラスタで Dataplane V2（`anetd`）を再起動すると、既存の VM が Pod 以外のネットワークに接続できなくなる可能性がある

`gke-metrics-agent` に、Edge プロファイルクラスタに対するメモリ上限がない

1.10.4 ユーザークラスタで Node Problem Detector が失敗する

1.14 アイランドモード IPv4 クラスタノードの Pod CIDR マスクサイズが 24 に設定されている

クラスタアップグレードのロールバックの失敗

1.13.0 から 1.14.x へのインプレースアップグレードが完了しない

VM の作成が断続的にアップロードエラーで失敗する

1.11 クラスタ内のマネージドコレクションコンポーネントは、1.12 へのアップグレードで保持されない

Docker コンテナランタイムを使用している一部のバージョン 1.12 クラスタが、バージョン 1.13 にアップグレードできない

クラスタの作成が完了する前に `bmctl` が終了してしまう

マルチ NIC、`containerd`、HTTP プロキシを使用していると、クラスタの作成に失敗する

制限付きの `umask` 設定があるシステムでのエラー

コントロールグループ v2 の非互換性

プリフライトチェックとサービスアカウント認証情報

`bmctl` は、前のバージョンのユーザークラスタを作成、更新、リセットすることはできません

`error during manifests operations` でアップグレードが停止する

`bmctl update` でメンテナンスブロックが削除されない

メンテナンスモード手順を使用しない場合、ノードが閉鎖解除される

レジストリミラーを使用するバージョン 11 の管理クラスタは、バージョン 1.10 のクラスタを管理できない

root 以外のログインユーザーとしてスナップショットを取得する

`stackdriver-log-forwarder` には `[parser:cri] invalid time format` 警告ログがあります

`metrics-server-config` への編集が保持されない

`stackdriver-log-forwarder` の `CrashloopBackOff` エラー

複数のデフォルトゲートウェイで外部エンドポイントへの接続が切断される

ユーザークラスタのネットワーキングカスタムリソースの編集内容が上書きされる

Pod の接続障害とリバースパスフィルタリング

コンテナが、containerd と SELinux を使用して Dockerfile で定義された `VOLUME` に書き込むことができない

ロードバランササービスが、コントロールプレーンホストネットワーク上のコンテナで機能しない

`stackdriver-operator` の CPU 使用率が高い

アノテーションベースの指標のスクレイピングが機能しない