ベアメタル版 Anthos クラスタの既知の問題

Anthos clusters on bare metal バージョンを選択します。

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

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

Category 識別されたバージョン 問題と回避策
アップグレードと更新 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.

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

回避策:

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

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

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

回避策

失敗したオペレーションによりアーティファクトが生成されますが、クラスタは動作しません。この問題の影響を受ける場合は、次の手順でアーティファクトをクリーンアップし、クラスタを作成します。
インストール 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 に設定されている。これは Anthos clusters on bare metal バージョン 1.11 のデフォルトである）。
  • クラスタが、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 設定があるシステムでのエラー

ベアメタル版 Anthos クラスタのリリース 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）は、ベアメタル版 Anthos クラスタではサポートされていません。/sys/fs/cgroup/cgroup.controllers の存在は、システムで cgroup v2 が使用されていることを示しています。


回避策

プリフライト チェックにより、クラスタマシンで cgroup v2 が使用されていないことが確認されます。
インストール 1.10, 1.11, 1.12, 1.13

インストール中の無害なエラー メッセージ

クラスタ作成ログを調査すると、クラスタの登録または Webhook の呼び出しに関する一時的なエラーが見つかる場合があります。


回避策

インストールではこうした操作を成功するまで再試行するため、これらのエラーは無視しても問題ありません。
インストール 1.10, 1.11, 1.12, 1.13

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

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

アプリケーションのデフォルト認証情報と bmctl

bmctl は、クラスタ オペレーションのロケーションの値が global に設定されていないときに、アプリケーションのデフォルト認証情報（ADC）を使用して cluster spec でその値を検証します。


回避策

ADC を機能させるには、GOOGLE_APPLICATION_CREDENTIALS 環境変数をサービス アカウント認証情報ファイルに向けるか、gcloud auth application-default login を実行する必要があります。
インストール 1.10, 1.11, 1.12, 1.13

Docker サービス

クラスタ ノードマシンで、Docker 実行可能ファイルが PATH 環境変数に存在し、Docker サービスが有効になっていない場合は、プリフライト チェックで不合格になり、Docker service is not active が報告されます。


回避策

Docker を削除するか、Docker サービスを有効にします。
インストール 1.10, 1.11, 1.12, 1.13

vSphere へのインストール

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


回避策

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


ethtool -k NET_INTFC |grep segm
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
NET_INTFC を、ノードの IP アドレスに関連付けられたネットワーク インターフェースに置き換えます。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 is not 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
アップグレードと更新 1.11, 1.12

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

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


Failed to upgrade cluster: cluster is not 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

回避策

Anthos VM ランタイムを無効にするには:

  1. VMRuntime カスタム リソースを編集します。 
    
kubectl edit vmruntime
  2. 仕様で enabled を false に設定します。 
    
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
...
  3. カスタム リソースをエディタに保存します。
  4. クラスタのアップグレードが完了したら、Anthos 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} は問題リソースの名前です。


回避策

ログにこうしたエラーが見つかった場合は、次の手順を行います。

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

Anthos ネットワーク ゲートウェイを使用する機能を持つクラスタのアップグレードがブロックされる

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


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

回避策

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


kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler

kubectl -n kube-system delete deployment \
    ang-controller-manager

kubectl -n kube-system delete ds ang-node
アップグレードと更新 1.10, 1.11, 1.12, 1.13

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

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


回避策

メンテナンス モードでノードを削除する手順などの詳細については、ノードをメンテナンス モードにするをご覧ください。
アップグレードと更新 1.10, 1.11, 1.12, 1.13

ノードが到達不能になると、ノードのドレインを開始できません

ベアメタル版 Anthos クラスタから Node にアクセスできない場合、Node のドレイン プロセスは開始されません。たとえば、クラスタのアップグレード プロセス中に 1 つの Node がオフラインになると、アップグレードが停止する可能性があります。めったに発生することではありません。


回避策

この問題が発生する可能性を最小限に抑えるには、アップグレードを開始する前に Node が正常に動作していることを確認してください。
アップグレードと更新 1.12

containerd 1.5.13 には libseccomp 2.5 以降が必要

Anthos clusters on bare metal リリース 1.12.1 には containerd バージョン 1.5.13 が付属しており、containerd のこのバージョンには libseccomp バージョン 2.5 以降が必要です。

システムに libseccomp バージョン 2.5 以降がインストールされていない場合は、既存のクラスタをバージョン 1.12.1 にアップグレードする前にこれを更新します。更新しなければ、次のようなロードバランサ ノードの cplb-update Pod にエラーが表示されることがあります。


runc did not terminate successfully: runc: symbol lookup error: runc: undefined symbol: seccomp_notify_respond

回避策

Ubuntu に最新バージョンの libseccomp をインストールするには、次のコマンドを実行します。


sudo apt-get install  libseccomp-dev

CentOS または RHEL に最新バージョンの libseccomp をインストールするには、次のコマンドを実行します。


sudo dnf -y install libseccomp-devel
オペレーション 1.10、1.11、1.12

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

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


回避策

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

バージョン 1.12.1（anthosBareMetalVersion: 1.12.1）以降では、kubectl cordon を使用しても、Anthos clusters 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 で上書きされます。このファイルを上書きすると、更新やアップグレードなどの標準のクラスタ オペレーションが、影響を受けるユーザー クラスタで失敗します。この問題は、バージョン 1.11.1 以前のベアメタル版 Anthos クラスタに適用されます。

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


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: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、デフォルトの名前空間は cluster-test になります。
  • USER_CLUSTER_NAME: 確認するユーザー クラスタの名前。

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


user-cluster-kubeconfig  -o json  | \
    jq -r '.data.value' | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

回避策

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

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

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

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

Anthos VM ランタイム - Pod を再起動すると、Pod 上の VM は IP アドレスを変更するか、IP アドレスが完全に失われます。

VM の IP アドレスが変更されても、Kubernetes サービスとして公開されている VM アプリケーションのネットワーク到達性に影響はありません。


回避策

IP アドレスが失われた場合、VM から dhclient を実行して VM の IP アドレスを取得する必要があります。
ロギングとモニタリング 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.10, 1.11, 1.12, 1.13

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

Anthos clusters on bare metal バージョン 1.10 と 1.11 の場合、[料金] ページで予想外に高い Metrics volume の料金が請求される場合があります。この問題は、次の両方の状況に該当する場合にのみ影響します。

  • アプリケーションのロギングとモニタリングが有効になっている（enableStackdriverForApplications=true）
  • アプリケーションの Pod に prometheus.io/scrap=true アノテーションが付いている

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


回避策

アプリケーションのロギングとモニタリングの使用時に Metrics volume の追加料金がかからないようにするには、次の手順に従います。

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

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

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


回避策

別の方法として、ConfigMap の編集をスクリプト化し、クラスタの更新またはアップグレードとともに実行することも可能です。
ロギングとモニタリング 1.11, 1.12

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

いくつかの Anthos 指標がサーポート終了になっており、ベアメタル版 Anthos クラスタ リリース 1.11で始めると、これらのサポートが終了したの指標のデータは収集されなくなりました。これらの指標をいずれかのアラート ポリシーで使用する場合、アラート条件をトリガーするデータはありません。

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

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

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


回避策

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

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

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 ファイルのパスに置き換えます。

  1. すべての stackdriver-log-forwarder Pod を終了します。 
    
    kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
        stackdriver-log-forwarder -p \
        '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    stackdriver-log-forwarder Pod が削除されたことを確認して、次のステップに進みます。
  2. 次の DaemonSet をデプロイして、fluent-bit バッファ内の壊れたデータをクリーンアップします。
    
kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
  3. 次のコマンドを使用して、DaemonSet がすべてのノードをクリーンアップしたことを確認します。
    
kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l \
    app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig KUBECONFIG -n \
    kube-system get pods -l \
    app=fluent-bit-cleanup --no-headers | wc -l
    2 つのコマンドの出力は、クラスタ内のノード数と同じになります。
  4. クリーンアップの DaemonSet を削除します。 
    
kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
  5. ログ フォワーダー Pod を再起動します。 
    
kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset \
    stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
ロギングとモニタリング 1.10, 1.11, 1.12, 1.13

Cloud Monitoring で不明な指標データ

バージョン 1.10.x の Cloud Monitoring のデータには、次のような無関係なサマリー指標エントリが含まれている場合があります。


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

これらのサマリータイプの指標は指標リストに含まれていますが、現時点では gke-metrics-agent ではサポートされていません。
ロギングとモニタリング 1.10, 1.11

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

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

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

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

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

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

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


ip route show

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

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

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

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

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

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


回避策

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

並列接続が多すぎる NAT のエラー

クラスタ内の特定のノードでは、ノードの IP アドレスによって、クラスタ外のアドレスにルーティングされるパケットに対してネットワーク アドレス変換（NAT）が提供されます。同様に、受信パケットがバンドル型ロード バランシング（spec.loadBalancer.mode: bundled）を使用するように構成されたロード バランシング ノードに入ると、送信元ネットワーク アドレス変換（SNAT）により、バックエンド Pod に転送される前にノード IP アドレスにパケットがルーティングされます。

Anthos clusters on bare metal が使用する NAT のポート範囲は 32768～65535 です。この範囲により、並列接続の数はそのノードのプロトコルあたり 32,767 に制限されます。接続ごとに conntrack テーブルのエントリが必要です。有効期間が短い接続数が多すぎると、conntrack テーブルが NAT のポートを使い果たします。ガベージ コレクタは古いエントリをクリーンアップしますが、クリーンアップは直ちには行われません。

ノード上の接続数が 32,767 に近づくと、NAT を必要とする接続のパケット ドロップが発生し始めます。

この問題を特定するには、問題のあるノードの anetd Pod で次のコマンドを実行します。


kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

次の形式のエラーが表示されます。


No mapping for NAT masquerade DROPPED

回避策

トラフィックを他のノードに再分散します。
ネットワーキング 1.10, 1.11, 1.12, 1.13

レイヤ 2 ロード バランシングがバンドルされたクライアント ソース IP

外部トラフィック ポリシーを Local に設定すると、バンドルされたレイヤ 2 ロード バランシングに No route to host などのルーティング エラーが発生する可能性があります。外部トラフィック ポリシーは、デフォルトで Cluster（externalTrafficPolicy: Cluster）に設定されています。この設定では、Kubernetes がクラスタ全体のトラフィックを処理します。LoadBalancer または NodePort のタイプの Service は、externalTrafficPolicy: Local を使用してクライアントの送信元 IP アドレスを保持できます。ただし、この設定では、Kubernetes はノードローカルのトラフィックのみを処理します。


回避策

クライアントの送信元 IP アドレスを保持する場合は、サービス IP に到達できるようにするために、追加の構成が必要になることがあります。構成の詳細については、バンドルされたロード バランシングの構成に記載されているクライアントの送信元 IP アドレスの保持をご覧ください。
ネットワーキング 1.10, 1.11, 1.12, 1.13

firewalld の変更で Cilium iptable ポリシー チェーンが消去される

CentOS または Red Had Enterprise Linux（RHEL）で firewalld を有効にしてベアメタル版 Anthos クラスタを実行している場合は、firewalld を変更すると、ホスト ネットワーク上の Cilium iptables チェーンが削除される場合があります。この iptables チェーンは、起動時に anetd Pod によって追加されます。Cilium の iptables チェーンが失なわれると、Node 上の Pod は、Node 外部のネットワーク接続を失います。

iptables チェーンが削除される firewalld の変更には、次に挙げるものがありますが、これに限定されません。

  • systemctl を使用した firewalld の再起動
  • コマンドライン クライアント（firewall-cmd --reload）を使用した firewalld の再読み込み

回避策

ノードで anetd を再起動します。anetd は、次のコマンドを使用して anetd Pod を見つけて削除することで再起動します。


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

ANETD_XYZ は、anetd Pod の名前で置き換えます。
ネットワーキング 1.10, 1.11, 1.12, 1.13

egressSourceIP アドレスの重複

下り（外向き）NAT ゲートウェイ機能のプレビューを使用する場合、別の EgressNATPolicy オブジェクトに対してすでに使用されている egressSourceIP アドレスを指定するトラフィック選択ルールを設定できます。これにより、下り（外向き）トラフィック ルーティングの競合が発生する可能性があります。


回避策

開発チームと連携し、EgressNATPolicy カスタム リソースで egressSourceIP アドレスを指定する前に、使用可能なフローティング IP アドレスを決定します。
ネットワーキング 1.10, 1.11, 1.12, 1.13

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

ベアメタル版 Anthos クラスタは、ソースの検証を無効にするために、ノードでリバースパス フィルタリングを構成します（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 に戻すか、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 の名前で置き換えます。
ネットワーキング 1.10, 1.11, 1.12, 1.13

ブートストラップ（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.11

GA カーネルでの Ubuntu 18.04.6 との非互換性

Anthos clusters on bare metal バージョン 1.11.0 と 1.11.1 は、GA カーネルの Ubuntu 18.04.6（4.15.0-144-generic～4.15.0-176-generic）と互換性がありません。この非互換性により、ネットワーク エージェントが、anetd ログで「BPF Program is too large」というエラーでクラスタ ネットワークの構成に失敗します。Pod のイベントログに、networkPlugin cni failed to set up pod エラーで Pod が ContainerCreating ステータスで停止することがあります。この問題は、Ubuntu ハードウェア有効化（HWE）カーネルには適用されません。


回避策

HWE カーネルを取得して、Ubuntu 18.04 用のサポートされている最新の HWE バージョンにアップグレードすることをおすすめします。
オペレーティング システム 1.10, 1.11, 1.12, 1.13

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

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


回避策
オペレーティング システム 1.10, 1.11, 1.12, 1.13

オペレーティング システムのエンドポイントの上限

RHEL と CentOS では、クラスタレベルの上限が 100,000 エンドポイントに制限されています。Kubernetes Service2 つのサービスが同一の Pod セットを参照する場合、2 つの別のエンドポイント セットとしてカウントされます。RHEL と CentOS 上の基礎的な nftable 実装には、この制約が存在します。これはベアメタル版 Anthos クラスタの固有の制限ではありません。
セキュリティ 1.10, 1.11, 1.12, 1.13

コンテナが、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, 1.13

Pod の作成中の SELinux エラー

SELinux により、コンテナ ランタイムが tmpfs マウントでラベルを設定できない場合、Pod の作成に失敗することがあります。この失敗はまれですが、SELinux が Enforcing モードで、一部のカーネルにある場合に発生することがあります。

SELinux が Pod 作成の失敗の原因であることを確認するには、次のコマンドを使用して kubelet ログにエラーがあるかどうかを確認します。


journalctl -u kubelet

SELinux によって Pod の作成が失敗すると、コマンドのレスポンスに次のようなエラーが含まれます。


error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied

この問題が SELinux の強制適用に関連していることを確認するには、次のコマンドを実行します。


ausearch -m avc

このコマンドは、監査ログでアクセス ベクトル キャッシュ（AVC）権限エラーを検索します。次のサンプル レスポンスの avc: denied は、Pod の作成エラーが SELinux の適用に関連していることを確認します。


type=AVC msg=audit(1627410995.808:9534): avc:  denied { associate } for pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492 scontext=system_u:object_r: container_file_t:s0:c61,c201 tcontext=system_u: object_r:locale_t:s0 tclass=filesystem permissive=0

SELinux でのこの Pod 作成の問題の根本的な原因は、次の Linux イメージにあるカーネル バグです。

  • 8.3 より前の Red Hat Enterprise Linux（RHEL）リリース
  • 8.3 より前の CentOS リリース

回避策

マシンを再起動すると、問題からの回復に役立ちます。

Pod 作成エラーの発生を防止するには、カーネルのバグを修正した RHEL 8.3 以降または CentOS 8.3 以降を使用してください。
リセット / 削除 1.10、1.11、1.12

Namespace の削除

Namespace を削除すると、新しいリソースをその Namespace に作成されることが妨げれられ、そうしたリソースにはマシンをリセットするジョブも含まれます。


回避策

ユーザー クラスタを削除する場合は、まず、クラスタ オブジェクトを削除した後、Namespace を削除する必要があります。そうしないと、マシンをリセットするジョブが作成できず、削除プロセスではマシンのクリーンアップ手順が省略されます。
リセット / 削除 1.10, 1.11, 1.12, 1.13

containerd サービス

bmctl reset コマンドで、containerd 構成ファイルやバイナリが削除されません。containerd systemd サービスは、起動されたまま実行し続けます。このコマンドでは、ノードにスケジュールされた Pod を実行するコンテナを削除します。
アップグレードと更新 1.10、1.11、1.12

Node Problem Detector が、クラスタのアップグレード後にデフォルトで有効になっていない

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


回避策:

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

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

root 以外のログインを使用するとクラスタのバックアップが失敗する

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


回避策:

この問題は、Anthos clusters on bare metal の 1.9.x、1.10.0、1.10.1 に適用され、バージョン 1.10.2 以降で修正されています。
ネットワーキング 1.10、1.11、1.12

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

バックエンド ポッドがコントロール プレーン ノードで実行され、かつコンテナの仕様で hostNetwork: true フィールドを使用している場合、LoadBalancer Service でパケットが破棄される anetd のバグがあります。

バグはバージョン 1.13 以降には含まれていません。


回避策:

hostNetwork Pod でサポートされる LoadBalancer Service を使用する場合は、次の回避策をお勧めします。

  1. コントロール プレーン ノードではなくワーカーノードで実行する
  2. Service 仕様で externalTrafficPolicy: local を使用し、ワークロードがロードバランサ ノードで実行されるようにする
アップグレードと更新 1.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 is not a valid feature name.
...

回避策:

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

  1. 管理ワークステーションで次のコマンドを実行します。
    
echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
  2. クラスタのアップグレードを再試行します。
さらにサポートが必要な場合は、Google サポートにお問い合わせください。