これらのエラーは、ノードのリソースを原因とする強制排除イベント、または Pod のスケジューリング不能を示しています。Anthos Network Gateway Pod には PriorityClass がないため、他のワークロードと同じデフォルトの優先度が設定されます。
ノードにリソースの制約があると、ネットワーク ゲートウェイ Pod が強制排除される場合があります。この動作は ang-node DaemonSet では特にうまくいきません。これらの Pod は特定のノードでスケジュールする必要があり、移行できないためです。
回避策:
1.15 以降にアップグレードします。
短期的な修正として、PriorityClass を Anthos Network Gateway コンポーネントに手動で割り当てることができます。Anthos clusters on bare metal のコントローラは、クラスタのアップグレード中など、調整プロセス中にこれらの手動の変更を上書きします。
...
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]
[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
この問題は、Anthos clusters on bare metal バージョン 1.14.2 以降で修正されています。
kind クラスタ内でクラスタを作成している間、次のようなイメージの pull エラーのため、gke-metrics-agent Pod が起動しません。
error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
また、ブートストラップ クラスタの containerd ログに次のエントリが表示されます。
Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Pod に次の「failing to pull」エラーが表示されます。
gcr.io/gke-on-prem-staging/gke-metrics-agent
回避策
kind クラスタ内での gke-metrics-agent Pod の目的は、クラスタ作成の成功率を促進することと、内部トラッキングとモニタリングであるため、エラーにもかかわらず、クラスタ作成プロセスはブロックされません。
そのため、このエラーは無視してください。
回避策
kind クラスタ内での gke-metrics-agent Pod の目的は、クラスタ作成の成功率を促進することと、内部トラッキングとモニタリングであるため、エラーにもかかわらず、クラスタ作成プロセスはブロックされません。
そのため、このエラーは無視してください。
オペレーション、ネットワーキング
1.12, 1.13, 1.14, 1.15
IPv6 Service エンドポイントにアクセスすると、CentOS または RHEL の LoadBalancer ノードがクラッシュする
ノードを再起動した後、NodePort または LoadBalancer Service の断続的な接続問題が発生することがあります。たとえば、断続的な TLS handshake または接続リセットエラーが発生することがあります。この問題は、Anthos clusters on bare metal バージョン 1.14.1 以降で修正されています。
この問題の影響を受けているかどうかを確認するには、影響を受ける Service のバックエンド Pod が実行されているノードの iptables 転送ルールを確認します。
[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")
この問題は、Anthos clusters on bare metal リリース 1.12.9、1.13.6、1.14.3、およびそれ以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 を使用しています。この問題は、Anthos clusters on bare metal の以前のすべてのバージョンに影響します。
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")
外部ピアが多数のルート（約 100 以上）をアドバタイズすると、Anthos clusters on bare metal の高度なネットワークは BGP セッションを正しく管理できません。受信ルートが多い場合、ノードローカルの BGP コントローラは BGP セッションの調整に時間がかかり、ステータスを更新できません。ステータス更新、またはヘルスチェックがないと、セッションは古くなっているため削除されます。
Anthos clusters on bare metal バージョン 1.14.2 以降では、AddOnConfiguration を使用して受信ルートを処理する機能を無効にすることもできます。--disable-received-routes 引数を ang-daemon DaemonSet の bgpd コンテナに追加します。
ネットワーキング
1.14, 1.15
conntrack テーブル挿入エラーによるアプリケーション タイムアウト
カーネル 5.15 以降を使用している Ubuntu OS で実行されているクラスタは、netfilter 接続トラッキング（conntrack）テーブルの挿入エラーの影響を受けやすくなります。conntrack テーブルに新しいエントリを格納するスペースがあっても、挿入エラーが発生する場合があります。この障害は、チェーン長に基づいてテーブルの挿入を制限するカーネル 5.15 以降の変更が原因で発生します。
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
多数のノードを持つ Anthos clusters 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"]}
回避策:
この問題は、Anthos clusters on bare metal バージョン 1.13.4 以降で解決されています。
Anthos clusters on bare metal の Edge クラスタでは、metrics-server の CPU 上限を低く設定すると、metrics-server が頻繁に再起動される場合があります。metrics-server が異常であるため、水平 Pod 自動スケーリング（HPA）は機能しません。
metrics-server の CPU 上限が 40m 未満の場合、クラスタが影響を受ける可能性があります。metrics-server の CPU の上限を確認するには、次のいずれかのファイルを確認します。
次の例に示すように、--config-dir=/etc/config の行を削除して CPU の上限値を増やします。
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase 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
hostNetwork Pod への NodePort の直接接続が機能しない
NodePort Service による hostNetwork が有効な Pod への接続は、バックエンド Pod がターゲット NodePort と同じノード上にある場合、失敗します。この問題は、hostNetwork された Pod で使用する LoadBalancer Service に影響します。複数のバックエンドを使用すると、散発的な接続障害が発生する可能性があります。
この問題は、eBPF プログラムのバグが原因で発生します。
回避策:
Nodeport Service を使用する場合は、バックエンド Pod が実行されるノードをターゲットにしないでください。LoadBalancer Service を使用する場合は、hostNetwork された Pod が LoadBalancer ノードで実行されないようにしてください。
クラスタで 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 を再起動できます。この問題の再発を回避するには、Anthos clusters on bare metal 1.14.1 以降にアップグレードします。
オペレーション
1.13, 1.14.0, 1.14.1
gke-metrics-agent に、Edge プロファイル クラスタに対するメモリ上限がない
クラスタのワークロードによっては、gke-metrics-agent が 4, 608 MiB を超えるメモリを使用する場合があります。この問題は、Anthos clusters on bare metal の Edge プロファイル クラスタにのみ影響します。デフォルトのプロファイル クラスタには影響しません。
マルチ 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
Node Problem Detector が 1.10.4 ユーザー クラスタで失敗する
Anthos clusters on bare metal 1.11.0、1.11.1、1.11.2 の管理クラスタが 1.10.x ユーザー クラスタを管理している場合、Anthos clusters on bare metal ユーザー クラスタ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 のチャーンが高い期間にクラスタでネットワークが不安定になることがあります。
クラスタが影響を受ける場合、クラスタに新しいノードを追加し、使用可能な podCIDR がないと、anetd Pod は次のエラーを報告します。
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
オペレーション、Anthos VM ランタイム
1.11, 1.12, 1.13, 1.14, 1.15
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, ...
マネージド コレクション コンポーネントは Managed Service for Prometheus の一部です。
バージョン 1.11 Anthos clusters の gmp-system 名前空間にマネージド コレクション コンポーネントを手動でデプロイした場合、バージョン 1.12 にアップグレードすると、関連するリソースは保持されません。
Anthos clusters on bare metal バージョン 1.12.0 以降、gmp-system 名前空間内の Managed Service for Prometheus コンポーネントと関連するカスタム リソース定義は、enableGMPForApplications フィールドで stackdriver-operator によって管理されます。enableGMPForApplications フィールドはデフォルトの true に設定されているため、バージョン 1.12 にアップグレードする前に名前空間に Managed Service for Prometheus コンポーネントを手動でデプロイすると、stackdriver-operator によってリソースが削除されます。
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.
クラスタが、コンテナ ランタイムとして containerd を使用するように構成されている（Anthos clusters on bare metal バージョン 1.15 のデフォルトであるクラスタ構成ファイルで nodeConfig.containerRuntime が containerd に設定されている）。
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
[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
Anthos VM ランタイムが有効になっていると、クラスタをバージョン 1.12.0 以降にアップグレードできない
Anthos clusters on bare metal リリース 1.12.0 では、Anthos VM ランタイムの GA リリースを適切にサポートするために、Anthos VM ランタイムに関連するすべてのリソースが vm-system 名前空間に移行されます。Anthos VM ランタイムがバージョン 1.11.x 以前のクラスタで有効になっている場合は、最初に 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
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
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 が予期せずノードを閉鎖解除しません。
USER_CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、Anthos clusters on bare metal のクラスタの名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、デフォルトの名前空間は cluster-test になります。
ユーザー クラスタ kubeconfig ファイルを見つけます。Anthos clusters on bare metal は、クラスタの作成時に管理ワークステーションに kubeconfig ファイルを生成します。デフォルトでは、このファイルは bmctl-workspace/USER_CLUSTER_NAME ディレクトリにあります。
[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'
回避策:
回避策を表示する
Anthos clusters on bare metal をバージョン 1.11.0 以降にアップグレードします。
[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
バンドルされた 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
metrics-server-config への編集が保持されない
Pod の密度が高いと、極端な場合、ロギングとモニタリングのオーバーヘッドが過剰になり、Metrics Server が停止して再起動する可能性があります。Metrics Server を実行し続けるために、metrics-server-config ConfigMap を編集してより多くのリソースを割り当てることができます。ただし、調整により、metrics-server-config に対して行われた編集がクラスタの更新またはアップグレード オペレーション中にデフォルト値に戻されることがあります。Metrics Server は直ちに影響を受けませんが、次に再起動したときに、元に戻された ConfigMap が取得され、再び過剰なオーバーヘッドが発生する可能性があります。
いくつかの Anthos 指標がサーポート終了になっており、Anthos clusters on bare metal リリース 1.11 以降、これらのサポートが終了した指標のデータは収集されなくなりました。これらの指標をいずれかのアラート ポリシーで使用する場合、アラート条件をトリガーするデータはありません。
1.11 より前の Anthos clusters 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] に移動
[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
Anthos clusters on bare metal バージョン 1.12.x では、ユーザー クラスタ内のネットワーキング カスタム リソースを手動で編集できます。Anthos clusters on bare metal は、クラスタのアップグレード時に、ユーザー クラスタ内のカスタム リソースと管理クラスタのカスタム リソースを調整します。この調整は、ユーザー クラスタのネットワーク カスタム リソースに直接行われた編集内容を上書きします。ネットワーキング カスタム リソースは管理クラスタでのみ変更する必要がありますが、Anthos clusters on bare metal バージョン 1.12.x ではこの要件は適用されません。
ユーザー クラスタ上で前述のカスタム リソースのいずれかを変更した場合は、管理クラスタ上の対応するカスタム リソースをアップグレード前に変更します。この手順により、構成の変更内容が確実に保持されます。Anthos clusters on bare metal バージョン 1.13.0 以降では、ユーザー クラスタのネットワーキング カスタム リソースを直接変更することはできません。
ネットワーキング
1.11, 1.12, 1.13, 1.14, 1.15
並列接続が多すぎる NAT のエラー
クラスタ内の特定のノードでは、ノードの IP アドレスによって、クラスタ外のアドレスにルーティングされるパケットに対してネットワーク アドレス変換（NAT）が提供されます。同様に、受信パケットがバンドル型ロード バランシング（spec.loadBalancer.mode:
bundled）を使用するように構成されたロード バランシング ノードに入ると、送信元ネットワーク アドレス変換（SNAT）により、バックエンド Pod に転送される前にノード IP アドレスにパケットがルーティングされます。
Anthos clusters on bare metal が使用する NAT のポート範囲は 32768～65535 です。この範囲により、並列接続の数はそのノードのプロトコルあたり 32,767 に制限されます。接続ごとに conntrack テーブルのエントリが必要です。有効期間が短い接続数が多すぎると、conntrack テーブルが NAT のポートを使い果たします。ガベージ コレクタは古いエントリをクリーンアップしますが、クリーンアップは直ちには行われません。
外部トラフィック ポリシーを 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, 1.14, 1.15
firewalld の変更で Cilium iptable ポリシー チェーンが消去される
CentOS または Red Had Enterprise Linux（RHEL）で firewalld を有効にしてベアメタル版 Anthos クラスタを実行している場合は、firewalld を変更すると、ホスト ネットワーク上の Cilium iptables チェーンが削除される場合があります。この iptables チェーンは、起動時に anetd Pod によって追加されます。Cilium の iptables チェーンが失なわれると、Node 上の Pod は、Node 外部のネットワーク接続を失います。
Pod の接続を復元するには、net.ipv4.conf.all.rp_filter を手動で 0 に戻すか、anetd Pod を再起動して net.ipv4.conf.all.rp_filter を 0 に戻します。anetd Pod を再起動するには、次のコマンドを使用して anetd Pod を見つけて削除します。新しい anetd Pod が代わりに開始されます。
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）カーネルには適用されません。
2020 年 12 月、CentOS コミュニティと Red Hat は CentOS の開発およびサポートの終了を発表しました。2022 年 1 月 31 日に CentOS 8 はサポート終了（EOL）となりました。EOL の結果として、yum リポジトリが CentOS で機能しなくなり、クラスタの作成とクラスタのアップグレードのオペレーションが失敗するようになりました。これは、CentOS のすべてのサポートされているバージョンに適用され、Anthos clusters 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-*
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
[ダッシュボード] を選択し、[Anthos clusters ノード ステータス] ダッシュボードを削除します。