バージョン 1.6。このバージョンは現在サポートされていません。詳細については、バージョンのサポートポリシーをご覧ください。バージョン 1.7 にアップグレードする方法については、1.7 ドキュメントのベアメタル版 Anthos のアップグレードをご覧ください。

利用可能なサポートされているバージョン: 1.13 | 1.12 | 1.11

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

インストール

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

コントロールグループ v2（cgroup v2）は、ベアメタル版 Anthos クラスタ 1.6 と互換性がありません。Kubernetes 1.18 では cgroup v2 はサポートされていません。また、Docker は、20.10 以降は試験運用版のサポートのみを提供しています。systemd はバージョン 247.2-2 では、デフォルトで cgroup v2 に切り替えられました。/sys/fs/cgroup/cgroup.controllers の存在は、システムで cgroup v2 が使用されていることを意味します。

ベアメタル版 Anthos クラスタ 1.6.2 を起動すると、プリフライトチェックにより、クラスタマシンで cgroup v2 が使用されていないことが確認されます。

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

高可用性（HA）クラスタのインストール中に、etcdserver leader change に関するエラーが表示されることがあります。このエラーメッセージは無害なもので、無視してかまいません。

クラスタのインストールに bmctl を使用すると、create-cluster.log の一番最後に Log streamer failed to get BareMetalMachine のログメッセージが表示されます。このエラーメッセージは無害なもので、無視して構いません。

クラスタ作成ログを調査すると、クラスタの登録または Webhook の呼び出しに関する一時的なエラーが見つかる場合があります。インストールではこうした操作を成功するまで再試行するため、これらのエラーは無視しても問題ありません。

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

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

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

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

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

Docker サービス

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

アップグレードと更新

ベアメタル版 Anthos クラスタ 1.6.x リリースでのアップグレードはできません。

`.manifests` ディレクトリがない場合、`bmctl update cluster` は失敗します。

bmctl update cluster を実行する前に .manifests ディレクトリが削除された場合、コマンドは次のようなエラーで失敗します。

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

最初に bmctl check cluster を実行すると、この問題を修正できます。これにより、.manifests ディレクトリが再作成されます。

この問題は、Anthos clusters on bare metal 1.10 以前に適用され、バージョン 1.11 以降で修正されています。

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

bmctl update コマンドでは、クラスタリソース構成の maintenanceBlocks セクションを削除や変更をすることはできません。メンテナンスモードでノードを削除する手順などの詳細については、ノードをメンテナンスモードにするをご覧ください。

オペレーション

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

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

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

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

以下を置き換えます。

ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
USER_CLUSTER_NAME: 確認するユーザークラスタの名前。

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

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-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 ファイルのパスに置き換えます。レスポンスで、ユーザークラスタのノードの詳細が返されます。クラスタのマシン名が正しいことを確認します。
次のコマンドを実行して、管理クラスタ内の壊れた 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

リセット / 削除

ユーザークラスタ認証情報

bmctl reset コマンドは、クラスタ構成ファイル中の最上位の認証情報セクションを使用します。ユーザークラスタの場合、ファイルを手動で更新して、この認証情報セクションを追加する必要があります。

マウントポイントと `fstab`

リセットによって、/mnt/anthos-system と /mnt/localpv-share/ の下のマウントポイントがマウント解除されることはありません。また、リセットによって、/etc/fstab の対応するエントリはクリーンアップされません。

Namespace の削除

Namespace を削除すると、新しいリソースをその Namespace に作成されることが妨げれられ、そうしたリソースにはマシンをリセットするジョブも含まれます。ユーザークラスタを削除する場合は、まず、クラスタオブジェクトを削除した後、Namespace を削除する必要があります。そうしないと、マシンをリセットするジョブが作成できず、削除プロセスではマシンのクリーンアップ手順が省略されます。

セキュリティ

クラスタ CA / 証明書はアップグレード中にローテーションされます。現在、オンデマンドローテーションサポートは利用できません。

ベアメタル版 Anthos クラスタは、kubelet 提供の証明書を自動的にローテーションします。各 kubelet ノードエージェントは、証明書の有効期限が近くなると、証明書署名リクエスト（CSR）を送信できます。この CSR は、管理クラスタ内のコントローラで検証し、承認されます。

ネットワーキング

レイヤ 2 負荷分散がバンドルされたクライアントソース IP

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

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

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 の名前で置き換えます。

ブートストラップ（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 に渡して別の値を指定します。

異なるクラスタ間での IP アドレスの重複

異なるクラスタ間で重複する IP アドレスを検証するプリフライトチェックはありません。

ベアメタル版 Anthos クラスタの `hostport` 機能

現在、ContainerPort の hostport 機能は、サポートされていません。

OS

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

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

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

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

構成

コントロールプレーンとロードバランサの仕様

コントロールプレーンとロードバランサのノードプールの仕様は、特別なものです。これらの仕様で、重要なクラスタリソースが宣言され管理されます。そのリソースの原本が、クラスタ構成ファイルのそれぞれのセクションです。

spec.controlPlane.nodePoolSpec
spec.LoadBalancer.nodePoolSpec

したがって、トップレベルのコントロールプレーンとロードバランサのノードプールリソースは、直接変更しないでください。代わりに、クラスタ構成ファイル内の関連するセクションを変更してください。

クラスタとノードプール仕様の変更可能なフィールド

現在、クラスタを作成すると、クラスタ構成ファイルの次のクラスタ仕様フィールドとノードプール仕様フィールドのみを更新できます（これが変更可能なフィールドです）。

Cluster オブジェクト（kind: Cluster）の場合は、次のフィールドが変更可能です。
- spec.anthosBareMetalVersion
- spec.bypassPreflightCheck
- spec.controlPlane.nodePoolSpec.nodes
- spec.loadBalancer.nodePoolSpec.nodes
- spec.maintenanceBlocks
- spec.nodeAccess.loginUser
NodePool オブジェクト（kind: NodePool）の場合は、次のフィールドが変更可能です。
- spec.nodes

ノードに `NotReady` ステータスが表示されています

特定の負荷条件下では、ベアメタル 1.6.x ノードの Anthos クラスタは、Pod Lifecycle Event Generator（PLEG）が異常であるため、NotReady ステータスが表示されることがあります。ノードのステータスには次のエントリが含まれます。

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

この影響を受けるかどうかを確認するにはどうしたらよいですか？

この問題の考えられる原因は、runc バイナリバージョンです。問題のあるバージョンがインストールされているかどうかを確認するには、SSH を使用していずれかのクラスタマシンに接続し、次のコマンドを実行します。

/usr/bin/runc -v

出力が 1.0.0-rc93 の場合は、問題のあるバージョンがインストールされています。

考えられる回避策

この問題を解決するには、ベアメタル 1.7.0 の Anthos クラスタへのアップグレードをおすすめします。

アップグレードができない場合は、問題となっているノードマシンの containerd.io パッケージを以前のバージョンに戻すことができます。これを行うには、SSH を使用してノードマシンに接続し、次のコマンドを実行します。

Ubuntu

apt install containerd.io=1.4.3-1

CentOS/RHEL

dnf install containerd.io-1.3.9-3.1.el8.

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

インストール

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

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

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

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