ネットワーキング、オペレーション
1.10, 1.11, 1.12, 1.13, 1.14
優先度クラスがないため、Anthos Network Gateway コンポーネントが強制排除される、または保留中になる
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 のスケジューリング不能を示しています。Anthos Network Gateway Pod には PriorityClass がないため、他のワークロードと同じデフォルトの優先度が設定されます。
ノードにリソースの制約があると、ネットワーク ゲートウェイ Pod が強制排除される場合があります。この動作は ang-node DaemonSet では特に良好ではない状態になります。これらの Pod は特定のノードでスケジュールする必要があり、移行できないためです。
回避策:
1.15 以降にアップグレードします。
短期的な修正として、PriorityClass を Anthos Network Gateway コンポーネントに手動で割り当てることができます。ベアメタル版 Anthos クラスタのコントローラは、クラスタのアップグレード中など、調整プロセス中にこれらの手動の変更を上書きします。
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 へのアップグレードが失敗します。クラスタの作成とアップグレードのオペレーション中に、Anthos clusters 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この問題は、Anthos clusters on bare metal バージョン 1.14.2 以降で修正されています。
回避策:
クラスタをバージョン 1.15.x にアップグレードする前に、バージョン 1.14.2 以降にアップグレードできない場合は、ブートストラップ クラスタを使用してバージョン 1.15.x に直接アップグレードできます。
bmctl upgrade cluster --use-bootstrap= true
オペレーション
1.15
バージョン 1.15 クラスタは、重複するフローティング IP アドレスを受け入れない
Anthos Network Gateway では、既存の NetworkGatewayGroup カスタム リソースですでに使用されている spec.floatingIPs の IP アドレスを含む新しい NetworkGatewayGroup カスタム リソースを作成できません。このルールは、Anthos clusters 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 リソースのみが調整ツールによって認識されました。Anthos 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
変更を適用するには、編集したカスタム リソースを閉じて保存します。
Anthos VM ランタイム
1.13.7
非公開レジストリを使用する 1.13.7 クラスタで VM が起動しない場合がある
プライベート レジストリを使用する新規またはアップグレードされたバージョン 1.13.7 のクラスタで Anthos VM Runtime を有効にすると、ノード ネットワークに接続する、または GPU を使用する VM が正しく起動しない場合があります。この問題は、vm-system 名前空間の一部のシステム Pod で、イメージの pull エラーが発生することが原因です。たとえば、VM でノード ネットワークを使用している場合、一部の Pod では以下のようなイメージの pull エラーが報告されることがあります。
macvtap-4x9zp 0 /1 Init:ImagePullBackOff 0 70m
この問題は、Anthos clusters on bare metal バージョン 1.14.0 以降で修正されています。
回避策
クラスタをすぐにアップグレードできない場合は、手動でイメージを pull できます。次のコマンドは、VM の macvtap CNI プラグイン イメージを pull し、非公開レジストリに push します。
docker pull \
gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
REG_HOST /anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
REG_HOST /anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
REG_HOST
インストール
1.11, 1.12
kind クラスタでのクラスタ作成中に、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 bmc tl - co ntr ol - pla ne co nta i ner d [ 198 ]: t ime= "2022-09-13T23:54:20.378172743Z" level=i nf o msg= "PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23 : 54 : 21 bmc tl - co ntr ol - pla ne co nta i ner d [ 198 ]: t ime= "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 - o n - prem - s ta gi n g/gke - me tr ics - age nt 回避策
kind クラスタ内での gke-metrics-agent Pod の目的は、クラスタ作成の成功率を促進することと、内部トラッキングとモニタリングであるため、エラーにもかかわらず、クラスタ作成プロセスはブロックされません。
そのため、このエラーは無視して問題ありません。
回避策
kind クラスタ内での gke-metrics-agent Pod の目的は、クラスタ作成の成功率を促進することと、内部トラッキングとモニタリングであるため、エラーにもかかわらず、クラスタ作成プロセスはブロックされません。
そのため、このエラーは無視して問題ありません。
オペレーション、ネットワーキング
1.12, 1.13, 1.14, 1.15
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 または接続リセットエラーが発生する場合があります。この問題は、Anthos clusters on bare metal バージョン 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 つが保留状態になります。
この問題は、Anthos clusters on bare metal バージョン 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
オペレーション
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
[ 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 の変更を監視しない
これらの問題により、クラスタが機能しなくなる場合があります。
この問題は、Anthos clusters on bare metal リリース 1.12.9、1.13.6、1.14.3、およびそれ以降のリリースで修正されています。これらの新しいリリースでは、etcd バージョン 3.4.21 を使用しています。この問題は、Anthos clusters on bare metal の以前のすべてのバージョンに影響します。
回避策
すぐにアップグレードできない場合は、クラスタ内のノード数を減らすことで、クラスタの障害のリスクを軽減できます。etcd_network_client_grpc_sent_bytes_total 指標が 300 MBps 未満になるまでノードを削除します。
Metrics Explorer でこの指標を表示するには:
Google Cloud コンソールの Metrics Explorer に移動します。
Metrics Explorer に移動
[Configuration ] タブを選択します。
[指標の選択 ] を展開し、フィルタバーに「Kubernetes Container」と入力してから、サブメニューを使用して指標を選択します。
[有効なリソース ] メニューで、[Kubernetes Container ] を選択します。
[アクティブな指標カテゴリ ] メニューで、[Anthos ] を選択します。
[アクティブな指標 ] メニューで etcd_network_client_grpc_sent_bytes_total を選択します。
[適用] をクリックします。
ネットワーキング
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 オブジェクトのステータスが「Failed」の場合は、Anthos clusters on bare metal バージョン 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
受信ルートが多数存在するため BGPSession の状態が常に変化する
外部ピアが多数のルート（約 100 以上）をアドバタイズすると、Anthos clusters 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
回避策:
エクスポート ポリシーで、リモートピアからクラスタにアドバタイズされるルートの数を減らすか、なくします。
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 以降の変更が原因です。
この問題の影響を受けるかどうかを確認するには、次のコマンドでカーネル内の接続トラッキング システムの統計情報を確認します。
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
リセット / 削除
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 CLUSTER_NAMESPACE
インストール
1.13.1, 1.13.2, 1.13.3
トークンの不一致が原因で、大規模なクラスタで kubeadm join が失敗する
多数のノードを持つ 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 以降で解決されています。
影響を受けるバージョンを使用する必要がある場合は、まず 20 ノード未満のクラスタを作成し、インストールが完了した後にクラスタのサイズを変更してノードを追加します。
ロギングとモニタリング
1.10, 1.11, 1.12, 1.13.0
Edge クラスタでの metrics-server の CPU 上限が低い
Anthos clusters on bare metal の Edge クラスタでは、metrics-server の CPU 上限を低く設定すると、metrics-server が頻繁に再起動される場合があります。metrics-server が異常であるため、水平 Pod 自動スケーリング（HPA）は機能しません。
metrics-server の CPU 上限が 40m 未満の場合、クラスタが影響を受ける可能性があります。metrics-server の CPU 上限を確認するには、次のいずれかのファイルを確認します。
Anthos clusters on bare metal バージョン 1.x～1.12:
kubectl get deployment metrics-server -n kube-system \
-o yaml > metrics-server.yaml
Anthos clusters on bare metal バージョン 1.13 以降:
kubectl get deployment metrics-server -n gke-managed-metrics-server \
-o yaml > metrics-server.yaml
回避策:
この問題は、Anthos clusters on bare metal バージョン 1.13.1 以降で解決されています。この問題を解決するには、クラスタをアップグレードします。
クラスタをアップグレードできるようになるまでの短期的な回避策は、次のように metrics-server の CPU 上限を手動で増やすことです。
スケールダウン metrics-server-operator
kubectl scale deploy metrics-server-operator --replicas= 0
構成を更新して CPU の上限を引き上げます。
Anthos clusters on bare metal バージョン 1.x～1.12:
kubectl -n kube-system edit deployment metrics-server
Anthos clusters 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><--- 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 ノードで実行されないようにしてください。
アップグレードと更新
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
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
バックログ チャンクの破損が 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 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"}]'
ネットワーキング、Anthos 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 を再起動できます。この問題の再発を回避するには、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 プロファイル クラスタにのみ影響します。デフォルトのプロファイル クラスタには影響しません。
回避策:
クラスタをバージョン 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
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 のチャーンが高い期間にクラスタでネットワークが不安定になる場合があります。
この問題は、65 ～ 128 の範囲外の maxPodsPerNode を使用するアイランド モード IPv4 クラスタにのみ影響します。
クラスタが影響を受ける場合、クラスタに新しいノードを追加し、使用可能な podCIDR がないと、anetd Pod は次のエラーを報告します。
error = "required IPv4 PodCIDR not available" 回避策
次の手順で問題を解決します。
1.14.1 以降のバージョンにアップグレードします。
ワーカーノードを削除してから、追加し直します。
コントロール プレーンノードを削除してから、ノードを追加し直し（1 つずつが望ましい）、クラスタのダウンタイムを回避します。
アップグレードと更新
1.14.0, 1.14.1
クラスタ アップグレードのロールバックの失敗
Anthos clusters on bare metal 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
前の手順でリストしたすべての 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 の Anthos clusters をバージョン 1.14.0 にアップグレードすると、コントロール プレーン ノードは次の必要な taint を失います。
node-role.kubernetes.io/master:NoSchedulenode-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
オペレーション、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 % 0 s
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 にアップグレードすると、関連するリソースは保持されません。
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 によってリソースが削除されます。
回避策
手動で管理するコレクション リソースを保持するには:
既存のすべての 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 が終了してしまう
ベアメタル版 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 回避策
失敗したオペレーションによりアーティファクトが生成されますが、クラスタは動作しません。この問題の影響を受ける場合は、次の手順でアーティファクトをクリーンアップし、クラスタを作成します。
回避策を表示する
クラスタのアーティファクトを削除してノードマシンをリセットするには、次のコマンドを実行します。
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
インストール、Anthos 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 に設定されている。これは Anthos clusters on bare metal バージョン 1.12 のデフォルトである）。
クラスタが、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+rxroot ユーザーが所有し、ディレクトリ内に存在するすべてのファイルを（再帰的に）/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 clusters on bare metal 1.13 以前ではサポートされていません。ただし、バージョン 1.14 では、プレビュー 機能として cgroup v2 がサポートされています。/sys/fs/cgroup/cgroup.controllers の存在は、システムで cgroup v2 が使用されていることを示しています。
回避策
cgroup v2 をシステムで使用している場合は、Anthos clusters on bare metal バージョン 1.14 にアップグレードします。
インストール
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
プリフライト チェックとサービス アカウント認証情報
管理クラスタまたはハイブリッド クラスタによってトリガーされるインストール（つまり、ユーザー クラスタなど、bmctl で作成されていないクラスタ）では、プリフライト チェックは、Google Cloud サービス アカウントの認証情報や、関連付けられている権限を検証しません。
インストール
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
アプリケーションのデフォルト認証情報と bmctl
bmctl は、クラスタ オペレーションのロケーションの値が global に設定されていないときに、アプリケーションのデフォルト認証情報（ADC） を使用して cluster spec でその値を検証します。
回避策
ADC を機能させるには、GOOGLE_APPLICATION_CREDENTIALS 環境変数をサービス アカウント認証情報ファイルに向けるか、gcloud auth application-default login を実行する必要があります。
インストール
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Docker サービス
クラスタ ノードマシンで、Docker 実行可能ファイルが PATH 環境変数に存在し、Docker サービスが有効になっていない場合は、プリフライト チェックで不合格になり、Docker service
is not active が報告されます。
回避策
Docker を削除するか、Docker サービスを有効にします。
インストール
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
vSphere へのインストール
vSphere VM にベアメタル版 Anthos クラスタをインストールする場合は、tx-udp_tnl-segmentation フラグと tx-udp_tnl-csum-segmentation フラグをオフに設定する必要があります。これらのフラグは、vSphere ドライバ VMXNET3 によるハードウェア セグメンテーション オフロードに関連しており、ベアメタル版 Anthos クラスタの GENEVE トンネルでは機能しません。
回避策
各ノードで次のコマンドを実行して、これらのフラグの現在の値を確認します。
ethtool -k NET_INTFC | grep segm NET_INTFC
レスポンスには、次のようなエントリが含まれます。
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
... 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
アップグレードと更新、Anthos VM ランタイム
1.11, 1.12
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
回避策
Anthos VM ランタイムを無効にするには:
VMRuntime カスタム リソースを編集します。
kubectl edit vmruntime 仕様で enabled を false に設定します。
apiVersion : vm.cluster.gke.io/v1
kind : VMRuntime
metadata :
name : vmruntime
spec :
enabled : false
...
カスタム リソースをエディタに保存します。
クラスタのアップグレードが完了したら、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} は問題リソースの名前です。
回避策
ログにこれらのエラーがある場合は、次の手順を完了します。
kubectl edit を使用して、ログ メッセージに含まれるリソースから kubectl.kubernetes.io/last-applied-configuration アノテーションを削除します。変更を保存してリソースに適用します。
クラスタのアップグレードをもう一度行ってください。
アップグレードと更新
1.10、1.11、1.12
Anthos Network Gateway を使用する機能を持つクラスタのアップグレードがブロックされる
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...
回避策
注意: 次の回避策では、マニフェストを削除し、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.13, 1.14, 1.15
ノードが到達不能になると、ノードのドレインを開始できません
ベアメタル版 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 USER_CLUSTER_NAMESPACE cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、デフォルトの名前空間は cluster-test になります。USER_CLUSTER_NAME
出力内のクラスタ名（次のサンプル出力の contexts.context.cluster を参照）が管理クラスタ名である場合は、指定したユーザー クラスタが影響を受けます。
apiVersion : v1
clusters :
- cluster :
certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
server : https://10.200.0.6:443
name : ci-aed78cdeca81874
contexts :
- context :
cluster : ci-aed78cdeca81
user : ci-aed78cdeca81-admin
name : ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context : ci-aed78cdeca81-admin@ci-aed78cdeca81
kind : Config
preferences : {}
users :
- name : ci-aed78cdeca81-admin
user :
client-certificate-data : LS0tLS1CRU...UtLS0tLQo=
client-key-data : LS0tLS1CRU...0tLS0tCg== 回避策
次の手順で、影響を受けるユーザー クラスタ（USER_CLUSTER_NAME
ユーザー クラスタ kubeconfig ファイルを見つけます。Anthos clusters on bare metal は、クラスタの作成時に管理ワークステーションに kubeconfig ファイルを生成します。デフォルトでは、このファイルは bmctl-workspace/USER_CLUSTER_NAME ディレクトリにあります。
この kubeconfig が正しいユーザー クラスタ kubeconfig であることを確認します。
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE PATH_TO_GENERATED_FILE
次のコマンドを実行して、管理クラスタ内の壊れた 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
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 のシンボリック リンクを作成します。
オペレーション、Anthos VM ランタイム
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Anthos VM ランタイム - Pod を再起動すると、Pod 上の VM は IP アドレスを変更するか、IP アドレスが完全に失われます。
VM の IP アドレスが変更されても、Kubernetes サービスとして公開されている VM アプリケーションのネットワーク到達性に影響はありません。
回避策
IP アドレスが失われた場合、VM から dhclient を実行して VM の IP アドレスを取得する必要があります。
ロギングとモニタリング
1.10
コンテナ ランタイム インターフェース（CRI）パーサー が解析時間として誤った正規表現を使用している場合、stackdriver-log-forwarder Pod のログに次のようなエラーと警告が記録されます。
[ 2022 /03/04 17 :47:54] [ error] [ parser] time string length is too long [ 2022 /03/04 20 :16:43] [ warn] [ parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z' 回避策:
回避策を表示する
Anthos clusters on bare metal をバージョン 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
予想外の請求のモニタリング
Anthos clusters on bare metal バージョン 1.10 から最新バージョンでは、[お支払い ] ページで予想外に高い 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
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 ダッシュボードに影響を与える
いくつかの Anthos 指標がサーポート終了になっており、Anthos clusters on bare metal リリース 1.11 以降、これらのサポートが終了した指標のデータは収集されなくなりました。これらの指標をいずれかのアラート ポリシーで使用する場合、アラート条件をトリガーするデータはありません。
次の表に、サポートが終了した個別の指標と、それらに代わる指標を表示します。
サポートが終了した指標
置き換える指標
kube_daemonset_updated_number_scheduledkube_daemonset_status_updated_number_scheduled
kube_node_status_allocatable_cpu_coreskube_node_status_allocatable_memory_byteskube_node_status_allocatable_podskube_node_status_allocatable
kube_node_status_capacity_cpu_coreskube_node_status_capacity_memory_byteskube_node_status_capacity_podskube_node_status_capacity
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] に移動
ナビゲーション パネルで、ダッシュボード ] を選択し、[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
すべての 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
クリーンアップの 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
Cloud Monitoring で不明な指標データ
バージョン 1.10.x の Cloud Monitoring のデータには、次のような無関係なサマリー指標エントリが含まれている場合があります。
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile 無関係なサマリー指標が含まれている可能性があるその他の指標タイプ:
apiserver_admission_step_admission_duration_seconds_summarygo_gc_duration_secondsscheduler_scheduling_duration_secondsgkeconnect_http_request_duration_seconds_summaryalertmanager_nflog_snapshot_duration_seconds_summary
これらのサマリータイプの指標は指標リストに含まれていますが、現時点では gke-metrics-agent ではサポートされていません。
ロギングとモニタリング
1.10, 1.11
指標エクスポートの断続的な中断
Anthos clusters on bare metal では、一部のノードで通常の指標の継続的なエクスポートが中断されたり、指標が欠落したりすることがあります。この問題がクラスタに影響する場合は、少なくとも次の指標でデータのギャップが見られる可能性があります。
kubernetes.io/anthos/container_memory_working_set_byteskubernetes.io/anthos/container_cpu_usage_seconds_totalkubernetes.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
複数のデフォルト ゲートウェイで外部エンドポイントへの接続が切断される
ノードに複数のデフォルト ゲートウェイを使用すると、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 など）では、次のカスタム リソースを使用します。
BGPLoadBalancerBGPPeerNetworkGatewayGroupNetworkAttachmentDefinitionClusterCIDRConfigFlatIPMode
管理クラスタでこうしたカスタム リソースを編集すると、整合化の手順でユーザー クラスタに変更が適用されます。
回避策
ユーザー クラスタ上で前述のカスタム リソースのいずれかを変更した場合は、管理クラスタ上の対応するカスタム リソースをアップグレード前に変更します。この手順により、構成の変更内容が確実に保持されます。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 のポートを使い果たします。ガベージ コレクタは古いエントリをクリーンアップしますが、クリーンアップは直ちには行われません。
ノード上の接続数が 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, 1.14, 1.15
レイヤ 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, 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 外部のネットワーク接続を失います。
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, 1.14, 1.15
egressSourceIP アドレスの重複下り（外向き）NAT ゲートウェイ 機能のプレビューを使用する場合、別の EgressNATPolicy オブジェクトに対してすでに使用されている egressSourceIP アドレスを指定するトラフィック選択ルールを設定できます。これにより、下り（外向き）トラフィック ルーティングの競合が発生する可能性があります。
回避策
開発チームと連携し、EgressNATPolicy カスタム リソースで egressSourceIP アドレスを指定する前に、使用可能なフローティング IP アドレスを決定します。
ネットワーキング
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
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, 1.14, 1.15
ブートストラップ（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, 1.14, 1.15
CentOS でクラスタの作成またはアップグレードの失敗
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-* 長期的な解決策としては、別のサポートされているオペレーティング システム への移行を検討してください。
オペレーティング システム
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
オペレーティング システムのエンドポイントの上限
RHEL と CentOS では、クラスタレベルの上限が 100,000 エンドポイントに制限されています。Kubernetes Service2 つのサービスが同一の Pod セットを参照する場合、2 つの別のエンドポイント セットとしてカウントされます。RHEL と CentOS 上の基礎的な nftable 実装には、この制約が存在します。これは Anthos clusters on bare metal の固有の制限ではありません。
セキュリティ
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
コンテナが、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, 1.14, 1.15
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, 1.14, 1.15
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 を有効にするには:
ノードで node-problem-detector systemd サービスが実行されているかどうかを確認します。
SSH コマンドを使用してノードに接続します。
ノードで 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
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
ロードバランサ サービスが、コントロール プレーン ホスト ネットワーク上のコンテナで機能しない
バックエンド Pod がコントロール プレーン ノードで実行され、かつコンテナの仕様で 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 is not 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'
クラスタのアップグレードをもう一度行います。
[ダッシュボード] を選択し、[Anthos clusters ノード ステータス] ダッシュボードを削除します。